[Bug 786802] New: vaapidecode: h264: fix nal aligned streams

["GStreamer" (GNOME Bugzilla)]

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

Bug ID: 786802
Summary: vaapidecode: h264: fix nal aligned streams
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@gmail.com
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@gmail.com,
***@igalia.com
GNOME version: ---

Running the following pipeline:

gst-launch-1.0 filesrc location=CI_MW_D.264 ! h264parse ! video/x-h264,
stream-format=byte-stream, alignment=nal ! vaapih264dec ! vaapisink

seems to show only a single frame while the pipeline works correctly with au
alignment:

gst-launch-1.0 filesrc location=CI_MW_D.264 ! h264parse ! video/x-h264,
stream-format=byte-stream, alignment=au ! vaapih264dec ! vaapisink

A quick workaround seems to be to not mark the GST_H264_NAL_AU_DELIMITER units
as AU and FRAME START which makes the above pipeline work but the problem still
persists for other files such as BAMQ1_JVC_C.264.

Files from ITU-T_H.264.1(2016-02)_AVCv1_bitstreams.zip from
https://www.itu.int/net/itu-t/sigdb/spevideo/VideoForm-s.aspx?val=102002641.

["GStreamer" (GNOME Bugzilla)]

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

sreerenj <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Priority|Normal |High

--- Comment #1 from sreerenj <***@gmail.com> ---
Setting the priority as High since the "aligname=nal" should be considered as
the default format of h264 and which should work with vaapih264dec.

["GStreamer" (GNOME Bugzilla)]

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

Hyunjun Ko <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@igalia.com

--- Comment #2 from Hyunjun Ko <***@igalia.com> ---
I've looked into this issue all this week.
This is a bit tricky but let me try to explain briefly.

1. This is introduced by my commit to gsth264parse (201e71c in gst-plugins-bad)
Since the commit landed, incoming data with byte-stream/nal is like:
<AU><SLICE> instead of just only <SLICE>.
vaapih264dec can't handle this now, which is this issue.

2. I think vaapih264dec is doing fine in the way it should do.
Adding AU to a frame and adding SLICE to the frame (by add_to_frame)
and have_frame call.

3. Meanwhile, in the base video decoder, it tries to decide frame information
such as pts, duration, etc. See gst_video_decoder_get_buffer_info_at_offset.
Previously it choose info from slice buffer properly, but for now it choose
from AU buffer.

Finally this wrong information leads to dropping all frames in
gst_video_decoder_clip_and_push_buf.

Acutally, I tried to improve gst_video_decoder_get_buffer_info_at_offset, but I
realized that I have to be careful since there are lots of cases.

Now I'm looking for other solution. :(

["GStreamer" (GNOME Bugzilla)]

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

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #3 from GStreamer system administrator <***@gstreamer.net> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/67.