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

[Reimar Döffinger]

On Tue, Mar 10, 2009 at 04:51:15PM -0700, Roman V Shaposhnik wrote:
> On Tue, 2009-03-10 at 20:04 +0100, Reimar D?ffinger wrote:
> > On Tue, Mar 10, 2009 at 11:58:57AM -0700, Roman V Shaposhnik wrote:
> > > > > > 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.
> > 
> > My suggestion with the separate demuxer will restore exactly the same
> > behaviour, except that it will also play badly cut files if the have a
> > header section and in addition will never require seeking.
> 
> So the only issue at hand is how to support autodetection, right? 
> Would it be possible to read a 1st frame and feed it to the decoder?

How do you know know where a frame starts and where it ends?
Also you can't use the DV decoder to detect if something is a DV frame,
the MPlayer DV demuxer does that and it detect almost any random crap as
valid DV. It even decodes "fine", except that it is random crap.
I am not sure how many bits are actually checked but I'd expect 16 bits
would be a high estimate. Often 20 or more frames were played before an
error (sometimes even before a resolution change), so for a reliable
autodetection my estimate is that you would have to read at least 50 DV
frames.

> > > 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. 
> > 
> > Then someone should simplify our DV encoder because it is full of stuff
> > like
> >                    0xc;       /* reserved -- always b1100 */
> > If that is not necessary that is an extreme amount of bloat.
> 
> Well, sticking to the spec does add complexity. Which is, I suspect,
> the reason quite a few hardware DV encoders don't give a rip about
> some of these. Michael had a good summary of how the specs in general
> are supposed to be implemented.

There is a difference between "reserved stuff may be whatever it wants"
and "we should try to support wrong values for reserved stuff". What you
said sounded like the former.
And yes it makes a difference, because in the second case
1) it's ok (and IMO advisable) to call those files broken
2) it is unreasonable to support those broken files too much at the expense of
the correct ones.

The current code e.g. can find and play a DV file in the middle of a CD
image, without need for mounting it first (I know, not a particularly
common use case).
By using those demuxers split like that you can still use -f dv to make
it work for that case.
I can justify different demuxers differently: for "correct" DV files
proper autodetection is simple and reliable, needs reading only a few
bytes and does not needs seeking nor relevant amount of buffering.
When you allow anything non-critical to be missing, allow reserved
values to have any value etc. autodetection will require reading and
analyzing huge amounts of data and IMO is not really feasible, nor does
it allow to implement a reliable read_timestamp which would be necessary
to support seeking in DV files that consist of part with different
resolutions/DV frame sizes.
You also can not do any error detection/recovery, nor can you reliably
resync. That for me justifies making those two distinct formats.