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

[Baptiste Coudurier]

Hi Reimar,

On 3/10/2009 1:18 AM, 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".

It seems file is weird indeed.
However, it seems this file has some pattern which could be recognized
around offset 0x50 (3F 07 00), and after this file seems ok.

>>> Since it seems all DV decoders and demuxers including ours have no
>>> error checking whatsoever it still plays "fine".
>>> Unfortunately, the recently added autodetection, that also allows to
>>> play badly cut DV files, can not handle it.
>> Right. So the problem would be a regression, as far as I can tell.
>> Thus the question: can the autodetection code be fixed?
> 
> What do you mean? If it can be played automatically (based on the
> extension, as before)? My patch accomplishes that.
> Maybe the dv_video_source section could be really autodetected, but
> unless either almost all "reserved - must be 1" comments in the encoder
> are wrong or such files are very common, I am somewhat against that (and
> would suggest that we make our demuxer give big fat warnings about
> invalid files first before supporting them better, all those "read some
> constant offset and ignore everything else" that all DV decoders do only
> supports everyone creating files sloppily)...

It seems adding a probe function disabled the recognition of the
.dv extension. This is a bit odd, and maybe the probe code in lavf
could honor the extension if mentioned, and raise a bit the score.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org