The caps should always represent what the user is supposed to see.
So if there is a sequence_display_extension associated with the
stream then use the display_horizontal_size/display_vertical_size
to update the src caps (if they are less than the values provided
by sequence header).
https://bugzilla.gnome.org/show_bug.cgi?id=704009
Restore the original h264parser behaviour to report cropped dimensions
in size caps.
https://bugzilla.gnome.org/show_bug.cgi?id=694068
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Migrate the code to use the new parser API based on GstMpegVideoPacket.
Also try to optimize gst_mpegv_parse_process_config() by using more of
GstMpegVideoPacket and determining the extension_start_code_identifier
prior to calling the parser function for that extension packet.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Don't send any source caps yet if we're still in
drop-buffers-until-we-get-a-sequence-header mode.
Fixes transmuxing of many MPEG-TS/PS streams into
formats which require things like width, height or
codec_data on the input caps.
Also fixes issues when using playbin with decoder
sinks that want width/height etc.
https://bugzilla.gnome.org/show_bug.cgi?id=695879
API is now in baseparse in gstreamer.
Timestamps in MPEG-TS streams are based on the last timestamp
before the start code of the picture. GstBaseParse sets the
timestamp based on the beginning of the sequence header, if
one exists before the picture. This fixes the case where the
timestamp occurs in the MPEG-TS stream between the seq header
and picture start code.
Timestamps in MPEG-TS streams are based on the last timestamp
before the start code of the picture. GstBaseParse sets the
timestamp based on the beginning of the sequence header, if
one exists before the picture. This fixes the case where the
timestamp occurs in the MPEG-TS stream between the seq header
and picture start code.
Otherwise we will intersect with the srcpad template caps and add all the caps fields
that the parser will ever set, no matter if downstream restricts this field or not.
This requires upstream to set this field on the caps to successfully negotiate.
https://bugzilla.gnome.org/show_bug.cgi?id=690184
This allows filtering out videos for hardware decoders that do not
support GMC at all or only support a limited number of sprite warping
points (usually 1).
Right now decodebin will concider the pad template caps as fixed and if a decoder
has restriction on for example height/width it won't be autoplugged because
gst_caps_is_subset fails as those fields are missing from the pad template caps.
We fix the issue here making sure that the pad caps are fixed using data from
the stream.
Sometimes the codec_data buffer for simple/main pushed by asfdemux is 5 bytes
instead of 4. When that happens, codec_data is still valid but it seems to have
one 0x00 trailing byte. Might be a bug in the demuxer, needs more investigation.
