[MPlayer-dev-eng] Re: [PATCH] SSA/ASS subtitles support
Rich Felker
dalias at aerifal.cx
Thu Jul 6 06:26:27 CEST 2006
On Thu, Jul 06, 2006 at 09:58:43AM +0800, ?????? wrote:
> Hi,
>
> On Wednesday 05 July 2006 23:53, Evgeniy Stepanov wrote:
> > You won't be able to get multicolored subtitles this way. It is better to
> > write your own function using ass_read_subdata as an example.
>
> No problem, It's could be a start point ;)
>
>
> > Not exactly. New system adds events to ass_track as they are found in the
> > stream and keeps them forever. The old system only keeps the latest event,
> > which is clearly not enough with ssa.
> >
> > You can't extract _all_ subtitles in a file until it is completely demuxed.
> > So you should allocate an ass_track for each mp4 subtitle track, and update
> > it with subs coming from the demuxer. In matroska/ssa case it is
> > implemented in ass_process_chunk() and ass_process_line().
>
> So it's the limit of the container? Then MP4 is special I think, In MP4 the
> every track is completely indexed, in fact MPlayer already generated all the
'special' i guess is one way to put it. what do you do if the index is
damaged or missing? for a file format to be any good you need to be
able to read it without the index. imo the super-extensive index of
mp4 is just bloat, making the overhead for the file very large.
> infomation needed to generate every subtitle (start time, offset in the
> file...). Audio & video track is well indexed too, thus when
> demux_fill_buffer is called, it simply fill the requied audio/video track,
> subtitle track will not be demuxed "by the way". That's why I prefer get
> subtitles in the open process. If there is too many subtitles the delay might
> be noticable in this approach though.
yes, in general i would think the performance impact is unacceptable.
especially consider reading off slow media like cdrom/dvd, where
seeking is slow.
rich
More information about the MPlayer-dev-eng
mailing list