Hide Forgot
Created attachment 564372 [details] Screenshot of non-printing character in multi-line subtitles Description of problem: libass attempts to display non-printing characters in multi-line subtitles Version-Release number of selected component (if applicable): libass-0.10.0-1.fc16.x86_64 How reproducible: Always affects the same subtitles the same way, but doesn't impact all subtitles. Results: See screenshot.
Thanks for the bug report. Some questions first: * Does it impact only specific kind of subtitles, e.g. ASS, SRT, ...? * Can you provide a simple subtitle file where it happens? * Or, can you say me which anime and subbing group is the screenshot from (no links please though, for legal reasons). * What media player does this happen in? Totem, VLC, mplayer2, another, all of them?
Created attachment 564548 [details] Screenshot Without SSA-ASS Screenshot of video on mplayer with SSA/ASS subtitle rendering turned off. Notice no non-printing characters at the end of the lines.
Created attachment 564549 [details] Screenshot With SSA-ASS Screenshot of video on mplayer with SSA/ASS subtitle rendering turned on. Notice there are non-printing characters at the end of the lines.
I don't have much experience at video encoding, but I'll answer your questions as best as I can. > Does it impact only specific kind of subtitles, e.g. ASS, SRT, ...? I uploaded new attachments. When I have "SSA/ASS subtitle rendering" disabled, the problem doesn't exist. When I turn it back on, the problem returns. > Can you provide a simple subtitle file where it happens? If you can tell me how to extract a simple subtitle file from a .mkv file, then yes. > Or, can you say me which anime and subbing group is the screenshot from (no links please though, for legal reasons). I have this problem across a number of files encoded by different groups. > What media player does this happen in? Totem, VLC, mplayer2, another, all of them? I am using mplayer 1.0-0.123.20110412svn, although this continues to happen on more recent versions. Unfortunately, I couldn't get the file to play at all on totem, and I am not in a position to install vlc. This originally started when libass was updated to 0.10. I just never got around to reporting it until now.
Ok, looks like I've found it - Ai Yori Aoshi, subbed by E-D. But I have to disappoint you - it works for me; well, to be more precise it works for me using mplayer2 build, after I replaced it with mplayer I also see the issue, so I suppose it's a bug in mplayer when using newer libass and advise you to fill it against mplayer. Just for your info, the subtitles in question are in SRT format, you just render them via libass.
Hi, I got the same issue after yum[13644] Updated: libass-0.10.1-2.fc17.x86_64 Hi, Joe did you report it upstream ( in mplayer) ? if yes where ? or did we have any solution ?
Due to the difficulty of working with mplayer's developers, I do not have a resolution in all cases. The best I can say is that fewer subtitles are impacted, but I still have at least one file where I can reproduce this error.
(In reply to comment #7) > Due to the difficulty of working with mplayer's developers, I do not have a > resolution in all cases. The best I can say is that fewer subtitles are > impacted, but I still have at least one file where I can reproduce this > error. It's always easier to work on bugs when you can provide a test case -- I think I didn't write it explicitly, but from a Matroska (.mkv/.webm) file you can extract subtitles with mkvextract command line app. It's rather easy to use. If you could provide the mplayer devs a simple subtitle file where this error occurs, I'm sure it would be easier to communicate with them, but they're known for not being best in this area (which is part of the reason, why mplayer2 fork exists...)
(In reply to comment #8) Hi , I use smplayer with mplayer backend and I add to .mkv, one .srt with mmg from mkvtoolnix-gui. I'm using smplayer, when I disable the use of libass, no problem , but not when I enable use libass. Before update of libass rpm also no problem, so I don't see why is mplayer fault. About an example of .srt, every line with multilines (linefeed , \n ). we will see one square at the end the representation of linefeed.
(In reply to comment #9) > (In reply to comment #8) > > Hi , I use smplayer with mplayer backend and I add to .mkv, one .srt with > mmg from mkvtoolnix-gui. > I'm using smplayer, when I disable the use of libass, no problem , but not > when I enable use libass. > Before update of libass rpm also no problem, so I don't see why is mplayer > fault. > > About an example of .srt, every line with multilines (linefeed , \n ). we > will see one square at the end the representation of linefeed. Hi, basically, libass is developed to display (advanced) substation alpha subtitles (ASS and SSA), when you use it to display plain text subs, my guess is that the app must somehow translate it to a format libass understands first, and that's where mplayer is probably failing. I tried to make simple .srt file: 1 00:00:00,000 --> 00:00:05,000 test\Nnewline and in both mplayer (1.0-0.142.20120205svn.fc17) and mplayer2 (de435ed git snapshot) it displays correctly, using libass-0.10.1-2 from F17 updates repo... so just a multilined subtitle isn't enough to reproduce the issue (btw. when I use \n instead of \N it just prints it as if there where space). However, when I do it like in the screenshoted anime, i.e. 1 00:00:00,000 --> 00:00:05,000 test newline then it's displayed correctly, unless I merge it with video in matroska (via mmg), then mplayer -ass indeed blows up and starts printing rectangles whenever new line is present. mplayer2 works correctly. So unless mplayer devs themselves tell it's a bug in libass and why, it's most likely a bug in mplayer.
(In reply to comment #10) > 1 > 00:00:00,000 --> 00:00:05,000 > test > newline > > then it's displayed correctly, unless I merge it with video in matroska (via > mmg), then mplayer -ass indeed blows up and starts printing rectangles > whenever new line is present. mplayer2 works correctly. So unless mplayer > devs themselves tell it's a bug in libass and why, it's most likely a bug in > mplayer. OK , I made a wrong assumption, that was libass update, as you said is mplayer fault , so we may open a bug on rpmfusion, mplayer, Julian may have any solution or build to test . Unfortunately I don't have much time , but Joe you could help on that. Thanks,
bug opened in rpmfusion https://bugzilla.rpmfusion.org/show_bug.cgi?id=2615
To Joe, from https://bugzilla.rpmfusion.org/show_bug.cgi?id=2615 fixed with mplayer-1.0-0.144.20120205svn.fc17 and on mplayer of F18 thanks,