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

[Michael Niedermayer]

On Sun, Feb 24, 2013 at 09:56:05PM +0100, Richard wrote:
> 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
> >>>>'AV_CODEC_ID_PRIVATE_STREAM_2' to
> >>>>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.

what i wanted to know is if use of the packets has been tested, above
sounds like a "no"
and also how they would be used ?

ATM this patch smells wrong but i dont know what its used for so i
could be wrong and sure cant recommand how to improve it when i dont
even know what this is used for exactly

for example random buffering + no timestamps just feels wrong also
this feels a bit like a hack, to output a private stream raw like
that. we dont do that for audio or video either, there you get clean
packets one for each frame with timestamps, a codec id and various
other things


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130224/0cbc883f/attachment.asc>