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

[Tomas Härdin]

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.

/Tomas