After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 737173 - h264parse wrongly insert DISCONT flags when converting into AVC
h264parse wrongly insert DISCONT flags when converting into AVC
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal major
: 1.9.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-09-23 13:09 UTC by Josep Torra Valles
Modified: 2016-07-24 15:58 UTC
See Also:
GNOME target: ---
GNOME version: ---

attempt to fix the issue (1.04 KB, patch)
2014-09-24 16:36 UTC, Josep Torra Valles
rejected Details | Review

Description Josep Torra Valles 2014-09-23 13:09:56 UTC
Running the following pipeline produces wrongly ordered frames being rendered.

GST_DEBUG=*parse*:6 gst-launch-1.0 -fv filesrc location= ~/media/interlaced_short.mts ! tsdemux ! h264parse ! video/x-h264, stream-format="avc", alignment="au" ! vtdec ! queue ! glimagesink 2> ~/gst.log

Clip at

Digging in the log seems that skipped data like SEIs is interpreted as a DISCONT which seems a wrong behaviour.

Other issues might be somewhere else in the vtenc or video decoder base class.
Comment 1 Josep Torra Valles 2014-09-24 16:36:54 UTC
Created attachment 286992 [details] [review]
attempt to fix the issue
Comment 2 Josep Torra Valles 2014-09-24 16:40:35 UTC
The first part of the proposed changes is intended to include the AU delimiter NALU when and AU is collected instead of letting the parser skip it when dealing with the following AU.

The second change is adding one to frame size, which I can't explain from were it comes, but there's exactly one byte still skipping which causes a DISCONT flag being set.
Comment 3 Josep Torra Valles 2014-09-27 04:48:52 UTC
This issue is a regression as GStreamer 1.2 series doesn't exhibit this behavior.
Comment 4 Jan Schmidt 2014-09-27 13:23:42 UTC
Comment on attachment 286992 [details] [review]
attempt to fix the issue

The unexplained +1 on the size is from the h264 codec parser not setting the start code position properly for all NAL types, making the next iteration have to skip one byte. It isn't correct and should not be needed.

I'll have another patch soon.
Comment 5 Jan Schmidt 2014-09-27 15:16:15 UTC
Actually, I wont. I give up - it's all a nasty mess.

If AU delimiters are output, they must be the first thing in the next AU, according to of the spec. They can't be gathered into the previous AU.

The weird +1 thing comes from commit 6af387cd5ab2c946025e5499903e75ee87b063a9 - which tries to handle (valid) cases where the start code is only 3 bytes long, which makes the first loop on the next buffer skip 1 zero byte if there's a 4-byte start code. I don't think that detection code is entirely correct, but it shouldn't matter - it should be sufficient for the parser to detect a 3-byte start code, and generate 4-byte start codes where needed. The real problem is that it's skipping that first byte, which makes base_parse mark things as discont when they are not. We need a way to make base_parse advance without making things discont.
Comment 6 Matej Knopp 2014-09-27 15:51:43 UTC
I agree with Jan. The detection code is not perfect (I wrote in the original bug comment that it doesn't cover all cases from but making the parser skip one zero byte without marking the buffer as DISCONT would imho be less work than covering all cases from in the NAL scanner.
Comment 7 Josep Torra Valles 2016-07-24 15:58:05 UTC
Closing because it seems to be fixed in current master.