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

Richard peper03 at yahoo.com
Sun Feb 24 21:56:05 CET 2013

On 24/02/13 21:50, Richard wrote:
> On 24/02/13 21:06, Michael Niedermayer wrote:
>> On Sun, Feb 24, 2013 at 08:31:35PM +0100, Richard wrote:
>>> On 18/02/13 07:24, Richard wrote:
>>>> Hi,
>>>> In order to improve DVD playback, I need the DVD NAV packets in-sync
>>>> with the other audio/video/subtitle packets.  The information is stored
>>>> in 'PRIVATE_STREAM_2' MPEG-PS packets (startcode 0x1bf), which are
>>>> currently filtered out.
>>>> The attached patch adds a new codec ID
>>>> identify these packets.
>>>> The contents of these packets is clear for DVDs but looking at the
>>>> existing code, it appears that Dreamcast videos (Sofdec) also use this
>>>> startcode but for other purposes, so I'm not sure it's feasible to
>>>> create any sort of decoder for these packets.  As it is, the patch
>>>> simply returns the contents of the packet unchanged.  It is up to the
>>>> calling application to process the contents.
>>>> All comments welcome.
>>> Any comments on this?
>> do you have an actual application that uses this ? that is has the
>> output been tested somehow ?
> Yes, I'm working on improving DVD playback in MythTV.  There is a wealth
> of information stored in these packets that lets the player code
> determine, for example, when there's a timecode discontinuity, or when
> the next block with video packets will come.  Particularly because of
> the timecodes discontinuities, it's important to get these packets
> *before* the discontinuities occur to be able to anticipate them.
> The contents of these packets (in a DVD context) is describe on these
> two pages (just to give an idea of the sort of data available):
> http://dvdnav.mplayerhq.hu/dvdinfo/pci_pkt.html
> http://dvdnav.mplayerhq.hu/dvdinfo/dsi_pkt.html
> Ideally, these packets would be delivered completely in-sync with the
> audio/video/subpicture packets, but that doesn't seem to be possible due
> to, as I mentioned, the buffering required for the 'normal' packets.  If
> there is a way, I'm all ears.

Sorry, in response to the question 'Has the output been tested 
somehow?', yes, I've tested this in Myth.  I don't have the code written 
yet to handle the changes but I can confirm that a new data stream is 
detected and that the packets are returned via av_read_frame.


More information about the ffmpeg-devel mailing list