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

Baptiste Coudurier baptiste.coudurier
Wed Jun 17 01:54:17 CEST 2009

Erik Van Grunderbeeck wrote:
>> The demuxer is extended by using stream startcode 0x1ff and 
>> checking for a small header id (like "EXTNAVDATA").
>>> 2a) Extend the mpeg ts reader to allow commands to be send to the
>>>  API through a new stream type. That stream type includes 
>>> "commands" to be executed. Will PS be supported ? Is 
>>> STREAM_TYPE_COMMAND needed if you use STREAM_TYPE_DATA and 
>> I am not sure I understand the question?
>> I interpreted stream type by another CODEC_TYPE_*
> 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.

>>> Also there need to be some way's to feed commands back to the 
>>> protocol. I know this has been discussed here before (ege the 
>>> E_AGAIN thread), but it seems to me more devices/protocols 
>>> (example video camera's, network broadcast layered protocol's, 
>>> server's with channel switching) could
> benefit
>>> from a [generic] send command layer.
>> Well if that's needed, why not, simple, generic and clean but 
>> that's obvious. Like read_seek, read_pause ? Maybe this could be 
>> made more generic.
> 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.

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

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

More information about the ffmpeg-devel mailing list