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

[Michael Niedermayer]

On Wed, Nov 09, 2011 at 11:10:55AM +0100, Tomas Härdin wrote:
> 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
> off
> 

> 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?

You and baptiste are our mxf maintainers, what has to be fixed and
what not is your twos decission. More precissely you have a git repo
and its your decission what you consider ok for it.
i will merge it when you say its ready to be merged

if you want my oppinon, then yes fixing this later sounds like the
better approach


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111109/82c42d6c/attachment.asc>