On 18/02/2021 08:47, Nuo Mi wrote:
On Thu, Feb 18, 2021 at 6:52 AM Mark Thompson <s...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
