[FFmpeg-devel] [PATCH] Bluray Subtitle Support, v7 (Updated patch to v12)
Wed Aug 26 20:02:45 CEST 2009
On Wed, Aug 26, 2009 at 07:18:42PM +0200, Reimar D?ffinger wrote:
> On Wed, Aug 26, 2009 at 06:36:01PM +0200, Michael Niedermayer wrote:
> > On Wed, Aug 26, 2009 at 01:34:45PM +0200, Reimar D?ffinger wrote:
> > > No, you need this patch, but Michael will have to comment on what is the
> > > right approach (it disables empty packets for timestamp encoding for
> > > subtitles, which causes the massive size increase):
> > "the right approuch" is what is written in the spec in question about
> > the specific subtitle format
> > if subtitles are placed in more than a single packet a timebase and likely
> > dummy 0 packets are needed in avi. But as said the question is how should
> > the correct avi file look like ...
> There should be a subtitle packet approximately correctly interleaved,
> and no empty subtitle packets.
> In avi, the subtitle contains the display time as absolute values,
> so the pts value it gets on demuxing is not relevant (this part is admittedly
> ugly and might cause some issues when remuxing, editing or whatever -
> but essentially that's out of our hands).
> For official files, we get the message "[avi @ 0x2231a60]scale/rate is
> 0/0 which is invalid.", so scale and rate are set to 0 (though even if
> we do that, we sure should not set the internal time_base to 0/0 as the
> current code tries to do, that opens a far to big can of worms!).
> Note that I think this would cause some serious issues for
> non-interleaved files, but I'd just consider interleaved files with
> XSUB subtitles invalid (I don't think they are valid actually).
fine, so i have a few more questions
* is 0/0 actually required by spec / players or just like the existing
* are the 0 packets we write causing actual problems with spec/players?
the internal timebase should be set to whichever value the timebase of
the subs has (ms ?)
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
about the 0 packets, well your patch was probably pretty close to what
we would have to do ... arbitrarly ommiting them
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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel