[vlc-devel] Re: Pre-roll
Steve Lhomme
steve.lhomme at free.fr
Tue Feb 15 12:58:09 CET 2005
Steve Lhomme a écrit :
> Hi,
>
> As mentionned yesterday, I have a problem with Matroska chapters (and
> seeking in general). I have 2 chapters that are very close in the file
> (a few seconds). When I seek on the second chapter, VLC starts display
> data from the previous chapter because that's where the keyframe that
> should be used is located... That means this second chapter is useless.
> But since our menu system relies on chapters, I *need* this to work (the
> few seconds of video is actually a menu section).
>
> In DirectShow this works fine, because it uses something which I think
> is called pre-roll (probably from movie tapes that have to start playing
> before you switch from one tape to another). It does the decoding
> (audio, video, etc) from that keyframe but only start rendering the
> content when the given pre-roll timecode is reached.
>
> I managed to do this in the Matroska demuxer by setting a p_block->i_pts
> to -1 for the data (frames) that should be decoded but not used for
> rendering. But there are 2 problems :
>
> - even though the keyframe and all consecutive frames are supposed to be
> decoded, the first frame displayed shows that this isn't the case (like
> when you start decoding using a P/B frame).
>
> - The pre-roll time (the few seconds mentioned) is used during
> rendering. That means no audio or video for a few seconds. This time
> should be the shortest possible (in DirectShow it's less than a second).
Thanx to fen, I managed to remove this problem. Now I only set the PCR
of data blocks that should be rendered. The other ones are just sent to
the decoder with their actual pts and dts values.
The problem is that we are back to the previous behaviour. That means
the keyframes don't seem to be used by the decoder, although I'm sure
they are sent by the demuxer. I think it happens because when
"displayable" frame are found we set the output clock, and due to
internal mechanisms of VLC "old" frames are discarded, maybe even at the
decoder level. Am I right on this ? Is there a way to avoid this ?
(existing or to code)
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel
mailing list