[FFmpeg-trac] #8366(avformat:new): Audio ticks and video/audio out-of-sync when using MXF files with pre-charge
FFmpeg
trac at avcodec.org
Tue Nov 12 20:30:54 EET 2019
#8366: Audio ticks and video/audio out-of-sync when using MXF files with pre-
charge
------------------------------------+------------------------------------
Reporter: HenkDemper | Owner:
Type: defect | Status: new
Priority: normal | Component: avformat
Version: git-master | Resolution:
Keywords: MXF | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
------------------------------------+------------------------------------
Comment (by Tjoppen):
Replying to [comment:4 HenkDemper]:
> Replying to [comment:2 Tjoppen]:
> > This sounds like an OP3a file, despite what the header says, since
it's cutting off the start/end of a !FilePackage to make the
!MaterialPackage. Adding full OP3a support is a tall order of course.
Setting start_time on the relevant AVStreams might be enough in this case.
libavformat/mov.c does something similar for edit lists, but frankly it's
a horrible hack that doesn't belong in a demuxer..!
>
> Using the Origin field for (only) pre-charge purposes does not make the
MXF file OP3a.
Yes, it does. To quote S377m:
>Single item: The file contains only one item. There is a single material
package !SourceClip which is '''the same duration''' as the top-level file
package(s).
The MXF Book backs this up (page 27):
>In some applications, it may be desirable to play out only the central
contribution portion of our example file. In this case a material package
is used that describes only this central portion of the file, and not the
color bars, slate, or black portion of the stored content. The operational
pattern that describes this functionality is OP3a.
Replying to [comment:4 HenkDemper]:
> Logically (let's say viewable) it is still !SingleItem-!SinglePackage
and categorised as OP1a.
The file has Duration = 287 in the MP clips, but 299 in the FP clips.
Therefore it is not !SingleItem per 7.3.1 in S377m.
> I have sample files from Sony (Japan camera division) also with
!PreCharge in XDCAM (from their camera's/Servers) labelled as OP1a.
This wouldn't be the first time a vendor was wrong.
> > Any patch that attempts to fix this should take care that edit lists
are added both to remuxed MOVs and MXFs, and that such remuxed MXFs are
marked as OP3a.
>
> As mentioned I think that 'only' the Origin offset for audio must be
added/taken into account somewhere when audio samples are fetched, such
that for t = 0 in the MXF file the Edit Unit with value 'Origin' is used
instead of 0.
No, both audio and video have Origin > 0. It you only cut the audio then
the output will be horribly out of sync :)
I don't know how the ffmpeg CLI deals with start times on streams. Can it
be told to decode but discard the first Duration number of edit units?
What if Origin is very large? I do not want the same kind of hack that
libavformat/mov.c does for edit lists, that crap doesn't belong in a
demuxer.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8366#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list