[vlc-devel] Re: going backwards (it's going to be fun)

[Jean-Paul Saman]

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).

Grtz,
Jean-Paul Saman.



-- 
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>