libass behavior when PlayResX & PlayResY are missing in ass subs
Hi! Lately i've been playing with ass subtitles and i've noticed that when subtitle file doesn't specify PlayResX *and* PlayResY libass hardcodes them to 384x288. What's the reasoning with this? I think this is a bit against SSA/ASS specs I've found on the net: PlayResY: This is the height of the screen used by the script's author(s) when playing the script. SSA v4 will automatically select the nearest enabled setting, if you are using Directdraw playback. PlayResX: This is the width of the screen used by the script's author(s) when playing the script. SSA will automatically select the nearest enabled, setting if you are using Directdraw playback. Locally I've modified ass_render.c so that if both values are missing in the sub file they are set to orig_width, orig_height (this seems to be at least a bit consistent with situation when either PlayResX or PlayResY is given -- see ass_lazy_track_init() around line 210 of ass_render.c ). -- Just a friendly Jedi Knight | I find your lack of faith Robert Ramiega jedi@plukwa.net | disturbing http://nlj.plukwa.net/
On Tuesday 21 October 2008 19:23:48 Robert Ramiega wrote:
Hi!
Lately i've been playing with ass subtitles and i've noticed that when subtitle file doesn't specify PlayResX *and* PlayResY libass hardcodes them to 384x288. What's the reasoning with this?
Because that's what Vobsub does. And there are scripts out there that don't set either PlayResX or PlayResY, and expect the logical screen size to be 384x288.
I think this is a bit against SSA/ASS specs I've found on the net:
PlayResY: This is the height of the screen used by the script's author(s) when playing the script. SSA v4 will automatically select the nearest enabled setting, if you are using Directdraw playback.
PlayResX: This is the width of the screen used by the script's author(s) when playing the script. SSA will automatically select the nearest enabled, setting if you are using Directdraw playback.
I think it does not say anything about the case when PlayResX and PlayResY are unspecified. The word 'nearest' is probably related to the existing value of PlayResX(Y).
Locally I've modified ass_render.c so that if both values are missing in the sub file they are set to orig_width, orig_height (this seems to be at least a bit consistent with situation when either PlayResX or PlayResY is given -- see ass_lazy_track_init() around line 210 of ass_render.c ).
On Tue, Oct 21, 2008 at 08:09:44PM +0400, Evgeniy Stepanov wrote:
On Tuesday 21 October 2008 19:23:48 Robert Ramiega wrote:
Hi!
Lately i've been playing with ass subtitles and i've noticed that when subtitle file doesn't specify PlayResX *and* PlayResY libass hardcodes them to 384x288. What's the reasoning with this?
Because that's what Vobsub does. And there are scripts out there that don't set either PlayResX or PlayResY, and expect the logical screen size to be 384x288.
Out of curiosity could you, please, point me to such script/situation (this "half-PAL" resolution puzzles me). As for Vobsub - well it's an argument to keep things as they are but still isn't Vobsub out-of-developement for quite some time. Mimicking Vobsub is probably good thing but maybe it's time to set new standard =o) (just random thoughts, please ignore them if they are annoying to you) btw by "script" you mean subtitle file or (shell) script? -- Just a friendly Jedi Knight | I find your lack of faith Robert Ramiega jedi@plukwa.net | disturbing http://nlj.plukwa.net/
On Wednesday 22 October 2008 18:23:39 Robert Ramiega wrote:
On Tue, Oct 21, 2008 at 08:09:44PM +0400, Evgeniy Stepanov wrote:
On Tuesday 21 October 2008 19:23:48 Robert Ramiega wrote:
Hi!
Lately i've been playing with ass subtitles and i've noticed that when subtitle file doesn't specify PlayResX *and* PlayResY libass hardcodes them to 384x288. What's the reasoning with this?
Because that's what Vobsub does. And there are scripts out there that don't set either PlayResX or PlayResY, and expect the logical screen size to be 384x288.
Out of curiosity could you, please, point me to such script/situation (this "half-PAL" resolution puzzles me).
Sorry, I don't remember where I have seen it.
As for Vobsub - well it's an argument to keep things as they are but still isn't Vobsub out-of-developement for quite some time. Mimicking Vobsub is probably good thing but maybe it's time to set new standard =o) (just random thoughts, please ignore them if they are annoying to you)
But subtitles are still made with Vobsub in mind. Anyway, changing default values will not improve anything.
btw by "script" you mean subtitle file or (shell) script?
Subtitle file.
On Oct 22, 2008, at 1:14 PM, Evgeniy Stepanov wrote:
On Wednesday 22 October 2008 18:23:39 Robert Ramiega wrote:
On Tue, Oct 21, 2008 at 08:09:44PM +0400, Evgeniy Stepanov wrote:
On Tuesday 21 October 2008 19:23:48 Robert Ramiega wrote:
Hi!
Lately i've been playing with ass subtitles and i've noticed that when subtitle file doesn't specify PlayResX *and* PlayResY libass hardcodes them to 384x288. What's the reasoning with this?
Because that's what Vobsub does. And there are scripts out there that don't set either PlayResX or PlayResY, and expect the logical screen size to be 384x288.
Out of curiosity could you, please, point me to such script/situation (this "half-PAL" resolution puzzles me).
Sorry, I don't remember where I have seen it.
As for Vobsub - well it's an argument to keep things as they are but still isn't Vobsub out-of-developement for quite some time. Mimicking Vobsub is probably good thing but maybe it's time to set new standard =o) (just random thoughts, please ignore them if they are annoying to you)
But subtitles are still made with Vobsub in mind. Anyway, changing default values will not improve anything.
btw by "script" you mean subtitle file or (shell) script?
Subtitle file.
I know this topic is several months old, but something should be done about this. One of the biggest areas in which the full features of ssa/ ass fonts are used is in Anime/Japanese softsubs. The groups that do these often use the full features of SSA and expect that PlayResX and PlayResY if not defined, default to the current resolution of the video. In fact I've gone and asked groups that release subs without these that their files are bugged and when I say that I'm using MPlayer they say that this is a known MPlayer bug. If not changing the default, an easy way to switch between the two modes should be provided (besides using ssa overrides). Also I have to ask what does ssa subs have to do with vobsubs? They are two entirely different formats. Shouldn't libass (if you are using it to decode subtitles) decide based on format of the file to use either vobsub defaults or ssa defaults? I have many videos with resolutions of 1280x720 resolution that when this default is applied to them it makes the subtitles about 1/3 the vertical size of the video and completely unwatchable.
On Wed, 2009-01-14 at 11:10 -0500, Ergzay wrote:
I know this topic is several months old, but something should be done about this. One of the biggest areas in which the full features of ssa/ ass fonts are used is in Anime/Japanese softsubs. The groups that do these often use the full features of SSA and expect that PlayResX and PlayResY if not defined, default to the current resolution of the video. In fact I've gone and asked groups that release subs without these that their files are bugged and when I say that I'm using MPlayer they say that this is a known MPlayer bug. If not changing the
Do you have such samples? I've seen samples that break if you assume the script to use video dimensions instead of the default resolution, but not samples that behave as you describe. Such behavior does not seem very desirable either, as it would make the script break if used with a different resolution encode of the same program.
Also I have to ask what does ssa subs have to do with vobsubs? They
I think VSFilter was meant where the previous messages said Vobsub.
On Jan 14, 2009, at 11:23 AM, Uoti Urpala wrote:
On Wed, 2009-01-14 at 11:10 -0500, Ergzay wrote:
I know this topic is several months old, but something should be done about this. One of the biggest areas in which the full features of ssa/ ass fonts are used is in Anime/Japanese softsubs. The groups that do these often use the full features of SSA and expect that PlayResX and PlayResY if not defined, default to the current resolution of the video. In fact I've gone and asked groups that release subs without these that their files are bugged and when I say that I'm using MPlayer they say that this is a known MPlayer bug. If not changing the
Do you have such samples? I've seen samples that break if you assume the script to use video dimensions instead of the default resolution, but not samples that behave as you describe.
Such behavior does not seem very desirable either, as it would make the script break if used with a different resolution encode of the same program.
Yes I have a couple. A 50 megabyte sample of one is uploading to ftp://upload.mplayerhq.hu/MPlayer/incoming/ Filename is hyakko_04.mkv. Problem is seen first at 2:04. And actually this is an interesting example. Mplayer states there isn't a PlayRes set but it is set in the file, but it seems to ignore it.
Also I have to ask what does ssa subs have to do with vobsubs? They
I think VSFilter was meant where the previous messages said Vobsub.
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
On Wed, 2009-01-14 at 11:59 -0500, Ergzay wrote:
On Jan 14, 2009, at 11:23 AM, Uoti Urpala wrote:
Do you have such samples? I've seen samples that break if you assume
Yes I have a couple. A 50 megabyte sample of one is uploading to ftp://upload.mplayerhq.hu/MPlayer/incoming/ Filename is hyakko_04.mkv. Problem is seen first at 2:04. And actually this is an interesting example. Mplayer states there isn't a PlayRes set but it is set in the file, but it seems to ignore it.
I couldn't check the file yet (the crappy permissions system still hasn't set the correct access), but based on your description it sounds like this file does NOT have the kind of problem you complained about. Of course if the file tries to specify a different resolution but MPlayer can not parse it then things will not work if that resolution differs from the default.
On Wed, 2009-01-14 at 19:14 +0200, Uoti Urpala wrote:
On Wed, 2009-01-14 at 11:59 -0500, Ergzay wrote:
On Jan 14, 2009, at 11:23 AM, Uoti Urpala wrote:
Do you have such samples? I've seen samples that break if you assume
Yes I have a couple. A 50 megabyte sample of one is uploading to ftp://upload.mplayerhq.hu/MPlayer/incoming/ Filename is hyakko_04.mkv. Problem is seen first at 2:04. And actually this is an interesting example. Mplayer states there isn't a PlayRes set but it is set in the file, but it seems to ignore it.
I couldn't check the file yet (the crappy permissions system still hasn't set the correct access), but based on your description it sounds like this file does NOT have the kind of problem you complained about.
The file is readable now, and the problem seems to be that there is a question mark at the start of the script, so that it begins with '?[Script Info]'. That's visible when extracting the subtitles with mkvextract, so it's not only an MPlayer demuxing error. That breaks parsing of the [Script Info] section where PlayResX and PlayResY are specified. So this has little to do with the correct default values to use when PlayRes is not specified.
Le quintidi 25 nivôse, an CCXVII, Uoti Urpala a écrit :
The file is readable now, and the problem seems to be that there is a question mark at the start of the script, so that it begins with '?[Script Info]'.
Could it be some sort of byte order mark gone wrong somewhere (either at muxing of in your editor)? Regards, -- Nicolas George
On Jan 14, 2009, at 1:42 PM, Nicolas George wrote:
Le quintidi 25 nivôse, an CCXVII, Uoti Urpala a écrit :
The file is readable now, and the problem seems to be that there is a question mark at the start of the script, so that it begins with '?[Script Info]'.
Could it be some sort of byte order mark gone wrong somewhere (either at muxing of in your editor)?
I was thinking that myself, but this is the same source version that is the "official" version of the file, the only place it could go wrong then is when demuxing and mkvextract didn't know what to do with the character. And seeing as this file plays fine on media player classic with whatever windows tools, one of a couple things is happening; it's a windows non-ascii character of some sort, parsing on windows is done by ignoring all non-related characters, the default on the windows players is the view resolution of the video, or something else. I'll try and find another example file, I'm sure I have a couple around. I watch tons of videos with ssa subs and I'm always finding small glitches and things, but don't usually report problems as 50% of the time when I report something I get no response (at least on the mplayer-users list).
participants (5)
-
Ergzay -
Evgeniy Stepanov -
Nicolas George -
Robert Ramiega -
Uoti Urpala