Got 1080i Live TV Transcoding Working at True 59.94p – Can Emby Support This Natively?

[bzellinger 1]

I've been testing Emby Live TV with an HDHomeRun and 1080i59.94/29.97 MPEG-2 OTA channels.

When these channels have to be transcoded for a browser, Emby currently outputs 1080p29.97. This discards half of the temporal resolution of the original interlaced broadcast and is very noticeable with sports, racing, scrolling text, and camera pans.

I was able to get proper 1080p59.94 output by modifying Emby's generated FFmpeg command.

Emby normally generates CUDA deinterlacing similar to:

yadif_cuda@f1

with:

-r:v:0 29.970029830932617

Changing those to:

yadif_cuda@f1=mode=send_field

and:

-r:v:0 59.940059661865234

produces true field-rate 1080p59.94 output.

I verified this in the FFmpeg transcode log. The output reports 1920x1080 progressive at 59.94 fps, and 3-second HLS segments contain approximately 180 frames. Motion on 1080i sports/racing content is noticeably smoother and looks like properly deinterlaced broadcast television.

I currently accomplish this with a small FFmpeg wrapper that intercepts Emby's generated command and makes those two changes before launching Emby's real FFmpeg. It works reliably with NVIDIA NVDEC/NVENC on an RTX 2080.

It would be great if Emby supported this natively, perhaps with an option such as:

Deinterlacing frame rate

• Same as source frame rate (29.97p/25p)
• Field rate (59.94p/50p)

Or Emby could automatically use field-rate deinterlacing when the client supports the resulting 50/59.94 fps progressive stream.

For NVIDIA/CUDA, yadif_cuda=mode=send_field already appears to provide everything needed. Similar field-rate modes could presumably be used for the other supported hardware/software deinterlacers.

This would make a substantial difference for transcoded 1080i Live TV, particularly sports.

[Luke 43402]

Hi @bzellingercan we please see an ffmpeg log example?

By the way you can also accomplish this with the diagnostics plugin. It has an option to search and replace on the generated ffmpeg command line.

[bzellinger 1]

Thanks for the reply!

I've attached an FFmpeg transcoding log from Emby Server 4.9.5.0 using an NVIDIA RTX 2080. Also attached the wrapper log.

The source is a 1080i MPEG-2 OTA broadcast from an HDHomeRun, being transcoded for playback in Chrome.

I actually tried the Diagnostics plugin first. I was able to change the deinterlacing filter from:

yadif_cuda@f1

to:

yadif_cuda@f1=mode=send_field

However, Emby was still specifying:

-r:v:0 29.970029830932617

This resulted in FFmpeg generating field-rate frames but dropping approximately half of them to maintain the requested 29.97 fps output.

I eventually created a small FFmpeg wrapper that intercepts the generated command and changes both parameters:

Original:

• yadif_cuda@f1

• -r:v:0 29.970029830932617

Modified:

• yadif_cuda@f1=mode=send_field

• -r:v:0 59.940059661865234

This successfully produces 1080p59.94 output.

The attached log confirms:

Video: h264 (High), cuda(tv, progressive), 1920x1080 ... 59.94 fps

It also shows multiple 3-second HLS segments containing 180 frames each, confirming that the higher frame rate is actually being produced.

One thing worth noting: the FFmpeg command shown near the beginning of the log still contains Emby's original parameters because my wrapper modifies them after Emby generates the command. The actual FFmpeg output further down reflects the modified parameters.

The difference is very noticeable with sports and other fast-moving 1080i broadcasts.

Ideally, Emby could handle this natively by selecting field-rate deinterlacing and setting the appropriate output frame rate automatically.

ffmpeg-transcode-ea97914f-fd18-46ee-96c6-30fa0716a4bb_1.txt emby-ffmpeg-wrapper.log