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

[Erik Van Grunderbeeck]

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

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


Erik