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

Reimar Döffinger Reimar.Doeffinger
Wed Mar 11 10:31:25 CET 2009


On Wed, Mar 11, 2009 at 02:14:44AM -0700, Baptiste Coudurier wrote:
> On 3/10/2009 1:54 AM, Reimar D?ffinger wrote:
> > On Tue, Mar 10, 2009 at 01:21:52AM -0700, Baptiste Coudurier wrote:
> >> 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.
> > 
> > Here is a patch that uses this. But, compared to my other suggestion it
> > might not work for DV files that are broken differently (the section we
> > are checking for does not seem important, so I would expect there will
> > be DV files that lack it, even if it violates the specification).
> > Also it requires seeking.
> 
> In fact, it seems the demuxer seeks anyway in read_header, so I guess
> the patch should be fine.

It still might support less files than the original code, even if we
have no samples. I also do not know if the specific way this file is
"broken" is in any way common.
There is also the option of using _both_ this patch and the extra
demuxer for the really bad cases, which should also "re-enable" the
extension-based autodetection...




More information about the ffmpeg-devel mailing list