[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
Mon Nov 18 13:55:55 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:6 HenkDemper]:
> Hello Tjoppen,
>
> I have & read the MXF Book, know & implemented ST377, but I think the
original design idea about OP1a was to have a single '''logical''' clip
from start-to-end. Anyhow all places I can find these simple pre-charged
files (so only including pre-charge and roll-out) they are marked as OP1a.
There is just no other technical way to achieve this and when exchanging
files we (broadcast industry) don't want to label them (in this case) as
anything other than OP1a, exactly because what you state: there are not so
much MXF readers available that (claim) to support anything beyond OP1a...
This may well be the intent, but it's also not what the spec says :) But,
!OperationalPattern is just informative, the truth for any particular file
is in how its MPs and FPs are laid out.
> If we would like to be 100% sure, I might reach out to 'Mr MXF' (Bruce
Devlin) or others on the original MXF design team (that came up with the
OP's) and ask him/them for his/their advise on the subject... but given
that these files are actually frequently used/seen in practice it won't
change the use case, so maybe wasted time... In the end the goal should be
to let FFmpeg (/libavformat/VLC/...) cope with as many files as possible.
Agree ?
FFmpeg can certainly be made to support at least this class of files. At
some point it's better to let things like libmelt take over
> > No, both audio and video have Origin > 0. It you only cut the audio
then the output will be horribly out of sync :)
>
> Well, the video Origin is already used correctly in FFmpeg: the pre-
charge video frames (amount: Origin) are used used to produce the first
visible frame, but never displayed itself. So it would 'only' need
handling for the audio case, which is now out-of-sync with video if there
is pre-charge...
I didn't notice this when looking at the file, but perhaps ffplay does
sync differently from ffmpeg.
> > 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.
>
> We (as in our software) placed this pre-charge logic in the MXF file
reader (because it is specific to MXF files and handled differently in for
instance QuickTime files as mentioned). We first 'ask' the MXF reader
which 'media frame' (Source Package, Index Table) to fetch for 'display
frame' (viewable, Material Package) and then ask it to fetch that 'media
frame' (for audio that is. for video we need to dig back to fill the
decoder with pre-charge video frames). That would seem the proper 2-step
way supporting any media (single/multi-item) in a MXF (or any other
wrapper) file, with a split responsibility between the wrapper
(MXF/QuickTime/...) and upper layer I would say ?
>
> As mentioned, I'm not intimate with how this (timing, single/multiple
items in editlist/timeline, media vs display frames, pre-charge, ..)
should/is exactly be properly handled in FFmpeg, but my guess would be the
fix for the problem on-hand would be in libavformat\mxfdec.c. Happy to
study that code more (as a possible next step), but do not want (as you
mention) add 'crap in the wrong places'... So open for alternative
suggestions...
Well, exporting this information so that the ffmpeg CLI could make use of
it for all streams probably wouldn't hurt. But there are some use cases to
consider:
* remuxing MXF -> MXF
* remuxing MXF -> MOV
* remuxing MOV -> MXF
* transcoding MXF, including all frames and including EDL information
(only MOV and MXF out)
* transcoding MXF, cutting off the start and end, no EDL (any output
format)
I don't think there's any other containers that support EDL stuff, but I
may be wrong. Which of the bottom two to pick is sort of business logic..
If support for this were added then FFmpeg could claim support for "single
clip OP3a" perhaps
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8366#comment:7>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list