[Bug 654294] [basevideodecoder] Impossible to flush pending frames in ::set_format

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Aug 12 12:08:35 PDT 2011


https://bugzilla.gnome.org/show_bug.cgi?id=654294
  GStreamer | gst-plugins-bad | 0.10.13

--- Comment #4 from David Schleef <ds at schleef.org> 2011-08-12 19:08:31 UTC ---
The idea was that "format" was supposed to represent the uncompressed format. 
In the decoder, there's also the concept of "compressed format", which is any
information that the decoder needs to pull from upstream caps.  Little if any
of this information is actually necessary to *decode* the video, except perhaps
for a few screwy formats that i'm not remembering at the moment (WMV9, maybe?).
 However, things like pixel-aspect-ratio and framerate should be copied into
the output caps.  The copying should be done in the base class, preferably.

So I think the correct concept is that GstVideoFormat should be reference
counted, and attach it to each frame to represent the uncompressed format. 
Decoder should have a second compressed format attached.  Once the proper
copying is done in the base class, there should be very little need for
decoders to implement set_format().

However, this leaves out one detail, which is codec_data.  IMO, it's reasonable
to handle this separately.

On a related subject, we might want to have a high-level boolean that
represents whether or not the codec can handle format changes on the fly.  This
is somewhat related to codec_data, since for example, an h264 decode can change
format on the fly only when it's in annex b mode.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list