Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#3818 closed defect (wontfix)

Not possible to remux mp4 files from Sony XDCAM cameras

Reported by: rmk Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: mov
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Files from professional Sony XDCAMs produce files containing MPEG-2 video and PCM 16 audio in an mp4 container. ffmpeg does not allow to remux these files.

Sample command line and output:

ffmpeg -i xdcam.MP4 -c copy -y -strict experimental xdcam_remuxed.mp4
ffmpeg version N-64810-gf74f227 Copyright (c) 2000-2014 the FFmpeg developers

built on Jul 26 2014 21:40:24 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
configuration: --enable-gpl --enable-libx264 --enable-libfaac --enable-nonfree --extra-ldflags=-L/usr/local/lib --extra-cflags=-I/usr/local/include
libavutil 52. 92.101 / 52. 92.101
libavcodec 55. 69.100 / 55. 69.100
libavformat 55. 48.101 / 55. 48.101
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.102 / 4. 11.102
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100

Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'xdcam.MP4':

Metadata:

major_brand : mp42
minor_version : 0
compatible_brands: mp42
creation_time : 2011-07-15 14:58:27

Duration: 00:00:01.52, start: 0.000000, bitrate: 38413 kb/s

Stream #0:0(eng): Video: mpeg2video (Main) (mp4v / 0x7634706D), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 36861 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default)
Metadata:

creation_time : 2011-07-15 14:58:27
handler_name : Video Media Handler

Stream #0:1(eng): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, 2 channels, s16, 1536 kb/s (default)
Metadata:

creation_time : 2011-07-15 14:58:27
handler_name : NRT Metadata Handler

[mp4 @ 0x7f9254001800] Could not find tag for codec pcm_s16be in stream #1, codec not currently supported in container
Output #0, mp4, to 'xdcam_remuxed.mp4':

Metadata:

major_brand : mp42
minor_version : 0
compatible_brands: mp42
encoder : Lavf55.48.101
Stream #0:0(eng): Video: mpeg2video (a[0][0][0] / 0x0061), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 36861 kb/s, 25 fps, 25k tbn, 25k tbc (default)
Metadata:

creation_time : 2011-07-15 14:58:27
handler_name : Video Media Handler

Stream #0:1(eng): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, stereo, 1536 kb/s (default)
Metadata:

creation_time : 2011-07-15 14:58:27
handler_name : NRT Metadata Handler

Stream mapping:

Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)

Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument

Change History (9)

comment:1 Changed 5 years ago by rmk

Uploaded sample to /incoming/ticket3818

comment:2 Changed 5 years ago by cehoyos

  • Resolution set to wontfix
  • Status changed from new to closed

This is not a limitation of FFmpeg but the mp4 specification that does not allow pcm audio, see http://www.mp4ra.org/codecs.html

comment:3 Changed 5 years ago by rmk

While I believe you that this is true I thought ffmpeg had the policy of supporting files not in compliance with a certain spec at least on a case-by-case basis, provided they are out there in the wild and not from a crazy source (and maybe only when -strict experimental is set, which I thought it was for). A categorical decision like this means that people will have to use other tools (e.g. ffmbc can do it) when they want to create files like the one created by one of the most popular professional cameras. is the policy to only support decoding for those files? Anyway, of course it's the project developers' decision, fair enough. Should I need it, I can maintain a private patch. Just ran into it and thought I'd report it.

comment:4 follow-ups: Changed 5 years ago by Cigaes

“provided they are out there in the wild and not from a crazy source” is for reading non-standard files. This is indeed ffmpeg's policy. And ffmpeg can read your file.

For writing, that would be something like “provided there is a genuine need for it”.

As a side note, it seems that the MJPEG2000 specification defines “raw ” and “twos” that look like uncompressed PCM.

comment:5 in reply to: ↑ 4 Changed 5 years ago by cehoyos

Replying to Cigaes:

As a side note, it seems that the MJPEG2000 specification defines “raw ” and “twos” that look like uncompressed PCM.

In a related ticket, it was claimed that FFmpeg does not write (standard-conforming) MJPEG2000 files. I find that credible.

comment:6 Changed 5 years ago by cehoyos

  • Component changed from undetermined to avformat
  • Keywords mov added
  • Version changed from unspecified to git-master

comment:7 in reply to: ↑ 4 ; follow-up: Changed 5 years ago by rmk

Replying to Cigaes:

“provided they are out there in the wild and not from a crazy source” is for reading non-standard files. This is indeed ffmpeg's policy. And ffmpeg can read your file.

For writing, that would be something like “provided there is a genuine need for it”.

That's of course a grey area but as I do not have a strong case myself other than "why is it not possible like with other camera files", I think that position is generally a good thing.

As a side note, it seems that the MJPEG2000 specification defines “raw ” and “twos” that look like uncompressed PCM.

That's interesting.You mean there would actually be potential for confusion between a jpeg2000 video sample description and that of raw audio? That would be messy indeed. Thanks for the info.

comment:8 Changed 5 years ago by cehoyos

ISO 15444-3 - the specification that allows raw audio - defines that such files have the brand mjp2 (which is currently not supported by FFmpeg for output files) and not mp42. I wonder how Sony explains the creation of such files.

comment:9 in reply to: ↑ 7 Changed 5 years ago by cehoyos

Replying to rmk:

Replying to Cigaes:

As a side note, it seems that the MJPEG2000 specification defines “raw ” and “twos” that look like uncompressed PCM.

That's interesting. You mean there would actually be potential for confusion between a jpeg2000 video sample description and that of raw audio?

No, definitely not.

Note: See TracTickets for help on using tickets.