No subject

perhaps some people in the videolan team will like to help with this.


Sigmund

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).
> 
> Thoughts?
> 
> Regards,
> 
> John
> 
> --
> Falling You - exploring the beauty 
> of voice and sound
> http://www.mp3.com/fallingyou
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 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>