Converting a H264 MXF to a H264 MOV with "-vcodec copy" results in mov unreadable by QuickTime

[Arnaud]

Summary of the bug:

Using ffmpeg 2.5 (but doesn't work either with 2.6, 2.7 nor master)

How to reproduce:

%./ffmpeg -i h264_vid.mxf -vcodec copy  test.mov

Video is readable by most players (totem, VLC) but not Quicktime, which reports the following errors:
"chroma_format_idc too large for high profile" and "invalid H264 profile 122 and/or level 4.1"

Not using "-vcodec copy" results in a video readable by Quicktime, but with very poor quality.

The problem seems to be that in
avformat_open_input / mxf_read_header / mxf_parse_structural_metadata, we call "ff_generate_avci_extradata" if codec is H264, which uses a default set of extradata that Quicktime doesn't support AFAICT.

In avformat_find_stream_info, we actually find some (correct) extradata, but we don't set them because st->codec->extradata isn't NULL (already set in avformat_open_input), here:

if (st->parser && st->parser->parser->split && !st->codec->extradata)

As a workaround, when using ffmpeg's lib, removing the extra data between avformat_open_input call and avformat_find_stream_info fixes the issue.

I don't have a workaround when using command line.

[Arnaud]

I've put the original file on my Google Drive: ​https://drive.google.com/file/d/0BxAjgoe3PaRwdXV6ZGxpNzRxWHc/view?usp=sharing (since it exceeds the size limitation of the bug tracker)

[Carl Eugen Hoyos]

Please test current FFmpeg git head and please provide the command line that allows to reproduce the issue together with the complete, uncut console output to make this a valid ticket.

[Arnaud]

log ffmpeg-master git

[Arnaud]

Attached log when running ffmpeg built from git master head.
I confirm the issue is still present with this build.

Let me know if you need anything else. In any case the video in available (see comment 1) so you should be able to easily reproduce the problem.

[Carl Eugen Hoyos]

Replying to Arnaud:

In any case the video in available (see comment 1) so you should be able to easily reproduce the problem.

I disagree and please understand that while I am thankful that you opened this ticket, I have to add that I find it rude to use open source software without providing the local patches to the developers (no matter if the patches will be used or not).

$ ffmpeg -i h264_vid.mxf -vcodec copy out.mov
ffmpeg version N-74769-gc3cd1a7 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration:
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 59.100 / 56. 59.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.101 /  5. 40.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
[mxf @ 0x25783c0] "OPAtom" with 2 ECs - assuming OP1a
[mxf @ 0x25783c0] Could not find codec parameters for stream 0 (Video: none, none, 1920x1080): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
h264_vid.mxf: could not find codec parameters
Input #0, mxf, from 'h264_vid.mxf':
  Metadata:
    uid             : 6cb3041f-371a-4db9-b067-49cefe64abab
    generation_uid  : 12ae10af-ca72-4ea3-b60a-e02cb822de57
    company_name    : Doremi Labs, Inc.
    product_name    : LibMedia
    product_version : 1.0.0
    product_uid     : a1ed80d7-c157-6f4c-9b6b-03955342f5b9
    modification_date: 2015-08-27 08:36:22
    application_platform: QT
    material_package_umid: 0x060A2B340101010501010F201300000063D64B46740D4757919DA38E176A189C
    material_package_name: Material Package
    timecode        : 00:00:00:00
  Duration: 00:00:10.00, start: 0.000000, bitrate: 15664 kb/s
    Stream #0:0: Video: none, none, 1920x1080, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 24 tbn, 24 tbc
    Metadata:
      file_package_umid: 0x060A2B340101010501010F20130000009FE4956565C24E42BB0580426CF25316
      file_package_name: File Package: SMPTE 381M frame wrapping of AVC video elementary stream
[mov @ 0x25b4ac0] Codec for stream 0 does not use global headers but container format requires global headers
[mov @ 0x25b4ac0] Could not find tag for codec none in stream #0, codec not currently supported in container
Output #0, mov, to 'out.mov':
  Metadata:
    uid             : 6cb3041f-371a-4db9-b067-49cefe64abab
    generation_uid  : 12ae10af-ca72-4ea3-b60a-e02cb822de57
    company_name    : Doremi Labs, Inc.
    product_name    : LibMedia
    product_version : 1.0.0
    product_uid     : a1ed80d7-c157-6f4c-9b6b-03955342f5b9
    modification_date: 2015-08-27 08:36:22
    application_platform: QT
    material_package_umid: 0x060A2B340101010501010F201300000063D64B46740D4757919DA38E176A189C
    material_package_name: Material Package
    timecode        : 00:00:00:00
    encoder         : Lavf56.40.101
    Stream #0:0: Video: none, none, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 24 fps, 24 tbr, 24 tbn, 24 tbc
    Metadata:
      file_package_umid: 0x060A2B340101010501010F20130000009FE4956565C24E42BB0580426CF25316
      file_package_name: File Package: SMPTE 381M frame wrapping of AVC video elementary stream
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument

Anyway: This could be considered a regression since c5142a95a51320e65d80d6bca0eb69fcff05508f related to tickets #524, #1294 and #1666, could also be considered a duplicate of ticket #3499.

[Arnaud]

"I have to add that I find it rude to use open source software without providing the local patches to the developers (no matter if the patches will be used or not)."

You better watch your language.
I just said I provided the video to ease the investigation. I didn't said I won't help (actually the opposite, supposing "Let me know if you need anything else" means anything to you).

I just thought it would be easier for you to reproduce it on your computer, as I guess you have all you need to do so. I worked on lot of open source projects, and I always appreciate when users can send me buggy content to help to reproduce the problem, instead of just log files.

Regarding the "local patches", what are you talking about? I said I found a workaround, not a patch to ffmpeg, and explained the workaround. As this is application code, IMO it might be difficult to read, so I preferred to explain how to workaround the problem, instead of providing that might be difficult to read. But I can provide the code for sure *if you ask for it*

Actually, I'm not sure what you are expecting, but anyway, here is a snippet of my workaround (nothing complicated)

AVFormatContext *ic = NULL;
fmpeg_av_open_input_file(&ic, videoInputSource, NULL, 0);
...
// Begin workaround: remove extradata
AVCodecContext* icodec = ic->streams[i]->codec;
if (icodec)
{
  av_free(icodec->extradata);
  icodec->extradata = NULL;
  icodec->extradata_size = 0;
}
// End workaround
ffmpeg_av_find_stream_info(ic)

I've heard that ffmpeg's people have a bad reputation, of being rude and, unfortunately, given my experience with this first ticket opened, I tend to believe it's true.
I just wanted to help, not to heard that I'm *rude* because I didn't magically guess what you want.

[Carl Eugen Hoyos]

Replying to Arnaud:

Regarding the "local patches", what are you talking about?

Your sample does not work (at all) with current vanilla FFmpeg (including the version you posted the output for): It is not possible to reproduce the issue you describe without patching FFmpeg, see the console output I posted above. Either you are using a different sample or a different (patched) FFmpeg but you didn't provide the patch.

[Carl Eugen Hoyos]

Replying to Arnaud:

I've heard that ffmpeg's people have a bad reputation, of being rude and, unfortunately, given my experience with this first ticket opened, I tend to believe it's true.

Don't worry, it's only me;-)

[Arnaud]

Sorry for being a bit harsh: I didn't understand what you meant, and as I was just trying to honestly help, I didn't mean to be rude in any way.
As you didn't mentionned anything in your comment, I didn't paid attention to the log file.

I didn't realized this might have some importance, but indeed we use a slightly modified version to support h264 into MXF (the patch file is automatically applied, so I forgot about it). Actually, I'm not sure if this conforms to the spec or not...

I will attach it.
I guess the important part is the "AV_CODEC_ID_H264 /* H264 Frame wrapped */" in mxfdec.c

[Arnaud]

ffmpeg patch

[Carl Eugen Hoyos]

Replying to Arnaud:

Sorry for being a bit harsh:

Don't worry, we are used to it;-)

I didn't understand what you meant, and as I was just trying to honestly help, I didn't mean to be rude in any way.
As you didn't mentionned anything in your comment, I didn't paid attention to the log file.

I did mention that I disagree with your assumption that I am able to reproduce the issue. But even if not, why should I have posted your (exact) command line with the actual console output (that differs from the one you posted)?

I didn't realized this might have some importance, but indeed we use a slightly modified version to support h264 into MXF (the patch file is automatically applied, so I forgot about it).

You didn't remember it when I told you that you have local patches applied?
Sorry that you found my original comment rude, this forgetfulness was exactly what I meant.

Actually, I'm not sure if this conforms to the spec or not...

Imo, this makes no big difference for a decoding issue.

I will attach it.

Thank you. Ideally you would send a patch (only the mxf.c part) made with git format-patch to the development mailing list.
Can you make the dvvideo sample available?

I guess the important part is the "AV_CODEC_ID_H264 /* H264 Frame wrapped */" in mxfdec.c

I sent a different patch yesterday that I believe is slightly cleaner, but it's up to the maintainer to decide.

[Arnaud]

Replying to cehoyos:

I did mention that I disagree with your assumption that I am able to reproduce the issue. But even if not, why should I have posted your (exact) command line with the actual console output (that differs from the one you posted)?

My bad: I just read your comment and didn't have a look the the console output.

You didn't remember it when I told you that you have local patches applied?

I thought by "local changes" you were referring to the workaround I've found (so my confusion)

Ideally you would send a patch (only the mxf.c part) made with git format-patch to the development mailing list.

As you already submitted a patch ("Support more mxf files with codec_ul" if I'm right), do you think it's worth it?

Can you make the dvvideo sample available?

Regarding the diff in riff.c? I don't know why we needed this, not sure if I have a sample. Will try to find one.

[Carl Eugen Hoyos]

Replying to Arnaud:

Ideally you would send a patch (only the mxf.c part) made with git format-patch to the development mailing list.

As you already submitted a patch ("Support more mxf files with codec_ul" if I'm right), do you think it's worth it?

I believe the changes to mxf.c look important and should be committed and this is what I tried to explain above.
I cannot really comment on the changes to mxfdec.c, you should probably send them to get an actual review by a mxf maintainer.

Can you make the dvvideo sample available?

Regarding the diff in riff.c? I don't know why we needed this, not sure if I have a sample. Will try to find one.

Thank you!

[Carl Eugen Hoyos]

Possibly related sample provided by Matrox