Ok, further analysis brought up that it seems to be connected to both, some properties of the source file, could be the actual picture "content" AND the final duration of the file as i explained before - the stuff with -12 frames and such...
Still we did not yet decide how to proceed, so i'll be back once more, stay tuned!
Some encoded MXF files not compatible with Avid consolidating
Re: Some encoded MXF files not compatible with Avid consolidating
emcodem, wrapping since 2009 you got the rhyme?
Re: Some encoded MXF files not compatible with Avid consolidating
Aaaaand... durmrolls...
we decided to to for ClosedGOP and hope the problem is then worked around. Which hopefully saves me a lot of time because i don't have to tell the ffmepg guys about the bug
Please wait about 2 weeks...
we decided to to for ClosedGOP and hope the problem is then worked around. Which hopefully saves me a lot of time because i don't have to tell the ffmepg guys about the bug
Please wait about 2 weeks...
emcodem, wrapping since 2009 you got the rhyme?
Re: Some encoded MXF files not compatible with Avid consolidating
Ok, and as a further update on this; hopefully actually pretty valuable information for some people out there.
In the end, it turned out that it does not seem to be possible to generate Closed GOP XDCAMHD mpeg mxf streams using ffmpeg at the current time.
So after all we did have to investigate this issue in depth and it turns out that ffmpeg would generate this fault mpeg stream whenever the "INPUT AUDIO is shorter than the INPUT AUDIO".
Description of the Problem:
The input file showed less audio duration than video duration. Additionally it showed a certain duration which lead the output file to end on a P frame (stored order) instead of e.g. an I frame.
Technical details:
the mxf muxer discards any packets that do not carry matching audios to the corresponding videos by default, without taking care if the finally received GOP from the MPEG encoder delivered a valid GOP. As the Audio stream of this source file was shorter than it's video stream we therefore ended up with an invalid "Temporal reference" for one of the last 2 frames in the GOP and therefore also an implausible MXF index temporal flag of the frame in question.
After all, we were able to solve this issue hopefulle by adding the "apad" filter to our generated ffmpeg command which obviously used to generate missing audios.
Further technical details:
We were under the impression that we take already care of these kind of issue by using the -shortest flag of ffmpeg but obviously our implications regarding this flag were wrong. Also, we did not open an issue with the ffmpeg group because after knowing whats causing the problem, it seems to be pretty clear that the use of the filter "apad" is just kind of mandatory in this very case. The issue is by design and not a bug.
Anyway, it should be solved in the next release 1.2, so no more invalid mpeg streams generated in the XDCAMHD encoder node when the input has less audio than video.
In the end, it turned out that it does not seem to be possible to generate Closed GOP XDCAMHD mpeg mxf streams using ffmpeg at the current time.
So after all we did have to investigate this issue in depth and it turns out that ffmpeg would generate this fault mpeg stream whenever the "INPUT AUDIO is shorter than the INPUT AUDIO".
Description of the Problem:
The input file showed less audio duration than video duration. Additionally it showed a certain duration which lead the output file to end on a P frame (stored order) instead of e.g. an I frame.
Technical details:
the mxf muxer discards any packets that do not carry matching audios to the corresponding videos by default, without taking care if the finally received GOP from the MPEG encoder delivered a valid GOP. As the Audio stream of this source file was shorter than it's video stream we therefore ended up with an invalid "Temporal reference" for one of the last 2 frames in the GOP and therefore also an implausible MXF index temporal flag of the frame in question.
After all, we were able to solve this issue hopefulle by adding the "apad" filter to our generated ffmpeg command which obviously used to generate missing audios.
Further technical details:
We were under the impression that we take already care of these kind of issue by using the -shortest flag of ffmpeg but obviously our implications regarding this flag were wrong. Also, we did not open an issue with the ffmpeg group because after knowing whats causing the problem, it seems to be pretty clear that the use of the filter "apad" is just kind of mandatory in this very case. The issue is by design and not a bug.
Anyway, it should be solved in the next release 1.2, so no more invalid mpeg streams generated in the XDCAMHD encoder node when the input has less audio than video.
emcodem, wrapping since 2009 you got the rhyme?