[Ffmpeg-cvslog] Re: r5468 - trunk/libavformat/mov.c

Michael Niedermayer michaelni
Mon Jun 12 19:28:15 CEST 2006


Hi

On Mon, Jun 12, 2006 at 07:16:49PM +0200, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Mon, Jun 12, 2006 at 03:09:20PM +0200, bcoudurier wrote:
> >> Author: bcoudurier
> >> Date: Mon Jun 12 15:09:19 2006
> >> New Revision: 5468
> >>
> >> Modified:
> >>    trunk/libavformat/mov.c
> >>
> >> Log:
> >> simplify, completely ignore streams not recognized, that fixes seeking for some files
> > 
> > iam strongly against ignoring unrecogized streams, a demuxer should present
> > whats in the file to the user application, if this breaks seeking the bug
> > is somewhere else
> > 
> > 
> > [...]
> > 
> 
> You would be more in favor of presenting those CODEC_TYPE_MOV_OTHER
> streams ? 

i think yes ...


> Atm streams are not presented to libavformat but stays in the
> demuxer private layer.

yes, and iam not happy about the resulting mess of having to remap stream ids


> 
> I see no point presenting a stream the demuxer cannot demux.

hmm, the demuxer should be able to demux it, we just have no codec or 
muxer which can make sense of it or is there aother problem iam unaware of ?


> 
> Now, situation is:
> - either remove streams like I did.
> - present them to libavformat, assigning CODEC_ID_DATA or CODEC_ID_NONE.
> 
> Do you prefer the latter ?

yes

it would also be nice if we could remux (-*codec copy) these streams

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-cvslog mailing list