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

[Erik Van Grunderbeeck]

> 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.


>> 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). 

>>> 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"

erik