[FFmpeg-cvslog] r11621 - trunk/libavformat/mov.c

[Michael Niedermayer]

On Mon, Jan 28, 2008 at 12:38:16AM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> >> > it creates race conditions with threads
> >> 
> >> No.
> >
> > If you set a RESET_CODEC flag in an AVPacket and update
> > codec_id width/height/extradata in AVCodecContext from the demuxer then the
> > decoder which can run in a seperate thread (see ffplay) will have these
> > values change below its fingers while still having older AVPackets to
> > decode
> >
> > so, there is a race condition
> 
> That's only a race condition if you allow the demuxer to mess with the
> codec parameters.  It's not an inherent, unsolvable race condition.
> The proper way of handling any such change is to emit a packet
> describing what changed.  Whatever comes next in the processing
> pipeline can then pick it up and apply the changes at the right point.

such packets would have to be generated by the muxer on seeking as well


> 
> >> > breaks ALL remuxing (even to mov)
> >> 
> >> No it does not break anything, if it's done well.
> >> Now don't even try to remux this stream into any other container not
> >> supporting this feature, this would be pointless, and real stream copy
> >> in mov case is to remux the whole stream in one track, not splitting them.
> >
> > its not pointless to remux one of the streams (for example the svq1 one
> > droping the rpza)
> > with multiple AVStreams thats just works
> 
> Your suggestion still breaks your very own ever-precious, completely
> lossless stream copy to the same container.

no, not neccessarily, the muxer just would have to merge the streams back
your variant with codec switch packets wouldnt have working stream copy
out of the box either but would need quite a bit of code to handle them


> 
> > It is dangerous to be right in matters on which the established authorities
> > are wrong. -- Voltaire
> 
> You're starting to sound and behave more and more as though you were
> one of these "established authorities", and I'm not liking it.

You sound like one who has few technical arguments if you have to resort
to such non technical attacks ...

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080128/3b480fde/attachment.pgp>