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

Erik Van Grunderbeeck erik
Wed Jun 17 02:22:11 CEST 2009

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


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

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. 

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


More information about the ffmpeg-devel mailing list