View Full Version : In defense of the built-in Bob() filter...


Katie Boundary
11th June 2016, 19:41
One of these images was generated with the following script:

mpeg2source("101.d2v")

TFM(pp=0)

bilinearresize(512,288)

The other was generated this way:

mpeg2source("101.d2v")

bob(b=0,c=1)

selecteven()

bilinearresize(512,288)

Can you tell which is which?
https://scontent-ord1-1.xx.fbcdn.net/v/t1.0-9/13450896_1699811713616617_8788308528972810171_n.jpg?oh=5c1180a9609b8c9dd6fbcdd1cb9b70c6&oe=57D0258D
https://scontent-ord1-1.xx.fbcdn.net/v/t1.0-9/13445680_1699811716949950_4832694715972748094_n.jpg?oh=7ca0f47c2ecca6bd29ad08eee4de4beb&oe=57D5DC88

Motenai Yoda
11th June 2016, 20:36
1- tfm(pp=0) don't do any deinterlacing thing, only field match, if the source is a telecined plain, will be better than any bobber deinterlacer blender
2- you resize to AAAx288 which is almost the same as lowpass or blending all the artifacts a bobber will do
3- comparison image too much compressed to say anything.

hello_hello
12th June 2016, 01:39
In your Simpleresize thread you mentioned not using Reduceby2 due to the half pixel shift referred to in the documentation, but you'll defend this:

Bob (http://avisynth.org.ru/docs/english/corefilters/bob.htm)
However, it will appear to "shimmer" in stationary scenes because the interpolation doesn't really reconstruct the other field very accurately.

While ignoring this:
http://forum.doom9.org/showthread.php?p=1765736#post1765736

Surely you understand the difference between a field matcher and a deinterlacer well enough to understand you're comparing apples with mango fruit? Film converted to NTSC using pulldown isn't interlaced as such, it just uses the interlaced nature of NTSC to spread eight fields over ten (four frames over five), but the film content itself is still progressive and can be recovered. You wouldn't de-interlace it in exactly the same way you wouldn't field match interlaced video, because for interlaced video the two fields combining to make a single frame aren't the same moment in time.

johnmeyer
12th June 2016, 01:56
Bob <> IVTC

Bob is the completely and totally incorrect tool to use if the original material is film, and if it has been telecined to play at 29.97.

Hello_hello is 100% correct. +1

Groucho2004
12th June 2016, 02:55
Bob <> IVTC

Bob is the completely and totally incorrect tool to use if the original material is film, and if it has been telecined to play at 29.97.

Hello_hello is 100% correct. +1
Déjà-vu

Katie Boundary
12th June 2016, 06:26
Bob is the completely and totally incorrect tool to use if the original material is film, and if it has been telecined to play at 29.97.

This is obviously relevant to a screencap from Babylon 5, which has tons upon tons of shots rendered at 30p and even some that were composited at 60i.

hello_hello
12th June 2016, 06:48
This is obviously relevant to a screencap from Babylon 5, which has tons upon tons of shots rendered at 30p and even some that were composited at 60i.

Obviously, 30p is progressive and shouldn't require field matching or de-interlacing.

Not that your screenshots mean anything without also including an unmolested screenshot of the source frame, or better still, a sample of the video from which it came.

wonkey_monkey
12th June 2016, 13:26
This is obviously relevant to a screencap from Babylon 5, which has tons upon tons of shots rendered at 30p and even some that were composited at 60i.

It's still the wrong tool to use.

Your little "test" is ridiculous and disingenuous. You resized the image to 50%, thus disguising most of the artefacts that would have told us which image was which. It's like asking us to guess which colour matrix was used by giving us black and white images.

Then you compress the output to a 16kb JPEG, which is horrendously high compression.

If you do a blink comparison you'll see that the differences in JPEG compression far outweigh the differences caused by the interpolation.

Izuchi
12th June 2016, 14:41
Did you seriously just upload those images to facebook and then reposted them here? At least save them as PNGs and use an actual image hoster.

Katie Boundary
12th June 2016, 21:34
Did you seriously just upload those images to facebook and then reposted them here?

Yes, for I am lazy.

At least save them as PNGs and use an actual image hoster.

But JPEG more closely resembles MPEG, which is what most codecs these days are based on, AND all the good free hosting sites have gone or turned to crap. No site today is what Photobucket and Imageshack used to be.

microchip8
12th June 2016, 23:12
But JPEG more closely resembles MPEG, which is what most codecs these days are based on, AND all the good free hosting sites have gone or turned to crap. No site today is what Photobucket and Imageshack used to be.

you're adding an EXTRA layer of compression when saving them as JPG which makes your pics not identical to the MPEG vids you did. That's why people ask for lossless formats like PNG, to not add another compression with artifacts on top of an already compressed image snapshot

feisty2
12th June 2016, 23:21
imgur

hello_hello
12th June 2016, 23:56
postimage.org
imgur.com
imgsafe.org
pasteboard.co

Katie Boundary
13th June 2016, 04:40
you're adding an EXTRA layer of compression when saving them as JPG which makes your pics not identical to the MPEG vids you did. That's why people ask for lossless formats like PNG, to not add another compression with artifacts on top of an already compressed image snapshot

MPEG? There was no conversion to MPEG at any point in the process of generating these images. I opened the AVS files in Virtualdub, copied source frame to clipboard, and pasted in MS Paint.

I'm not an idiot.

Katie Boundary
13th June 2016, 05:00
Okay, here's a slightly easier challenge. This time, we're looking at a still image from Gene Roddenberry's Andromeda, brought to you by the oh so awesome imgur:

http://imgur.com/xPSaNwV
http://imgur.com/Lu6DH7D

So, any guesses?

hello_hello
13th June 2016, 06:07
So, any guesses?

I've tried guessing why you post screenshots without providing information regarding the type of source video, a screenshot of the source frame, or why in all the threads you've started to spout your bizarre ideas you've not once posted a sample of the source video when requested.
And you want people to guess? I'm guessing you've got something to hide.

wonkey_monkey
13th June 2016, 08:47
So, any guesses?

First you need to learn how to correctly post imgur images.

Secondly, give us an example which you haven't resized. Doing so disguises the artefacts you're challenging us to pick out, although in this case one image looks a lot worse than the other.

Edit: thirdly, and most importantly, just make your point and be done with it.

feisty2
13th June 2016, 09:07
Resize your shit down to 1x1 and there will be absolutely no difference :)

Groucho2004
13th June 2016, 10:24
Resize your shit down to 1x1
Word.

huhn
13th June 2016, 12:04
ohh i have a brilliant idea. (not really)

let's take a source and do a proper comparison. even through we know the results already!

comparison:

ffmpegsource2("C:\x\title07 (1)-001.mkv").trim(250,250)
loop(100,0,0)
bob(b=0,c=1)

selecteven()

bilinearresize(720,480)

bob (https://abload.de/img/bobg5xkb.png)

ffmpegsource2("C:\x\title07 (1)-001.mkv").trim(250,250)
loop(100,0,0)
TFM(PP=0)

TFM (https://abload.de/img/tfmpepbs.png)

source sample: http://filehorst.de/d/bkAimEgt

Katie Boundary
13th June 2016, 17:27
Resize your shit down to 1x1 and there will be absolutely no difference :)

As far as I can tell, that's exactly what Imgur is doing, which is why suggesting imgur in the first place was stupid.

720,480

What in god's name are you doing?!?

feisty2
13th June 2016, 17:46
As far as I can tell, that's exactly what Imgur is doing, which is why suggesting imgur in the first place was stupid.


Obviously, that ain't nothing imgur was or is or will be doing cuz I been using imgur like forever and that never happened once, blaming something for shits you did by your very self is another level of stupidity.

wonkey_monkey
13th June 2016, 18:11
As far as I can tell, that's exactly what Imgur is doing, which is why suggesting imgur in the first place was stupid.

That's not what it's doing. You're using it wrong.

You have put the URL of the image's full page between the IMG tags, instead of the direct URL of the images themselves.

If anyone remotely cares at this point, these are the images KB is banging on about:

http://i.imgur.com/xPSaNwV.jpg
http://i.imgur.com/Lu6DH7D.jpg

I don't know about anyone else but it seems pretty obvious that the lines in the first image have come off worse, though since I have no idea what probably over-complicated method KB used to actually get this far, I'm not prepared to say that that was definitely the bob()bed one.

And I still don't know what the point of this thread is.

Groucho2004
13th June 2016, 18:24
And I still don't know what the point of this thread is.
Apparently it's some sort of puzzle:
Can you tell which is which?:rolleyes:

hello_hello
13th June 2016, 19:40
I don't know about anyone else but it seems pretty obvious that the lines in the first image have come off worse, though since I have no idea what probably over-complicated method KB used to actually get this far, I'm not prepared to say that that was definitely the bob()bed one.

And I still don't know what the point of this thread is.

The insistence on resizing to a 512x288 resolution for screenshots is fairly puzzling, given it's far from normal when encoding, unless you have a method of sending the encoded version back to 1992.

The bottom pic definitely managed to come through the Katie process fairly unscathed compared to the top one, but we don't know if the source was interlaced, telecined, progressive, or what Katie inflicted on the video for each screenshot, so it's fairly meaningless.... once again with no screenshot or sample of the source for comparison.

filler56789
13th June 2016, 20:25
Converting Babylon 5 episodes to low-res MPEG-1 clips is a capital sin. :mad:

The choice is clear and simple:

repentance :) or destruction :devil:

huhn
13th June 2016, 21:59
What in god's name are you doing?!?

Anamorphic Encoding.

Katie Boundary
14th June 2016, 03:54
Converting Babylon 5 episodes to low-res MPEG-1 clips is a capital sin. :mad:

The choice is clear and simple:

repentance :) or destruction :devil:

Want to know what else I converted to VCD-compliant MPEG-1?

...


...

The Dark Knight.

Now back off or Die Hard and the first two Alien movies will be next. (waves mouse and keyboard menacingly)

Anamorphic Encoding.

Okay but... why? And why are you using MKV as a source? And what's this loop and trim crap? Why is only one script subject to resizing? Your comparison is not in any way analogous to mine.

hello_hello
14th June 2016, 05:00
Okay but... why? And why are you using MKV as a source? And what's this loop and trim crap? Why is only one script subject to resizing? Your comparison is not in any way analogous to mine.

You can put mpeg2 video in an MKV container. Google MakeMKV and brace yourself.

Loop and Trim crap?
He's narrowed decoding down to a single frame with it.

No, huhn's comparison is not analogous to yours. He didn't resize the video or compress the screenshots. huhn's screenshots make sense for comparing filters. Your screenshots are a waste of time.

huhn
14th June 2016, 07:10
Okay but... why? And why are you using MKV as a source? And what's this loop and trim crap?

why 720x480? because it is the native resolution and this give the most accurate results.

bilinearresize(720,480) does nothing by the way. sorry i'm not used to bob().

this all was created on my HTPC using the normal text editor.

trim is is needed so people know what frame i was using. loop was used so i can take a screen using mpc-hc.


Why is only one script subject to resizing?
because the screen is already 720x480.

Your comparison is not in any way analogous to mine.

you want a to compared BOB() VS TFM()?

the point of TFM() is that you get the full resolution and the point of bob() is that you are losing 50 % of the source pixel and replace them using a resizer.

your comparison is a comparison of bob-> bilinear vs pure bilinear. downscaling to 288p with bilinear looks terrible that's nothing new. a dvd has a way higher resolution than this why lowering the resolution? the DVD resolution is already very low.

Ghitulescu
14th June 2016, 07:48
downscaling to 288p with bilinear looks terrible that's nothing new. a dvd has a way higher resolution than this why lowering the resolution? the DVD resolution is already very low.

Because Katie just discovered VCD and she's fascinated by it.

That's nothing new under the sun - audiophools discovered the worst technologies and now claim these are better than the established ones.

Let her be happy.

Sharc
14th June 2016, 10:26
Original clip = PAL DVD, progressive content 720x576 (encoded as interlaced for DVD spec compliance)

script 1:
DGSource("C:\.......\VTS_01_1.dgi")
a=bilinearresize(720,288)
b=tfm(pp=0).bilinearresize(720,288)
compare(a,b)
Result: PSNR = 98 dB (= no deterioriation)


script 2:
DGSource("C:\.......\VTS_01_1.dgi")
a=bilinearresize(720,288)
b=bob(b=0,c=1).selecteven().bilinearresize(720,288)
compare(a,b)
Result: PSNR = 45.2 dB (worse than script 1, but visually still good)


Added:

... and for a telecined 1920x1088 source:

Script for comparing tfm() vs bob(), keeping the duplicated frames, i.e. 29.97 fps progressive):
DGSource("C:\......\telecined.dgi")
a=tfm().bilinearresize(720,288)
b=bob(b=0,c=1).selecteven().bilinearresize(720,288)
return compare(a,b)

Result: PSNR = 49.09 dB

Means the 2 versions deviate little only, and when watching they look "quite the same" and it is hard to tell which is better.

(I resized to 288 vertical just to follow the OP's approach. Without vertical resizing to 288, TFM() clearly wins. In case of subsequent encoding the difference will become even more prominent to the detriment of the bob() because the jaggies of the bob() variant will consume extra bits.)

Katie Boundary
14th June 2016, 16:45
why 720x480? because it is the native resolution and this give the most accurate results.

I'd argue that the "most accurate" results are the ones that most closely resemble what you'd actually see at a resolution and bitrate that are suitable for Internet distribution.

trim is is needed so people know what frame i was using. loop was used so i can take a screen using mpc-hc.

USE VIRTUALDUB.

downscaling to 288p with bilinear looks terrible that's nothing new. a dvd has a way higher resolution than this why lowering the resolution?

Babylon 5 was shot at 16:9 and pan-and-scanned for broadcast. the DVDs restored the original aspect ratio. I needed a target resolution that was exactly 16:9. I also needed both the horizontal and vertical resolutions to be divisible by 16, because the MPEG gods are quick to anger. This leaves me with very few choices. 256x144 is far too small, though it would have been fun to post such images and watch all of your heads explode. 512x288 is acceptable and quite common. the next one is 768x432, which is very close to the same number of total pixels as NTSC DVD resolution (331,776 vs. 345,600), putting it in the "why bother re-encoding at all?" range.

I also wanted it to be the same resolution as my files derived from letterbox widescreen DVDs, wherein the relevant part of the image is only 720x360, and therefore upscaling to 768x432 would be as pointless as upscaling to 1920x1080.

the DVD resolution is already very low.

:rolleyes:

You're adorable.

Original clip = PAL DVD, progressive content 720x576 (encoded as interlaced for DVD spec compliance)

script 1:
DGSource("C:\.......\VTS_01_1.dgi")
a=bilinearresize(720,288)
b=tfm(pp=0).bilinearresize(720,288)
compare(a,b)
Result: PSNR = 98 dB (= no deterioriation)


script 2:
DGSource("C:\.......\VTS_01_1.dgi")
a=bilinearresize(720,288)
b=bob(b=0,c=1).selecteven().bilinearresize(720,288)
compare(a,b)
Result: PSNR = 45.2 dB (worse than script 1, but visually still good)

OMG WTF is with these people who post these whack-ass AVS scripts? This one doesn't even have any pictures!

For our final two experiments, I shall first provide another pair of shots from Andromeda. This is where the weaknesses of bob are most obvious:

https://scontent-sea1-1.xx.fbcdn.net/v/t1.0-9/13413652_1700776626853459_1723943621280465592_n.jpg?oh=e1583c125da9f32cdb125ddc4e725ff8&oe=580C9F1E
https://scontent-sea1-1.xx.fbcdn.net/v/t1.0-9/13435402_1700776630186792_498073797771426318_n.jpg?oh=9dc8443caa2e4513930db9e68dd5553c&oe=57D21E55

Of course, the differences are really only discernible in that one spot where you have a bunch of sharp, nearly horizontal lines all packed together. If we assume that only 10% of frames have this kind of "grill" feature, and that it's only taking up 10% of the frame, then the resulting video stream comes out to roughly ~99% perfect.

Finally, there's this:

https://scontent-sea1-1.xx.fbcdn.net/v/t1.0-9/13413512_1700781716852950_6048485524867646730_n.jpg?oh=c9b3a24d7428f75f575db6866fbd6153&oe=57FE7558

https://scontent-sea1-1.xx.fbcdn.net/v/t1.0-9/13417648_1700781710186284_2830161760413934546_n.jpg?oh=40dad5176ca972e00ec8a898f0d4a79b&oe=57FEFCA9

If you look very carefully at the windows in the egg-shaped building, you can probably take a pretty good guess which of these was bobbed and which was field-matched. Look at any other part of the image, however, and you'll need a magnifying glass to tell the difference.

filler56789
14th June 2016, 16:54
.........
I also needed both the horizontal and vertical resolutions to be divisible by 16, because the MPEG gods are quick to anger.

Divisible by 8, actually. TMPGenc does the right thing since ages ago. OTOH, support for mod-8 dimensions in HCenc is very-recent.

wonkey_monkey
14th June 2016, 17:13
If we assume that only 10% of frames have this kind of "grill" feature, and that it's only taking up 10% of the frame, then the resulting video stream comes out to roughly ~99% perfect.

Well, yes, if by "perfect" you mean after butchering the resolution of the video.

As I said before (or I think I did), this is like comparing colour matrixes by only looking at the results after applying grayscale. Pointless.

"Hey, look, bob() is only slightly worse than TFM if you remove all the high frequency components which are bob()'s worst artefact!" Brilliant "defense" ;)

Sharc
14th June 2016, 18:29
....OMG WTF is with these people who post these whack-ass AVS scripts? This one doesn't even have any pictures!

Instead of posting single pictures (no need to show more jaggies) I made some PSNR tests for 2 types of sources (progressive and telecined) based on YOUR 2 scripts in your first post.
The reason why one gets halfway decent results with bob() is mainly due to the vertical resize to 288 (applying low pass filtering) IMO.

Katie Boundary
14th June 2016, 18:44
Divisible by 8, actually. TMPGenc does the right thing since ages ago. OTOH, support for mod-8 dimensions in HCenc is very-recent.

Then explain why the VCD standard is 352x240 instead of 360x240

Explain why nobody torrents anything at 640x360, but 624x352 is common.

EDIT: https://en.wikipedia.org/wiki/Macroblock#Transform_blocks

Instead of posting single pictures (no need to show more jaggies) I made some PSNR tests for 2 types of sources (progressive and telecined) based on YOUR 2 scripts in your first post.

Your scripts look almost nothing like mine.

colours
14th June 2016, 19:42
Then explain why the VCD standard is 352x240 instead of 360x240

The VCD standard is not the MPEG-1 standard.

the next one is 768x432, which is very close to the same number of total pixels as NTSC DVD resolution (331,776 vs. 345,600), putting it in the "why bother re-encoding at all?" range.

Actually, why are you reencoding at all?

Katie Boundary
14th June 2016, 23:05
The VCD standard is not the MPEG-1 standard.

That has nothing to do with the size of macroblocks in MPEG-based codecs.

Actually, why are you reencoding at all?

When dealing with whole episodes/movies? To save hard drive space while retaining the ability to carry my entire DVD library in my pocket.

I'm also interested in music videos, but I have no plans to use 60i content in the making of any of those, so that's irrelevant here.

Nevilne
14th June 2016, 23:17
Downsizing DVD resolution videos, why have nobody thought of this brilliant idea before.



Explain why nobody torrents anything at 640x360, but 624x352 is common.

A time traveler, 15 year from the past.

johnmeyer
14th June 2016, 23:58
Explain why nobody torrents anything at 640x360, but 624x352 is common.Do you just make this stuff up? 624x352 is common? Common ??

I don't think so.

Reading this thread is, as others have said, like taking a trip in a time machine back to before the millennium, when people actually did make VCDs. In 2016, I can think of no reason whatsoever -- including wanting to carry around your movies -- that would ever justify this crazy workflow. MPEG-1 is a horrible encoder compared to modern codecs. There is no reason to ever, ever use it.

Period.

You do understand, don't you, that reducing resolution has zero (that is 0.0000) impact on file size? Instead, file size is 100% determined by bitrate, and nothing else. So, if you want small files, use a low bitrate.

I have all sorts of movies I've created for portable devices, but the only time I created anything at these absurdly low resolutions was 4-5 years ago when the gen1 devices only supported 640x480.

My recommendation would be to ditch everything you are doing and instead standardize on 720p. This still looks great on a laptop (or larger display), and if you encode with MeGUI or Handbrake, you can get wonderful quality at really low bitrates, especially with commercial movies.

filler56789
14th June 2016, 23:59
Then explain why the VCD standard is 352x240 instead of 360x240

Explain why nobody torrents anything at 640x360, but 624x352 is common.

1) Because someone decided so, of course :rolleyes:
Look, I have already successfully encoded to mod-EIGHT resolutions with TMPGenc Plus.
I serious doubt that the programmer who wrote it didn't know what he was doing.

2) Because most "releasers" are even more clueless than you are? :rolleyes:

Probably they used (Auto)GK, which apparently is pickier than it had to be.
Hell, there still are people who proudly use VirtualDubMod :D

Katie Boundary
15th June 2016, 00:03
Downsizing DVD resolution videos, why have nobody thought of this brilliant idea before.

It's extremely common...

A time traveler, 15 year from the past.

http://www.1337x.to/torrent/64087/Stargate-SG-1-Continuum-DivX-Ita-Eng-AC3-Sub-Ita-Tntvillage-Scambioetico

Uploaded 6 years ago, resolution 624x352.

Do you just make this stuff up? 624x352 is common? Common ??

I don't think so.

https://duckduckgo.com/?q=624x352+torrent&t=ffnt&ia=web

And that's not even a good search engine...

Reading this thread is, as others have said, like taking a trip in a time machine back to before the millennium, when people actually did make VCDs. In 2016, I can think of no reason whatsoever -- including wanting to carry around your movies -- that would ever justify this crazy workflow. MPEG-1 is a horrible encoder compared to modern codecs. There is no reason to ever, ever use it.

Please take your pointless bitching about VCDs to the appropriate thread. This is not it.

You do understand, don't you, that reducing resolution has zero (that is 0.0000) impact on file size? Instead, file size is 100% determined by bitrate, and nothing else. So, if you want small files, use a low bitrate.

What resolution DOES have an effect on is how low you can set the bitrate before the video starts to look like a realmedia file that was made from a captured VHS tape. that's pretty important.

My recommendation would be to ditch everything you are doing and instead standardize on 720p.

Yes... upscaling all of my DVD footage to 720p will totally increase the amount of real detail that it has. That's brilliant. Why didn't I think of it first?

I have already successfully encoded to mod-EIGHT resolutions with TMPGenc Plus.
I serious doubt that the programmer who wrote it didn't know what he was doing.

And people have made JPEGs in which the horizontal and vertical resolutions were both odd. That doesn't make it a good idea. Your argument is invalid.

filler56789
15th June 2016, 00:35
And people have made JPEGs in which the horizontal and vertical resolutions were both odd. That doesn't make it a good idea. Your argument is invalid.

That WORKS, period. The people who wrote the JPEG and MPEG specs are smarter than you, granted. A compliant encoder is required to deal with NON-mod16/mod8/mod4 frame dimensions. A compliant decoder is required to deal with NON-mod16/mod8/mod4 frame dimensions. The firmware of the ancient standalone DVD-players was not fully spec-compliant; this was one of the reasons why encoding to mod-16-only WAS important. But today, encoding video to mod-16-only frame dimensions does not make sense.

huhn
15th June 2016, 01:01
I'd argue that the "most accurate" results are the ones that most closely resemble what you'd actually see at a resolution and bitrate that are suitable for Internet distribution.
and that would be? even youtube is mostly 1080p or higher and is using codecs way better than mpeg1 so better for internet distribution.

and more important why does internet distribution matter to you?
USE VIRTUALDUB.
i use what ever i want and it is unlikely i will use that program anytime soon.

Babylon 5 was shot at 16:9 and pan-and-scanned for broadcast. the DVDs restored the original aspect ratio. I needed a target resolution that was exactly 16:9. I also needed both the horizontal and vertical resolutions to be divisible by 16, because the MPEG gods are quick to anger. This leaves me with very few choices. 256x144 is far too small, though it would have been fun to post such images and watch all of your heads explode. 512x288 is acceptable and quite common. the next one is 768x432, which is very close to the same number of total pixels as NTSC DVD resolution (331,776 vs. 345,600), putting it in the "why bother re-encoding at all?" range.


I also wanted it to be the same resolution as my files derived from letterbox widescreen DVDs, wherein the relevant part of the image is only 720x360, and therefore upscaling to 768x432 would be as pointless as upscaling to 1920x1080.
so quality doesn't matter?

:rolleyes:

You're adorable.

i just have some respect for picture quality.

johnmeyer
15th June 2016, 01:05
Yes... upscaling all of my DVD footage to 720p will totally increase the amount of real detail that it has. That's brilliant. Why didn't I think of it first?If all of your input is DVD, then I agree that up-scaling makes no sense. But, if you have DVDs, just encode them using the MeGUI "One Click Encoder" and be done with it: no need for all the weird things being discussed in this thread. If you aren't familiar with this MeGUI feature, it really does let you encode a DVD with one click, and it works remarkably well.

As for 720x480 looking worse at a given bitrate than would 352x240, that is true, but the tradeoff is not a linear one, and depends a lot on, well, a lot of things. In particular, if you go to your 1/4 DVD resolution, it does not mean that you will get equivalent "quality" (blockiness, mosquito noise, etc.) at 1/4 the bitrate. The tradeoff doesn't work like that.

One other thing that matters is the size of the display on which you will be watching. You have said you are doing all of this so you can carry around your all of your movies (why you would need to do this is another question). So, since you want to have them with you at all times, it sounds like you are going to watch the movies on some sort of portable display, and it will therefore be a pretty small display, something you can hold in your hand.

When viewing on a small display, you can go to pretty really low bitrates at 720x480, and it will still look fine.

Have you done comparison tests? I sure have. A two hour movie at 720x480 encoded to a file size of about 800 MB looks near-perfect on an iPhone or small iPad. And, 800 MB is about the size of a VCD, burned on an 80 minute CD, using Nero overburning (yes, I did make quite a few VCDs, back in the 1990s, when this technology was cutting edge).

And, let's face it: if you are willing to watch movies on a small device, using VCD technology, you are not someone who really cares about the quality of the video. If you did, you'd watch Blu-Ray on a big screen.

One thing for sure: you will get far better quality using H.264 than MPEG-1. No comparison.

One more point: I have no idea what the links to various low-res videos is supposed to prove. Yes, they still exist, but I haven't seen a modern movie or TV show encoded using MPEG-1 in years, and most of the stuff I've looked at is at least DVD resolution.

StainlessS
15th June 2016, 01:27
I found MeGUI to be not the easiest s/ware to come to grips with (you seem to go around in circles in the menus), its easy when you know it,
but till then is a little bit opaque.

Handbrake on the other hand I found to be extremely easy to use, I was quite amazed that a mate of mine (not any kind of even noobie at video processing), could produce rather good results.

Katie Boundary
15th June 2016, 01:54
That WORKS, period. The people who wrote the JPEG and MPEG specs blah blah bitch whine irrelevant crap

Let's get back to the important part. I was asked why I chose 512x288. My answer was "I needed a target resolution that was exactly 16:9. I also needed both the horizontal and vertical resolutions to be divisible by 16, because the MPEG gods are quick to anger. This leaves me with very few choices. 256x144 is far too small, though it would have been fun to post such images and watch all of your heads explode. 512x288 is acceptable and quite common. The next one is 768x432"

So unless you have some extraordinarily compelling case for why I should have picked 640x360, this part of the conversation is over.

and that would be? even youtube is mostly 1080p or higher

LOL. No. 1920x1080 is Youtube's hard upper limit at the moment, and most Youtube videos aren't even 1280x720.

and is using codecs way better than mpeg1 so better for internet distribution.

Keep all bitching about MPEG-1 to the relevant thread. This is not it.

and more important why does internet distribution matter to you?

Well, it's more a matter of versatility. Internet distribution is the ultimate fate of many, ahem, "backups"...

so quality doesn't matter?

http://westchestertownhall.com/wp-content/uploads/2014/05/strawman.jpg

If all of your input is DVD, then I agree that up-scaling makes no sense. But, if you have DVDs, just encode them using the MeGUI "One Click Encoder" and be done with it: no need for all the weird things being discussed in this thread. If you aren't familiar with this MeGUI feature, it really does let you encode a DVD with one click, and it works remarkably well.

Anything that "works" with only 1 click will screw something up that I would have otherwise diagnosed and corrected or otherwise adjusted for.

As for 720x480 looking worse at a given bitrate than would 352x240, that is true

Only at low enough bitrates. At high enough bitrates, the higher-resolution image will look better. In between, you're in the Weird Zone, making a tradeoff between macroblocking (high resolutions) and dot noise (low resolutions).

In particular, if you go to your 1/4 DVD resolution, it does not mean that you will get equivalent "quality" (blockiness, mosquito noise, etc.) at 1/4 the bitrate.

http://westchestertownhall.com/wp-content/uploads/2014/05/strawman.jpg

One other thing that matters is the size of the display on which you will be watching. You have said you are doing all of this so you can carry around your all of your movies (why you would need to do this is another question). So, since you want to have them with you at all times, it sounds like you are going to watch the movies on some sort of portable display, and it will therefore be a pretty small display, something you can hold in your hand.

Why carry a display with me at all, when they already exist everywhere I want to go?

(Let's not go into the fact that I've been known to carry mini-ITX desktops to McDonald's in my backpack, complemented by a 20-inch LCD that I carry around in a cardboard box with the other peripherals...)

if you are willing to watch movies on a small device, using VCD technology...

Please tell me how many VCDs you've seen that were encoded at 512x288.

http://westchestertownhall.com/wp-content/uploads/2014/05/strawman.jpg

One thing for sure: you will get far better quality using H.264 than MPEG-1. No comparison.

Please keep all random bitching about MPEG-1 to the relevant thread. This is not it.

One more point: I have no idea what the links to various low-res videos is supposed to prove.

It's to prove that 624x352 is quite a common resolution for... "backups"...

I haven't seen a modern movie or TV show encoded using MPEG-1 in years

Please keep all random bitching about MPEG-1 to the relevant thread. This is not it.

johnmeyer
15th June 2016, 02:14
Handbrake on the other hand I found to be extremely easy to use, I was quite amazed that a mate of mine (not any kind of even noobie at video processing), could produce rather good results.Yes, I think you are right. I've heard this same thing expressed by others. I got started with MeGUI instead of Handbrake because it accepted AVISynth scripts natively and Handbrake didn't. I don't know if that's changed.

johnmeyer
15th June 2016, 02:24
Keep all bitching about MPEG-1 to the relevant thread. This is not it.Between the repetition of this statement, and the obnoxious and totally irrelevant "straw man" graphics, it is quite obvious that you actually do not want any help achieving some goal. In fact, it appears that you do not want any help at all, since you have rejected virtually every bit of advice given in this thread (and in other recent threads as well).

You don't want to listen, so you'll never learn.

Since you don't want help, I'll be glad to oblige.

filler56789
15th June 2016, 02:29
Let's get back to the important part.

As you wish. I just pointed out that MPEG-1 and MPEG-2 encoders DO support mod-8 resolutions, period. But just like every good troll, you never know when to stop.

this part of the conversation is over.

I agree. Welcome to my IgnoreList (again).

StainlessS
15th June 2016, 02:38
because it accepted AVISynth scripts natively and Handbrake didn't. I don't know if that's changed.

Dont think it does (2+ years since I tried it).

Think it will even recreate DVD menus in MKV, was real impressive but cant remember exactly what it was that took my breath away.
EDIT: Not sure, think you may have to give Handbrake an ISO to be able to replicate DVD menus in MKV.

Was looking for a suitable smiley, but found this instead, luv it http://www.cosgan.de/images/smilie/frech/r070.gif

Katie Boundary
15th June 2016, 02:43
Between the repetition of this statement, and the obnoxious and totally irrelevant "straw man" graphics, it is quite obvious that you actually do not want any help achieving some goal. In fact, it appears that you do not want any help at all

...it took you 3 pages to realize that this thread had nothing to do with asking for help with anything?

Wow.

huhn
15th June 2016, 02:59
LOL. No. 1920x1080 is Youtube's hard upper limit at the moment, and most Youtube videos aren't even 1280x720.

https://www.youtube.com/watch?v=KMQ_rl7WiTA most of there videos are UHD.

and that's nothing special anymore...

Well, it's more a matter of versatility. Internet distribution is the ultimate fate of many, ahem, "backups"...

i see...

Katie Boundary
15th June 2016, 03:42
https://www.youtube.com/watch?v=KMQ_rl7WiTA most of there videos are UHD.

Well, I stand corrected.

and that's nothing special anymore...

Sorry but it most definitely is. I have folders on my external hard drive dedicated to the hundreds of vids that I've downloaded from youtube or other sites via Keepvid.com, Video DownloadHelper, etc., and I always grab the highest-resolution copy. 1080p is ultra-rare; slightly over half go as high as 720p.

Regardless, unless someone gives JMS a hundred million dollars to literally re-shoot all the live-action content in Babylon 5 and re-render all the CGI, Babylon 5 will never have more detail than it does at 480i. The same is true of Andromeda, Farscape, Birds of Prey, most of the Star Treks and Stargates, or literally any TV show that was produced after editing on tape became a thing but before about 2002. Ergo, there is absolutely no point in talking about the suitability of such high resolutions for the distribution of these shows over any medium.

EDIT: prepare your anuses, because I'm about to double the amount of butthurt in this thread. You want DVD-level resolution? You got it.

https://scontent-sea1-1.xx.fbcdn.net/v/t1.0-9/13435318_1700970193500769_3845856984972426008_n.jpg?oh=76115cf7a893b6065d1c02cc7d1e9f50&oe=5801F91B

https://scontent-sea1-1.xx.fbcdn.net/v/t1.0-9/13435430_1700970200167435_4668032349655494101_n.jpg?oh=28a24130c19563a6957e5df5f709011c&oe=580FEEF6

Even though I chose this frame specifically for the amount of fine detail in the blond character's hair, there's still no difference that can be seen there without actually flipping back and forth between the images in something like Windows Photo Viewer. The only place in the whole image where there IS a noticeable difference is on Garibaldi's left (your right) shoulder.

So, with almost no noticeable difference between AVIsynth's built-in Bob() filter and an actual proper field match, why should I believe that there's a huge difference between Bob() and more computationally intensive, easier-to-screw-up bob-deinterlacers like Yadif and NNEDI?

Sharc
15th June 2016, 07:29
Even though I chose this frame specifically for the amount of fine detail in the blond character's hair, there's still no difference that can be seen there without actually flipping back and forth between the images in something like Windows Photo Viewer. The only place in the whole image where there IS a noticeable difference is on Garibaldi's left (your right) shoulder.

So, with almost no noticeable difference between AVIsynth's built-in Bob() filter and an actual proper field match, why should I believe that there's a huge difference between Bob() and more computationally intensive, easier-to-screw-up bob-deinterlacers like Yadif and NNEDI?
Visible differences also depend on the nature of the picture. You wrote that low bitrate encoding matters to you. Keep in mind that jaggies will eat up bits for encoding which could better be spent elsewhere.
But to each his own... :)

huhn
15th June 2016, 07:51
So, with almost no noticeable difference between AVIsynth's built-in Bob() filter and an actual proper field match, why should I believe that there's a huge difference between Bob() and more computationally intensive, easier-to-screw-up bob-deinterlacers like Yadif and NNEDI?

source?

and this JPG is bob(): https://scontent-sea1-1.xx.fbcdn.net/v/t1.0-9/13435318_1700970193500769_3845856984972426008_n.jpg?oh=76115cf7a893b6065d1c02cc7d1e9f50&oe=5801F91B

feisty2
15th June 2016, 08:06
Well just do whatever the phuck you want with your freaking vids, since no one really agrees with you apparently, and you won't take any idea from others, what's the actual point of keeping this you against everyone else thing going?
Your vids, your call, do anything you like to them and be happy with it, no one else gives a phucking crap.

Sharc
15th June 2016, 08:15
Even though I chose this frame specifically for the amount of fine detail in the blond character's hair, there's still no difference that can be seen there without actually flipping back and forth between the images in something like Windows Photo Viewer. The only place in the whole image where there IS a noticeable difference is on Garibaldi's left (your right) shoulder.

If you are keen in spotting differences you may want to use a script like (again using your scripts of the first post):
a=tfm(pp=0).bilinearresize(512,288) #or the field matcher of your choice
b=bob(b=0,c=1).selecteven().bilinearresize(512,288) #bobber
return subtract(a,b).Levels(127, 1, 129, 0, 255)

When there are no differences, the picture is just grey.
You can also use the script to visualize the differences against the original (original resized to same resolution of course).

wonkey_monkey
15th June 2016, 09:04
Well, I stand corrected.

Get ready for a shock because you're about to be corrected again.


Explain why nobody torrents anything at 640x360, but 624x352 is common.

It's extremely common...

https://duckduckgo.com/?q=624x352+torrent&t=ffnt&ia=web

And that's not even a good search engine...

Google search results for "624x352 torrent": 367,000 results
Google search results for "640x360 torrent": 465,000 results

640x360 wins!

there's still no difference that can be seen

The only place in the whole image where there IS a noticeable difference is on Garibaldi's left (your right) shoulder.

Right, so you've contradicted yourself there, for a start. And the problem is also noticeable on her nose and in her hair.

Secondly, this is a still image. Bob's artefacts will be far more noticeable in motion because of all the shimmer. How about you post an animated, looping gif of just two frames, from a relativity still scene, using both tfm and bob, and see which is worse?

And what about those other images you (failed to) post? The bob artefacts were strikingly obvious in those, even at half resolution. So it looks like what you've done is cherry-picked an example where the artefacts aren't so bad (yet still very obvious in a particular place).

manono
15th June 2016, 10:58
Explain why nobody torrents anything at 640x360, but 624x352 is common
Because back in the dark ages of XviD encodes, Mod16 was required by the 'scene' and was suggested for encoder efficiency. 624x352 is Mod16 for both height and width, 640x360 isn't. These days it doesn't much matter but maybe some still keep to the old ways.

hello_hello
15th June 2016, 12:41
I think you'll find all the 624x352 torrents in those searches are Xvid/DivX AVI.The "scene" encoders mostly stuck to mod16 back then. Since the world switched to x264 encoding, chances are some people still use 624x352 out of habit, but 720x404 is probably far more common now. Why, I don't know. I'd use 704x396 instead as it's exactly 16:9, although when I'm re-encoding a 16:9 NTSC DVD, I generally resize to 832x468, as it's also exactly 16:9, and the closest mod4 16:9 resizing to the original height of 480.

Yes I know resizing the height is the work of Satan, but I invariably need to resize by a few pixels for one reason or another anyway, so I resize to 832x468. If I'd noticed lots of ill effects, I wouldn't do so (I resize the width to square pixels dimensions for my TV's media player) but I can't say I have, and the reality of it is, DVD video doesn't look all that spectacular anyway. In fact resizing to 832x468 with Spline36Resize has the effect of sharpening a little, and while I know sharpening artefacts are also a product of Satan, I generally like the subtle sharpening effect. It might be more subtle for NTSC than PAL. I can't remember. I mostly resize PAL DVDs to 960x540 and there's a larger amount of resizing than for an NTSC DVD, so the effect of the resizing might be more noticeable for PAL.

Katie is of course continuing with her preference for being wrong, because her claim that it's extremely rare for video to be uploaded as torrents at 1080p is about as accurate as her claim that 624x352 is still commonly used. I only looked at the first couple of search results, but the first one was uploaded in 2014, the second in 1991, and the third in 2008. Mind you I'm not sure if I'd search for "1080p torrent" and pay much attention to the number of results, given many torrent sites are probably telling search engines not to index them, or whatever the process is called. I'm not sure if they actually do that, but it's possible, plus when you search for something "naughty" via Google, the search results often include a link to a list of the results removed due to take down notices. Like this (https://www.lumendatabase.org/notices/12225931). I suspect VCD and even AVIs will pollute search results far longer than modern formats, as it's not likely many takedown notices are issued for VCD torrents, given most people stopped using VCD long before the Digital Millennium Copyright Act was introduced. The links to the search results Google remove are included in the take down link, but they're no longer included as standard search results.

Xvid's had it's day, and the party was over for VCD not long after it began... if there ever was one. I've no idea, as I've never encoded or burned a compliant VCD disc myself. I think by the time I became interested in re-encoding DVDs it was common for computers to have a DVD burner, and the DVD players I owned back then were all happy to play Xvid AVIs. Back then..... watching encoded video on a CRT TV.... I don't think I had a proper appreciation for how average Xvid's quality is. At least when using the default matrix, which I always did.

I see Katie's busy polluting her thread with silly pictures when she has no response to the points being made, or more likely, doesn't understand them.

the next one is 768x432, which is very close to the same number of total pixels as NTSC DVD resolution (331,776 vs. 345,600), putting it in the "why bother re-encoding at all?" range.

I laughed out loud when I read that one. It was possibly true in 1992, or if you still encode with MPEG1. There days, I can encode a PAL movie at 1024x576 and still reduce the file size considerably compared to the original vob files. Especially if it's a dual layer DVD. If it's single layer and therefore the DVD video bitrate is lower.... which seems to be more common these days, the size reduction is still quite substantial using CRF18, just not as large.
As I pointed out to Katie in her thread boasting abut compressing 168 episodes of Star Trek down to 76GB at VCD resolution, x264 should do much better. I only checked one folder on my drive, which contained Stargate SG1, but by comparison, with some tedious noise removal and debanding I ended up with 212 episodes and two movies compressed to 73Gig at CRF18 and 704x396 (they were so noisy, by the time much of it was removed, reducing the resolution a bit didn't make much difference). Maybe Katie was back in ostrich mode by then so she doesn't know AVC can be more efficient.

Speaking of which, the bitrate reduction for a given CRF value when re-encoding newer content isn't just my imagination is it? Thanks to digital cameras (and I assume due to a huge reduction in noise/grain), 720p encodes seem to be coming in at closer to DVD-encode bitrates these days, still using CRF18. Having to denoise less often is a joy. I use QTGMC in progressive mode for denoising, which is obviously slow, so being able to re-encode HD without noise removal is great. A lot of the time there's still compression artefacts to clean up so I'm still using QTGMC regularly, but not having to remove excessive grain all the time makes a nice change (I know some people don't mind grain but I find it quite annoying).

On the subject of MeGUI, I actually found it fairly intuitive. I switched from AutoGK to MeGUI so I was already a little familiar with Avisynth and the tools both programs have in common. I'll confess when I first looked at MeGUI my initial reaction was "how the &^*% do you use this", but once I discovered the File/Open menu it was really just a matter of following the prompts and running jobs added to the queue. I never use the OneClick encoder myself though, and I'm not sure MeGUI would be a good thing for Katie anyway. She'd probably be wanting to tell it how to do things, yet this would be one of those times when the software would know better, and for NTSC DVDs she mightn't be able to index the video while always ignoring the pulldown flags, or whatever she's doing. I still wonder what process Katie is using to open and preview the DVDs in VitualDub, given most of her diagnostification seems to have originated in the twilight zone. She's never enlightened us as to how she's doing it. Other than that, previewing a script in MeGUI's preview is no different to previewing it with VirtualDub.... aside from a lack of audio.

I wonder how long it'll take.... with not a single person agreeing with her methods.... before Katie will consider the possibility it's not the rest of the world that's wrong? It's actually quite impressive.... being able to ignore reality completely. I have a relative who does the same thing. He makes up his mind about something, then looks for info to support it while discarding everything else.... and given he has the whole internet at his disposal, it's not hard to find something, somewhere to support your opinion no matter how wrong or ridiculous it is. He has Borderline Personality Disorder though, so for him at least it's understandable.

colours
15th June 2016, 16:33
I'd use 704x396 instead as it's exactly 16:9, although when I'm re-encoding a 16:9 NTSC DVD, I generally resize to 832x468, as it's also exactly 16:9, and the closest mod4 16:9 resizing to the original height of 480.

I'd hate to argue against someone disagreeing with KB, but SIWOTI (http://xkcd.com/386/).

Resizing a DVD source to an exact 16:9 resolution is wrong most of the time, because DVD aspect ratios are based on analogue standards that say very weird things, like how NTSC is not really 486 active scanlines, but 484 full scanlines and 2 half scanlines. In particular, the correct pixel aspect ratio for NTSC 16:9 DVDs is 155200/127953, not 40/33 (ignores half scanlines) or 32/27 (ignores overscan) or whatever else you might see floating on the interwebs.

Granted, I'm not sure if the standards are ever followed to the letter, because it seems that there's not a single person alive who understands all of these arcane standards.

That has nothing to do with the size of macroblocks in MPEG-based codecs.

Which is also irrelevant???????????????????????????

Macroblocks are padded if the video resolution is not perfectly divisible by however wide the macroblocks are. This padding incurs a very slight compressibility penalty, and if that bothers you, maybe don't use MPEG-1. As johnmeyer also said, you'd win more from using x264 than you'd lose from not using a mod-16 resolution.

Sharc
15th June 2016, 17:01
I'd hate to argue against someone disagreeing with KB, but SIWOTI (http://xkcd.com/386/).

Resizing a DVD source to an exact 16:9 resolution is wrong most of the time, because DVD aspect ratios are based on analogue standards that say very weird things, like how NTSC is not really 486 active scanlines, but 484 full scanlines and 2 half scanlines. In particular, the correct pixel aspect ratio for NTSC 16:9 DVDs is 155200/127953, not 40/33 (ignores half scanlines) or 32/27 (ignores overscan) or whatever else you might see floating on the interwebs.....
Yep! Similar applies for PAL. A nice and helpful overview has been presented here (http://forum.doom9.org/showpost.php?p=1058927&postcount=11).

filler56789
15th June 2016, 17:04
.............

As johnmeyer also said, you'd win more from using x264 than you'd lose from not using a mod-16 resolution.

Even DivX or Xvid would be a much-better choice than MPEG-1, regarding compression efficiency /quality per bitrate. But then Katie probably would invent that "long GOPs are evil" :rolleyes: , "the MP4 container sucks" :rolleyes: , etc etc etc, blah-blah-blah, yadda-yadda-yadda.

Motenai Yoda
15th June 2016, 17:09
most of dvd has the half scanlines harcoded, or cropped away (something like 90% of dvds) so you should not consider them unless you know the video is rotated.

hello_hello
15th June 2016, 18:06
I'd hate to argue against someone disagreeing with KB, but SIWOTI (http://xkcd.com/386/).

Edit: Sorry about this post being so long but a couple of times I realised I hadn't mentioned all the reasons you're wrong when you say I'm not resizing "correctly". ;) If you assumed I only ever use the exact 4:3 or 16:9 PARs I don't. I may have given that impression by only mentioning exact 16:9 and 4:3 resizing. Although 4:3 ITU DVDs usually end up as 4:3 after cropping the crud, or I'll crop a bit extra to ensure the output is at least 4:3. I don't mind 4:3 encodes being a bit wider than 4:3, but often it doesn't work out that way.
If a source is fairly close to 16:9 I'll often crop until it's exactly 16:9. After crud removal, ITU resizing would be likely to make it into the "close enough to 16:9 to keep cropping" category (assuming there's no letter-boxing, of course). Often episodes of a TV show can have slightly different aspect ratios (different amounts of black to crop) so if I cropped the crud and nothing but the crud my brain probably wouldn't be able to cope for long. I aim to crop and resize each one to the average aspect ratio, or I pick a logical aspect ratio and stick with it...... 16:9, for example. ;)

Once upon a time I used anamorphic encoding, but then I bought a TV with a media player and a Bluray player that don't obey MKV/MP4 aspect ratios. I rarely use either players myself as I use a PC for playback, but for me it's easier to go with square pixels than worry about the video displaying correctly, and there's the Spline36Resize sharpening bonus....

I'd disagree with your argument regarding pixel aspect ratio. I'm fairly convinced (through experience) that all 4:3 DVDs are ITU and all but the oldest 16:9 DVDs use 16:9 resizing. That's for PAL, but I suspect NTSC is no different. A possible exception might be newer BBC 16:9 DVDs. I have unproven suspicions they're ITU, but I haven't been able to compare any to a HD square pixel source. For the times I've done so with other 16:9 DVD encodes, non-ITU has matched the HD source, with two exceptions. I'm pretty sure the PAL Terminator 2 DVD was one, but I can't remember the other.

I originally used the "not quite right" ITU pixel aspect ratios for the source video.... because MeGUI does. I'm fairly sure AutoGK does when ITU resizing is enabled.
I've created custom mpeg4 aspect ratios in MeGUI's configuration myself because by default it uses either the generic or "almost right" ITU PARs. The x264 encoder configuration includes mpeg4 PARs, but not ITU, so consistency was a motivation. MeGUI lets you manually change the Input Display Aspect Ratio to whatever takes your fancy. I have it defaulting to "generic PARs" so I just need to remember to change that to the mpeg4 for 4:3 DVDs. As a resizing bonus, the new width doubles as a reminder to check/change the Input DAR.
I hadn't realised until I created the custom mpeg4 aspect ratios that they result in the same display aspect ratios for PAL and NTSC, which means I only had to create two. 1.818 and 1.364 (or thereabouts... I can't remember exactly).

Even though there's "ITU", "almost ITU" and "Mpeg4" PARs, the differences between them are too small to trigger even my OCD tendencies, so for me it's either non-ITU or mpeg4 PARs these days.

The HDMI spec appears to say 16:9 is 16:9 and 4:3 is 4:3, and if I feed my TV 720x576 and tell it to resize to 16:9 or 4:3, that's how it resizes, and I've read reports regarding the picture width changing slightly when switching between composite and HDMI outputs on a player, so in reality a 4:3 DVD is probably never going to display correctly in a HDMI world unless it's resized to square pixels, and the worst that can happen for 16:9 DVDs is you pick the wrong DAR and have to remux to change it later, but at least you have that option.

Anamorphic encoding doesn't solve the resizing ambiguity. For 1024x576, you'd hope to end up with the encode displaying as 16:9 every time, and for 1048x576 it should always display a little wider, but if you decide the PAR choice was wrong after encoding you can always remux to change it, as you can for anamorphic encodes, although....
I kind of recall some players assume all 720x576 or 720x480 video is either 4:3 or 16:9 and display it that way even if the aspect ratio is set slightly different in the file (don't quote me on that, as I'd need to check) but even if a player takes it upon itself to choose either ITU or non-ITU simply because the video is 720x576, resizing to square pixels prevents that from happening. If the output aspect ratio is wrong it's the user's fault when resizing, but at least the player didn't get it wrong without giving me an option to correct it (although a tap on the 6 key on the numeric keypad tells MPC-HC to stretch the width by about 2.5%, and the 4 key reduces it, so they're effectively the ITU or non-ITU manual correction buttons).

Even assuming you could always correctly determine a DVD is supposed to be ITU while another is not, I'm absolutely certain I've encoded DVDs where the aspect ratio was wrong in places, or changed a bit, and not always just "should be ITU" wrong or "shouldn't be ITU wrong"... occasionally the level of wrongness approaches Katie magnitude (I've seen a football shaped Stargate on DVD, or ask the poor Metro-Goldwyn-Mayer lion what he's been though over the years).
Most DVDs aren't all over the place aspect ratio-wise, and the majority are probably close to being correct (ITU vs non-ITU aside), but you have to start somewhere, and choosing the shape of the source pixels seems as good a place as any, whether or not you resize to square pixel dimensions.

Katie Boundary
15th June 2016, 21:38
Visible differences also depend on the nature of the picture. You wrote that low bitrate encoding matters to you. Keep in mind that jaggies will eat up bits for encoding which could better be spent elsewhere.
But to each his own... :)

It's better to spend bits on jaggies than to spend them on interlaced or blended frames for all those orphaned fields in the content that I deal with on a daily basis.

Because back in the dark ages of XviD encodes, Mod16 was required by the 'scene' and was suggested for encoder efficiency. 624x352 is Mod16 for both height and width, 640x360 isn't. These days it doesn't much matter but maybe some still keep to the old ways.

"It's an elegant resolution from a more civilized age."

http://www.ranthollywood.com/wp-content/uploads/2015/05/Luke-Skywalker-Lightsaber.png

Resizing a DVD source to an exact 16:9 resolution is wrong most of the time, because DVD aspect ratios are based on analogue standards that say very weird things, like how NTSC is not really 486 active scanlines, but 484 full scanlines and 2 half scanlines. In particular, the correct pixel aspect ratio for NTSC 16:9 DVDs is 155200/127953

Great. Now I have to go and re-evaluate all these approximations of 16:9 that I went and documented for no reason, and see which ones are closest to 1.819418

...

Well that was a short search. 20:11, which shows up at both 320x176 and 640x352, is 1.81818... and that's an even better approximation of 1.819418 than 656x368 was for 16:9 (99.932% match vs. 99.729% match).

See, Colors, this is why I love you :) You've given me something new to be OCD about!

Macroblocks are padded if the video resolution is not perfectly divisible by however wide the macroblocks are. This padding incurs a very slight compressibility penalty

HAHA I WAS RIGHT!

Suck on it, Filler!

and if that bothers you, maybe don't use MPEG-1.

Keep all bitching about MPEG-1 to the relevant thread. This is not it.

Even DivX or Xvid would be a much-better choice than MPEG-1

Keep all bitching about MPEG-1 to the relevant thread. This is not it.

But then Katie probably would invent that "long GOPs are evil"

When configuring XviD, I cap i-frames at one every 240-600 frames depending on the frame rate at which I'm encoding. Whether that's "long" or not is subjective.

It also has nothing to do with this thread.

"the MP4 container sucks"

https://cdn.meme.am/instances/500x/60678176.jpg

hello_hello
15th June 2016, 22:51
It's better to spend bits on jaggies than to spend them on interlaced or blended frames for all those orphaned fields in the content that I deal with on a daily basis.
I wonder if she who can't be wrong will ever post a sample of the source video to show she knows what she'e talking about and isn't just unlucky to have such an unusually high number of orphaned fields in every DVD she owns.

Great. Now I have to go and re-evaluate all these approximations of 16:9 that I went and documented for no reason, and see which ones are closest to 1.819418...

Well that was a short search. 20:11, which shows up at both 320x176 and 640x352, is 1.81818... and that's an even better approximation of 1.819418 than 656x368 was for 16:9 (99.932% match vs. 99.729% match).

Looks like I can't tell Little Miss Can't Be Wrong that in my opinion the majority of 16:9 DVDs are 1.777, as she might still have me on her list of people to ignore so she can pretend to know everything. If someone else shares my opinion, they might have to break the news to her... now she's found something new to be wrong about.

HAHA I WAS RIGHT!

Suck on it, Filler!

Comedy Gold! First Katie argues the video has to be mod16, then she claims to be right after she's told it doesn't. Or maybe Katie imagines the resizing has to be mod16, while at the same time not needing to be mod16 because the encoder adds padding when it's not.
Filler was never wrong. He stated mod8 was fine several times, but the general consensus back in the days of Xvid was if you wanted to be 100% sure an AVI capable DVD playr would play the video in an AVI, it should be mod16, because they weren't always compliant. Some encoder GUIs wouldn't let you do anything else. MeGUI only began to indulge in non-mod16 resizing a few years ago. I think it still asks if you're sure when adding a non-mod16 script to the job queue with Xvid set to encode.

The 624x432 AVIs you're referring to.... are you aware they generally contain Xvid/Divx encoded video and that's not the same as mpeg1, which in turn isn't the same as VCD or standard or mpeg2 and therefore irrelevant to your choice of resolution? I'm asking out of concern.... you are seeking treatment for your ongoing inability to comprehend basic English?

hello_hello
15th June 2016, 23:18
One other thought on aspect ratios.... I rarely encode the extras on DVD or Bluray, but I did so a while back for Star Gate Universe, which was way better than any of the previous Star Gates and shouldn't have been cancelled even if it was a little too much like BattleStar Galactica at times (minus the God bothering and without showing any sign it would disappear up it's own backside around season four as BG did). Why does the good stuff tend not to rate? I'm still emotionally scarred from Firefly's cancellation. I'm not sure I'll ever fully recover.

Anyway, the extras were encoded at 720x480, and some contained scenes from episodes, so I compared them to the 1080p versions. The pixel aspect ratio wasn't mpeg4 if the HD version was correct. It wasn't using a generic "16:9" display aspect ratio either, but if memory serves me correctly it was fairly close. I think the require,ent to match the 1080p picture aspect ratio was 2 pixels cropped from each side and 16:9 resizing.

Based on that single experience I found myself wondering if the mpeg4 pixel aspect ratios for SD Bluray video are generally ignored the way ITU PARs are for 16:9 DVDs. Anyone know? It wouldn't surprise me but I've not compared any SD Extras and 1080p aspect ratios since

filler56789
16th June 2016, 01:51
HAHA I WAS RIGHT!

Pretending that you didn't understand what I wrote and/or what I meant... How typical of trolls.

Katie Boundary should move house to Yahoo! Answers. Or to Quora.

Seriously.

Because those sites always say a sincere 'welcome' to every type of troll.

hello_hello
16th June 2016, 02:07
I prefer my filters to be simple, fast, and dumb (separatefields, uncomb, ibob, simpleresize, et cetera). This has caused a lot of problems for me.

I'm still trying to get my head around the new signature.
It seems like something shifted reality sideways a little and it doesn't feel quite right yet.
Either that or sarcasm doesn't work as a forum signature.

filler56789
16th June 2016, 02:40
For Ms Boundary, a mod-8 (600x424), 24fps, MPEG-1 file,
created with TMPGenc Plus:

http://forum.videohelp.com/attachments/37410-1466040668/morpheus-argument.mpg

And obviously, it's not VCD-compliant... I'm so sorry... :rolleyes: :rolleyes: :rolleyes:

filler56789
16th June 2016, 02:59
Comedy Gold! First Katie argues the video has to be mod16, then she claims to be right when after she's told it doesn't. Or maybe Katie imagines the video has to be mod16, while at the same time not needing to be mod16 because the encoder adds padding when it's not.

Yes. And the decoder is required to ignore the "padding" and display "only what is relevant", so to speak.
Evidently, Katie has never considered that *1080* is not an integer multiple of 16...

hello_hello
16th June 2016, 04:57
Yes. And the decoder is required to ignore the "padding" and display "only what is relevant", so to speak.
Evidently, Katie has never considered that *1080* is not an integer multiple of 16...

I started to type the same thing regarding 1080p in my previous post, but then decided against it. She who's never wrong claims not to be reading my posts anyway, and it's always possible too much reality too quickly might cause her to retreat back to 1992 forever.

thecoreyburton
16th June 2016, 05:23
I'm surprised this thread has kept going this long!

1) Quite a lot of the information presented by Katie is inaccurate or significantly dated.
2) Despite several members giving sincere advice, examples, proof and potential solutions in several different ways, Katie either doesn't understand or refuses to listen.
3) Katie often edits her posts after the fact in a manner that doesn't attempt to add, correct or clarify information but rather to make the responding person seem ignorant.
4) There's no point to this thread. It was created to specifically without a question or situation.

I think it's best to assume this is a troll thread created to antagonize those who sincerely want to help. All the information and proof against the original example has been posted, sometimes repeatedly. If Katie can't come to a reasonable conclusion given all of the assistance provided then she won't. Whether it's because she can't comprehend what is being said (and I mean that in the nicest way) or whether it's because she refuses to, I think it's time to call it a day.

Edit: After looking at Katie's thread (http://forum.doom9.org/showthread.php?t=173583) and post (http://forum.doom9.org/showthread.php?t=173147&page=3) history as a whole, this seems to be a quite common trend.

colours
16th June 2016, 10:00
Wow, wall of text.

If you assumed I only ever use the exact 4:3 or 16:9 PARs I don't. I may have given that impression by only mentioning exact 16:9 and 4:3 resizing.

That was indeed the impression I got; sorry for misunderstanding.

I mean, the last DVD I processed (about a year ago) had no overscan and a sample aspect ratio of 6/5 (which is close to neither 32/27 nor 155200/127953), so I'm not claiming that most, or even a significant minority of, real-world DVDs follow BT.601. The spec exists and that's what it says; whether DVDs are produced to spec or not is a separate issue and I agree that the answer is generally "no".

Katie Boundary
17th June 2016, 05:16
For Ms Boundary, a mod-8 (600x424), 24fps, MPEG-1 file,
created with TMPGenc Plus:

http://forum.videohelp.com/attachments/37410-1466040668/morpheus-argument.mpg

And obviously, it's not VCD-compliant... I'm so sorry... :rolleyes: :rolleyes: :rolleyes:

http://www.newmediaandmarketing.com/wp-content/uploads/2014/05/irrelevant.gif

Evidently, Katie has never considered that *1080* is not an integer multiple of 16...

Actually, I just never cared because I never planned on upscaling Babylon 5 to 1920x1080

1) Quite a lot of the information presented by Katie is inaccurate or significantly dated.

Wrong. Well, there was that thing about Youtube videos existing at resolutions higher than 1080p, after which I admitted my mistake. But aside from that, you're wrong.

2) Despite several members giving sincere advice, examples, proof and potential solutions in several different ways, Katie either doesn't understand or refuses to listen.

Wrong again.

3) Katie often edits her posts after the fact...

Yay! You got one right!

...in a manner that doesn't attempt to add, correct or clarify information but rather to make the responding person seem ignorant.

Wrong. Strike 3, you're out.

4) There's no point to this thread. It was created to specifically without a question or situation.

Well, there WAS a point, but it wasn't made explicitly clear at first. I apologize. I'd go back and edit the original post to clarify the point, but then you'd probably use that to accuse me of trying to make you look ignorant.


Edit: After looking at Katie's thread (http://forum.doom9.org/showthread.php?t=173583) and post (http://forum.doom9.org/showthread.php?t=173147&page=3) history as a whole, this seems to be a quite common trend.

The only common trend I've noticed is that people on this forum have an extremely toxic habit of flooding my threads with spam, personal attacks, logical fallacies, and other garbage, while I desperately try to keep threads on-track.

BTW, your post is part of the aforementioned "spam, personal attacks, logical fallacies, and other garbage". Stop flooding this thread with it.

hello_hello
18th June 2016, 21:25
The only common trend I've noticed is that people on this forum have an extremely toxic habit of flooding my threads with spam, personal attacks, logical fallacies, and other garbage, while I desperately try to keep threads on-track.

I think that's a phenomenon known as "tunnel vision".

wonkey_monkey
18th June 2016, 22:52
The only common trend I've noticed is that people on this forum have an extremely toxic habit of flooding my threads with spam, personal attacks, logical fallacies, and other garbage, while I desperately try to keep threads on-track.

Funny how this happens to literally no-one else, isn't it? Could it be that there is some common factor?

johnmeyer
19th June 2016, 00:44
Funny how this happens to literally no-one else, isn't it? Could it be that there is some common factor?Of course there is this quote from a great book, "Catch-22:"

“Just because you're paranoid doesn't mean they aren't after you.”
― Joseph Heller, Catch-22

So, maybe we are all after him.