[FFmpeg-devel] [RFC] Questions and suggestions regarding AVSEEK_FORCE?

[Michael Niedermayer]

On Tue, Mar 30, 2010 at 01:56:24PM +0200, Tomas H?rdin wrote:
> On Tue, 2010-03-30 at 11:42 +0200, Michael Niedermayer wrote:
> > On Tue, Mar 30, 2010 at 10:02:39AM +0200, Tomas H?rdin wrote:
> > > I've been testing this for a few days, and the only case I have been
> > > able to find where it behaves strangely is when skipping in DV on a
> > > pipe, as mentioned earlier. Digging a bit in the DV demuxer it seems it
> > > always comes exactly 12928 B out of alignment for a DV25 file, which
> > > obviously results in broken output. However, since the same file
> > > delivered via nonseekable HTTP is skippable this leads me to believe
> > > there is some problem with the pipe protocol.
> > 
> > any idea what it could be?
> > also did you check that none of the url_fseeks in dv* fail?
> > 
> > anyway, as said the patch should be ok
> > 
> 
> There's only one url_fseek() outside of dv_read_header() and that is in
> dv_read_seek(). I added some log output, and it returns the same value
> it is given (38016000 for instance). The value of 12928 I got from
> moding url_ftell() with sys->frame_size before the seek, which means
> it's not aligned with frame_size for some reason. That value is zero for
> nonseekable HTTP. Adding it to the calculated offset makes both cases
> work, but it's an awful hack.
> 
> Digging around some more it seems that offset stems from
> dv_read_header(). For some reason the four-byte state that should be
> 0x1f07003f (after anding) at dv.c:414 is 0x0a2feb0f instead. That does
> not match what the file says at all (which says 0x1f0700bf).
> Unsurprisingly, the proper value shows up 12928 B later. This leads me
> to believe something messes up the ByteIOContext buffer before
> dv_read_header() is called - probably after the probing is done.

maybe its:
    if (url_fseek(*pb, 0, SEEK_SET) < 0) {
        url_fclose(*pb);
        if (url_fopen(pb, filename, URL_RDONLY) < 0)
            return AVERROR(EIO);
    }
from ff_probe_input_buffer()

this doesnt look like it could work with pipes
what happens if you limit the max probing size there to a value smaller than
our internal buffer? (so seek back would be guranteed to work)

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- 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/20100331/685e9228/attachment.pgp>