HEVC standard supports multi-layer streams (ITU-T H.265 02/2018 Annex
F). Each NAL unit belongs to a particular layer defined by nuh_layer_id
in the header.
Currently, all NAL units that do not belong to a base layer are
automatically removed in ff_h2645_packet_split(). Some data may
therefore be lost when future filters/decoders are designed to support
multi-layer streams.
A better approach is to forward nuh_layer_id > 0 packets and let blocks
down the chain decide how to process them. The condition to remove
packets has been moved to hevcdec and cbs.
Found-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This is in preparation for a patch for cbs_h2645. Now the packet's
rbsp_buffer can be owned by an AVBuffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
Now memcpy is avoided for NAL units that don't contain 0x03 escape
characters.
Improves performance of cbs_h2645_fragment_add_nals from 36940
decicycles to 6364 decicycles based on 8 runs with a 5.1 Mb/s H.264
sample (262144 runs each).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
* commit '61bd0ed781b56eea1e8e851aab34a2ee3b59fbac':
h264: Log more information about invalid NALu size
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The parser changes have lost the support for the needed padding, this adds it back
Fixes out of array reads
Fixes: 03ea21d271abc8acf428d42ace51d8b4/asan_heap-oob_3358eef_5692_16f0cc01ab5225e9ce591659e5c20e35.mkv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '90ed6c5cf7f236bc9efb47c97b40358c666d1386':
h2645_parse: compute the actual data length, without trailing paddding
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '8229eff4b7a98ae5d85bb75f3bb072781b4a8ebe':
h2645_parse: add a function for uninitializing the packet
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
