Waiting for the next NAL increases the latency. If alignment=nal/au
has been negotiated, assumes that 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
The comparision was not testing anything meaninful. This fixes the comparision
so we now update the caps whenever the value differ. This was detected by
coverity.
CID 1461291
Add new property "update-timecode" to allow updating timecode
in picture timing SEI depending on timecode meta. Since the picture
timing SEI message requires proper VUI setting but we don't support
re-writing SPS, this might not work for some streams
For interlaced video:
* set the interlace mode in the src caps
* double the height from SPS in the caps.
* set field latency, instead of frame latency.
Fix#778
Initially the case "only codec_data is different" was addressed in
https://bugzilla.gnome.org/show_bug.cgi?id=705333 in order for
unusual bitstreams to be handled. That's the case where sps and pps
are placed in bitstream. When sps/pps are signalled only via caps
by upstream, however, the updated codec_data is mandatory for decoder
and therefore we shouldn't ignore them.
Some raw h264 encoded files trigger the assignment of wrong PTS to buffers
when some SEI data is provided. This change prevents it to happen.
Also ensure this behavior is being tested.
As the H265/H264 bitstream can support multiple slices,
mastering_display_info_state and content_light_level_state
should be changed only on first slice segment.
Fix#1152
According to H264 ITU standards from 06/19, GST_H264_PROFILE_HIGH_422
(profile_idc = 122) with constraint_set1_flag = 0 and
constraint_set3_flag = 0 can be mapped to high-4:2:2 or high-4:4:4.
GST_H264_PROFILE_HIGH_422 with constraint_set1_flag = 0 and
constraint_set3_flag = 1 can be mapped to high-4:2:2, high-4:4:4,
high-4:2:2-intra or high-4:4:4-intra.
From the documentation of gst_base_parse_set_infer_ts, it should be
disabled for non-audio data. Currently just disabling for all video
parsers that have reordered data: h264, h265, mpeg, mpeg4, vc1. Was
already disabled in h263.
According to the spec, the least significant bit is reserved and should
always we set to 1. Though, some wrong file has been found. Considering
how low important this reserved bit is, relax the validation.
Related to #660
1. only recalculate src codec format if sink caps change
2. use correct value for "jp2c" magic in J2C box ID
3. only parse J2K magic once, and store result
4. more sanity checks comparing caps to parsed codec
A guint32 greater than 2^31 would be interpreted as negative by
gst_util_uint64_scale_int() and critical. Use the 64-bit integer version
of the function instead.
The SPS parsing functions take a parse_vui_param flag
to skip VUI parsing, but there's no indication in the output
SPS struct that the VUI was skipped.
The only caller that ever passed FALSE seems to be the
important gst_h264_parser_parse_nal() function, meaning - so the
cached SPS were always silently invalid. That needs changing
anyway, meaning noone ever passes FALSE.
I don't see any use for saving a few microseconds in
order to silently produce garbage, and since this is still
unstable API, let's remove the parse_vui_param.
Fix a recently introduced segfault. Don't de-reference a NULL
SPS pointer when attempting to update source caps before SPS
has been seen in the stream.
We generally always prefer the information from upstream for other
metadata (pixel-aspect-ration, etc.) and should also do so here.
Other parsers (h264parse) already do the same.
When sps parsing fails we use a fallback sps from the caps, since we
have got an sps we need to update parser state and header as in the case the
sps was successfully parsed
When sps parsing fails we use a fallback sps from the caps, since we
have got an sps we need to update parser state and header as in the case the
sps was successfully parsed
Closes#503
Set more unhandled flags to general_constraint_indicator_flags field.
The field is required for building "Codecs" parameter as defined
ISO/IEC 14496-15 Annex E. The resulting "Codecs" string might be used
in various places (e.g., HLS/DASH manifest, browser, player, etc)
... and set to caps if necessary.
Note 1) the mastering display info and content light level SEI meessages
are persistent in the corresponding codec video sequence (i.e., GOP).
So any bitstream containing those SEI messages
(and also all pictures are intended to be HDR rendered) should be ensured that
each first slice of codec video sequence follows those SEI messages.
Note 2) The codec video sequence is a group an [IRAP + NoRaslOutputFlag == 1]
and following AUs which are not [IRAP + NoRaslOutputFlag == 1]
The NoRaslOutputFlag is equal to 1 for each IDR AU, BLA AU and some CRA AU.
For a CRA AU to have NoRaslOutputFlag equal to 1, following condition should required.
* When the CRA AU is the first AU in the bitstream in decoding order
* or the CRA AU is the first AU that follows an end of sequence NAL in decoding order
* or the HandleCraAsBlaFlag equal to 1.
Due to the limited context in parse element, in this commint, CRA AU will not considered as
having the NoRaslOutputFlag equal to 1. Therefore, in the worst case,
mastering-display-info and content-light-level could be cleared one GOP after
when stream was chagned from HDR to SDR.
Expose SEI data in the H.264 bitstream parser API and
extract closed captions and other things that are not
specified in the H.264 spec itself in the videoparser.
Based on patch by: Mathieu Duponchelle <mathieu@centricular.com>
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/940
when computing timecode metas. Depending on the value of that flag,
n_frames is to be interpreted as a number of fields or a number of
frames. As GstVideoTimeCodeMeta always deals with frames, we want
to scale that number when needed.
This debug code will help determine why certain instances of closed
captions that are present in the Picture User Data are not actually
processed by the pipeline
vps/sps/pps in codec_data shouldn't be considered as inband data.
Otherwise, h26{4,5}parse never insert them to nal when transform
(packetized to byte-stream) use case
Similar change as the on I did in h264parse. We want to process SEI
recovery point as keyframe so muxers will mark them as seek points and
decoders will be able to start decoding from them rather than waiting
for an IDR.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/790
The spec states that "recovery point SEI message assists a decoder in
determining when the decoding process will produce acceptable
pictures for display after the decoder initiates random access or after the
encoder indicates a broken link in the coded video sequence."
Mark those as keyframes so muxers will mark them as seek points and
decoders will be able to start decoding from them rather than waiting
for an IDR.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/790
Direct applying the commit 7bb6443. This could fix also unexpected
nal dropping when nonzero "config-interval" is set.
(e.g., gst-launch-1.0 videotestsrc ! x265enc key-int-max=30 !
h265parse config-interval=30 ! avdec_h265 ! videoconvert ! autovideosink)
Similar to the h264parse, have_{vps,sps,pps} variables will be used
for deciding on when to submit updated caps or not, and rather mean
"have new SPS/PPS to be submitted?"
See also https://bugzilla.gnome.org/show_bug.cgi?id=732203https://bugzilla.gnome.org/show_bug.cgi?id=754124
