[FFmpeg-devel] [PATCH] Bluray Subtitle Support, v7 (Updated patch to v12)

Michael Niedermayer michaelni
Wed Aug 26 21:03:15 CEST 2009


On Wed, Aug 26, 2009 at 08:48:02PM +0200, Reimar D?ffinger wrote:
> On Wed, Aug 26, 2009 at 08:02:45PM +0200, Michael Niedermayer wrote:
> > fine, so i have a few more questions
> > * is 0/0 actually required by spec / players or just like the existing
> >   muxers do?
> 
> I have no spec and I have no player - testing by others is welcome.
> 
> > * are the 0 packets we write causing actual problems with spec/players?
> 
> They are causing a massive size increase with the current time base
> (8*90000 bytes per second) and even with the correct time base for 1 ms
> it would still be 8 kB/s

i understand that, if we would be going down that road we would use the
video fps as timebase ...


> 
> > the internal timebase should be set to whichever value the timebase of
> > the subs has (ms ?)
> 
> Yes, that can be done in the stream creation logic, but first the AVI
> demuxer must be stopped from overwriting it with bogus codec values.

but does it at all?
isnt it rather feeded with a bogus timebase?


> 
> > forcing the written timebase to 0/0 if we do have to do that, is easy
> > (obvious if(XSUB) put(0) ..), i dont think ff_parse_specific_params()
> > could set a 0/0 tb and the muxer would still function but if it works
> > that would be an option as well
> 
> ff_parse_specific_params already sets it to 0/1 and it works really
> badly or without extra hacks actually crashes, so no I don't think
> that's the way to go.
> 
> > the demuxer of course will require code to handle this (i think we dont
> > have any ATM), that is probably if(XSUB) pts=dts=AV_NOPTS_VALUE and leaving
> > it to a parser to fill them in
> 
> That is rather independent though IMO, since we have that issue already
> with the original .divx files.

> Also that will break transcoding, resulting in the message "Subtitle
> packets must have a pts", despite the fact that all the necessary info
> is there after decoding.

by the time ffmpeg.c sees the packet the parser alraedy did run and fill
a pts in

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090826/ecef157b/attachment.pgp>



More information about the ffmpeg-devel mailing list