[FFmpeg-devel] asf.c: fix for "random" ftell() reponse
Sun Dec 14 21:04:02 CET 2008
On Sun, Dec 14, 2008 at 02:58:46PM -0500, Ronald S. Bultje wrote:
> On Sun, Dec 14, 2008 at 2:36 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sun, Dec 14, 2008 at 02:08:22PM -0500, Ronald S. Bultje wrote:
> >> for RTSP-MS, each packet has its own ByteIOContext, and thus the
> >> ftell() returned by it is invalid compared to the data read so far
> >> (because it resets to zero at each new ASF packet). This means that
> > and why does it do that?
> For RTSP, each RTP (or RDT) packet contains a single ASF (or RM, or
> whatever) packet. I send those to the demuxer using a local
> ByteIOContext variable (since RTSP doesn't use buffered I/O and thus
> has no ByteIOContext). I guess in a way it is also extra safe since an
> error in the demuxer wouldn't screw up the RTSP demuxer state, but
> anyway, that's debatable. The point is that I have a local
> ByteIOContext which I init using the RTP/RDT packet data. This means
> that after a header of 5kb and 2 packets of 2kb each, the demuxer
> would expect a value of 9kb for url_ftell(), but it will return 2kb at
> the end of the second packet and 0kb at the beginning of the third. I
> can fix that by manually setting ByteIOContext->pos to whatever value
> the demuxer wants, but it seemed kind of hackish to me (although it
> would solve the problem also).
> Of course, if you can think of a better way to solve the fact that
> off=0 (rather than >=3), I'm open to any such solution.
i definitly think that pos should not reset to 0 after each packet
it should only be 1-2 lines of code to keep counting ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel