[FFmpeg-devel] [PATCH v6 3/9] avformat: add vvc raw demux
Mark Thompson
sw at jkqxz.net
Fri Feb 19 00:03:55 EET 2021
On 18/02/2021 08:47, Nuo Mi wrote:
> On Thu, Feb 18, 2021 at 6:52 AM Mark Thompson <sw at jkqxz.net> wrote:
>> On 17/02/2021 01:51, Nuo Mi wrote:
>>
>>> + for (i = 0; i < p->buf_size - 1; i++) {
>>> + code = (code << 8) + p->buf[i];
>>> + if ((code & 0xffffff00) == 0x100) {
>>> + uint8_t nal2 = p->buf[i + 1];
>>> + int type = (nal2 & 0xF8) >> 3;
>>> +
>>> + if (code & 0xc0) // forbidden_zero_bit and
>> nuh_reserved_zero_bit
>>> + return 0;
>>> +
>>> + if ((nal2 & 0x7) == 0) // nuh_temporal_id_plus1
>>> + return 0;
>>> +
>>> + switch (type) {
>>> + case VVC_SPS_NUT: sps++; break;
>>> + case VVC_PPS_NUT: pps++; break;
>>> + case VVC_IDR_N_LP:
>>> + case VVC_IDR_W_RADL:
>>> + case VVC_CRA_NUT:
>>> + case VVC_GDR_NUT: irap++; break;
>>> + }
>>> + }
>>> + }
>>> +
>>> + if (sps && pps && irap)
>>> + return AVPROBE_SCORE_EXTENSION + 1; // 1 more than .mpg
>>
>> How well does this test fully distinguish from previous standards using
>> the same start code style?
>>
>> (Can I have an H.264 or H.265 raw stream which passes this test? Can an
>> H.266 stream ever pass the test for those codecs, implying we need to
>> update them?)
>>
> The nal_unit_type located in a different byte. When a H.265 bitstream
> has nuh_layer_ids equal to VVC_SPS_NUT, VVC_PPS_NUT and VVC_IDR_N_LP,
> can pass the test. Vice versa
> All h266 conformance test clips will not detect as other formats. But if
> you have a well-designed clip, it may be. This is normal case for a raw
> bytestream detector.
I'm mainly asking because the H.264 probe function does check some PS IDs to have a bit more confidence that it is looking at an H.264 stream.
If the collision cases are rare such that they will never overlap except with crafted streams then this is probably fine.
- Mark
More information about the ffmpeg-devel
mailing list