[vlc-devel] Re: going backwards (it's going to be fun)
jpsaman at wxs.nl
Thu May 22 21:50:03 CEST 2003
j.zorko at att.net wrote:
> Hello, all ...
> By duplicating the MP3 frame detection code (GetHeader(), GetDWBE(), etc.) in the file access
> module, i've managed to implement MP3-frame based ff / rewind functionality in VLC. I'm not
> particularly happy about doing it this way, but perhaps as a short-term solution it's ok. For MPEG2
> / 4, i'll have to do the same.
> There has _got_ to be a better way.
> So, i've been looking again at extending input_thread_t to have a ( *pf_demuxdrop ) member,
> which would take parameters like ( input_thread_t *p_input, int i_skip, int i_play, int i_startcode ).
> This way, the input thread (vlc_root/src/input/input.c) would just deref this new pf_demuxdrop for
> fast-forward and rewind, and we don't have to duplicate code in places it shouldn't be. However,
> the problem is going backwards -- going forward (ff) doesn't demand an lseek(), but going
> backward (rewind) does. How far back should we seek? We would like to be able to seek to an
> exact place i.e. "go back 5 MP3 frames" or "go back 7 sequence headers" but this demands either
> a.) a cache of recently found off_t's where frames / startcodes were found (and a way to refresh the
> cache from any point in the file), or b.) some slower code that lseek()'s back progressively, looking
> for the nth occurence of an MP3 frame / startcode.
Count the GOP length for MPEG based streams. The GOP lenght is fairly
constant and can be used to calculate how far to jump back and forth.
> Each has advantages and disadvantages -- a.) would be quick, but the cache would either need to
> be very large, or refreshed (which might take a bit).
not needed with counting the GOP length.
Option b.) would not need a cache, but would
> be slower. Is there a consensus among the VLC team of which option (or something i've not
> considered) to implement, going forward (metaphorically)? The idea is to code this in such a way
> as to make it palatable to the VLC developers (we've internally agreed to submit fixes and
> enhancements we make to VLC back to the VLC community, and code duplication is not what I
> consider palatable).
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel