[FFmpeg-devel] [RFC] special "broken DV" demuxer
Roman V Shaposhnik
rvs
Tue Mar 10 19:58:57 CET 2009
On Tue, 2009-03-10 at 09:18 +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,
Fair enough.
> but I find it hard to believe that a file without header,
strictly speaking, raw DV files don't have anything that
resembles a dedicated header.
> audio or video sections,
I don't understand what you mean.
> > > 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?
I meant, that the file was playable before the change to the
autodetection.
> 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)...
I have to know more details on what exactly seems to be broken
in that stream to make a call. Its ok for reserved things to be
whatever they are.
Thanks,
Roman.
More information about the ffmpeg-devel
mailing list