[FFmpeg-devel] Fix -t with some formats

[Michael Niedermayer]

On Sat, Jun 11, 2011 at 12:11:33AM +0200, Etienne Buira wrote:
> On Fri, Jun 10, 2011 at 10:13:34PM +0200, Michael Niedermayer wrote:
> > On Fri, Jun 10, 2011 at 09:14:23PM +0200, Michael Niedermayer wrote:
> > > On Fri, Jun 10, 2011 at 02:00:40PM +0200, Etienne Buira wrote:
> > > > Hi all.
> > > > 
> > > > I recently ran into an issue recently reported on ffmpeg-user by Namsuk
> > > > Kim, despite it have been introduced a while ago.
> > > > This happened to me when transcoding an AVI source.
> > > > 
> > > > The issue is that with some formats, specifying -t ... does not stop
> > > > encoding, it just stops audio.
> > > > 
> > > > The attached patch fixes things for me (tm)(c).
> > > > 
> > > > Regards.
> > > 
> > > >  ffmpeg.c |    2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 81303204d76b9baa1ed304e566d3677575ecfe10  ffmpeg_fix_-t_with_some_formats.diff
> > > 
> > > applied, btw, if you use git, you can generate a patch by
> 
> Yes, I use git, but I didn't figure out a workflow I like with it (gonna
> have to lurk at docs).
> Is an attached format-patch better yet?

yes
applied
thx


> 
> > breaks:
> > TEST    lmlm4-demux
> > --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/lmlm4-demux  2011-06-07 17:56:53.828507600 +0200
> > +++ tests/data/fate/lmlm4-demux 2011-06-10 22:10:49.188506330 +0200
> > @@ -214,334 +214,3 @@
> >  0, 267267, 1327, 0x7d15307c
> >  1, 267840, 768, 0x8d766d40
> >  0, 270270, 1225, 0x1b5d0f5f
> > -0, 273273, 1173, 0x840efed5
> > -0, 276276, 1215, 0xa8e0035e
> > -0, 279279, 1295, 0x142918ca
> > -0, 282282, 1144, 0xf50cef50
> > -0, 285285, 1527, 0x7d13bd9d
> > -0, 288288, 5609, 0x1ae1921d
> > -0, 291291, 1303, 0xabdc264f
> > ...
> > 
> > Thus not yet pushed
> 
> That proves it works :)
> 
> By the way, I don't know if taking dts completely out of picture is a
> good idea, maybe it can be better than ist->pts. But then, I let
> someones who have better experience with many file formats than me
> comment.

well, i dont know what is best in practice. There are so many odd
half broken files that its hard to predict which will be worse

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20110611/4d0385b0/attachment.asc>