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 745409 - h264parse: broken output when caps change and stream-format=byte-stream
h264parse: broken output when caps change and stream-format=byte-stream
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.4.5
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-03-02 08:01 UTC by Aleksander Wabik
Modified: 2015-03-04 11:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The screenshot of the artifacts (77.97 KB, image/jpeg)
2015-03-02 08:05 UTC, Aleksander Wabik
  Details
h264parse: reset the parser information when caps changes (2.72 KB, patch)
2015-03-03 15:00 UTC, Thiago Sousa Santos
reviewed Details | Review
h264parse: reset the parser information when caps changes (3.88 KB, patch)
2015-03-03 16:39 UTC, Thiago Sousa Santos
accepted-commit_now Details | Review

Description Aleksander Wabik 2015-03-02 08:01:09 UTC
I am not sure what is causing problems here. It may be h264parse, or baseparse.

I have a source that produces packetized h264 data, with caps "video/x-h264, stream-format=byte-stream, alignment=au, width=.., height=..". When the video quality (adaptive streaming) changes, and I send new caps, then some frames will be broken. If I do not include width & height in the caps, so the quality change does not result in new caps, then playback goes smoothly.

I have engineered a gst-launch pipeline that allows reproducing this problem:

gst-launch-1.0 souphttpsrc location=http://www.digitalprimates.net/dash/streams/gpac/mp4-main-multi-mpd-AV-NBS.mpd ! dashdemux bandwidth-usage=0.3 ! queue2 ! qtdemux ! h264parse ! video/x-h264, stream-format=byte-stream, alignment=au ! h264parse ! avdec_h264 ! queue2 ! autovideosink

The explanation of the test pipeline:

- dashdemux bandwidth-usage=0.3 - I noticed that this bug reproduces on given content easily when the quality is changed to 720p. I use bandwidth-usage to make quality not to switch automatically to 1080p after first segment.
- h264parse ! video/x-h264, stream-format=byte-stream, alignment=au ! h264parse - the first parser and capsfilter is only required in order to make the (second) h264parse to obtain data in stream-format=byte-stream. This is required.

If I do not enforce byte-stream format, this bug does not reproduce.
If I enforce byte-stream, but remove the second h264parse, this bug does not reproduce. So I guess that the h264parse with byte-stream input is a source of the bug.

In order to reproduce, please run my pipeline. The video has hardcoded information about quality- if you see that it switched though 360p, 720p and 1080p without artifacts, then restart. You should see artifacts when switching to 720p, and when switching from 720p to 1080p. If the playback switches instantly to 1080p, without going through the intermediate qualities, maybe fiddling with bandwidth-usage property on dashdemux will be helpful.
Comment 1 Aleksander Wabik 2015-03-02 08:05:05 UTC
Created attachment 298254 [details]
The screenshot of the artifacts

I attach the screenshot. It always looks like bad scaling of the frame, green bars and green noise below the badly scaled video.
Comment 2 Aleksander Wabik 2015-03-02 14:05:53 UTC
Sometimes it also causes crash, when switching to 1080p quality:

Caught SIGSEGV
  • #0 poll
  • #1 g_main_context_iterate.isra
  • #2 g_main_loop_run
  • #3 gst_bus_poll
    at gstbus.c line 1091
  • #4 event_loop
    at gst-launch.c line 512
  • #5 main

Comment 3 Aleksander Wabik 2015-03-02 14:15:30 UTC
And to make everything very clear, my autovideosink plugs in xvimagesink, though the artifacts can be reproduced with any sink (cluttersink seems to freeze sometimes during quality switch though).
Comment 4 Thiago Sousa Santos 2015-03-03 15:00:27 UTC
Created attachment 298440 [details] [review]
h264parse: reset the parser information when caps changes

This prevents it from going into passthrough after receiving 2
byte-stream caps (different ones) as it would keep the have_pps and
have_sps set to true and would just go into passthrough without
updating its caps.

This patch makes it reset its stream information to restart properly
when new caps are received.
Comment 5 Sebastian Dröge (slomo) 2015-03-03 15:35:41 UTC
Comment on attachment 298440 [details] [review]
h264parse: reset the parser information when caps changes

Shouldn't it reset more than just the streaminfo if caps are changing? Otherwise seems to make sense
Comment 6 Thiago Sousa Santos 2015-03-03 16:39:43 UTC
Created attachment 298452 [details] [review]
h264parse: reset the parser information when caps changes

Updated to reset all data related to the stream format, only timestamping
data is kept when a new caps is received
Comment 7 Aleksander Wabik 2015-03-04 10:55:17 UTC
I confirm that the latest patch fixes my original problem, as well as the testcase pipeline that I posted.

Will this patch be merged to GStreamer 1.6?
Comment 8 Thiago Sousa Santos 2015-03-04 11:06:17 UTC
Thanks for the review and confirmations, the fix will be available in the next releases (1.5 and 1.6). I couldn't reproduce your crash, please reopen or file a new bug if it still crashes.

commit 14f6fcdbd89f1934700b26f3e3afa54c654cbabb
Author: Thiago Santos <thiagoss@osg.samsung.com>
Date:   Tue Mar 3 11:42:09 2015 -0300

    h264parse: reset the parser information when caps changes
    
    This prevents it from going into passthrough after receiving 2
    byte-stream caps (different ones) as it would keep the have_pps and
    have_sps set to true and would just go into passthrough without
    updating its caps.
    
    This patch makes it reset its stream information to restart properly
    when new caps are received.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=745409
Comment 9 Aleksander Wabik 2015-03-04 11:13:30 UTC
I couldn't reproduce the crash with the fix. Though the crash was not reproducing on my original testcase (my custom player), was reproducing only on the xvimagesink test pipeline, was not reproducing on cluttersink, and was probably very tightly related to the artifacts. Although the callstack didn't suggest the sink, I suppose it was sink-specific and had the same root cause as the artifacts.