[FFmpeg-devel] [RFC] special "broken DV" demuxer

Reimar Döffinger Reimar.Doeffinger
Tue Mar 10 16:44:19 CET 2009


On Tue, Mar 10, 2009 at 03:52:56PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 10, 2009 at 09:18:56AM +0100, Reimar D?ffinger wrote:
> > On Mon, Mar 09, 2009 at 04:40:13PM -0700, Roman V Shaposhnik wrote:
> > > On Sun, 2009-03-08 at 18:28 +0100, Reimar D?ffinger wrote:
> > > > in our samples there is one horribly broken DV file:
> > > > http://samples.mplayerhq.hu/V-codecs/DVSD/pond.dv
> > > > As far as I can tell (with my limited understanding of the DV format)
> > > > this is basically some DV headers "randomly" placed and then
> > > > the data essential to decoding DV written over it.
> > > 
> > > Huh? pond.dv used to be a perfectly good DV sample.
> > 
> > My judgement is limited since I never read the DV spec, but I find it
> > hard to believe that a file without header, audio or video sections,
> > half of the bits marked as "reserved, must be 1" in our encoder set to 0
> > etc. qualifies as "perfectly good".
> 
> Ive not checkd the spec but in general i interpret "reserved" as
> * encoder must set it to the value the specific spec says
> * decoder must not depend on its value
> * future specs may use reserved values differently and thus future
>   encoders may set them to different values.

IMO
* decoder should check them if easily possible, and warn that either the
  encoder is broken or it might misunderstand the data in the file.

If like for DV (almost) no decoder does that you end up with load of
messed-up files and you could just have saved the space that those
reserved bits use up because you can't un-reserve them anyway since
it would break lots of old files (unless you store purely informational
data).
But this has no relation with whether that file is valid or not...




More information about the ffmpeg-devel mailing list