[FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Dale Curtis]

Here's an updated patch with a fate test attached. You'll need to add
http://storage.googleapis.com/dalecurtis/buck480p30_na.mp4 to the
fate-suite/mov for this test. This is licensed under creative commons
attribution, so it should be fine for tests:
https://peach.blender.org/about/ I tried to use the existing samples, but
you need a clip long enough that the entire index isn't generated from the
start.

- dale

On Tue, Jul 25, 2017 at 1:03 PM, Michael Niedermayer <michael at niedermayer.cc
> wrote:

> On Mon, Jul 24, 2017 at 02:32:41PM -0700, Dale Curtis wrote:
> > On Thu, Jul 20, 2017 at 5:00 AM, Michael Niedermayer
> <michael at niedermayer.cc
> > > wrote:
> >
> > > Hi
> > >
> > > On Wed, Jul 19, 2017 at 07:30:01PM -0700, Dale Curtis wrote:
> > > > Thanks will take a look. Is this test not part of fate? make fate
> passed
> > >
> > > no, we should have tests for all (fixed) tickets in fate ideally
> > > but in reality most tickets lack a corresponding test
> > > I tried both in outreachy and as well in GSoC to improve this situation
> > > with student projects but both only moved this forward by a small
> > > step. Its a large amount of work to create robust, portable and
> > > practical tests for "all" tickets and everything else.
> > > The way out to get this actually done would be to pay a developer to
> > > create tests for "all" tickets in fate. I belive carl would be the
> > > ideal one to do this work as he has since a very long time always
> tested
> > > and kept track of all our tickets.
> > > I did suggest a while ago to someone at google that funding such
> > > project would make sense but IIRC i never heared back.
> > > if some company would fund something like this, i belive this would be
> > > very usefull in the long run for code quality
> > >
> >
> > I think it'd be pretty hard to get someone to go through and create tests
> > for every issue ever seen. Even Chromium has trouble with this, but
> making
>
> yes, unless theres someone who enjoys doing this kind of work.
>
>
> > it part of the culture helps. I.e. reviewers should ask for every change
> to
> > include a test.
>
> yes though theres already
> 1.8 patch submission checklist
> ...
> 26. Consider adding a regression test for your code.
> on http://ffmpeg.org/developer.html
>
>
> > I'm happy to add one to fate for this change. Or can do so
> > in a followup patch if you prefer.
>
> please do (any variant is fine)
>
> thx
>
> >
> > Does anyone have comments on this change specifically? We've already
> rolled
> > this into Chrome and it's working fine and passing all regression tests.
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Breaking DRM is a little like attempting to break through a door even
> though the window is wide open and the only thing in the house is a bunch
> of things you dont want and which you would get tomorrow for free anyway
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctts_fix_v5.patch
Type: text/x-patch
Size: 22095 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170731/3c6dee67/attachment.bin>