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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> 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.

If a decoder encounters an invalid value for a 'reserved' field, it
can mean one of three things:

1. Encoder used a later version of the spec.  The different values
   could mean anything, and the new syntax might not be compatible.
   Decoding will probably fail.

2. Encoder was buggy.  With luck, only the 'reserved' fields have bad
   values, and decoding will succeed.

3. File is damaged.  Depending on the extent of the damage, the
   recovery may be possible.

Unfortunately for us, determining which case applies to a specific
sample is difficult.

-- 
M?ns Rullg?rd
mans at mansr.com