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

[Baptiste Coudurier]

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 
>>> CODEC_ID_DVDNAVDATA ?
>> 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