[vlc-devel] going backwards (it's going to be fun)
j.zorko at att.net
j.zorko at att.net
Thu May 22 21:09:17 CEST 2003
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.
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). 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
Falling You - exploring the beauty
of voice and sound
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