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

[Michael Niedermayer]

On Wed, Mar 11, 2009 at 09:06:52AM +0100, Reimar D?ffinger wrote:
> 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.

May i suggest that people read and understand the dv specs before any further
hackery on the code?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090311/b0b4d7ae/attachment.pgp>