Ticket #2313 (new defect)
-metadata option puts null characters in, confusing iTunes.
| Reported by: | STrRedWolf | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avformat |
| Version: | unspecified | Keywords: | mov metadata |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Summary of the bug: If you use the -metadata option while converting video to an iTunes playable M4V, iTunes will refuse to recognize the file; it'll just ignore it. It will do a bit of analysis if you load a bulk of them up, but then ignore the whole batch if they all use the -metadata option.
A check with AtomicParsley? says that many of the atoms in the M4V have null-terminated values... which is not allowed and causes iTunes to think the file is bad.
How to reproduce:
% ffmpeg -i input -acodec libfaac -ac 2 -ab 160k -c:v libx264 -vprofile main -preset slow -tune film -level 3.1 -crf 28 -threads 0 -metadata media_type=10 -metadata network=FakeNetwork -metadata "show=Convention Archive" -metadata "title=ComicCon Cotham City" -metadata season_number=1 -metadata episode_sort=1 -metadata "track=1/1" -metadata episode_id=output output ffmpeg version 1.1.2 Copyright (c) 2000-2013 the FFmpeg developers built on Feb 17 2013 18:35:29 with gcc 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2) configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-O2 -pipe -march=native' --extra-cflags='-O2 -pipe -march=native' --extra-cxxflags='-O2 -pipe -march=native' --disable-static --enable-gpl --enable-version3 --enable-postproc --enable-avfilter --disable-stripping --disable-debug --disable-doc --disable-network --disable-vaapi --disable-runtime-cpudetect --enable-libmp3lame --enable-libvo-aacenc --enable-libtheora --enable-libx264 --enable-libxvid --enable-libfaac --enable-nonfree --enable-libdc1394 --disable-indev=oss --enable-x11grab --enable-libpulse --disable-outdev=oss --enable-libfreetype --enable-pthreads --enable-libvorbis --enable-libopenjpeg --disable-altivec --disable-avx --disable-vis --disable-neon --cpu=host --enable-hardcoded-tables libavutil 52. 13.100 / 52. 13.100 libavcodec 54. 86.100 / 54. 86.100 libavformat 54. 59.106 / 54. 59.106 libavdevice 54. 3.102 / 54. 3.102 libavfilter 3. 32.100 / 3. 32.100 libswscale 2. 1.103 / 2. 1.103 libswresample 0. 17.102 / 0. 17.102 libpostproc 52. 2.100 / 52. 2.100
Change History
comment:1 Changed 3 months ago by cehoyos
- Keywords mov metadata added
- Component changed from FFmpeg to avformat
comment:2 Changed 3 months ago by STrRedWolf
Let me see if I can reduce it down. I doubt I need to transcode it to show the bug. I'm now transcoding a clean file that I can test with...
tygris@sandra ~/video/tmp $ ffmpeg -i test-clean.m4v -c:v copy -c:a copy -metadata "title=AC2004 clip" -metadata media_type=10 -metadata network=BBFTV -metadata "show=BBFTV Test clip" -metadata season_number=1 -metadata episode_sort=1 -metadata "track=1/1" -metadata "episode_id=test-dirty.m4v" test-dirty.m4v
ffmpeg version 1.1.2 Copyright (c) 2000-2013 the FFmpeg developers
built on Feb 17 2013 18:35:29 with gcc 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2)
configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-O2 -pipe -march=native' --extra-cflags='-O2 -pipe -march=native' --extra-cxxflags='-O2 -pipe -march=native' --disable-static --enable-gpl --enable-version3 --enable-postproc --enable-avfilter --disable-stripping --disable-debug --disable-doc --disable-network --disable-vaapi --disable-runtime-cpudetect --enable-libmp3lame --enable-libvo-aacenc --enable-libtheora --enable-libx264 --enable-libxvid --enable-libfaac --enable-nonfree --enable-libdc1394 --disable-indev=oss --enable-x11grab --enable-libpulse --disable-outdev=oss --enable-libfreetype --enable-pthreads --enable-libvorbis --enable-libopenjpeg --disable-altivec --disable-avx --disable-vis --disable-neon --cpu=host --enable-hardcoded-tables
libavutil 52. 13.100 / 52. 13.100
libavcodec 54. 86.100 / 54. 86.100
libavformat 54. 59.106 / 54. 59.106
libavdevice 54. 3.102 / 54. 3.102
libavfilter 3. 32.100 / 3. 32.100
libswscale 2. 1.103 / 2. 1.103
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 2.100 / 52. 2.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test-clean.m4v':
Metadata:
major_brand : M4V
minor_version : 512
compatible_brands: isomiso2avc1
encoder : Lavf54.59.106
Duration: 00:00:30.04, start: 0.021333, bitrate: 641 kb/s
Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 720x576 [SAR 1:1 DAR 5:4], 475 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s
Metadata:
handler_name : SoundHandler
File 'test-dirty.m4v' already exists. Overwrite ? [y/N] y
Output #0, ipod, to 'test-dirty.m4v':
Metadata:
major_brand : M4V
minor_version : 512
compatible_brands: isomiso2avc1
episode_id : test-dirty.m4v
title : AC2004 clip
media_type : 10
network : BBFTV
show : BBFTV Test clip
season_number : 1
episode_sort : 1
track : 1/1
encoder : Lavf54.59.106
Stream #0:0(und): Video: h264 (avc1 / 0x31637661), yuv420p, 720x576 [SAR 1:1 DAR 5:4], q=2-31, 475 kb/s, 25 fps, 12800 tbn, 12800 tbc
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, 160 kb/s
Metadata:
handler_name : SoundHandler
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 750 fps=0.0 q=-1.0 Lsize= 2351kB time=00:00:30.03 bitrate= 641.3kbits/s
video:1740kB audio:587kB subtitle:0 global headers:0kB muxing overhead 1.020305%
Just one -metadata will not do the trick. No need to transcode.



Is video encoding necessary to reproduce this problem? If not, please add -vn to your command line.
Is one metadata option sufficient to reproduce the problem? If yes, please remove the others.
Is using libfaac necessary to reproduce the problem? If not, please use the native aac encoder (-acodec aac) to show the bug.
To make this a valid ticket, please post your command line together with complete, uncut console output.