aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/msvideo1enc.c
diff options
context:
space:
mode:
authorMattias Wadman <mattias.wadman@gmail.com>2024-02-13 11:17:46 +0100
committerAnton Khirnov <anton@khirnov.net>2024-02-18 07:33:27 +0100
commit78812cd147fa2ab1f0aa3019886c0abe00b7c63a (patch)
treebdd92f660d20f0303ceed51cb118f4942acf0242 /libavcodec/msvideo1enc.c
parenta4f019e44ed6c48975109ac34f54e04caffeab86 (diff)
downloadffmpeg-78812cd147fa2ab1f0aa3019886c0abe00b7c63a.tar.gz
avcodec/h2645_parse: Don't treat 0x000002 as a start code and truncate
According to ITU-T H.265 7.4.2.1 this byte sequence should not appear in a NAL unit but in practice in rare cases it seems it does, possibly due to buggy encoders. Other players like VLC and Quicktime seem to be fine with it. Currently when this sequence is found it is treated as if the next start code has been found and the NAL unit gets truncated. This change limits the code to only look for first start code 0x0000001 or first escape 0x000003. Sadly i can't share the original source file with the issue but the first 80 bytes of the NAL unit looks like this: │00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f│0123456789abcdef│ 0x00000│00 00 00 01 02 01 d0 bc 57 a1 b8 44 70 01 00 0b│........W..Dp...│ 0x00010│80 2e 00 c2 6c ec 3e b9 e3 03 fb 91 2e d2 43 cb│....l.>.......C.│ 0x00020│1d 2c 00 00 02 00 02 00 5c 93 72 6f 31 76 18 00│.,......\.ro1v..│ 0x00030│08 38 aa b1 4c 33 3f fd 08 cb 77 9b d4 3c db 02│.8..L3?...w..<..│ 0x00040│a2 04 73 15 75 de 3b c4 67 c0 8f ca ad 31 f1 99│..s.u.;.g....1..│ Signed-off-by: Anton Khirnov <anton@khirnov.net>
Diffstat (limited to 'libavcodec/msvideo1enc.c')
0 files changed, 0 insertions, 0 deletions