[FFmpeg-devel] [PATCH] rmdec.c: support for multirate files

Michael Niedermayer michaelni
Thu Jan 1 15:29:02 CET 2009

On Wed, Dec 31, 2008 at 06:56:47PM -0500, Ronald S. Bultje wrote:
> Hi,
> On Wed, Dec 31, 2008 at 4:22 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> > New patch attached.


> My patch adds a "cur_offset" variable that we seek to every next call
> to read_packet(). This obviously makes any sort of default seeking
> impossible, since we seek to one of the cur_offsets+framesizes
> whenever getting a new packet, thus making the previous call in the
> default av_seek() to url_seek() undone.

so your patch break the demuxer ...

> My questions:

> - is it bad practice to have a cur_offset variable and seek to it?

not as such, but it can be bad practice when there is code not expecting
this in the demuxer that is not updated

> - what if I would seek to it *before* returning from av_read_packet()?
> That way, I could get rid of the cur_offset and just cache the last
> timestamp and seek to the next predicted (or forward-read) timestamp.

Iam not sure what you are trying to do ...

> - or is RM seeking not supposed to work, should I not care (for now)
> and just implement a rm_read_seek() asap?

rm seeking should be working with normal rm files and svn, i have not
extensivly tested it and it very well may be working perfectly or be deeply

Either way, seeking support for non interleaved files will require you
to write a new rm_read_seek(), i think yes.


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/20090101/2b7d0c71/attachment.pgp>

More information about the ffmpeg-devel mailing list