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

[John Michael Zorko]

Sigmund,

> Making input_Seek call a funcion in the demux (which in turn call 
> pf_seek in
> the input) have been on the wanted list for a long time. If this 
> function
> exists in the demux then moduifying input_Seek to seek number of
> frames/packets/whatever whould be doable. The only needed thing is to 
> find a
> usfull abstraction so that it could be implemented in all the different
> demuxes.
>
> From what I can see you are on good way to implement this. And I think
> perhaps some people in the videolan team will like to help with this.

Wow, that would rock :-)

I already made a version of input_Seek() that accepted an 
INPUT_SEEK_SPECIAL, and that special thing was a start code in my case. 
  I did this awhile ago to implement seeking on, say, a sequence header 
for MPEG2.  However, I had made input_Seek(), in the special case, call 
a method in the file access module (*pf_seek_startcode) which would 
progressively scan the source file, forwards or backwards, for the nth 
sequence_header.  At the time, I didn't think of making it call 
something in the demux module, but this is easily changed.

If the VLC developers want to help with this, how should we do it?  I 
plan on having the majority of this work finished in the next day or 
so, and I was even considering working on it now (can't sleep, up at 
3am California time, what else is there to do but code? <smile>)

Anyway, we thought more about it and think that, to do this in the most 
media-agnostic way possible, we should change the pf_demuxdrop to not 
specify a start code, and instead have the start code specified in the 
demux module.  This way, we call (* pf_demuxdrop ) inside input.c, 
regardless of whether we're playing / streaming an MP3 or MPEG2 / 4 or 
whatever, and input.c remains the general input thread implementation, 
unaware of any media specifics.

We also thought about the implementation of the DemuxDrop method for 
things like MPEG2 GOPs, the issue being that the GOP start code might 
not appear in one pack header -- the first bytes may be part of the 
payload of one pack, the rest of the bytes part of the payload of 
another.  This was an issue I ran into when first creating the 
INPUT_SEEK_SPECIAL thing, and since at the time I didn't completely 
understand the demux module idea, I just changed it to look for 
sequence headers, which always seemed to be complete in one pack 
payload.  Anyway, we were thinking that perhaps DemuxDrop (and Demux) 
should be changed in the MPEG demux module to operate on GOPs / 
sequence headers, instead of packs, i.e. instead of just finding packs 
and putting them in the FIFO, it would find all packs that are part of 
a GOP, or follow a sequence header before another sequence header, and 
put only those packs in the FIFO.  What do you think about this?

Also, we were thinking of writing a demux module for RFC3119 (ADU 
frames and MP3 audio) since we want to eliminate the occasional audio 
glitch when seeking on MP3 frames (the idea is that ADU frames have no 
back pointer and can be decoded and played by themselves, not so for 
MP3 frames).

Regards,

John

Falling You - exploring the beauty of voice and sound
New EP, "hope thrown down," available now at
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>