Demux Error with AVC 422 Intra - Not supported ?

[Nicolas]

Summary of the bug:

Intra files from Canon EOS Mark II/III (video codec is AVC 422 Intra) seems to not be fully supported ? I have several files like this and all give me the same error : impossible to demux/remux with ffmpeg.exe and Color Issue if using my own application using ffmpeg libraries.

Full Description :

When trying to demuxing/remuxing such clip with ffmpeg.exe, it returns an error :

Command :

ffmpeg -ss 0 -i in.MXF -t 1 -c copy out.MXF
ffmpeg compiled from master branch the 17/12 - Commit 571e8ca2dd
built on Win10

The error :

Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[mxf @ 000002433EAFAE80] Received non-video packet before header has been written speed=0.996x
Error writing trailer of out.MXF: Invalid data found when processing input

I also tried to demux/remux it with the ffmpeg libraries : I coded a program which trim files with ffmpeg, so demux/remux with in/out frames, like the ffmpeg command I provided above.

With this program it kind of works, I manage to copy the frames and I get a readable file at the end, but the color slighlty changed (a bit like a change in exposure), maybe it could come from some a special ColorSpace option which changed or not detected when demuxing or an other things ? Note that the ColorShift is only visible when I open the resulting trimmed file in Premiere Pro. It is not visible when opening the file on VLC.

I suppose this color Shift I get is related to the error I get when running ffmpeg.exe, that's why I didn't open 2 different issues here.

File sample to reproduce :

I don't have a lot of files example, and the ones I get are huge compared to the sample size accepted (from the bug report). I selected the most little one I get and it is 100Mo large. Here is a direct link to get/test it :
​https://www.dropbox.com/s/z9z9jdf1dm16o4e/Canon_ColorDemuxIssue_422HighIntra.MXF?dl=0

(I will not remove the file from dropbox until the bug is fixed).

Note : Sorry if it is the wrong category, it looks like a bug but could be a feature request maybe ?

[mkver]

I can not reproduce the "[mxf @ 000002433EAFAE80] Received non-video packet before header has been written" error that you claim to receive.

[Nicolas]

Replying to mkver:

I can not reproduce the "[mxf @ 000002433EAFAE80] Received non-video packet before header has been written" error that you claim to receive.

Thanks for testing ! Indeed I should have started by testing with an official build.

There is actually no error with the ffmpeg command when testing the officiel 4.4.1 or latest master from ​https://www.gyan.dev/ffmpeg/builds/ as you told.

So the command error should come from how I compile ffmpeg.

The Color Range error is still present though when reading the file in Premiere Pro, so something changed in the file before/after, like a metadata or something which is interpreted by Premiere Pro ..

If I check the before/after metadata with "Media Infos", there are 2 things to notice :

First the "Format Profile" on the video stream from "High 4:2:2 Intra@L5.1" becomes "High 4:2:2@L5.1" so the "Intra" is removed. Could be harmless ?

Second, there is a "Color range" data on the video stream which has value "Min: 0, Max: 1023, Chroma range: 1023" and is not present in the final file. Maybe this change involves the "Color Changed" issue ?

[Balling]

Please note that mxf is using Annex B AVC bitsream, so if you go from mp4 that technically does not support Annex B you must insert -bsf h264_mp4toannexb. See this patch by mkver: ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/AM7PR03MB66600B2742E305A97C277D898F929@AM7PR03MB6660.eurprd03.prod.outlook.com/

As for how to compile ffmpeg, well usually the problem is you used wrong libraries for the ffmepg as an application, Color range for mxf for only recently added.

And you are right. With latest build from ​https://github.com/BtbN/FFmpeg-Builds it says

Stream size                 : 47.7 MiB (100%)
Color range                 : Full
Matrix coefficients         : BT.709
Format_Profile_Original     : High 4:2:2 Intra@L5.1

which is colour_range_Original and is the same as Color range: Min: 0, Max: 1023, Chroma range: 1023 same for Format_Profile_Original which now says High 4:2:2 Intra@L5.1.

But that is correct: for new file Color range - 1024 (0x400) (8 bytes) which is correct because you count from 1 there abd58a4192e4c5ea721b22365c211d8fa874f3d2 (I suppose 0 is reserved for something?).

Also, the problem is that

000177E  Profile Constraint (5 bytes)
000177E   Header (4 bytes)
000177E    Code:                                32777 (0x8009)
0001780    Length:                              1 (0x0001)
0001782   constraints (1 bytes)
0001782    constraint_set0_flag:                No
0001782    constraint_set1_flag:                No
0001782    constraint_set2_flag:                No
0001782    constraint_set3_flag:                Yes
0001782    constraint_set4_flag:                No
0001782    constraint_set5_flag:                No
0001782    reserved_zero_2bits:                 0 (0x0) - (2 bits)
0001783  Level - 5.1 (5 bytes)
0001783   Header (4 bytes)
0001783    Code:                                32778 (0x800A)
0001785    Length:                              1 (0x0001)
0001787   level_idc:                            51 (0x33)
0001788  Decoding delay - No (5 bytes)

is different in new file:

0001543  Level - 5.1 (5 bytes)
0001543   Header (4 bytes)
0001543    Code:                                33282 (0x8202)
0001545    Length:                              1 (0x0001)
0001547   level_idc:                            51 (0x33)
0001548 Timeline Track - Valid from Package (97 bytes)

so no Profile Constraint.

[Nicolas]

Thanks for the feedback !

Please note that mxf is using Annex B AVC bitsream, so if you go from mp4 that technically does not support Annex B you must insert -bsf h264_mp4toannexb. See this patch by mkver

Thanks for the info, however here I'm just going from MXF to MXF !

which is colour_range_Original and is the same as Color range: Min: 0, Max: 1023, Chroma range: 1023 same for Format_Profile_Original which now says High 4:2:2 Intra@L5.1.

But that is correct: for new file Color range - 1024 (0x400) (8 bytes) which is correct because you count from 1 there abd58a4192e4c5ea721b22365c211d8fa874f3d2 (I suppose 0 is reserved for something?).

I'm not sure to follow, are you saying that going from "High 4:2:2 Intra@L5.1" to "High 4:2:2 @L5.1" + Color_Range change is normal then ?

so no Profile Constraint.

Is it another bug ? Or could it be linked to the color shift we can see in Premiere Pro ?

[Balling]

Is it another bug ?

Yep. In ffmpeg.

Or could it be linked to the color shift we can see in Premiere Pro ?

No.

Color_Range change is normal then

Yes. Was that mxf file produced by Premier?

[Nicolas]

Thanks for the feedback.

Color_Range change is normal then

Yes. Was that mxf file produced by Premier?

So just to be sure of my understanding, for you both clips are different (in their header), but color should be interpreted in the same way (like VLC does for instance). So the color problem I see between before/after in PremierePro could be a bug from the PremierePro importer (which should but does NOT interpret the color in the same way for both clips) rather than a bug in the ffmpeg dexux/remux process ?

Also I'm unfamiliar with how ffmpeg and bug reporter interact usually. I'm also a developer but I'm not skilled enough / don't have enough time to fix ffmpeg internal bugs. I'm looking for someone which could help me for this "bug" (and others) and I could provide remuneration. Maybe I should more post a message in the mailing (ffmpeg-user ?) to ask for this ?

[Nicolas]

I found another media which has the same problem. However, it is not from a Canon Camera anymore but from a Sony one. It is still a MXF with High 4:2:2 Intra codec.

This time, MediaInfo has the following attribute on "ColorRange" :

Color range : Limited

Here is the file (1.64Gb) : ​LINK

[Carl Eugen Hoyos]

If your issue is not covered by ticket #9618, please open a new ticket that contains a command line (current FFmpeg git head) including the complete, uncut console output and points to a sample that is not 1.6G