[FFmpeg-devel] FW: pts/dts generation and index for mpegts (vob)

[Baptiste Coudurier]

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
> something
>> back?  The application clicks button X. This signal's the vm to continue,
> by
>> 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
> handling
> 				//	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,
> since
>>> the audio stream may change from AC3 2 channel to AC3 6 channel, and/or
> eg
>>> 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
> close). 

Demuxer or protocol internal elements need to be closed in the demuxer
or protocol.
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
needed.

>>>> Well, it will be added if it's really needed, don't focus on this if
> this
>>>> 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
> be
>>> 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