[FFmpeg-trac] #7437(undetermined:new): clap atom values ignored by ffmpeg when remuxing to matroska
FFmpeg
trac at avcodec.org
Fri Sep 14 16:45:03 EEST 2018
#7437: clap atom values ignored by ffmpeg when remuxing to matroska
-------------------------------------+-------------------------------------
Reporter: kieranjol | Type: defect
Status: new | Priority: normal
Component: | Version:
undetermined | unspecified
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Summary of the bug:
Sample file - https://we.tl/t-KoBK9MnSLu
My MOV file contains a clap atom that defines the clean aperture width as
703/576, but an actual width of 720/576. QuickTime player will perform a
crop and only display the 703/576 area. When remuxing to Matroska or other
containers, I would have assumed that the expected behaviour would involve
this cropping information being written to the remuxed file, probably
using the various PixelCrop values within Matroska (
https://matroska.org/technical/specs/index.html ) Specifically, this
value is stored in the QuickTime file using numerators and demoninators as
such:
{{{
$ mediainfo --Details=1 clap.mov | grep clap -n10
284-ECE5C05C Clean Aperture (40 bytes)
285-ECE5C05C Header (8 bytes)
286-ECE5C05C Size: 40 (0x00000028)
287:ECE5C060 Name: clap
288-ECE5C064 apertureWidth_N: 41472 (0x0000A200)
289-ECE5C068 apertureWidth_D: 59 (0x0000003B)
290-ECE5C06C apertureHeight_N: 576 (0x00000240)
291-ECE5C070 apertureHeight_D: 1 (0x00000001)
292-ECE5C074 horizOff_N: 0 (0x00000000)
293-ECE5C078 horizOff_D: 1 (0x00000001)
294-ECE5C07C vertOff_N: 0 (0x00000000)
295-ECE5C080 vertOff_D: 1 (0x00000001)
}}}
It is somewhat related to this issue https://trac.ffmpeg.org/ticket/1485
How to reproduce:
Using my sample file - I would expect the following command to include
the cropping information but it does not. ffprobe does not seem to read
this cropping info, so mediainfo is useful to check the clap values. My
sample was generated directly from a VHS capture using the Blackmagic
Intensity Shuttle, with lots of dropped frames which doesn't relate to
this issue
{{{
% $ ffmpeg -i clap.mov -c copy mkv.mkv
ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 8.0.0 (clang-800.0.42.1)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.0.2 --enable-shared
--enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-
avresample --cc=clang --host-cflags= --host-ldflags= --enable-gpl
--enable-ffplay --enable-libass --enable-libfreetype --enable-libmp3lame
--enable-libtesseract --enable-libx264 --enable-libxvid --enable-opencl
--enable-videotoolbox --disable-lzma --enable-libopenjpeg --disable-
decoder=jpeg2000 --extra-
cflags=-I/usr/local/Cellar/openjpeg/2.3.0/include/openjpeg-2.3
libavutil 56. 14.100 / 56. 14.100
libavcodec 58. 18.100 / 58. 18.100
libavformat 58. 12.100 / 58. 12.100
libavdevice 58. 3.100 / 58. 3.100
libavfilter 7. 16.100 / 7. 16.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 1.100 / 5. 1.100
libswresample 3. 1.100 / 3. 1.100
libpostproc 55. 1.100 / 55. 1.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'clap.mov':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
creation_time : 2018-09-13T08:48:41.000000Z
Duration: 00:00:01.00, start: 0.000000, bitrate: 80686 kb/s
Stream #0:0(eng): Video: v210 (v210 / 0x30313276),
yuv422p10le(smpte170m/bt470bg/bt709, top coded first (swapped)), 720x576,
79626 kb/s, SAR 59:54 DAR 295:216, 9 fps, 25 tbr, 25k tbn, 25k tbc
(default)
Metadata:
creation_time : 2018-09-13T08:48:41.000000Z
handler_name : ?Apple Alias Data Handler
encoder : Uncompressed 10-Bit YUV
timecode : 00:00:00:00
Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz,
stereo, s32 (24 bit), 2304 kb/s (default)
Metadata:
creation_time : 2018-09-13T08:48:41.000000Z
handler_name : ?Apple Alias Data Handler
timecode : 00:00:00:00
Stream #0:2(eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
creation_time : 2018-09-13T08:48:41.000000Z
handler_name : ?Apple Alias Data Handler
reel_name : 001
timecode : 00:00:00:00
Output #0, matroska, to 'mkv.mkv':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
encoder : Lavf58.12.100
Stream #0:0(eng): Video: v210 (v210 / 0x30313276),
yuv422p10le(smpte170m/bt470bg/bt709, top coded first (swapped)), 720x576
[SAR 59:54 DAR 295:216], q=2-31, 79626 kb/s, 9 fps, 25 tbr, 1k tbn, 25k
tbc (default)
Metadata:
creation_time : 2018-09-13T08:48:41.000000Z
handler_name : ?Apple Alias Data Handler
encoder : Uncompressed 10-Bit YUV
timecode : 00:00:00:00
Stream #0:1(eng): Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz,
stereo, s32 (24 bit), 2304 kb/s (default)
Metadata:
creation_time : 2018-09-13T08:48:41.000000Z
handler_name : ?Apple Alias Data Handler
timecode : 00:00:00:00
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 9 fps=0.0 q=-1.0 Lsize= 9834kB time=00:00:00.40
bitrate=200899.4kbits/s speed=10.3x
video:9720kB audio:112kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.017699%
}}}
Patches should be submitted to the ffmpeg-devel mailing list and not this
bug tracker.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/7437>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list