[FFmpeg-devel] [PATCH] MXF index table based seeking

Tomas Härdin tomas.hardin at codemill.se
Wed Nov 9 11:10:55 CET 2011

On Sat, 2011-11-05 at 17:40 +0100, Michael Niedermayer wrote:
> On Sat, Nov 05, 2011 at 02:28:20PM +0100, Georg Lippitsch wrote:
> > Hi!
> > 
> > Are there any news regarding review/rework of this MXF patch?
> > IIRC there were some objections against committing, but no one ever
> > told me what was missing or wrong.
> Iam also a bit unhappy about the state of the review/rework and ive
> largely lost track of what is waiting on what.
> are there any patches or git repositories that are in their authors
> oppinon ok to be commited? any that are waiting for a review ?
> any review comments that are waiting to be implemented ?
> also testcases that show bugfixes or improvemnts would help
> what about https://github.com/Tjoppen/FFmpeg ?
> is some of this ready ? what is holding it up ?

Sorry, I've been busy with thesis work and work-work. Here's a quick
status update:

- I have yet to include Georg's single_eubc patch (mxfdec: Avoid index
table parsing if only a single segment with no entries is present)
- The changes to mxf_read_header() in 4ac9511 (mxfdec: Parse
IndexTableSegments and convert them into AVIndexEntry arrays) belong in
44af6ee (mxfdec: Clip wrapping and seeking support)
- The seeking only works properly if the file uses one single contiguous
essence container (OpAtom does). In all other case the seeking will be

The last point requires quite a bit of logic to fix since MXF allows
essence containers to be split over partitions. Seeking didn't work
properly before though, so at least it's not worse. I suppose we can
save fixing this for later?

Basically, we have: Op1a demuxes fine but seeks won't end up exactly
where you expect (just like before). OpAtom demuxes fine and seeks work
properly (AFAICT).


More information about the ffmpeg-devel mailing list