704x400 versus 704x396: Does it make a difference?

[TheFluff]

Blame our analog ancestors.

[Starks]

Originally Posted by TheFluff

Blame our analog ancestors.

One would think that digital technology would liberate us from such ridiculous and archaic standards. I'm rather shocked that this isn't the case.

[TheFluff]

It's all about backwards compatibility.

[Unearthly]

Quoted from the linked article (very interesting read, haven't gotten to go through the whole thing yet though):

From the video industry's point of view, the current (SDTV, as opposed to HDTV which is another kettle of fish) digital video formats - those that actually get used in practical real-life applications such as DVD, DV, VCD, SVCD, digital television etc. - are all about interoperability. At the advent of digital video - late 1970's, when committee work was started on CCIR 601 (later to become ITU-R BT.601) - there was already a vast catalog of analog video material in formats defined solely by analog standards. What is more, enormous amounts of money had been poured in analog studio equipment such as cameras, video switchers, proc amps, tape decks and other tools of trade. What a waste it would have been if the "next generation" digital video formats were designed in a such way they had absolutely nothing in common with old analog formats, and required ditching all the analog equipment!

It was clear from the beginning that the industry wanted a smooth, well-defined transition path between the current analog systems and the brave new digital world without running into too many compatibility issues. It was also considered necessary to be able to freely mix and match digital and analog equipment. The result was that the digital (SDTV) video formats we now use are based on the concept of digitizing old, analog video signals, thus interlocking to the analog video standards.

This connection between the digital and analog domains is permanent. Some of the fundamental features of digital video, such as image geometry, are actually defined in the analog standards. Even if we go all-digital, the relationship is still there, as long as we use either ITU-R BT.601 pixels or "industry standard" square pixels.

It makes sense from a business standpoint, even if it might stink from an ideal standpoint.

[Starks]

Originally Posted by TheFluff

It's all about backwards compatibility.

Heh. Never thought of it that way.

Also, what is it called when the resolution calls for 852x480 but is actually 720x480?

[Bot1]

http://en.wikipedia.org/wiki/Anamorphic_widescreen

[Nicholi]

When you are using anamorphic you still treat the entire Crop/Resize thing the same. Except the so called "final resolution" in your calculations is the resolution after being resized anamorphically (853x480 in this case). This is because you want the AR error of what is viewed by the hosers to be as low as possible, which is only after the image has been resized.

The usual custom I believe for anamorphic videos then is to encode the video after cropping to the nearest mod16 res (for compression reasons obviously). This resolution really does not matter whatsoever since it is going to be resized to the final resolution on viewing. You know what the final resolution is (after being anamorphically resized), and you know what your crop is, thus you know what the AR error is after being resized. So really you see in anamorphic encoding this intermediate resolution is of little importance. At least in terms of calculating the AR error and what the final resolution should be.

Mod16'ness is next to godliness.

Truly, isn't encoding phun kids?!

[ArchMageZeratuL]

I just want to add a little note to mention that most viewers won't realize things are wrong until there's over 10% of aspect ratio error, so they most certainly won't notice the 1% "error" in keeping 704x400 non-anamorphic. It's likely that there were other small errors before that introduced a similar or greater error, anyway, and nobody will be able to tell. Even careful measuring of perfect circles in the image will give you results within that margin of error.

For the 10% case, many people had that with ZX's Evangelion releases. I don't remember what playback combination exactly did it, but it would just ignore the aspect ratio and display it at 704x480, instead of at 4:3... And most people never realized that anything was wrong. And, as you can see, (704-640)/640 = 10%.

So, in summary, I'll say what everyone else has been saying: keep the video mod16, and use anamorphic if you must. If it's 704x400, not setting the anamorphic flag won't make any noticeable difference. Anyone claiming to be able to see it is lying. If it's something like 704x480 at 4:3, the difference is noticeable for many, but not most. Definitely do set the flag.

[Zero1]

Originally Posted by ArchMageZeratuL

For the 10% case, many people had that with ZX's Evangelion releases. I don't remember what playback combination exactly did it, but it would just ignore the aspect ratio and display it at 704x480, instead of at 4:3... And most people never realized that anything was wrong. And, as you can see, (704-640)/640 = 10%.

Out of interest, was the AR flag set in bitstream or container?
Personally, given the choice I will specify the framerate and aspect ratio in the bitstream, rather than container; then at least if at some stage it's transmuxed, the information remains intact. A nice example is the TS dumps I used to do; the AR and framerate information is stored in the MPEG-2 bitstream, so when I demuxed them from the TS and threw them into an MP4; everything worked as it should without me needing to specify aspect ratios or anything.

OT: Actually I was testing Nero for a friend some days ago and was quite impressed to see that it took an anamorphic, VFR, high profile H.264 MP4 and converted it to MPEG-2 and set the AR in the MPEG-2 bitstream with perfect sync. I was expecting it just to letterbox it and display as is; and I really expected some kind of failure regarding framerates.

Also to say that most people didn't notice is perhaps not an accurate assumption, I mean there may have been many people that noticed it but couldn't be bothered to whine about it, or bring it up.

Then again, if they didn't notice, I could probably believe that; that's why leechers leech and encoders encode. But 10% is quite a lot. The fact that it didn't fill their screen, and wasn't quite narrow enough to be 16:9, in addition to the characters looking a little wide should have given them a clue.

[Potatochobit]

Ok, so I'm starting to make encodes off of DVD sources so I'm learning about mod16.

704x400 and 640x480 are the most common sizes for mod16?
now the DVD is actually 720, which is divisible by 16, but we still need to crop the video left and right by 12 pixels. This is true even for Widescreen looking shows?

the aspect ratio is what causes the video distortion? so it should always read 98% or higher?
here is what my numbers look like, the AR says 1.760 so this is too high? I havent found a way to change it in staxrip but I'm still learning. when I change the resize field, the AR changes also.

Spoiler:

here I took out 12 pixels on both side in the crop screen. the white bars on the left and right will be cut out. doesnt seem like too much? staxrip recommended 2 pixels each side?

Spoiler:

after I cropped 12 on each side the AR now returned to 1.760(0.15%) so, this is good now right?


when I did this test encode, the motion in the video is pixelated, or shows lines so to speak.still frames show perfect but when people move and such u can see a a few blocks. this is not an AR problem, it is a DVDrip problem or an interlace problem?

Spoiler:

A friend who doesnt know anything about encoding (who happens to have the videos ) was trying to encode but the picture comes out bad. you can see it pixelated here. see it in her hair? this is an AR problem or just a bad encode GUI problem?

Spoiler:

anyway, thanx for the help! I think I'll ask him to send me the VOB files so I can work on it.

[jfs]

NTSC DVD video is always 720x480 pixels. This is a 5:4 ratio of width to height, obviously neither 4:3 or 16:9, ie. DVD video never has square pixels. After cropping 16 pixels total from the sides, to get 704x480, you will have to make a decision: Anamorphic encode or not? Here, anamorphic means "encoded resolution is 704x480, played back resolution and aspect ratio is different." An anamorphic encode will usually give better quality without wasting bitrate, the only "drawback" (which isn't) is that it requires you to use a modern container such as MP4 or MKV.
If you do not want to have an anamorphic video you must resize the video before encoding, to either 640x480 (for fullscreen/4:3 video) or 704x400 (for widescreen video.) But resizing should be the last thing you do! There's other things first.

The interlacing artifacts you can see on the third picture you posted are from the telecine process. You must do inverse telecine on the video before encoding, which will most often also result in the frame rate changing from 29.97 to 23.976 fps. In anime you can however often encounter video that requires you to use variable frame rate (VFR) to truly look proper, because some sections might be animated in 23.976 fps and some in 29.97 fps. Again, VFR (at least to be done properly) requires a modern container, MP4 or MKV.
IVTC must be done before resizing. Edit: And IVTC is NOT deinterlacing. Telecined material must not be treated as interlaced video.
You can read much more about what telecine actually is and how IVTC works on Doom9.

The last picture you posted is simply not aspect ratio corrected, it's neither 16:9 or 4:3, but DVD resolution displayed as if the PAR (pixel aspect ratio) was 1:1 (square.)


Also I will tell you to stop using an automated application and learn how to build and use a toolchain yourself: Decrypt raw video off DVD. Index MPEG streams. IVTC and filter video with Avisynth. Encode video with x264 (or whatever.) Optionally transcode audio from DVD, unless you want to keep the original. Mux into final file.
The IVTC+filter step is by far the most demanding and is what really determines the quality of your encode.

[SirCanealot]

Originally Posted by jfs

After cropping 16 pixels total from the sides, to get 704x480, you will have to make a decision: Anamorphic encode or not?

Although to note that some DVDs don't require cropping as they use up the full 720x frame...

[martino]

Originally Posted by SirCanealot

Although to note that some DVDs don't require cropping as they use up the full 720x frame...

Actually you might find the fact that 8 and 8 pixels on each side are not shown during playback interesting, so they are pretty much "redundant" information. If I had the link which explained this in a much more complex way handy then that page would offer interesting reading material... Or you can wait for someone to explain it in more depth themselves.

[TheFluff]

Originally Posted by SirCanealot

Although to note that some DVDs don't require cropping as they use up the full 720x frame...

Bzzzt, worng

Even if they use the full 720 pixels you should still crop. See http://lipas.uwasa.fi/~f76998/video/conversion/

[Potatochobit]

Yeah, I tried to add ITVC filter earlier to the first encode, but it would not let me.

I thought it was a problem with x264, but after reading some more guides on doom9 I found out that most deinterlacer's are not compatible with YV12. this is the same case with ITVC?

When I first entered the x264 encode settings it asked me to convert to YV12, I wonder why that is.
anyway, so running just one ITVC filter good enough or do I need other filters to fix teleclining?

I have made a second encode, with 8 pixels each side, without specifying YV12, and the ITVC filter did work. it looks decent, but I can't really tell since I don't know what I am looking for.
the bitrate is at 980 with 102% quality. raising the bitrate any higher would just be a waste of bandwidth right?

when I use the resize filter after changing the resolution how would I know when to use soft or very sharp? usually I don't mess with it.

edit: awww i found a tiny error still. most of the frames are fine, but some little places still have the teleclining problem like around the mouth in one or two frames So I'm messing with DGindex right now to see how the de interlacing works.

ok this is strange, I compared my encode to an xvid version I have that I pulled off a torrent. the same frame is also messed up, so maybe this cannot be fixed or was not worth fixing. see her lips in the pic? everything else in the videos are fine cept small areas like this.

Spoiler:

[Starks]

Originally Posted by Potatochobit

ok this is strange, I compared my encode to an xvid version I have that I pulled off a torrent. the same frame is also messed up, so maybe this cannot be fixed or was not worth fixing. see her lips in the pic? everything else in the videos are fine cept small areas like this.

Spoiler:

Delicious mouth combs... Do they appear anywhere else?

[jfs]

Problems like mouth combs are what YATTA is there to fix.

[Potatochobit]

there is one other frame that it slightly appears.

Yeah i'm just going to have to bite down and learn yatta. But I think I'm going to take a break this weekend

[Shounen]

Because the majority of all encoders of the world simple just dosn't get the filtering and cropping/resizing part....

This is mostly pointed to those resizing (or simply letting the the container, a la MKV do the work) PAL must be one of the worst sources to work with, both quality, frame and pixel wise, this's why I'm never gonna bother with it.

There's alot of Interlaced source..the worst must be the UGLY, EDITED ones from American/US R1's (NTSC) of Anime taken from Japan (NTSC R2) I've seen em... Fieldorder have been messed up, Ugly editing and lots of Interlaced leftovers.

I would shoot those using R1's as "Anime" source. Your sir do not even deserve to Encode.

To keep the mod16 rule, you can either resize the video or let the final container do the work, a la MKV (and mp4 also if im not mistaken)

[TheFluff]

Originally Posted by Potatochobit

I thought it was a problem with x264, but after reading some more guides on doom9 I found out that most deinterlacer's are not compatible with YV12. this is the same case with ITVC?

no

Originally Posted by Shounen

words