AnimeSuki Forums

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

Go Back   AnimeSuki Forum > AnimeSuki & Technology > Tech Support

Notices

Reply
 
Thread Tools
Old 2006-05-09, 02:15   Link #1
Garylisk
Baka Neko!
*Fansubber
 
 
Join Date: Nov 2003
Location: St. Louis, MO
Age: 34
Send a message via ICQ to Garylisk Send a message via AIM to Garylisk Send a message via MSN to Garylisk Send a message via Yahoo to Garylisk Send a message via Skype™ to Garylisk
Odd frame size, not sure if this is HDTV or just a really nice rip.

Look at the screen shots.. the framne size is an odd 640x360. The first episode was 640x352, but now eps 2 and 3 are 640x360.

http://i77.photobucket.com/albums/j4...isk/sasami.jpg
http://i77.photobucket.com/albums/j4...lisk/misao.jpg

The quality is really nice, I am not complaining... the ripper used 120fps as is typical, I don't get that either... but what can anyone on here tell me about this odd frame size?

PS - the eyes in this show creep me out.
__________________
-+-[Garylisk | Busybody of FoT | http://www.fotsubs.net/]-+-
Garylisk is offline   Reply With Quote
Old 2006-05-09, 03:20   Link #2
Eeknay
Gendo died for your sins.
*Fansubber
 
 
Join Date: Dec 2005
The first resolution is exactly 16:9 (1.78), but not mod16. The second resolution is a bit off (1.81), but is mod16.

In conclusion, Japanese cappers are crazy.
Eeknay is offline   Reply With Quote
Old 2006-05-10, 12:03   Link #3
killmoms
Former Triad Typesetter
 
 
Join Date: Dec 2003
Location: Washington, DC
Age: 30
How is 640 x 360 not exactly 16:9? Do a little cross-multiplication action, a la 7th grade, and you'll see it is exactly 16:9. 640 times 9 divided by 16 is, in fact, 360.

16/9 = 1.77777777~
640/360 = 1.7777777~

So, the first one was wrong (or cropped for some reason), and the second one is right.

You were right about one thing though: Japanese cappers ARE crazy.

EDIT: Wait a sec, read you wrong. I see what you meant. Still though, why do people worry about mod16 anyway, considering that newer codecs can encode in smaller increments?
__________________
thrillmoms.com - You know it.
@killmoms - I say things.
killmoms is offline   Reply With Quote
Old 2006-05-10, 12:43   Link #4
Eeknay
Gendo died for your sins.
*Fansubber
 
 
Join Date: Dec 2005
I can't remember off the top of my head but if you do a quick search on Doom9 I'm sure you'll get to the bottom of it.
Eeknay is offline   Reply With Quote
Old 2006-05-10, 14:09   Link #5
DryFire
Panda Herder
 
Join Date: Dec 2005
Location: A bombed out building in Beruit.
I few 640x480 raws I've dealt with are 640x360 with 8 pixels of black bar (4 on top and 4 on bottom. I suppose the capper who left it at 640x352 wanted a mod 16 resolution or didn't want to upsize it.
DryFire is offline   Reply With Quote
Old 2006-05-11, 02:11   Link #6
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 27
@ClessAlvein: It's not optimal. You're wasting bits encoding half or quarter blocks. IIRC, x264 (or at least older revisions of it) deals with it by adding black borders up to the nearest mod16 resolution.

Also, keep in mind that not all DEcoders deal with non-mod16 content properly.
__________________
| 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 2006-05-11, 02:42   Link #7
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 34
Send a message via AIM to Quarkboy
Assuming that you at least have a mod 4 resolution (anything else would TRULY be insane), I think h264 with it's 4x4 intra block search isn't going to waste too many bits anymore for non mod 16 resolutions. At least, I think they also made some optimizations lately for non mod16 encoding. Haven't done a full suite of tests, but I've made a number of encodes in 704x396 which were perfectly fine.

Using xvid, I'm not so sure of the drop in efficiency.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2006-05-11, 16:18   Link #8
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 29
119.88 fps is a convienient way of making a variable frame rate video (such as MKV with timecodes), constant framerate. With it being 119.88, it means that it can cleanly be decimated to 29.97 or 23.976 (if you intend to put out a CFR version of it).

However, you will find some AVI's out there that are 119.88fps when they don't need to be. Out of curiosity I took a 119.88 fps Gundam Seed Destiny OP (ew) episode and transmuxed it to MP4 (the original intent was just to see how much space it would save). MP4box automatically drops NVOPs. NVOPs are basically null or placeholder frames. The original intention was for "Variable Frame Rate" in a constant frame rate container. You would set a framedropping threshold in the encoder and when the change is below a certain threshold, it is not coded, and an NVOP is placed there. In effect the last frame is held and the NVOP is put there so the decoder/parser has something to read (and nothing to output, therefore holding the previous frame) and in a sense allows VFR in a CFR container.

The other method, still using NVOPs but with a slight difference, is just one of the two workarounds for getting MPEG-4 ASP with B-frames into AVI/VfW. What happens here is called packed bitstream. Due to VfW limitations, B-frames wouldn't work without a hack of sorts, since to form a B-frame you need infomation from a previous and future frame. VfW has a one frame in, one frame out limitation, which means it just cannot obtain the data from multiple frames simultaneously. This hack, known as packed bitstream, and developed by DivX means that a P and B frame essentially get "packed" together and forced through the decoder at the same time. So providing the decoder has read the last frame, with 2 frames being forced through at once, it now means it has the data to be able to decode the B-frame. AVI/VfW though are not very intelligent. Packing two frames together on a regular basis (which can happen a hell of a lot when using B-frames, but depending on the source) means you end up with a serious discrepancy in the number of frames (remember you are getting 2 frames and packing them into 1), and what with AVI being outdated, it cannot handle a Variable Frame Rate as such. In this instance, an NVOP is placed after the packed frame to make the correct number of frames.

Anyway, back to the point. I transmuxed this episode and it killed a ton of NVOPs. The file it returned was pure 23.976 fps CFR, and even the frame count checked out Ok.

As it happens, there is a tool that will let you add these NVOPs to the bitstream (originally for the purpose of VFR > 119.88fps CFR), so it seems to me that some cappers are adding these null frames for the hell of it, or maybe simply doing it for the wrong reason.

Let me explain. The most appealing use for VFR, would be to preserve "hybrid" sources. That might be anime with mainly 24fps, with some 30fps CG thrown in (or pans), or it could be that the OP and ED are 30fps but the rest of the episode is not. VFR would allow you preserve the 30fps segments since if they are very fluid it's unlikely that these frames will fall within a sane threshold and get decimated. The other side to that, is where you have the 24fps sections, the duplicates with the highest redundancy will be decimated with even a low threshold (barring compression artifacts that might interfere). In theory you will preserve the full motion of the 30fps sections, but you will not penalise the video in general, since you aren't encoding the video at 30fps and coding all the duplicates in the 24fps parts.

The other use of VFR, may be to simply save bits. You might decimate the whole video to give a 23.976fps (CFR) source and then slap a dedup over that with a higher threshold to nuke most duplicates. While it's true that frames with a lot of temporal redundancy compress extremely well, it would still be preferable not to code them at all in my opinion. The saving you would make when decimating a file to be encoded at a high bitrate would probably be negligable, but when I was encoding Kamichu at 30MB for curiosity's sake, I had to save bits wherever I could.

Now since I only have the OP of the encode in question, I cannot verify, but I would assume that method 2 was used, that it was either a 23.976fps max animation, or it was hybrid, decimated and deduped. There is constant motion in the OP, so obviously no frames would have been deduped from the OP. There might have been duplicates removed from the main episode, so I cannot categorically say that the NVOPs were added needlessly, but as far as the OP goes, these NVOPs served no purpose other than providing a higher framerate for a constant framerate section of video.

Now as for adding NVOPs for the hell of it (making 119.88 fps for no reason), it's possible that someone could decimate a video (giving 23.976fps) and use dedup with such a low threshold that nothing, except from maybe the odd frame gets dropped. Without testing, I believe that would give me a timecode file that I could use with tc2cfr to turn a 23.976fps CFR AVI into a 119.88fps CFR AVI.

Sound retarded? Well it's common knowledge that they also upscale D1 source (720x480) to 720p or so. Thing to remember with widescreen broadcasts is that they may just letterbox the encode and the active image area will only be approx 720x360 (It's non square pixels, remember), upscaling that to 1280x720 is ugly, especially with awarpsharp and edeen like the cappers seem fond of

It's part of the capper e-penis deal, "OMG MOAR RESOLUTIONZ" (aka upscale get), but it's beyond me why anyone would think that a 119.88fps raw would attract more leechers... Even if it was pure interlaced and you captured it as progressive (lol), you would need at most 59.94fps (1 frame per field).

What you need to remember too, is that Japanese DVB broadcasts at 29.97 fps. They don't put out some magic VFR video that needs to be converted to a 119.88 fps AVI. Just bog standard 29.97fps, sir, nothing to see here.

To justify 119.88fps raws in my opinion, you would need to:

1) Stream dump DVB or capture
2) Create a decimated AVI file using the Dedup filter (like the framedropping option in XviD) which will output a timecode file also
3) Use tc2cfr to take your decimated AVI and timecodes and create a new 119.88fps AVI (it reads the timecode file and adds the NVOPs)

Better yet, distro the stream dump , or just do a low threshold dedup and distro the MKV (so preserving the 24/30fps, else just decimate to 23.976 and stop with the retarded files).

As people have correctly remarked, 640x360 is "16:9" (I will come to this later) but not mod 16. Most smart people would resize to 640x360 and crop to give 352. For one it saves potential problems, decoding ugliness, loss of efficiency and for two, it's not like people will miss 4 pixels at the top and bottom.


Quote:
Originally Posted by ClessAlvein
How is 640 x 360 not exactly 16:9? Do a little cross-multiplication action, a la 7th grade, and you'll see it is exactly 16:9. 640 times 9 divided by 16 is, in fact, 360.

16/9 = 1.77777777~
640/360 = 1.7777777~

So, the first one was wrong (or cropped for some reason), and the second one is right.
This is the stuff that seperates the encoders from the encoders ;p

640x360 is exactly 16:9; as far as Pixel Aspect Ratio is concerned (quite literally the "shape" of the image as square pixels)
However... D1 active area is in the region of 704-711x486. For DVD and broadcast, this is rounded to 704 or 720 (black borders added where applicable) and the 486 is cropped to 480. There are two reasons, firstly mod 16 is optimal for MPEG-2, since it's macroblocks are 16x16, this also means you avoid "semi" or "offscreen" macroblocks, padding and the like. The other thing, is that for interlaced video, it is required that it is mod 32 (I won't go into the specifics because it is beyond the scope of this forum, but it is to do with the coding of fields rather than frames). The height of 480 fits mod32, which means it is automatically mod16 also.

Now bear that in mind, that the image before it is screwed over for DVD is around 704-711x486. Now the fact that the 6 pixels are missing from the height is irrelevant to the aspect ratio of the image (Display Aspect Ratio), only the aspect ratio of the frame (Pixel Aspect Ratio) is affected. Think back to the 640x360/640x352, the image is the same aspect ratio, just there are less vertical pixels.

Lets take a common scenario, resizing a 720x480 DVD source to 640x480 (square pixels). Most people would crop to 704x480 and resize to 640x480. For the most part that is fine, but technically it is wrong. Remember I told you that D1 vertical size is 486, but cropped to 480 for DVD? Well since the PAR doesn't matter, but the DAR does, it would actually be 486*1.33r, giving you 648x486 as true square pixels 4:3. Sounds whack, eh? What you would probably do is resize 704x480 to 648x480 and crop the 4 pixels from each side (or if not possible, just 8 pixels total). That way you keep the correct DAR, and by cropping you also get the correct PAR.

Now here's the fun part. All this amounts to... 640x360 not being 16:9 :O
Think anamorphic. Now I have seen some pretty whack DVDs in my time, some have borders as big as Xbox so you will need to take this with salt. Remember that 486 is D1 height, and that it is cropped to 480 for compression reasons. When you resize the 480 to 360, that is a factor of 1.33r, now if you divide 486 by 1.33r you get 364.5 (oh shit, I split the pixel). So when you resize your 704x480 source to 360, you are altering the aspect ratio, since really it ought to be 364.5 (or whatever your resizer will allow). Again, 364.5x1.77r=648, so resizing a source to 648x~364 and cropping to 640x352 might be good.


As for mod 16, even the most recent standards like h.264 make use of 16x16 macroblocks (in addition to smaller ones also), so mod 16 is still optimal. It kind of depends on the encoder how it handles non mod 16, if it padded you might end up encoding garbage, or may even change what block types are used to fit the frame (ie if it's getting near the edge of a frame, forcing a small MB where a 16x16 would not have fit). Both methods would reduce efficiency. I guess you could be relatively safe if you disabled certain modes, but I'd rather lose a few pixels for the sake of mod 16 than cripple an encode.


Quote:
Originally Posted by Quarkboy
Assuming that you at least have a mod 4 resolution (anything else would TRULY be insane), I think h264 with it's 4x4 intra block search isn't going to waste too many bits anymore for non mod 16 resolutions. At least, I think they also made some optimizations lately for non mod16 encoding. Haven't done a full suite of tests, but I've made a number of encodes in 704x396 which were perfectly fine.

Using xvid, I'm not so sure of the drop in efficiency.
It may not waste bits as such, but using a bunch of 4x4's where a 16x16 might have worked fine just because it's a non mod 16 resolution also amounts to suboptimal. You essentially limit the encoders options (if it worked like that).
__________________
Zero1 is offline   Reply With Quote
Old 2006-05-11, 16:51   Link #9
killmoms
Former Triad Typesetter
 
 
Join Date: Dec 2003
Location: Washington, DC
Age: 30
Jesus. Didn't realize the actual D1 area was less/more than 720 x 480. What a bitch. Yay digital approximations for outdated analog standards.

Please tell me that D5 active areas actually conform to the pixel counts in the HD standards.
__________________
thrillmoms.com - You know it.
@killmoms - I say things.
killmoms 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 09:00.


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