[MPlayer-dev-eng] [patch] loading libass subtitles from network

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed Feb 3 23:48:14 CET 2010


On Thu, Feb 04, 2010 at 01:24:18AM +0300, Yuriy Kaminskiy wrote:
> Currently libass doesn't use mplayer stream infrastructure, and fails to load
> subtitles from network.
> This patch fixes that.

I'm too tired to review properly, but please get rid of all the #ifdef NETWORK
stuff, it only means having two different code paths to test without any real
advantage (unless your proposed patch has architectural issues?).

> Name (re)displayed later anyway (SUB:...), and displayed correctly with
> -identify, so I considered that not important to bother (fixing would need
> changing (upstream) libass, or dirty hackery in libass msg hook).

IMO: who cares

> If #define'ing ass_read_file feels too hackerish, squash second patch in (while
> being out-of-tree, less changed files - better ;-)).

I expect getting rid of the network dependency should make this unnecessary.
Does your patch work with old libass versions btw?
If not, you should at least update the configure check.

> +ass_track_t* ass_read_stream(ass_library_t* library, char *fname, char *charset) {

I suspect fname and charset should be const.

> +	fd=open_stream (fname, NULL, &i);

extra space before (

> +	if (fd->end_pos > STREAM_BUFFER_SIZE)
> +		/* read entrie file at one if size is known */

? At least two typos I think

> +		if (buf_alloc >= 10*1024*1024) {
> +			mp_msg(MSGT_ASS, MSGL_INFO, MSGTR_LIBASS_RefusingToLoadSubtitlesLargerThan10M, fname);
> +			sz = 0;
> +			break;

That on the other hand is the kind of limit I do not really like, does the current code have that also?

> +		if (buf) free(buf);

Useless if

> +	buf[sz] = '\0';

Use just 0, '\0' is just pointless clutter

> +		if(track->name)
> +			free(track->name);

Also pointless if



More information about the MPlayer-dev-eng mailing list