[MPlayer-users] recent libass text rotation corruption

Erik Auerswald auerswal at unix-ag.uni-kl.de
Wed Dec 19 13:42:55 CET 2012


Hi Robert,

On 12/19/2012 08:20 AM, Robert Henney wrote:
> sample screen capture showing the differences between recent mplayer
> versions:
>
> http://rut.org/images/r35319.png
> http://rut.org/images/r35698.png

You suspect libass changes to be the cause. There were two change sets 
modifying libass between revisions 35319 and 35698:

$ svn log -r35319:35698 libass
------------------------------------------------------------------------
r35356 | SubJunk | 2012-11-06 06:41:14 +0100 (Tue, 06 Nov 2012) | 3 lines

Updated libass to 0.10.1

This closes #2099
------------------------------------------------------------------------
r35368 | SubJunk | 2012-11-07 00:09:28 +0100 (Wed, 07 Nov 2012) | 1 line

libass: Fixed RTL languages
------------------------------------------------------------------------

It would probably help if you could test those two revisions.

Between svn revisions 35319 and 35698 a rewrite of vf_ass has happened 
as well, which might be the cause for your regression:

$ svn log -r35319:35698 libmpcodecs/vf_ass.c
------------------------------------------------------------------------
r35338 | upsuper | 2012-11-02 06:42:48 +0100 (Fri, 02 Nov 2012) | 5 lines

a new implementation of vf_ass

The introduction of this patch can be found here:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2012-October/070853.html

------------------------------------------------------------------------
r35362 | reimar | 2012-11-06 21:00:44 +0100 (Tue, 06 Nov 2012) | 2 lines

Avoid unused variable warnings.

------------------------------------------------------------------------
r35530 | upsuper | 2012-11-30 14:07:39 +0100 (Fri, 30 Nov 2012) | 2 lines

Cosmetic: Reindent.

------------------------------------------------------------------------
r35668 | upsuper | 2012-12-12 18:13:39 +0100 (Wed, 12 Dec 2012) | 1 line

Move some code up.
------------------------------------------------------------------------
r35669 | upsuper | 2012-12-12 18:13:44 +0100 (Wed, 12 Dec 2012) | 3 lines

Accelerate ass rendering by using SSE4 for yuv422.

The render_frame_yuv422_sse4 is ~4x faster than render_frame_yuv422.
------------------------------------------------------------------------
r35670 | upsuper | 2012-12-12 18:18:01 +0100 (Wed, 12 Dec 2012) | 3 lines

Accelerate ass rendering by using SSE4 for yuv420p.

The render_frame_yuv420p_sse4 is ~3x faster than render_frame_yuv420p.
------------------------------------------------------------------------
r35673 | upsuper | 2012-12-13 03:17:27 +0100 (Thu, 13 Dec 2012) | 2 lines

Reduce register usage to fix the compilation in x86.

------------------------------------------------------------------------
r35674 | upsuper | 2012-12-13 06:19:20 +0100 (Thu, 13 Dec 2012) | 1 line

Replace an unnecessary SSE4 instruction.
------------------------------------------------------------------------
r35675 | upsuper | 2012-12-13 06:19:25 +0100 (Thu, 13 Dec 2012) | 1 line

Put xmm7 clearance into each asm block.
------------------------------------------------------------------------
r35676 | upsuper | 2012-12-13 06:19:29 +0100 (Thu, 13 Dec 2012) | 1 line

Rename consts & avoid using a GNU extension.
------------------------------------------------------------------------
r35678 | upsuper | 2012-12-14 03:16:30 +0100 (Fri, 14 Dec 2012) | 5 lines

Reduce register usage in an asm block.

Reduce to 4 registers in an asm block of render_frame_yuv420p_sse4
with simplification of code. After the modification, this function
can still be ~3.5x faster than render_frame_yuv420p.
------------------------------------------------------------------------
r35679 | upsuper | 2012-12-14 03:16:36 +0100 (Fri, 14 Dec 2012) | 5 lines

Reduce register usage in an asm block.

Reduce to 4 registers in the asm block of render_frame_yuv422_sse4.
After this modification, the function is only ~3.4x faster than
render_frame_yuv422.
------------------------------------------------------------------------
r35691 | upsuper | 2012-12-17 02:34:58 +0100 (Mon, 17 Dec 2012) | 2 lines

Cosmetic: reindent & move defines out of function

------------------------------------------------------------------------
r35696 | upsuper | 2012-12-18 11:51:55 +0100 (Tue, 18 Dec 2012) | 2 lines

Cosmetic: reindent.

------------------------------------------------------------------------

You might want to test those, too.

FFmpeg shows changes in ffmpeg/libavfilter/vf_ass.c as well...

> also, although it may not be related, when seeking I'm often getting "Ran out
> of numbered images, expect crash. Filter before vo is broken." followed by
> mplayer dying.  this also seems to have started after a recent change
> in svn.

That diagnostic was added in revision 34949:

$ svn log -r34949
------------------------------------------------------------------------
r34949 | reimar | 2012-05-21 21:59:58 +0200 (Mon, 21 May 2012) | 4 lines

Change MP_IMGTYPE_NUMBERED semantics.

This makes it easier to detect filters that claim to
support it for direct rendering but actually don't.
------------------------------------------------------------------------

Anyway, I'd assume that you need to provide more information about your 
setup, e.g. complete console output of "mplayer -v YOUR_OPTIONS 
YOUR_FILE" when this problem occurs. This would show hardware info, 
video filters, video output used, error messages, and much more.

HTH,
Erik


More information about the MPlayer-users mailing list