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

Reimar Döffinger Reimar.Doeffinger
Wed Aug 26 21:31:05 CEST 2009


On Wed, Aug 26, 2009 at 09:03:15PM +0200, Michael Niedermayer wrote:
> On Wed, Aug 26, 2009 at 08:48:02PM +0200, Reimar D?ffinger wrote:
> > 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 ...

And if a video was mixing different frame-rate content you'd constantly
be off by a frame at least. That does not sound like a real solution to
me - except as a hack to avoid the whole time_base/pts issues while
still relying on the absolute time stamp to get reliable display times.

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

I think that's not documented. Are demuxers supposed to use
st->codec->time_base and overwrite st->time_base?
Why should they even look in st->codec when there is the "same" thing
one level lower?
Without further explanation it seems quite idiotic to me, especially
when a perfectly fine value gets override by obvious nonsense.

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

As long as there is no parser it won't... As soon as someone writes a
parser, fine, but I am not ok with breaking the only way to test xsub
transcoding and just hoping for someone to fix it again.



More information about the ffmpeg-devel mailing list