Wed Aug 5 14:32:43 CEST 2015
perhaps some people in the videolan team will like to help with this.
On Thu, May 22, 2003 at 07:09:17PM +0000, 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.
> 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
> consider palatable).
> 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>
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