[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