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

[Baptiste Coudurier]

Erik Van Grunderbeeck wrote:
>>> Ok. I understand your question now also. I used CODEC_TYPE_ATTACHMENT
>>>  as a stream type (since those pass through the demuxer/streaming 
>>> layer now), and CODEC_ID_TTF for codec id. I obviously need to use 
>>> another codec id, and CODEC_ID_DVDNAVDATA sounds like a good name.
> 
>> Yes, also CODEC_TYPE_ATTACHMENT is not appropriate, I'm fighting to
>> remove it :)
>> Use CODEC_TYPE_DATA for now if possible.
> 
> Sure.
> 
>>> Example: signaling the VM of the DVD player that a button has been 
>>> clicked, or that it can continue after it displayed a still image.
> 
>> That's not related to libavformat but application IMHO.
> 
> Aye, but the application needs to feed it back to the VM. 
> 
> 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.

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

>>> So generic would be a good idea. Example not related to this but 
>>> perhaps to consider; I can imagine that a subscriber to a broadcast 
>>> mask on UDP wants to "change" to another channel (ege subnet mask).
>>> That's a command to be send. Perhaps sending a "generic blob" that
>>> the specific codec then knows how to decode would work?
> 
>> 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_.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org