peterbennett
Posts: 3
Joined: Fri Jun 16, 2017 7:45 pm

Advanced and fast deinterlace not working if not tunneled

Tue Jun 20, 2017 3:27 pm

I have been struggling with this for some time. We use OpenMAX for video playback in MythTV. It used to work but at some upgrade point deinterlaced videos started to show jagged edges like they were not being deinterlaced. It either occurred starting with a new raspbian version or maybe started with the RPI3.

My testing shows that advanced and fast deinterlace only work if the input to image_fx is tunneled from a decoder. Is this intentional and is there any way to get it to work with OMX_EmptyThisBuffer calls ?

I created some sample programs that play back video with image_fx advanced deinterlace. I have 3 programs at
https://github.com/bennettpeter/raspber ... nMAX/Video

(il_deint_t1)
decode -> tunnel -> image_fx -> C code that empties and fills buffers -> render

(il_deint_t2) This is how MythTV does it
decode -> C code that empties and fills buffers -> image_fx -> tunnel -> render

(il_deint_t1t2)
decode -> tunnel -> image_fx -> tunnel -> render

il_deint_t1 and il_deint_t1t2 show the video perfectly deinterlaced. il_deint_t2 shows jaggies as it it was not deinterlaced.

These three programs are a bit messy as they are test programs. In particular they take a parameter n to prevent deinterlace but the code to support that is not complete. To build the programs you must first run make in /opt/vc/src/hello_pi/libs/ilclient/.

I have a test file (raw mpeg2) at https://www.dropbox.com/s/82voelqrpvxr5 ... video?dl=1

If you need me to clean up the test program code let me know.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4437
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Advanced and fast deinterlace not working if not tunnele

Tue Jun 20, 2017 4:53 pm

Some indication of when you think this started failing would be useful. You can go backwards with firmware version by using "sudo rpi-update <hash", where the hash is the commit in https://github.com/Hexxeh/rpi-firmware/commits/master

One potential candidate would be https://github.com/Hexxeh/rpi-firmware/ ... d0df7c8d38. That added buffer flags OMX_BUFFERFLAG_INTERLACED and OMX_BUFFERFLAG_TOP_FIELD_FIRST. Without those there is no signalling of which field is which, so I can understand the algorithm going into bypass. I'm not seeing you preserving the nFlags field in il_deint_t2, but I have only had a quick look.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

peterbennett
Posts: 3
Joined: Fri Jun 16, 2017 7:45 pm

Re: Advanced and fast deinterlace not working if not tunnele

Tue Jun 20, 2017 7:12 pm

OK Thank you that solves it.

I added one line and it works now:
pOutHeader->nFlags = buff_header->nFlags

There is a comment for nFlags in the openmax specification "A component
should propagate this field from an input buffer to its associated output buffer." which was not done.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4437
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Advanced and fast deinterlace not working if not tunnele

Tue Jun 20, 2017 8:19 pm

peterbennett wrote:There is a comment for nFlags in the openmax specification "A component
should propagate this field from an input buffer to its associated output buffer." which was not done.
The components do AFAIK. In this case it was the client not doing it ;)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

peterbennett
Posts: 3
Joined: Fri Jun 16, 2017 7:45 pm

Re: Advanced and fast deinterlace not working if not tunnele

Tue Jun 20, 2017 8:23 pm

Yes - that should have been in my code - I added it to MythTV and it works much better now. Thanks for the prompt help with this.

Peter

Return to “OpenMAX”

Who is online

Users browsing this forum: No registered users and 1 guest