The first time update_src_caps is called, there's no frame parsed yet,
therefore we don't know whether the file has alternate-field interlacing
mode. If we run it again after we have a frame, it might be that now we
have the SEI pic_struct parsed, and therefore we know that it's
field-based interlaced, and therefore the height must be multiplied by
two. Earlier on this was not detected as a change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2022>
Instead of relying on GstBaseParse default behaviour of computing
the duration of a parsed buffer based on the framerate passed
to gst_base_parse_set_framerate(), we instead compute the duration
ourselves, as we have more information available.
In particular, this means we now output buffers with a duration
that matches that of raw interlaced buffers when each field is
output in a separate buffer.
This fixes DTS interpolation performed by GstBaseParse, as the
previous behaviour of outputting each field with the duration of
a full frame was messing up the base class calculations.
When not enough information is available, h264parse simply falls
back to calculating the duration based on the framerate and hope
for the best as was the case previously.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1973>
1. Set the default output alignment to frame, rather than current
alignment of obu. This make it the same behaviour as h264/h265
parse, which default align to AU.
2. Set the default input alignment to byte. It can handle the "not
enough data" error while the OBU alignment can not. Also make it
conform to the comments.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1979>
The current behaviour for obu aligned output is not very precise.
Several OBUs will be output together within one gst buffer. We
should output each gst buffer just containing one OBU. This is
the same way as the h264/h265 parse do when NAL aligned.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1979>
The current optimization when input align and out out align are
the same is not very correct. We simply copy the data from input
buffer to output buffer, but we failed to consider the dropping of
OBUs. When we need to drop some OBUs(such as filter out the OBUs
of some temporal ID), we can not do simple copy. So we need to
always copy the input OBUs into a cache.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1979>
1. Add the mono_chrome to identify 4:0:0 chroma-format.
2. Correct the mapping between subsampling_x/y and chroma-format.
There is no 4:4:0 format definition in AV1. And 4:4:4 should
let both subsampling_x/y be equal to 0.
3. Send the chroma-format when the color space is not RGB.
Fixes: #1502
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1974>
This AV1 parse implements the conversion between alignment of obu,
tu and frame, and the conversion between stream-format of obu-stream
and annexb.
TODO:
1. May need a property of operating_point to filter the OBUs
2. May add a property to disable deep parse.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1614>
Adding vp9parse element to parse various stream information such as
resolution, profile, and so on. If upstream does not provide resolution and/or
profile, this would be useful for decodebin pipeline for autoplugging
suitable decoder element depending on template caps of each decoder element.
In addition, vp9parse element supports unpacking superframe into
single frame for decoders. The vp9 superframe is a frame which consists
of multiple frames (or superframe with one frame is allowed) followed by superframe
index block. Then unpacked each frame will be considered as normal frame
by decoder. The decision for unpacking will be done by downstream element's
"alignment" caps field, which can be "super-frame" or "frame".
If downstream specifies the "alignment" as "frame",
then vp9parse element will split an incoming superframe into single frames
and the superframe index (located at the end of the superframe) data
will be discarded by vp9parse element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1041>
This reverts commit b75a61342f.
The parser would only set the mode to progressive or mixed, missing the
cases where it should have been interleaved. Interleaved is more
difficult to detect because in h264 it happens per frame. On the other
hand, h264 decoders detect the interlacing information per-frame and set
the caps correctly. By giving potentially incorrect interlacing
information in the parser already, it's being enforced downstream even
after decoding, breaking some use cases (e.g. an encoder can't properly
mark the stream as TFF or BFF). On the other hand, there's no valid use
case for having interlacing information on the caps at the parsing
stage, so after a lot of discussion, it was decided to revert this.
Initial commit message:
=========================
Those are the rules:
In the SPS:
* if frame_mbs_only_flag=1 => all frame progressive
* if frame_mbs_only_flag=0 => field_pic_flag defines if each frame is
progressive or interlaced, thus the mode is 'mixed' in GStreamer
terms.
https://bugzilla.gnome.org/show_bug.cgi?id=779309
=========================
Fixes#1313
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1335>
If the input has a miss-placed filler zero byte (e.g. a filler without a 4
bytes start code on the next NAL), we would endup using the same timestamp
twice. Ask the base class to read the timestamp from the buffer were the NAL
actually starts.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
This will stop stripping four bytes start code. This was fixed and broken
again as it was causing the a timestamp shift. We now call
gst_base_parse_set_ts_at_offset() with the offset of the first NAL to ensure
that fixing a moderatly broken input stream won't affect the timestamps. We
also fixes the unit test, removing a comment about the stripping behaviour not
being correct.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1251>
Otherwise we may endup pushing incomplete caps, which cause a renegotiation.
Note that this has the effect that caps are no longer pushed twice in presence
of valid framerate in the headers.
Otherwise we may endup pushing incomplete caps. Note that this has the side
effect that caps are no longer pushed twice in presence of VUI with valid
framerate.
There is some code to fixup broken stream that uses the SEI location,
this code is meant to locate SUFFIX SEI only. This should prevent
unwanted side effect if SUFFIX SEI is used.
Waiting for the next NAL increases the latency. If alignment=nal/au
has been negotiated, assumes the the buffer contains a complete
NAL and don't expect a second start-code. This way, nal -> nal,
au -> au and au -> nal no longer introduce latency.
As a side effect, the collect_pad() function was not able to poke at the
following NAL. This call is now moved before processing the NAL, so
it's looking at the current NAL before it's ingested into the parser
state in order to dermin if the end of an AU has been reached. The AUD
injection state as been adapted to support this.
This change will break pipelines if alignment=nal is used without respecting the
alignment. Effectively, the parser will no longer fix the broken aligment
which will result in parser error and the termination of the pipeline. Such
issue existed in tsdemux element and might exist in any forks of that code.
Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1193
