Opened 3 years ago
Last modified 2 years ago
#9732 new defect
The mov demuxer does not correctly read the `cprt` box
Reported by: | Xiaolei Yu | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | mov |
Cc: | IvanB | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
The mov demuxer does not correctly read the cprt
box specified in ISO/IEC 14496-12.
Metadata boxes specified in 3GPP use the same layout and are also handled incorrectly.
How to reproduce:
Use the following command to generate a 3gp file
% ffmpeg -f lavfi -f color -frames:v 1 -c:v libx264 -metadata copyright=abcdefg out.3gp
% ffmpeg -i out.3gp
produces:
ffmpeg version N-106627-g61d0b1d21f Copyright (c) 2000-2022 the FFmpeg developers built with gcc 11 (Debian 11.2.0-18) configuration: --cc=/usr/lib/ccache/gcc --enable-gpl --enable-libx264 libavutil 57. 24.101 / 57. 24.101 libavcodec 59. 26.100 / 59. 26.100 libavformat 59. 22.100 / 59. 22.100 libavdevice 59. 6.100 / 59. 6.100 libavfilter 8. 33.100 / 8. 33.100 libswscale 6. 6.100 / 6. 6.100 libswresample 4. 6.100 / 4. 6.100 libpostproc 56. 5.100 / 56. 5.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'out.3gp': Metadata: major_brand : 3gp6 minor_version : 256 compatible_brands: 3gp6isomiso2avc1 copyright : copyright-eng : Duration: 00:00:00.04, start: 0.000000, bitrate: 300 kb/s Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 320x240 [SAR 1:1 DAR 4:3], 150 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
Change History (3)
comment:2 by , 3 years ago
Cc: | added |
---|
As I understand, current implementation of 'cprt' box reading is broken indeed (or at least doesn't conform to ISO/IEC 14496-12).
According to the specification the box should be a Full Box that contain language field, followed by the copyright text in utfstring
format (so either utf-8 or utf-16).
Current implementation reads this as a string length, followed by the actual string, which results in empty string. ("version" field, =0, goes to "string length").
I wonder if somebody have any samples (maybe from some custom mov/mp4 dialect) where 'cprt' box correspond to the current implementation. If there are some, probably we need to find a way to somehow distinguish the types of the boxes we read.
The same thing is also true for the most of 3gpp metadata boxes. For example, according to 3GPP specification, 'gnre' (genre) is written in a similar way to ISO/IEC 14496-12's 'cprt' (so as a FullBox + language + utfstring), but we read it as id3v1_genre index.
comment:3 by , 2 years ago
Keywords: | mov added; cprt mp4 removed |
---|
Deleted