[FFmpeg-devel] FW: pts/dts generation and index for mpegts (vob)
Erik Van Grunderbeeck
Wed Jun 17 03:45:35 CEST 2009
> The VM is in a wait state on button display (and remember, this runs in
> libdvdread, and thus at protocol level). How do you want to signal
> back? The application clicks button X. This signal's the vm to continue,
> sending the command "selected menu Z". That translates in open
> cell/chapter/vob Y and stream data, and data returns to the demuxer. DVD's
> are interactive, and thus you need a two way pipe.
>Well, application will request next packet in some way using
>libavformat, if what goes next to clicking button X is one chapter,
>application will request this chapter.
>I'm not sure libavformat should handle "click" button X.
We are talking about the same way of handling things I think. Libavformat
would not and doesn't handle click events. Piece of code:
for(int iTeller = 0; iTeller < m_ButtonCount; iTeller++) <-
// clear all our queues
PacketQueue_ClearAll(); <- application
dvd_protocol_select_button(iTeller); <- send
My handler (at app level) now calls dvd_protocol_select_button(). That
however is (right now) implemented on protocol handler level, bypassing
anything of libav. That has problems if you are reading from 2 dvd's at the
same time (since I cant see what handler is open). So, I need a call into
libavformat passing the (file-)context, that will then distribute it to the
>> Btw; this also may mean on application level: close and reopen codecs,
>> the audio stream may change from AC3 2 channel to AC3 6 channel, and/or
>> the mpeg decoder has new screen dimensions. I send commands for that now,
>> but there's issues with the libav indexer and the time stamp generator.
>Nope, no commands. Add new stream if codec change, application must
>close old one and open new one.
Yes, correct. And there are problems there. Timestamps are getting offset,
there used to be a problem with locking (that's solved with the new lock
mechanism), and the index handling can't be closed (since its just a codec
>>> Well, it will be added if it's really needed, don't focus on this if
>>> is hypothetical.
>> It's an internal mind fight. My programming background shows me: makes
>> things generic. My open-source background shows me; don't bother, it will
>> rewritten and/or ignored by other developers when they code changes ;)
>Make it generic _enough_ for what's _needed_.
<grin> that's like saying: "pray to all gods, and hope you picked the right
one when the curtain falls"
More information about the ffmpeg-devel