[FFmpeg-devel] FW: pts/dts generation and index for mpegts (vob)
Wed Jun 17 04:07:07 CEST 2009
Erik Van Grunderbeeck wrote:
>> 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++) <-
> application handling
> if(m_Buttons[iTeller].PtInRect(point)) <-
> application handling
> // clear all our queues
> PacketQueue_ClearAll(); <- application
> // send
> dvd_protocol_select_button(iTeller); <- send
> to libavformat
> // ok
> return TRUE;
> 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
> correct protocol.
2 dvds: 2 AVFormatContexts 2 URLProtocols, pick the right one.
You certainly need to the correct AVFormatContext as argument.
avformat_handle_event(AVFormatContext, "bleh", ...) might be a good idea.
>>> 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
Demuxer or protocol internal elements need to be closed in the demuxer
Humm freeing per stream index you mean ? Possible.
I think for this return AVERROR_EOS (End Of Stream) might be nice.
After this, user can free everything through an API in libavformat if
>>>> 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"
Just hope your API will work with Blu-ray :)
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel