Flickering of top line when using deinterlacer

[reufer]

Hi

Since a while I'm observing a flickering of the top image line when using the deinterlacer. Today, I set up a fresh raspian image to test this with current omxplayer but the flickering is visible here as well. I've uploaded a sample of a SD-MPEG2 TS-stream:

http://www.reufer.ch/temp/00001.ts

I'm launching omxplayer with: omxplayer -p -o hdmi -d 00001.ts

With this sample, the whole first line is flickering, sometimes it's only half of the line. With omxplayer there's an additional issue with the rest of the image, but this is not the case with my application.

When disabling the deinterlacer, the first line is fine: omxplayer -p -o hdmi --nodeinterlace 00001.ts

Do you have any solution to get rid of this problem?

Regards, Thomas

[10robinho]

I can confirm this is happening with other streams too on my RPI2.

[reufer]

@popcornmix, did you had a chance to reproduce the issue?

[popcornmix]

I have had a look. The real problem is the video is not actually interlaced but it claims to be. Run omxplayer --nodeinterlace and it looks better. The second problem is the top line of the video is always black. For an interlaced video that means even deinterlaced fields have a black line at the top and odd fields don't. Because the deinterlace routine requires lines of context above and below it can't deinterlace the top and bottom lines the same way we duplicate the top and bottom lines which means you get a double line of black on one field and none on the other field which makes the flickering worse.

I have played with doing the normal deinterlace on the top and bottom lines, but treating the frame as reflected at the top/bottom edges for the context lines and that seems to improve things. That's only a proof of concept and is too slow for HD, but it should be possible to support this efficiently with some more work.

[reufer]

Thanks for the analysis!

So, the broadcast company is actually sending progressive content on a interlaced program? Sounds feasible, since the effect is seen only on certain material. In that case I'd appreciate if you could treat the top line in a way that reduces the flickering. Maybe this could be enabled per parameter? Currently, I use the advanced deinterlacer for SD and fast deinterlacer for HD material, so this workaround could be limitted to the advanced implementation only.

Regards, Thomas

[popcornmix]

Can you try updating firmware (rpi-update) and test again.

[reufer]

Just updated the firmware, but flickering still exists… are there any new parameters I need to set for the deinterlacer? For SD I use advanced deinterlacer: http://projects.vdr-developer.org/git/vdr-plugin-rpihddevice.git/tree/omx.c#n341

BTW: When browsing through the firmware commits, I see many improvements at the deinterlacer component. So it might be very helpful to update the ilcompontens-Documentation contained in this repo, since (at least) I used it quite a lot.

[popcornmix]

The fix only applies to advanced deinterlace. Can you test with latest omxplayer (make sure you have apt-get upgraded it), just in case you have a configuration problem? You can use --advanced with omxplayer to force advanced deinterlace (although it should be a default for SD resolution).

[reufer]

I just copied omxplayer's config to my application and with these parameters the issue is gone. Even the tickers on news channels are now running absolutely smooth - that's great, thanks a lot!

However, could you please add some description of the new parameters to the documentation? I think it's worth to keep the docs in this repo up to date, otherwise others may struggle as well. Or is there still work in progress?

[reufer]

I just observed a problem with omxplayer's deinterlacer config: My application uses OpenVG to draw the OSD on top. When replaying SD material with the advanced deinterlacer, the decoder freezes constantly when I open the OSD. This does not happen when using the fast deinterlacer and it's limitted only to replay, not live TV, where CPU usage is slightly increased.

Could there be a resource problem or a race condition? I have 256MB allocated to the GPU, which should be enough. After the freeze, the application tries to flush the queues, but gets stocked in trying to disable port buffers with ilclient_disable_port_buffers().

There is no additional log with the default level, when setting the level to 64, it looks like this: http://www.reufer.ch/temp/omxlog.txt

Do you seen any obvious issue or is there any other debug information I could provide?

[popcornmix]

OpenVG, OpenGL and the advanced deinterlace all use the v3d hardware so it is possible. Kodi uses OpenGL and advanced deinterlace without problem, but openVG may be the different.

Can you provide an application I can run that shows the problem?

[popcornmix]

also what does vcgencmd version report?

[reufer]

The version is: Nov 18 2015 15:43:45 Copyright (c) 2012 Broadcom version 0c9af7cde38e223c95c3404f468db8fc5004495c (clean) (release)

I'll prepare a small howto to run my application (actually VDR is the application, I just did the plugin to run it on a Rpi) - there are now packets available for Raspbian, so it's easy to setup.

[popcornmix]

Okay, you have this fix: https://github.com/raspberrypi/firmware/commit/591b25a7749027ce095a49d0a515294491dd26fc which might have been relevant.

[reufer]

Here's a short how-to to show the issue with my application. I just tested it with a fresh Raspbian image, latest firmware and 128M of GPU RAM:

get VDR and binary rpihddevice plugin

echo 'deb http://e-tobi.net/vdr-experimental jessie base vdr-multipatch' | sudo tee --append /etc/apt/sources.list sudo gpg --keyserver keyserver.ubuntu.com --recv D62E4F5B041390BC sudo gpg --export --armor D62E4F5B041390BC | sudo apt-key add - sudo apt-get update sudo apt-get install vdr sudo apt-get install vdr-plugin-rpihddevice

build rpihddevice plugin with omxplayer’s deinterlacer config from source

echo 'deb-src http://e-tobi.net/vdr-experimental jessie base vdr-multipatch' | sudo tee --append /etc/apt/sources.list sudo apt-get update sudo apt-get install vdr-dev libavcodec-dev libavresample-dev libavutil-dev libavformat-dev git clone git://projects.vdr-developer.org/vdr-plugin-rpihddevice.git cd vdr-plugin-rpihddevice git checkout d97493c4c2c7502aaf49f5a44bb5ebe85a198e6 make && sudo make install

get sample recording

I've never observed the issue with live-TV but it's easily reproducible with a recording. I think the major difference is that buffer usage is quite low for live-TV while buffers are filled up to the maximum during playback. I've uploaded a sample recording which, by the way, also shows the problem of #499 (but the issue is also seen with other recordings, video size and codec does not make any difference): cd /var/lib/video sudo wget http://www.reufer.ch/temp/h264_sky.tar.gz sudo tar -xzf h264_sky.tar.gz sudo chown -R vdr:vdr h264_sky

get remote plugin to control vdr via telnet

VDR normally uses LIRC, but for easy testing there's a plugin which also supports OSD and remote by telnet: sudo apt-get install vdr-plugin-remote sudo sed -i '/-i autodetect/c\-p tcp:3333' /etc/vdr/conf.d/50-remote.conf echo '0.0.0.0/0' | sudo tee --append /etc/vdr/svdrphosts.conf

get sample remote config for telnet

cd /var/lib/vdr sudo wget http://www.reufer.ch/temp/remote.conf sudo chown vdr:vdr /var/lib/vdr/remote.conf With the provided config, you get a mapping as follows: m Menu, Enter OK, Backspace Back, cursor keys and numbers are straight forward.

start vdr

sudo service vdr start Use telnet from a different machine/shell to control VDR: telnet <IP> 3333

To reproduce the issue, open the Menu, goto Recordings and select the test sample. When replay has started, toggle the status OSD by pressing OK. After toggling a few times, playback will freeze...

Please let me know, if you have any questions. Thanks a lot for your efforts! Thomas

[popcornmix]

I got all the way to the telnet command without obvious failure. But:

$ telnet 192.168.0.149 3333
Trying 192.168.0.149...
telnet: Unable to connect to remote host: Connection refused

I also can't telnet from the local pi itself. Starting vdr service did cause some overlay to appear (channel not available and then what looks like a channel number and date/time and then blank again).

Any logs that are useful to you?

[reufer]

Ok, it seems that VDR is running. Please make sure that the remote plugin's telnet server is enabled and VDR accepts connections from your client's address:

/etc/vdr/svdrphosts.conf

#
# svdrphosts    This file describes a number of host addresses that
#               are allowed to connect to the SVDRP port of the Video
#               Disk Recorder (VDR) running on this system.
# Syntax:
#
# IP-Address[/Netmask]
#

#127.0.0.1             # always accept localhost
#192.168.0.0/16        # any host on the local net
#204.152.189.113      # a specific host
#0.0.0.0/0            # any host on any net (USE THIS WITH CARE!)
0.0.0.0/0

/etc/vdr/conf.d/50-remote.conf

[remote]
-p tcp:3333

[popcornmix]

It's running now. (I had somehow lost the vdr-plugin-remote package). I'm seeing corruption with the sample video - are you seeing that?

[reufer]

Yes, that's actually issue #499, but has no influence on this. The freeze also happens with all other recordings, no matter what size (SD/HD) or codec (H264/MPEG2) they are. If you want me to provide another sample, just let me know!

[popcornmix]

I am sometimes seeing the stream stop before the end. Just left with a black screen. I can still bring up the menu and play the recording again.

However I have once seen it once hang when pressing m (while video is playing). It hangs with video frame on screen and m key is unresponsive. It appeared that playback was aborted about a minute later. I assume this is the issue you are reporting?

[reufer]

I have to check if VDR stops too early - it should actually query media time and compare it with latest PTS of the recording. But yes, the issue is the other one you observed. I was testing by toggling the replay screen by pressing OK (Enter) during playback, but this shouldn't make any difference. The abortion was probably triggered by VDR's watchdog, but I haven't been waiting for such a long time...

[reufer]

Is there any progress on this issue? I just tried with today's firmware, but the problem still exists. I'd really appreciate to get a solution here, since people are complaining about the weak deinterlacer used as a workaround to avoid the crash.

[reufer]

Fixed with b2ee39c7a6dc8a73ee7b559c7a833271eb10ca11 - thanks a lot! However, it's not related to #545 - this issue is still pending.