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 660254 - gst-ffmpeg video decoders don't clear DELTA_UNIT buffer flags after decoding the delta
gst-ffmpeg video decoders don't clear DELTA_UNIT buffer flags after decoding ...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-27 15:59 UTC by Mart Raudsepp
Modified: 2013-07-17 10:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Mart Raudsepp 2011-09-27 15:59:48 UTC 
It seems that most or all gst-ffmpeg video decoders are passing buffers downstream with the GST_BUFFER_FLAG_DELTA_UNIT flag set on most buffers, and only a few don't have that flag set - probably those where keyframes happened in the coded buffers.
I believe that because the buffers presumably contain raw decoded data of full frames, none of them should be having the DELTA_UNIT flag set anymore once passed on downstream.
Comment 1 David Schleef 2011-12-09 02:00:10 UTC 
You are correct.
Comment 2 Mart Raudsepp 2011-12-09 02:57:17 UTC 
There also was a discussion on IRC regarding the fact that with the correct behaviour, downstream doesn't have the information anymore if in the packed stream is was a keyframe (and rather a precise image, free of motion compensation and such) or not. Not sure if/when it could be useful. It would be useful in some testcase implementation based on buffer probes, but there it should be possible to get around it by moving or adding another probe before the decoder
Comment 3 Sebastian Dröge (slomo) 2011-12-09 09:34:00 UTC 
Could you provide a patch to remove the delta-unit flag from all decoder output buffers?
Comment 4 Edward Hervey 2013-07-17 10:54:57 UTC 
This should be handled by base video encoder class and fixed, no ?
Comment 5 Sebastian Dröge (slomo) 2013-07-17 10:59:36 UTC 
Yes and is