[FFmpeg-devel] [RFC/PATCH] Pass PRIVATE_STREAM_2 MPEG-PS packets to caller

Richard peper03 at yahoo.com
Mon Feb 25 22:41:23 CET 2013


On 25/02/13 20:35, Reimar Döffinger wrote:
> On 25 Feb 2013, at 17:23, Richard <peper03 at yahoo.com> wrote:
>>> IMO
>>> all things for which proper fields exist like pts/dts/duration/codec_id
>>> and so on should be set correctly before some raw packets of any
>>> stream are exported just to get to their correct values.
>>
>> That's fine by me.  From my point of view, it's just a question of what to do with packets that are defined as 'user-defined'.  If you want to handle them 100% correctly, you can't make any assumptions about their contents as anyone could use them for any purpose.  Almost any attempt to determine their contents without context *could* fail.  All you can do is pass them on unprocessed to allow the calling application (which has the context required) can decode them.
>
> This is actually likely not good enough.
> I don't know if they are stored exactly in that, but ATSC CC subtitles are stored in such a user data field as well.
> However, they need to be reordered according to the decoder reordering, so if you split them naively the resulting data stream will be completely unuseable.
> You won't be able to see thay for DVDs, since there the "solution" is thy B frames are not allowed to contain CC data.
> Which I am afraid is another argument to make this DVD-only, unless you want to come up with a way to handle the reordering...

Hi Reimar,

As far as my patch goes, it only affects packets with start code 0x1bf 
(private_stream_2), and only in MPEG program streams.  The current 
behaviour is to filter these packets out completely.  So at the moment, 
any application wanting/needing these packets is going to be disappointed.

As far as I know, CC subtitles (on a DVD at least) are carried in the 
video packets.  I don't know where, exactly, but they're certainly not 
private_stream_2 packets.

My point about what to do with user-defined packets was a generic one.
If ISO13818-1 defines 'private_stream_2' packets as having start code 
0x1bf followed by the length, followed by 'length' bytes of user-defined 
(but not ISO13818-1 defined) data, how do you write something that 
sticks to that specification but bases its processing on the contents of 
those packets?  Officially, you don't and can't know what's in there.

Unofficially, of course, you may know that these packets are almost 
exclusively used for DVD navigation data and so the chances of some 
other application using packets with the same length and same first byte 
(or whatever other conditions you want to check) are pretty low.

But that, in the end, is context.  Either lavf can make its best guess 
as to the contents of a packet, or the calling application can provide 
the context.  It's not as nice, but if neither of those are possible, I 
don't see how its possible to do anything other than pass those packets 
through 1:1 and let the calling application do the hard work.

Now, I'm no AV expert, so if I'm missing something obvious, please let 
me know.

Richard.


More information about the ffmpeg-devel mailing list