[Bug 745409] New: h264parse: broken output when caps change and stream-format=byte-stream

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=745409

            Bug ID: 745409
           Summary: h264parse: broken output when caps change and
                    stream-format=byte-stream
    Classification: Platform
           Product: GStreamer
           Version: 1.4.5
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: don't know
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: awabik at opera.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.