Interlaced video output

[linuxstb]

Hi,

I've written my own openmax video player (a client for tvheadend - https://github.com/linuxstb/pidvbip) and am having problems with interlaced channels.

If I configure my Pi (in config.txt - my app doesn't yet support changing video modes) to 1080i (group 1, mode 20) then play back a 1080i H264 stream, it looks like the decoder isn't correctly syncing the fields to the HDMI output - the output is a lot of flickering. Sometimes, the video will manage to sync itself and play perfectly, but most of the time it is wrong.

I've seen this effect also in omxplayer when playing recordings of these streams.

Does anyone know if this is fixable in my code? Or is this a GPU firmware/codec issue?

Thanks.

[dom]

Sorry, GPU doesn't handle native deinterlace. It is a very complicated issue (what to do when framerate or resolution doesn't precisely match display).
You should use the deinterlace component and set the display to a progressive mode.

[linuxstb]

Thanks for the reply.

Does the GPU handle deinterlacing of HD content now? I thought it was only supported for SD content.

But my main TV only supports 1080i, so in any case deinterlacing on the Pi isn't a universal solution.

You say it's a complicated issue, but what if this functionaility is limited to only the cases when the video matches the HDMI mode exactly. I think that would meet the needs of a lot of users who want to use the Pi to display digital TV.

Or alternatively, I was wondering if there was another way to get synchronised interlaced content out of the Pi? e.g. by using the video_decode component to handle the hard work of decoding, but then rendering the interlaced output using something other than the video_render component?

Thanks.

[dom]

Thanks for the reply.

Does the GPU handle deinterlacing of HD content now? I thought it was only supported for SD content.

But my main TV only supports 1080i, so in any case deinterlacing on the Pi isn't a universal solution.

You say it's a complicated issue, but what if this functionaility is limited to only the cases when the video matches the HDMI mode exactly. I think that would meet the needs of a lot of users who want to use the Pi to display digital TV.

Or alternatively, I was wondering if there was another way to get synchronised interlaced content out of the Pi? e.g. by using the video_decode component to handle the hard work of decoding, but then rendering the interlaced output using something other than the video_render component?

Thanks.

1080i does deinterlace but with a simpler "bob" algorithm.
You would try experimenting with omxplayer and a 1080i stream, and your display in a 1080i mode that matches the framerate.
Add option "-y" (but not "-r").

You may find that 50% of the time, the odd and even fields line up correctly and you get the output you want. If that is the case, then I could look into some way of syncronising the fields.
If that doesn't work 50% of the time, then something mroe complicated is happening, and it may be harder to solve.

[linuxstb]

Hi Dom,

Yes, that's exactly what happens - 50% of the time it's OK, 50% it's out of sync. I see that in my app, and also with omxplayer as you suggested.

It would be great if you could fix this. I've created a 60 second sample file (1080i @ 50Hz) if it helps, which I've been testing with CEA mode 20. I'll PM you the URL.

Thanks,

[0julian]

Hi,

has there been any progress on this? I'd be very interested in proper 1080i output as well. Most TV screens will do a much better job in deinterlacing 1080i than a simple bob algorithm

Regards,
Julian

[BeeblePete]

I too am interested in proper interlaced output. Presumably it's less data to push outward so once the dance is done properly it should perform better than 1080p. Dramas shot and broadcast interlaced and my morning exercise disc come alive in my blu-ray player but are a strobey mess when I play them from LibreELEC.

[dom]

Have a look at command line omxplayer and --nativedeinterlace option. Be aware that is purely an experimental option that will only work in a very limited set of use cases.
Have a read of this thread for some details of the complexities involved.