[Bug 796495] Missing frames when encode with B frames from YUV file and num-buffers specified

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #1 from U. Artie Eoff <***@intel.com> ---
FWIW:

gst-launch-1.0 filesrc location=test.yuv num-buffers=90 ! rawvideoparse
format=nv12 width=1920 height=1080 ! checksumsink

...outputs 90 values

["GStreamer" (GNOME Bugzilla)]

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

Nicolas Dufresne (ndufresne) <***@ndufresne.ca> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|major |normal

["GStreamer" (GNOME Bugzilla)]

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

Nicolas Dufresne (ndufresne) <***@ndufresne.ca> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@ndufresne.ca

--- Comment #2 from Nicolas Dufresne (ndufresne) <***@ndufresne.ca> ---
Looks like is the b-frames setting that impact the results here, a simpler way
to reproduce the issue:

gst-launch-1.0 videotestsrc num-buffers=90 ! vaapih264enc max-bframes=4 !
h264parse ! multifilesink

If you move it back to 0 bframes, there it's good. I'm confirming this issue.

["GStreamer" (GNOME Bugzilla)]

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

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|Missing frames when encode |vaapih264enc: Missing
|with B frames from YUV file |frames when encode with B
|and num-buffers specified |frames from YUV file and
| |num-buffers specified

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #3 from U. Artie Eoff <***@intel.com> ---
@Victor, I see you changed the subject. Please not that this happens with
vaapih265enc too!

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #4 from U. Artie Eoff <***@intel.com> ---
(In reply to U. Artie Eoff from comment #3)

Post by "GStreamer" (GNOME Bugzilla)
@Victor, I see you changed the subject. Please not that this happens with
vaapih265enc too!

/not/note/

["GStreamer" (GNOME Bugzilla)]

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

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|vaapih264enc: Missing |vaapi{h264,h265}enc:
|frames when encode with B |Missing frames when encode
|frames from YUV file and |with B frames from YUV file
|num-buffers specified |and num-buffers specified

["GStreamer" (GNOME Bugzilla)]

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

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

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

["GStreamer" (GNOME Bugzilla)]

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

Fei <***@intel.com> changed:

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

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #5 from Fei <***@intel.com> ---
Take a example, if set max-bframes as 4, then encoder need 4 frames in a list
together to encode the 4 B frames per time. If the total frame number can not
divide by 4, then there will be less than 4 frames in list in the end. And the
list will be release and the frames will be drop in it during flush. So one
solution is to change B frame into P frame in flush and re-encode all the
remind frames instead of drop them. But seems it is hard to implement because
encode/flush are called in video encode base class. Any suggestion on this?

["GStreamer" (GNOME Bugzilla)]

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

--- Comment #6 from Nicolas Dufresne (ndufresne) <***@ndufresne.ca> ---
I can't comment on the solution, I would have to check what other encoders do
by parsing the results, but it seems fair.

The base class will signal the moment you should do that on finish() virtual
function. It's of course harder than usual, as we are implementing a part of
the encoder.

["GStreamer" (GNOME Bugzilla)]

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

U. Artie Eoff <***@intel.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |major

["GStreamer" (GNOME Bugzilla)]

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

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

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

--- Comment #7 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/97.