h264: Picture corruption

[julianscheel]

I've hit a new case of corruption with the h264 decoder using this sample: http://jusst.de/files/corrupt-h264.ts It actually is a capture from a prominent german TV station which switched over from mpeg2 to h264 these days. Several channels are affected by that issue now. It somehow looks like some broken reference frame handling, I'd presume.

[popcornmix]

I'll repeat my comment from other issue for completeness:

I've played file with debugger attached but it's not hitting the cabac size assert so I think this is a different issue. There is an assert at start:

4005    {/*coundn't find the reference picture, give up*/
4006       vd3_bs_assert(0);
4007       return;
4008    }

but I think that is expected as the file doesn't start from an I frame (VLC displays corruption for a while). Will need @deborah-c to investigate.

[julianscheel]

@deborah-c Any hope you could have a look at this soonish?

[julianscheel]

I just pushed another example file, which starts with working decoding and then suddenly at time 01:14 begins to suffer by heavy artefacts when decoded with mmal. ffmpeg can handle is just fine. http://jusst.de/files/corrupt-h264-2.ts @popcornmix Is there some exception triggered when the issue starts maybe? To me it really looks as if the dpb gets somehow screewed up.

[popcornmix]

This file has the same assert as before ("coundn't find the reference picture, give up") but it doesn't occur until some way into the file. The artefacts looks very similar. So I suspect the two files are hitting the same issue.

[julianscheel]

@popcornmix Ok, this somehow matches what I'd assumed considering how the artefacts are looking like. Now the big question is: Do we have any chance to investigate this further as long as @deborah-c is not available? I used to have debugged this kind of stuff a lot in the early times of vdpau when I implemented the dpb in libxine, so I presume I might still be able to understand that kind of stuff. But probably there's no chance for me to look into the related code?

[deborah-c]

Sorry, will try to get to this soon -- I'm still having health issues, but able to do some work...

[julianscheel]

@deborah-c This is great news. I hope you'll get well soon and let me know if I can do anything to assist you.

[popcornmix]

Interestingly the file in #463 (http://www.reufer.ch/temp/h264_sky.tar.gz) played corrupt for me from start for a few minutes then cleared up. However on subsequent plays it started correctly. This is using the vdr player which may be keeping the video_decode component open between files?

Anyway it feels like there is something uninitialised (possible in dpb) which playing a later part of the file is fixing.

[julianscheel]

That's really interesting. When doing constant playback of these channels the issue just appears and vanishes at somehow random points in time.

[popcornmix]

Another report of the same issue: http://forum.kodi.tv/showthread.php?tid=249700

[julianscheel]

@deborah-c Don't want to bug you, just wanted to ask whether you had a chance to have an initial look yet? Something like a feeling if it's an easy fix or a simple one would help us a bit for planning our next steps.

[glenvt18]

Probably the same issue from another broadcaster: https://drive.google.com/open?id=0BxEZpdTX1bPvdTJ3TjFZZVFrTGM

[cczarski]

It seems that this is another instance of the same issue:

https://drive.google.com/file/d/0B6JnjFM0x9nAeHFGeTkxVTlocjA/view?usp=sharing https://drive.google.com/file/d/0B6JnjFM0x9nAakpSdlFqVHo4WmM/view?usp=sharing

[gkreidl]

popcornmix sent me here, after I had sent him a test file. I've got the same problem in my transcoder package which uses gstreamer1.0-omx. So I'll be also watching this thread for any kind of solution.

[SneakyPie]

Are there any new information, if and when you can expect a patch.

[Quantomax]

It seems to be a timeframe-counter issue:

A "Jukebox" recording (SD h264, 720x576i) shows this behavior reproducibly: 0:00:00.00 Picture broken / blocking effects 0:37:26.21 Picture gets clear 1:20:21.00 Picture blocking again 2:03:12.11 Picture fine again 2:30:00.00 ... until EOF

While producing the marks with "vdr" by pressing "0" and moving by "4" and "6" I noticed, that one half picture seems to be decoded ok (eg. line 1 3 5..), the other is simply grey (2 4 6.. resp.) in the "blocked" sections.

[gkreidl]

software decoders (VLC, HandBrake) play/decode these files or streams without any problems

[julianscheel]

@Quantomax That's interesting. As it's roughly 43 minutes between issue appearing and disappearing it's roughly 25_60_43=64500 frames, which is not too far away from a 16bit boundary. So a wild guess would be that for reference frame lookup some 16 bit reference id is used inside the codec. Could you confirm this, @popcornmix @deborah-c ? If so then the cleanup might be because reference ids start again from 0 after that time and whatever missmatch occured gets resolved by that... But honestly this is pure speculation :)

[ClashC]

Is there any news here? perhaps something to the test? ;) Merry Christmas

[supaMUC]

Any update? This is really annoying, not only the problems with the video but also with the sound volume gowing up and down...

[popcornmix]

I've found a suspicious cast in the decoder. Here is a test firmware with a potential fix: https://dl.dropboxusercontent.com/u/3669512/temp/firmware_dpb.zip

Please confirm if it fixes your current issue and whether you spot any regressions with other h264 video (it shouldn't affect other codecs).

[cczarski]

Copied the "start_x.elf" and the "fixup_x.dat" files into the /boot folder of my RPi2, First tests look primising. I did not see the picture corruptions any more. Other H.264 videos also play fine. Will continue to test ...

Very, very cool. Thanks so much!

[gkreidl]

I've lots of such files and will run some tests tomorrow and report.

[supaMUC]

Works for me with openelec on my RPi2.

Thank you so much!!

[SneakyPie]

The german IPTV seems to be good! I will watch it. Thanks, a lot.

[ghost]

Great! Telekom entertain h264 streams now perfectly with this firmware.

[ClashC]

Great, i have no problem with the new firmware now.

[gkreidl]

Tested with omxplayer (live TV and recordings) and my transcoder application (gstreamer-omx based) and all worked well. No regressions found so far.

[Rayn0r]

At first glance it seems fixed. I tested with live TV for about an hour. No distortions occurred during that time. Testing will continue tomorrow...

[popcornmix]

This is now in rpi-update firmware. @julianscheel feel free to close when happy.

[glenvt18]

@popcornmix Could you take a look at this sample - no video and audio with openelec 6.0 and omxplayer. It's not a regression as it doesn't work with the old firmware too. Other channels are fixed now, thanks a lot.

[popcornmix]

@glenvt18 can you open a new issue as this is not related to this one.

[glenvt18]

@popcornmix Created #529.

[julianscheel]

Thanks for fixing @popcornmix - Tests are all good now

[Tobi-BPi]

Hello.

Can somebody tell me if this issues is fixed at the moment included in the Openelec 6.0.1?

Best regards Tobi

[popcornmix]

No, I don't believe the firmware was updated. You can manually update the firmware.

[NWiBGRsK]

@popcornmix

out of curiosity, can you tell me what has changed in the stream that has caused the issue?

[popcornmix]

There is a picture count in the stream that resets every IDR. Typically these occur every second or two so the size of the picture count is always small.

The picture count is 16-bits , but there is logic in the decoder to extend that to more bits if it ever wraps. However that code had never been exercised as the numbers never get that big (even with commercial test stream sets). Until the German broadcaster changed something in their encoder.

When the picture count reached 32768 a bug in the code treated that as a signed 16-bit number, which becomes negative. The picture count becomes wrong and we use the wrong reference frames, hence the corruption.

The fix just removed two unwanted casts to int16_t, so the values remained as uint16_t which does the right thing.

[NWiBGRsK]

@popcornmix Perfect explanation, many thanks!

[Natascha303]

Probleme here. Pi3 doesn't boot after i transfered the unzipped files on SD Card via Win10 (also tried on Ubuntu)

OSMC 2016.04-1

Pi3 is blinking 5 times green Long and than fast short. Red is not blinking, keeps red.

What did i wrong ?

Thanks!

Who can help me ?

[popcornmix]

What does vcgencmd version report?

[Natascha303]

HXF5:~ # vcgencmd version Feb 19 2016 19:53:38 Copyright (c) 2012 Broadcom version 573126451d3fb80e6de5ffb7d1fa117d814417b8

[popcornmix]

That doesn't sound up to date. Try: sudo rm /boot/.firmware_revision; sudo rpi-update and then reboot.

[Natascha303]

unfortunately, not...here the command answer http://abload.de/img/clipboard01y1s26.jpg

how to perform a rpi update on osmc? they block it https://discourse.osmc.tv/t/cant-run-rpi-update/6347

and manually copying via sd Card it destroys it. no more booting.

(also tried it with openelec 6.03 - same result)

so guys, how did you update the files ? it seems to work for everyone here thanks

[popcornmix]

Ah - you shouldn't use rpi-update on OSMC. Try updating in My OSMC. If there is a problem with that then ask here: https://discourse.osmc.tv

[Natascha303]

My Osmc has installed the needed files, thank you

[deagl0r]

the fix with "firmware_dpb.zip" doesn´t work for me. RPi2, IPTV Telekom Entertain Germany/Berlin 75% of the screen are in green blocks. I copy the content of the zip to sdcard. What is wrong on my pi?

[gkreidl]

AFAIK, The fix has been added to the official firmware. No need to use the experimental patch any more.

[deagl0r]

hmmm i make a clean installation an test it.