AnimeSuki Forums

Register Forum Rules FAQ Members List Social Groups Search Today's Posts Mark Forums Read

Go Back   AnimeSuki Forum > Anime Related Topics > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2007-03-16, 05:11   Link #1
Grv
宜しく
*Fansubber
 
 
Join Date: Feb 2006
Age: 30
HD/SD encodes (MOD16) and Typesetting

I just wanted to pose this question to the wider community as we've been looking at the best way to work around this situation internally. Ultimately with the move toward h.264 only releases, it would be best practice to use MOD16 resolutions for all encodes.

The problem here is how to handle the slight difference in aspect ratio between say 1280x720 and 704x400.

Current suggestions range from using 1280x720 work raws, applying all the typesetting to that then downscaling to 704x400. But there is also the cropping approach.

What do people generally believe to be the best approach when it comes to fine typesetting (i.e. frame-by-frame)?
__________________
Yoroshiku Fansubs: Website | Twitter | IRC
Grv is offline   Reply With Quote
Old 2007-03-16, 05:23   Link #2
martino
makes no files now
 
 
Join Date: May 2006
If you are using .ass for typesetting, then the script automatically gets resized to match the video resolution. Though someone else should explain this better, since I don't know much about how ASS works. All I know is that you don't have to specify the resolution of the video, ASS will do that for you.

If you are using AFX, then you'd better make the original typeset in 1280x720 (you don't really want to upscale it to loose quality/sharpness, now do you?). Then if you want to apply it to the 704x400 version all you have to do is add the overlay and add .yourfavresizer(704,400) and the typeset will get resized (note that I use TheFluff's insertsign() function, so it might be a bit different in case of the overlay() function; I can't look it up right now).

Now, if you look at the possible resolutions (and their aspect ratios):
Code:
16/9      1.7777777777777777777777777777778
704/396   1.7777777777777777777777777777778
704/400   1.76
1280/720  1.7777777777777777777777777777778
You can see that the difference between the ratios are so small that you can ignore them. So I wouldn't really be too concerned about going from 720p to 704x400 when doing the typesets, unless you have to overlay really many of them on a frame/scene, at a very precise location, with a very precise width and length.

Also AFAIK x264 doesn't really have any problems with non-mod16 resolutions, I think that mod16 is recommended much more for for older types of encoders like XviD and DivX to increase compressibility, not 100% sure though. But yes, generally why not use mod16 automatically when you can...at least I do.
__________________
"Light and shadow don't battle each other, because they're two sides of the same coin"
martino is offline   Reply With Quote
Old 2007-03-16, 05:30   Link #3
Grv
宜しく
*Fansubber
 
 
Join Date: Feb 2006
Age: 30
We use a mixture of AFX and ASS for typesetting. The vast majority is in ASS though. I believe Mitomi does the typesetting using a resolution of 1600 width or something, so it's very precise. Which generally leans towards using the 1280x720, apply TS, downsize approach.

Just putting the feelers out really to see how other people have handled it
__________________
Yoroshiku Fansubs: Website | Twitter | IRC
Grv is offline   Reply With Quote
Old 2007-03-16, 06:55   Link #4
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 30
Hmm, three points:

First of all, any kind of block-DCT/motion vector based video compression such as MPEG-4 (both part 2 ASP and part 10/H.264) are much more efficient when the encoded video resolution is a whole multiple of the largest macroblock size, which is 16. A MOD16 encode should use less bits than a non-MOD16 encode which is eg. 4 pixels smaller. I haven't done any actual experiments, but try taking some video which is MOD16 and encode in constant quantizer and note down the resulting size, then take the same video, crop 4 pixels off the bottom and encode again at the same quantizer as before, the second one should be at least as big as the first one. (Chance is the second one is the bigger even though it seems to have less pixels.)
You can do the same experiment with JPEG pictures, just the block size is 8 there.

Also, with ASS the script and video resolution don't have to match, though it's a very good idea to let them, or at least have script resolution be a whole multiple of the video resolution. And note that this is the encoded video resolution, not the displayed. (This is important for anamorphic encodes.) If you use a script resolution higher than the video resolution, you will still gain the extra precision even if the video isn't at the script resolution when the subs are rendered.
The reason you shouldn't let the script resolution have a different width/height ratio than the video encoded resolution is simply that scaling is done in a rather odd way in VSFilter, and the effects can be a bit funny if you use the wrong width/height ratio. (Anyone who ever generated a karaoke effect at the wrong script resolution will know what I mean. All the syllables will be incorrectly spaced.)

Last this is just that, anamorphic encoding. If anamorphic encoding is supported on the target container (MKV and MP4 do, AVI should but no playback software supports it) you can encode at some really bizarre (ok, use a sensible one) but still MOD16 resolution, and have the video resized to the correct aspect ratio on playback. This can also be used as a "trick" to save bandwidth on HD encodes, eg. downscale 1280x720 to 1024x720, you're scrapping some horizontal resolution but not so much it should be visible (by normal people) but you will save a whole lot of bits.
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2007-03-16, 07:06   Link #5
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Well, if you're doing an HD/SD release (like I do with two of my shows), I take a simple philosophy:

the HD is a mod16 res (1280x720), and the SD is half size (640x360) (and much lower bitrate.

Since I figure, the people who download the SD version aren't going for the high quality one anyway, so if the encoding isn't as bit-savvy as it could be, so be it.

Plus, I know that x264 handles non-mod16 encoding by padding the edges with a reflection image of the partial edge macroblocks (instead of blackness, like xvid), and that really doesn't waste that many bits compared to the slightly bigger resolution.


As for the production itself, I simply work in 1280x720 for all typesetting, and qc encoding etc... and then when making the SD encode I just add in a resize and lower the target bitrate.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-03-16, 07:13   Link #6
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Quote:
Originally Posted by Grv View Post
it would be best practice to use MOD16 resolutions for all encodes.
Code:
12:48:22 [Rizon] -!- TheFluff [~fluff@MOD16.is.my.Religion]
12:48:22 [Rizon] -!-  ircname  : TheFluff
(...)
12:48:22 [Rizon] -!- End of WHOIS
Damn straight.

x264 tells you so, too:
Code:
avis [info]: 704x396 @ 23.98 fps (1001 frames)
x264 [warning]: width or height not divisible by 16 (704x396), compression will suffer.
Another reason to use MOD16 is that you can get really funky decoder bugs if you don't. Certain versions of ffdshow will display a green line diagonally over the entire image with some non-mod16 sources.

Quote:
Originally Posted by Grv View Post
The problem here is how to handle the slight difference in aspect ratio between say 1280x720 and 704x400.

Current suggestions range from using 1280x720 work raws, applying all the typesetting to that then downscaling to 704x400. But there is also the cropping approach.

What do people generally believe to be the best approach when it comes to fine typesetting (i.e. frame-by-frame)?
I don't see the problem, really. If you have a 1280x720 raw and plan on releasing in both 704x400 and 1280x720, there's really only one sensible way to do it, namely typeset on the 1280x720 and apply the textsub() call after cropping and resizing. I always crop anyway, and if you do it right the aspect ratio error will usually be less than 0.5%. That minor difference is not enough to make the typesetting seem off. Same thing goes for AFX really, except in that case it's probably best to apply the AFX before cropping and downscaling. Alternatively you could crop and resize the overlay clips with the same parameters as you use on the main raw, but it yields mostly the same result anyway, so why bother...

It should be noted that while ASS has PlayResX and PlayResY headers, these have nothing to do with the actual video resolution. They just define the granularity and size of the ASS "canvas" so to speak. If they happen to be the same as the physical resolution of the video, one ASS pixel is the same as the video pixel, but if they are not (and frequently they aren't), an "ASS pixel" is something quite abstract. While I usually use the video resolution or an exact multiple thereof for various reasons, there are typesetters that always use 1600x1200 or something. There are arguments either way, but it's largely irrelevant here, I think.
Edit: listen to what jfs says, he's the resident VSFilter guru.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2007-03-16, 07:40   Link #7
Devastator
Senior Member
 
 
Join Date: May 2006
There's another way to resize AFX typesets, though I'm not sure how many people use this method. You could create a new composition that's 704x400, copy the 1280x720 composition into it and scale it to match the 704x400 (or to match 711.[1]x400) and render that out for use with the 704x400 raw. All other methods I'd use have been mentioned, so no point repeating them.

Quote:
Originally Posted by Quarkboy View Post
Plus, I know that x264 handles non-mod16 encoding by padding the edges with a reflection image of the partial edge macroblocks (instead of blackness, like xvid)
I've actually seen this before, but honestly, it's anything but pretty.
Devastator is offline   Reply With Quote
Old 2007-03-16, 08:28   Link #8
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Devastator View Post
I've actually seen this before, but honestly, it's anything but pretty.
Well, you don't SEE it... unless the decoder is borked. The padding is done internally during the compression and the extra edges aren't shown on playback.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-03-16, 08:47   Link #9
Devastator
Senior Member
 
 
Join Date: May 2006
Well, I guess it was more of the idea of mirroring that caught my eye. I just checked around for the past while and can't seem to find any non-mod16 h.264 encodes, though I do have a lot of WMV9 ones (for which, the mirroring of the bottom row can be seen during playback). Not that I have any interest to bother with such, but I could test some h.264 encodes to see what happens. It could very well be that the WMV9 decoder is borked, but that goes without saying when it's MS.
Devastator is offline   Reply With Quote
Old 2007-03-16, 09:10   Link #10
GacekSSJ4
Junior Member
 
 
Join Date: Mar 2007
I just read jfs' topic and he wrote about doing typesets in higher resolutions. So i wanted to ask:

For example i got RAW video with 640x360 resolution... and i will set 1280x720 in my script. How will it exacly work ??
Will VSFilter divide my every pixel in my vieo in 4 pixels and put subtitles with more precision... ?? Just asking to be sure
__________________
GacekSSJ4 is offline   Reply With Quote
Old 2007-03-16, 10:11   Link #11
jfs
Aegisub dev
 
 
Join Date: Sep 2004
Location: Stockholm, Sweden
Age: 30
I'm not sure here, but I believe VSFilter handles higher script resolutions "properly" in that sense, that it actually does get sub-pixel precision when script resolution is bigger than video resolution. This also includes anti-aliasing. As long as you keep script resolution a whole multiple of video resolution everything will behave properly and as one would expect. You simply gain more precision in positioning. (Also, if you double width and height of the script resolution, you will also have to double font sizes and border widths to get the same result.)

And when typesetting on anamorphic video, remember to scale X or Y by a bit to avoid getting a stretched font on the display. (VSFilter knows nothing about anamorphish but happily passes along the aspect ratio so it doesn't break it either. Well except if you use its "add black edges" option in DShow.)
__________________

Aegisub developer [ Forum | Manual | Feature requests | Bug reports | IRC ]
Don't ask for: More VSFilter changes (I won't), karaoke effects, help in PM's
jfs is offline   Reply With Quote
Old 2007-03-16, 12:26   Link #12
GacekSSJ4
Junior Member
 
 
Join Date: Mar 2007
Ahhh.... That may come handy someday

Thank you. For this and Aegisub LOL
__________________
GacekSSJ4 is offline   Reply With Quote
Old 2007-03-22, 11:48   Link #13
Starks
I see what you did there!
*Scanlator
 
 
Join Date: Apr 2004
Age: 27
Send a message via AIM to Starks
ASS pixels are really only useful in Aegisub...
__________________
Starks is offline   Reply With Quote
Old 2007-03-22, 17:04   Link #14
xat
Senior Member
*Fansubber
 
Join Date: Dec 2005
Quote:
Originally Posted by Starks View Post
ASS pixels are really only useful in Aegisub...
Gaining sub-pixel precision can be useful for typesetting in general, and if you're using that, chances are that you're not using aegisub's point and click \pos'ing. Could you clarify?
xat is offline   Reply With Quote
Old 2007-03-25, 13:01   Link #15
Starks
I see what you did there!
*Scanlator
 
 
Join Date: Apr 2004
Age: 27
Send a message via AIM to Starks
Quote:
Originally Posted by xat View Post
Gaining sub-pixel precision can be useful for typesetting in general, and if you're using that, chances are that you're not using aegisub's point and click \pos'ing. Could you clarify?
I do use the point and click positioning in Aegisub... It's only useful if the typesetter remembers to use the proper PlayRes to match the raw's resolution, otherwise it's a pain in the .ass (from my limited experience) to edit afterwards.
__________________
Starks is offline   Reply With Quote
Old 2007-03-25, 14:11   Link #16
Harukalover
In exile
 
 
Join Date: May 2006
Location: There! Not there! There!
Age: 26
Quote:
Originally Posted by Starks View Post
I do use the point and click positioning in Aegisub... It's only useful if the typesetter remembers to use the proper PlayRes to match the raw's resolution, otherwise it's a pain in the .ass (from my limited experience) to edit afterwards.
/me points to the shiny Resample Resolution option in Tools.
__________________
"Brainpower without willpower is no power."
Harukalover is offline   Reply With Quote
Old 2007-03-25, 15:24   Link #17
Starks
I see what you did there!
*Scanlator
 
 
Join Date: Apr 2004
Age: 27
Send a message via AIM to Starks
Quote:
Originally Posted by Harukalover View Post
/me points to the shiny Resample Resolution option in Tools.
I know. But then the font and size sensitive karaoke gets all out of whack...
__________________
Starks is offline   Reply With Quote
Old 2007-03-26, 13:17   Link #18
Alizar
Junior Member
 
Join Date: Mar 2006
Quote:
Originally Posted by TheFluff View Post
Another reason to use MOD16 is that you can get really funky decoder bugs if you don't. Certain versions of ffdshow will display a green line diagonally over the entire image with some non-mod16 sources.

This glitch tends to only show when ffdshow is used to decode AND vsfilter is running (no vsfilter = no glitch) and the source is non-MOD8 in terms of width (i.e. 852x480).

Otherwise, you're simply risking the playback software being too stupid to catch the padding that both x264 and xvid add to allow them to encode anything that isn't MOD16 and therefore displaying that garbage. In essence, that's what you're paying in terms of compression loss for choosing a non-MOD16 res. It's as if you're encoding at the next available MOD16 resolution. So if you encode at 704x396, the encoder just adds padding (frequently just duplicating the last block, if I understand correctly) and writes video that is 704x400, just setting a flag to prevent its display.

So, like Fluff said, no good argument against the slight resize in most cases. The % AR error is minimal, and you're already paying for it. So you might as well go MOD16, avoid any arcane errors, and be done with things.
Alizar is offline   Reply With Quote
Old 2007-03-26, 15:06   Link #19
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Okay, well, here's a question then:

Assuming I start with a 1280x720 source... Isn't it true that resizing to exactly 1/2 height x width to 640x360 produces less artifacts then resizing to, say 640x368?

So although I might waste some bits, isn't perfect factor of 2 resizing end up with a cleaner picture in the end?
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2007-03-26, 19:21   Link #20
checkers
Part 8
*IT Support
 
 
Join Date: Jul 2006
Location: Western Australia
Age: 26
Send a message via MSN to checkers
only if you use a point resizer
checkers is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 02:27.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
We use Silk.