madVR - high quality video renderer (GPU assisted)

[Qaq]

You mean you got problems with wrong colors with deinterlacing turned on?Nope. I'm stick with XP now and have not tried DXVA2 things yet.Or what do you mean?I mean that with 12 Catalyst you may find some postprocess feature disabled but its still working.And what does HDCP have to do with anything?The main goal is to prevent HDCP encoded video stream from affecting by crapy video driver. Just like audio bitstream you know. I won't be suprised if I'm wrong here though.

[Sneals2000]

Well, do the math yourself:

16/9 = ?
1024/576 = ?
1050/576 = ?
576 * 16 / 9 = ?

It's not a good idea to blindly trust some website if you can do the proper math yourself... ;)

It's not quite as simple as that as you aren't considering the aspect ratio of the source...

Standard ITU 601 SD video is conventionally carried in a 720x576 frame. HOWEVER - this frame is slightly wider than 4:3 or 16:9. A 720x576 frame is NOT a 4:3 or 16:9 source. It's wider than 4:3 or 16:9. If you scale directly from a 720x576 ITU 601 source frame to 1024x576 (for 16:9) or 768x576 (for 4:3) square pixels ignoring this fact, then you're going to slightly stretch things...

In fact, for 50Hz video, the central 702x576 portion of the 720x576 frame contains the 4:3 or 16:9 image - with 9 samples either side to ensure no under/overshoots etc. are cropped. (Incidentally - this is why some DVB broadcasts are 704x576 - the nearest multiple to 702x576 compatible with MPEG2/H264 compression - rather than 720x576)

If you simply scale the 720x576 image to 1024x576 (16:9 square pixels) or 768x576 (4:3 square pixels) you're stretching the image slightly, and incorrectly...

If you want to scale 16:9 ITU 601 video to 1024x576 to create a 16:9 frame, then you need to scale the central 702x576 area to 1024x576 square pixels (NOT the 720x576 full frame).

However if you are working with pro-video systems, but need to work square pixels (say in compositing etc.) then you scale the 720x576 frame to 1050x576 square pixels, with the central 1024x576 portion containing the 16:9 frame. It's generally seen as bad practice to crop 720x576 video to 702x576 video during the production chain.

(If you leave the 18 samples outside the 702x576 frame - 26 samples outside the 1024x576 frame - black you can hit issues if you start shrinking pictures - as you'll see the black edges)

1050 x 576 is obviously wider than 16:9 - but explains where the 1050 vs 1024 figures come from.

It's surprising how many companies get this wrong. Adobe did initially... You still see annoying width changes in some broadcast chains where things are going wrong.

http://81-208-25-53.ip.fastwebnet.it/Manuali/Coding%20Specifications/BBC%20-%20Commissioning.pdf

http://www.mikeafford.com/blog/2009/03/pal-d1-dv-widescreen-square-pixel-settings-in-after-effects-cs4-vs-cs3/

If you scale 720x576 video you either crop 9 samples either side and scale 702x576 to 1024x576, or you scale 720x576 to 1050x576 and then crop 13 samples either side from the 1050x576 frame to get 1024x576.

This all dates back to basics and the analogue TV systems SD digital TV standards are based on. In 576/50i analogue video (aka 625/50 analogue component or analogue composite PAL/SECAM) the active video occupies 52us of a 64us line. If you sample this active video at 13.5MHz (as ITU 601 does for luminance) you end up with 702 samples in 52us. That is 702 samples for a full width 4:3 or 16:9 image. ITU 601 padded this to 720x576 for multiple reasons. This is why a 4:3 or 16:9 ITU frame is contained within the central 702x576 section of a 720x576 ITU 601 frame. Otherwise you'd need to do all sorts of resampling/reclocking when converting between analogue and digital video.
In the late 70s/early 80s when ITU 601 was being ratified (as CCIR Rec 601) digital devices were islands in analogue installations, and needed to be as transparent as possible. As analogue signals are often not very 'clean' - it made a lot of sense to sample a little bit more than the 702x576 active video portion, to avoid cropping edge transients with harmonics etc. which if cropped could induce ringing, and also to cope with devices that had somewhat less-than-ideal line timing (like VTRs of that era). It's similar thinking to having 16-235 rather than 0-255 dynamic range in active video (so that you don't clip undershoots and overshoots which could easily be present on analogue sources)

(NB. I used to be a broadcast video R&D engineer and did a LOT of work with ITU 601 4:3 and 16:9 video back in the day...)

[Sneals2000]

This (http://ps-auxw.de/cgi-bin/ar-calc.pl?source_type=pal&source_ar=widescreen&transform_type_1=none&transform_x_1=&transform_y_1=&transform_type_2=none&transform_x_2=&transform_y_2=&transform_type_3=none&transform_x_3=&transform_y_3=&transform_type_4=none&transform_x_4=&transform_y_4=&transform_type_5=none&transform_x_5=&transform_y_5=&transform_type_6=none&transform_x_6=&transform_y_6=&transform_type_7=none&transform_x_7=&transform_y_7=&transform_type_8=none&transform_x_8=&transform_y_8=&keep=true&calculate=Calculate) says 1050 × 576 (ITU scaling).

For 16:9 SD ITU 601 video :
720x576 scales to 1050x576 square pixels (i.e. the full 720x576 frame is wider than 16:9)
702x576 scales to 1024x576 square pixels (i.e. crop 9 samples from either side of the 720x576 frame to isolate the central 16:9 image area)

For 4:3 :
720x576 scales to 788x576 square pixels (i.e. the full 720x576 frame is wider than 4:3)
702x576 scales to 768x576 square pixels (i.e. crop 9 samples from either side of hte 720x576 frame to isolate the central 4:3 image area)

This is because 720x576 ITU 601 video is wider than 4:3 or 16:9 - the 4:3 or 16:9 portion is within the central 702x576 portion.

Something that a LOT of people get wrong...

If you are scaling 16:9 SD 576/50i video to 1920x1080 or 1280x720 square pixel 16:9 resolutions then you need to crop 9 samples either side from the 720x576 frame and scale the central 702x576 portion to 1920x1080 or 1280x720..

(I'm sure lots of people think the 702x576 used by people who really understand digital video - like broadcast engineers - is a typo for 720x576... It isn't.)

It may not seem important - but when you feed video through multiple up/down converters, and drop devices into and out of the broadcast chain, you definitely see things go wrong...

[leeperry]

I have to admit that I never quite understood the whole 720x576 being 4:3 AR with non-square pixels story...but hey, they make 1024x768 Plasma TV's with a 16/9 AR, so I assumed that non-square pixels were an acceptable practice in the video world.

So how do you know the actual AR of a 720x576 FS stream then? Are you saying that 720x576 FS is not/never meant to be watched with a 4:3 AR? It sure looked OK to me :o

[madshi]

@Sneals2000,

thanks a lot for your informative post, this is the first time I hear of that. I do have a few worries, though. Would you mind to address them?

(1) Does this only apply to BBC / UK, or to all PAL content world wide?
(2) Does this also apply to PAL DVDs?
(3) How about NTSC? Any similar sheenigans going on there, too?

I'm especially wondering about PAL DVDs. Since DVDs are all digital, and most DVDs are being encoded directly from the 2K (or higher) masters, I'm wondering if DVD encoding houses encode AR to 720x576 or to 702x576?

Thanks!

Call for test: Anyone who has DVDs and Blu-Rays of the same movie, please upscale the DVD to Blu-Ray resolution and check whether madVR shows the correct AR or whether the image is slightly squeezed.

P.S: Sneals2000, if you find anything else wrong in madVR, please let me know!

[ajp_anton]

Some DVDs are made with ITU scaling in mind, some are not (in which case they are scaled to exactly 4:3 or 16:9).
I guess you can learn which studios do what, but there's no way of telling for sure except to find and look at round objects, or compare with a HD version.
If you have two DVDs with different scalings, your setup *will* play one of them wrong.

According to ITU, 4:3 DVDs are scaled to 15:11 and 16:9 DVDs are scaled to 20:11. For both PAL and NTSC.

Guidelines I've heard for when a DVD is likely to *not* have ITU scaling: (not guaranteed to be correct)
- The DVD was produced in or after 2006.
- There is very little cropping at the sides (image width is closer to 720 than 702).

[06_taro]

All PAL and NTSC DVDs have such problems, 702x576 for PAL and 702.222222...x480 for NTSC.
Here (http://lipas.uwasa.fi/~f76998/video/conversion/) is a quick guide for those aspect ratio stuffs.

[andydufresne]

Sorry if this was covered I could not find an answer.

What is the best way to upgrade to the latest madVR release without losing existing settings?

[dansrfe]

Sorry if this was covered I could not find an answer.

What is the best way to upgrade to the latest madVR release without losing existing settings?

Just replace all of the files from the new madVR zip into your previous madVR directory. The settings are stored in the .bin file and the registry.

[turbojet]

A debug log might help. What does "extended display" mean exactly? You mean some special mode of dual monitor setup? Does the problem only occur in that one mode? In all other modes playback works just fine?

http://netload.in/dateiCAu3jjDSru/madVR-log.zip.htm Extended display is a non-primary (no taskbar on all but Win8) in an extended setup of multi monitors. Happens in both windowed and exclusive mode.

Not at the moment, but it's on my to do list.

Ok, worth considering the labels I mentioned? hddvd/hd-dvd could fixed with *hd* having a higher priority then *dvd*

Anamorphic PAL is 1024x576 after aspect ratio correction. So width must be higher than 1024, or height bigger than 576 to quality for "HD".

if par=4:3 and width <721 matrix=601
if par=16:9 and width <721 matrix=601
if width <721 matrix =601 else matrix=709
would this work?

To my eyes in the very few test images I saw, spline144 looked oversharpened. But I have to preserve final judgement because I simply didn't have enough time to evaluate it properly. Anyway, now is not the time to talk about FineSharp or alternatives. Busy with other stuff atm...
Thought I'd mention it before you started working on it.

Are you guys sure 702 is actually the correct width of dvd's? I've always heard (mostly from an electronics engineer) 703 PAL and 706 NTSC which is typically rounded to 704.

[andydufresne]

Just replace all of the files from the new madVR zip into your previous madVR directory. The settings are stored in the .bin file and the registry.

Thank you

[DragonQ]

The thing that confuses me about all of this is that I have some videos from DVDs that are 704x576, but if I scale them to 1024x576 they look stretched. Scaling them to 1001x576 (so there are slim black bars on the side of the 16:9 frame) looks correct. Same with some of my DVDs that are 720x576 - they look fine at 1024x576, at 1050x576 they look stretched.

I suppose it could just be that the DVDs were made "incorrectly".

Fortunately this isn't an issue in the HD world!

[THX-UltraII]

I have a question madshi. I m using SVP Frame (probably familiar with you http://www.svp-team.com/wiki/Frame_interpolation_overview) and I using an option in SVP Frame called 'to screen refresh rate' this means that eg. 23,976 content is frame interpolated to the refresh rate that you set in the NVIDIA control panel. The author of SVP frame told me tha t my goal is to get 59.94 reported by madVR and that this can be done by choosing the 59 profile (NOT the 60!) in the nvidia control panel. He is right because when I choose 59 in the nvidia control panel madVR reports 59.94XXX. madVR also tells me I get 1 dropped frame every 21 minutes. This would mean approx. 3 per our. But the strange thing is that I get 20-30 dropped frames per hour. You might have an idea what could be the cause of this?

(ps. I m bitstreaming and ReClock is no option for me because I need bitstreaming for my D-Box decoder)

[ajp_anton]

The thing that confuses me about all of this is that I have some videos from DVDs that are 704x576, but if I scale them to 1024x576 they look stretched. Scaling them to 1001x576 (so there are slim black bars on the side of the 16:9 frame) looks correct. Same with some of my DVDs that are 720x576 - they look fine at 1024x576, at 1050x576 they look stretched.

I suppose it could just be that the DVDs were made "incorrectly".

Fortunately this isn't an issue in the HD world!I just explained this. These DVDs don't follow ITU scaling and just assume a 64:45 stretch making 720x576 exactly 1024x576 and 704x576 into ~1001x576.

[6233638]

For 16:9 SD ITU 601 video :
720x576 scales to 1050x576 square pixels (i.e. the full 720x576 frame is wider than 16:9)
702x576 scales to 1024x576 square pixels (i.e. crop 9 samples from either side of the 720x576 frame to isolate the central 16:9 image area)Well that explains why I have never been able to get this test pattern (http://www.abload.de/img/dvd_snapshot_00.08_20i8r31.png) from DVE to display correctly, whether it was back in the day of analogue CRTs, upscaling DVD players on HDTVs, or HTPC-based playback. It always looked slightly oval.

With the CRT you could at least correct it to be a circle by adjusting the image width. (and with MPC-HC you can almost fix it by either adjusting the image to be slightly wider, or slightly shorter - but it's not exact)

Call for test: Anyone who has DVDs and Blu-Rays of the same movie, please upscale the DVD to Blu-Ray resolution and check whether madVR shows the correct AR or whether the image is slightly squeezed.Unfortunately, I have made it a habit to get rid of the DVD version of a film as soon as I get the Blu-ray release, so I don't have many left to compare.

Sample 1: Blu-ray (http://www.abload.de/img/blu198uxb.jpg) DVD (http://www.abload.de/img/dvd1-2wlo8u.jpg)
Sample 2: Blu-ray (http://www.abload.de/img/blu207uem.jpg) DVD (http://www.abload.de/img/dvd2f1u5y.jpg)
I had to shift the position on them slightly as they didn't match identically, but it appears that 720x576 to 1024x576 is what studios assume.

As an aside, here's that first sample with Lanczos 3 AR (http://www.abload.de/img/dvd1-2wlo8u.jpg) scaling, and SoftCubic 80 (http://www.abload.de/img/dvd156u5g.jpg). This is why I tend to prefer softer scaling algorithms with commercial DVDs.

[Sneals2000]

@Sneals2000,

thanks a lot for your informative post, this is the first time I hear of that.


Yep - it comes as a surprise to many - even though it's an inherent part of ITU 601 - the core SD digital video standard. It's a direct result of 13.5MHz sampling. Sorry if it seems a bit pedantic - but when I saw 1050x576 being slightly dissed, I had to pipe up.

Whilst analogue TV is effectively almost dead (though it may surprise many to know that very high quality analogue signals are still in widespread use in TV studios - particularly SD studios - though some HD cameras also use the same systems - to connect studio cameras to their control rooms down triax cables) - digital TV standards are still based on them.

This is particularly important in studios and live production areas - where you don't want delays - and so don't use frame stores or significant compression.


I do have a few worries, though. Would you mind to address them?

(1) Does this only apply to BBC / UK, or to all PAL content world wide?


It applies to all correctly handled 576/50i content in 4:3 and 16:9. This should be everything, but particularly content mastered by broadcasters and those who supply broadcasters (like movie studios) who generally adhere to international standards like ITU 601.

It's not specific to the BBC or the UK - though the BBC may have been better at explaining it to their suppliers and internal production areas and may also stick to the standards more accurately than some others. (Though I know there was a visible issue for a while in the BBC One HD / SD chains causing width changes)


(2) Does this also apply to PAL DVDs?


Yes - it should apply to all ITU 601 content - DVDs, Digital broadcasts, digital VT recordings etc. irrespective of production or distribution.

(Note I say should)


(3) How about NTSC? Any similar sheenigans going on there, too?


Yes - though NTSC is slightly more confusing to get a grip on because of the change from 486 to 480 active lines with the introduction of DV and MPEG2 (though ISTR D1/D2 and I think D3 captured 486 lines). I've not worked extensively with NTSC but I believe it is based on 711x486 (but with 6 lines cropped when analogue NTSC was digitised I'm not sure what has happened). It's a lot less clear though (and I'm based in 50Hz land so have never really had to deal with it)


I'm especially wondering about PAL DVDs. Since DVDs are all digital, and most DVDs are being encoded directly from the 2K (or higher) masters, I'm wondering if DVD encoding houses encode AR to 720x576 or to 702x576?


If they are doing things correctly they will encode the 16:9 image to the central 702x576 frame. Of course there is no guarantee that every DVD mastering house will do this. In fact I bet some or many don't. Particularly those working entirely in the file-based domain with IT-based workflows.

DVDs mastered from broadcast SD video sources (rather than file-based downconversion of HD sources) should definitely be properly ITU 601 compliant though.

Certainly HD 1920x1080 broadcasts simulcast in SD should be converted to 702x576 - and as more and more broadcasters now originate in HD, there should be a lot of empty 9 samples either side! (Assuming downconversion is being done correctly...) As I've mentioned - lots of broadcasters use 704x576 rather than 720x576 for broadcast for this reason. Why bother encoding 16 samples every line that a viewer should never see?

AIUI most standalone hardware DVD players follow these standards for replay... Those with upscaling should scale the central 702x576 area to 1920x1080 or 1280x720.


Thanks!

Call for test: Anyone who has DVDs and Blu-Rays of the same movie, please upscale the DVD to Blu-Ray resolution and check whether madVR shows the correct AR or whether the image is slightly squeezed.

P.S: Sneals2000, if you find anything else wrong in madVR, please let me know!

It's a complicated issue and one that even broadcast manufacturers occasionally get wrong. However ITU 601 is very clear - it's based on a 13.5MHz sampling rate, and 576/50i is entirely based on 52us active lines in a 64us total line.

I'd not be at all surprised to find a significant number of DVDs mastered with a 1920x1080 or higher source scaled directly to 720x576 rather than to the central 702x576 area. Incorrectly.

I'd also not be surprised if some HD downconversion from 1920x1080 or 1280x720 to SD was incorrectly scaled to 720x576 rather than 702x576. Doesn't make it right...

At the end of the day it's going to be a very small geometric distortion, and I suspect there are significant numbers of DVDs mastered in both ways. However ITU 601 is really clear - and all SD digital video based on 720x576 should be ITU 601 compliant - and anything handling ITU 601 content should really follow the standards I would suggest. Just because others don't doesn't mean everyone shouldn't...

It might be a few years old but : http://www.quantel.com/repository/files/library_DigitalFactBook_20th.pdf (http://www.quantel.com/repository/files/library_DigitalFactBook_20th.pdf) is a very useful bit of background. Quantel were one of the main drivers of digital SD video. The entries on Aspect Ratio confirm the 702x576 and 711x486 ratios.

[DragonQ]

Does that not become a problem if there are more 720x576 SD videos than 702x576 videos out there? I dunno if there is, just that it might be a possibility. I don't think any of the software I've used for video playback properly trims the outer 18 pixels and scales the inner 702 pixels to 1024, and I've rarely noticed aspect ratio being incorrect.

Now I'm curious I might grab recordings of BBC One HD and BBC One to see how MPC-HC and MediaPortal handle them.

EDIT: Yep, both MPC-HC and MediaPortal just stretch the full 720 pixels to 1024, resulting in a slightly squished image and thin black bars on either side. Screengrabs:

HD (http://www.aotplaza.com/Files/HTPC/Screengrabs/ITU%20601/BBC%20-%20HD.png) | SD (http://www.aotplaza.com/Files/HTPC/Screengrabs/ITU%20601/BBC%20-%20SD.png) | SD Fixed (http://www.aotplaza.com/Files/HTPC/Screengrabs/ITU%20601/BBC%20-%20SD%20Adjusted.png)

However, just because the BBC conforms to ITU 601 doesn't mean all SD channels do, so it's likely very complicated. Most SD channels are 704x576 for a start, so if these are being fully stretched to 1024 then there'll be minimal distortion in comparison. I have no idea how 544x576 works in terms of ITU 601 active area though.

[Sneals2000]

Sample 1: Blu-ray (http://www.abload.de/img/blu198uxb.jpg) DVD (http://www.abload.de/img/dvd1-2wlo8u.jpg)
Sample 2: Blu-ray (http://www.abload.de/img/blu207uem.jpg) DVD (http://www.abload.de/img/dvd2f1u5y.jpg)
I had to shift the position on them slightly as they didn't match identically, but it appears that 720x576 to 1024x576 is what studios assume.

As an aside, here's that first sample with Lanczos 3 AR (http://www.abload.de/img/dvd1-2wlo8u.jpg) scaling, and SoftCubic 80 (http://www.abload.de/img/dvd156u5g.jpg). This is why I tend to prefer softer scaling algorithms with commercial DVDs.

Hmm - yet the SD grabs are slightly narrower with black samples either side. Annoying. It's as if the standard is being partially followed...

[Sneals2000]

Does that not become a problem if there are more 720x576 SD videos than 702x576 videos out there? I dunno if there is, just that it might be a possibility. I don't think any of the software I've used for video playback properly trims the outer 18 pixels and scales the inner 702 pixels to 1024, and I've rarely noticed aspect ratio being incorrect.

It's a very minor distortion - only noticable in most cases if you are a critical viewer looking at perfect circles - or if the same content is switched through two chains, only one of which is properly compliant (as happened with BBC One HD/SD at one point...)


Now I'm curious I might grab recordings of BBC One HD and BBC One to see how MPC-HC and MediaPortal handle them.

EDIT: Yep, both MPC-HC and MediaPortal just stretch the full 720 pixels to 1024, resulting in a slightly squished image and thin black bars on either side.


Yep - that's what should happen with properly mastered SD video that is mastered to that international standards (i.e. ITU 601) An HD 16:9 1920x1080 or 1280x720 source should be downscaled to 702x576 and sit in the middle of the 720x576 frame - as can be seen by BBC One HD and BBC One SD. I'd hope Channel Four and ITV1 HD and SD were similar. (Particularly as Channel Four is played out by the same people as play out BBC channels - Red Bee Media - formerly BBC Broadcast)


However, just because the BBC conforms to ITU 601 doesn't mean all SD channels do, so it's likely very complicated.

It isn't a BBC vs other broadcasters issue. The BBC doesn't build it's equipment in house after all - it buys it from Sony, Panasonic, GrassValley, Avid, JVC, Ikegami, Crystal Vision, Snell, Axxon etc.... It's a standards compliance issue. ITU 601 is a clear standard - but it isn't always followed - particularly in the software domain (though many software developers do follow it - particularly if they want to sell to broadcasters). I know that the BBC are quite careful in the software domain - particularly with HD/SD conversion. (They also use FFMBC rather than FFMPEG for broadcast conversion as this fork does better with some broadcast video specific stuff)

If you build a broadcast chain with properly ITU 601 compliant kit (and software) you'll get ITU 601 compliant video... It's the SD digital video standard that DVD, DVB, Studios, Camcorders etc. are based on for SD video.

I'd expect most mainstream broadcasters will have SD and HD video very similar to the BBC. They'll be using the same type of kit, and it isn't as if there is a 720 vs 702 switch you flick in most of this stuff.

As has been said many broadcasters run 704x576 (nearest MPEG multiple to 702x576) and scaling 704x576 to 1024x576 will be a tiny distortion.

Not sure about 544x576 - however I believe that the standard approach is to crop 4 samples (2 each side) to generate a 540x576 frame, and then scale this to 720x576 (to keep the resampling neat as a 4 to 3 re-sampling ratio). This is because the 544x576 is just an interim format created by resampling a 720x576 source. I think this means that the 4:3 or 16:9 image corresponding to the 702x576 portion occupies the central 526.5 samples of the 544x576 image... But I may be very wrong. And I suspect I'm not alone if I am!

(And I think I've heard of 528x576 being used - as that is a neater MPEG multiple - similar to 702 vs 720)

it IS a tiny aspect ratio issue (if you look at the two BBC One SD grabs you'd probably not notice one was slightly out if you only saw it in isolation - and I'm sure many CRTs had worse geometry errors back in the day!) - and I'm not trying to make a huge thing about it (though I do believe that if you have standards you should stick to them)

I just saw a post questioning 1050x576 and thought I'd comment on it.

(I only came to the thread to decide what video card to buy!)

[Sneals2000]

I have to admit that I never quite understood the whole 720x576 being 4:3 AR with non-square pixels story...but hey, they make 1024x768 Plasma TV's with a 16/9 AR, so I assumed that non-square pixels were an acceptable practice in the video world.

So how do you know the actual AR of a 720x576 FS stream then? Are you saying that 720x576 FS is not/never meant to be watched with a 4:3 AR? It sure looked OK to me :o

I'd say that you should always assume 720x576 video is ITU 601 compliant. It's the only proper standard for 720x576 video that I know of...

That means the 4:3 or 16:9 video is within the 702x576 central area. There is no other offical standard.

Of course some mastering may not follow ITU 601 and not follow any official standard and instead map the 720x576 image to be 4:3 or 16:9. That is non-standard.

I guess there's no real way of knowing...

Given the relatively small aspect ratio differences involved - I doubt many people are that worried... On the other hand - given the huge noise some make about <16 and >235 levels being preserved I'm surprised...

[Sneals2000]

Are you guys sure 702 is actually the correct width of dvd's? I've always heard (mostly from an electronics engineer) 703 PAL and 706 NTSC which is typically rounded to 704.

Absolutely certain about 576/50i (aka "PAL") being 702 samples wide. Comes directly from 13.5MHz sampling of a 52us active line.

I don't know about NTSC - as there were all sorts of issues with 480 vs 486 lines. (Modern digital "NTSC" is based on 480 active lines, but analogue NTSC and digital broadcast video originally worked on the basis of 486 active lines)

(NB PAL changed from analogue 575 to digital 576 active lines - but didn't change picture height. How? Originally analogue "PAL" was deemed to be 575/50i active lines - with each 575 line frame made up from two fiels each of 287.5 lines - one had a half-line at the top, one had a half-line at the bottom. In digital "PAL" these half-lines are padded to full lines creating 2 x 288 line fields or a 576 line frame. You often still see the half-lines at the top and bottom of frame when viewing 576/50i content scaled to 1920x1080 and viewed with no overscan)

[6233638]

So I've gone back and done some testing with hardware accelerated decoding and interlaced DVD playback, as something didn't look right when doing that aspect ratio testing earlier.


If I use DXVA2 Native decoding in LAV Video, I am only able to select Video as a source type, Film is not available - Video appears twice when hitting the keyboard shortcut. It doesn't appear to be a problem with the label either, it's definitely not being deinterlaced as film content.

If I use DXVA2 Copy-back decoding in LAV Video, Film-type deinterlacing works correctly.

If I use CUVID, Film-type deinterlacing is available, but not enabled by default. When CUVID is set to 25/30p output, it is detected as having a 2:2 cadence, and 4:4 when set to 50/60p output, but the output is aliased/low resolution as if the wrong type of deinterlacing is being applied.
I see that CUVID no longer has the option to force a specific type of deinterlacing, and suspect that it's only using "Adaptive" now, which is probably the cause of problems there; Film-type content needs to use "None (Weave)" option to look correct.

EDIT: Unchecking the "Enable Adaptive HW Deinterlacing" option with CUVID also looks correct. I don't know if the only difference now is that the "bob" option has been eliminated. When you uncheck that option, the "High-Quality Processing" option is greyed out, but I don't know if that would have been used with the "None (Weave)" option anyway.


So only Software decoding, CUVID with "Adaptive HW Deinterlacing" disabled, or DXVA2 Copy-Back are working correctly with interlaced film-type content. (I only have film-type content to test with)

In case it makes a difference, this was PAL film-type content. (as you probably guessed from the 2:2/4:4 cadence)

Hmm - yet the SD grabs are slightly narrower with black samples either side. Annoying. It's as if the standard is being partially followed...It looks like the image is the correct aspect ratio when scaled from 720x576 to 1024x576, but with black bars on either side of it. If I stretch it to eliminate the bars, the image looks distorted.

[pie1394]

The old-day CRT has the overscan area. The signal is analog. The electron scanning beam is contiguous, not like flat panel devices --- PDP, LCD, DMD-DLP, etc... So you never see all CRTs have the same aspect ratio like 4:3 or 16:9 w/o accurate calibration. But only very few people can tell the minor difference.


In my country, most DVB-T broadcasters send out MPEG-2 704x480i30 signal on SDTV programs. But few of them send out MPEG-2 720x480i30 one.

Yet the DAR (Display Aspect Ratio) is described in the MPEG-2 stream's header. It does cause issues on calculating PAR (Pixel Aspect Ratio) to prevent unnecessary horizontal scaling for MPEG-2 720x480, 720x576 DVD / SDTV contents.

At that time I decided to use MPEG-4 PAR to describe the image pixel apect ratio. I also made the MPEG-2 decoder to send out the video frame with fake PAR information to the video scaling processor. So all 720x480, 720x576 combinations always get the same PAR of 704x480, 704x576.

If the output signal is NTSC / PAL / SDTV D1, for the 704x480 and 704x576 contents at 100% zooming rate, just let the video player to put the video displaying window at (8,0)-(704, 480/576) of the video frame buffer w/o any scaling.

[pie1394]

FWIW, if your CPU doesn't support SSE4.1 then madVR is not doing copyback internally, so the behaviour is different to what CUDA/DXVA-copyback in LAV Video Decoder do. In theory native DXVA should perform better in your situation, but with a small hit on chroma image quality.


I am just curious which SSE4.1 instructions are needed in your operation...

Any consideration about AVX?

It is supported on the 2nd and newer Core i processors. Not only the integer parts, it also does provide some boosts over SSE3 on FP32 / FP64 intensive calculations. The Altivec-type 3-operand instruction formats also get some benefits on saved code size. But 256-bit AVX packed shuffle / sum-of-2 instruction logics are somewhat different from 128-bit SSE3 ones on the same sized element.

[turbojet]

It's wiki, so not to be taken as a scientific fact but https://en.wikipedia.org/wiki/Overscan#Analog_to_digital_resolution_issues proves both Sneals2000 (analog) and EE guy (digital) correct. It's all above my head but he explained it to me a few years ago and something about color carrier and a bunch of numbers it came out to 703 and 706 respectively, bored me to death. But it's 1 pixel no naked eye could tell the difference. However avisynth has issues with resolutions that aren't mod4, green lines and repeated lines, dunno know if that's a problem with madvr.

[Mangix]

Request: add a text file to the madvr.zip file that states miscellaneous stuff.

In particular the peculiarities of DXVA2 scaling, decoding, deinterlacing, w/e. It's confusing as not only must this information be chased down, it's subject to change. And if anyone does not follow the hundreds of pages in this thread, important notes can be missed.

[ryrynz]

Whilst madVR has been stable for quite some time I still believe Madshi considers it a "in development" project and is still interested in implementing a few more features.
Full documentation will likely be supplied once it gets close to or hits 1.0

[nevcairiel]

I am just curious which SSE4.1 instructions are needed in your operation..

The important instruction is MOVNTDQA, a special instruction to read memory more efficiently from write-combining memory, as used by GPUs. Without this, a Copy-Back implementation is most likely very inefficient.

AVX does not provide an improvement over this, AVX2 will however, AFAIK.

[egur]

The important instruction is MOVNTDQA, a special instruction to read memory more efficiently from write-combining memory, as used by GPUs. Without this, a Copy-Back implementation is most likely very inefficient.

AVX does not provide an improvement over this, AVX2 will however, AFAIK.

I implemented an AVX2 copy back function which works fine on Haswell. It doesn't provide any performance improvements over SSE4.1. To date I haven't found an implementation faster than the QuickSync implementation (either SSE4.1 and AVX2).
Copy back should be done on 2 threads using SSE aligned addresses.

You must use the VS2012 compiler or Intel compiler 12.1 (maybe 13.0, didn't check) or newer.
The instructions used are:
VMOVNTDQA: streaming load 256bit. Used via the _mm256_stream_load_si256 intrinsic function.
VMOVDQA: aligned store 256bit. Used via the _mm256_store_si256 intrinsic function.

See the code here (http://sourceforge.net/p/qsdecoder/code/HEAD/tree//trunk/IntelQuickSyncDecoder/QuickSyncUtils.cpp) (gpu_memcpy_avx2 function).

[pie1394]

I implemented an AVX2 copy back function which works fine on Haswell. It doesn't provide any performance improvements over SSE4.1. To date I haven't found an implementation faster than the QuickSync implementation (either SSE4.1 and AVX2).
Copy back should be done on 2 threads using SSE aligned addresses.



Does it mean the Haswell is still restricted with maximum 64 bytes read per PCI-e transaction?

Without the buffered DMA unit + internal CPU data ram, it is quite inefficient for CPU to fetch / write-back large stride-based contiguous non-cacheable memory like video frame buffer or peripheral memory. Yet it is often only provided on the video processors, not general-purposed one like x86...

[egur]

Does it mean the Haswell is still restricted with maximum 64 bytes read per PCI-e transaction?

Without the buffered DMA unit + internal CPU data ram, it is quite inefficient for CPU to fetch / write-back large stride-based contiguous non-cacheable memory like video frame buffer or peripheral memory. Yet it is often only provided on the video processors, not general-purposed one like x86...

I haven't tried reading from a PCI-E device. I used CB to copy from the integrated GPU. the iGPU communicates with the CPU via a ring bus not PCI-E. They sit on the same silicon die. There's no DMA copy going on.
For discrete GPUs, I'm not sure how CB actually works, this is not my cup of tea...
I can guess that the surface is copied via DMA when it's locked via the LockSurface function, but maybe not.

[madshi]

Ok, worth considering the labels I mentioned? hddvd/hd-dvd could fixed with *hd* having a higher priority then *dvd*
I haven't decided on the labels yet, but I don't think I'll support either DVD or HDDVD/HD-DVD. I'll rather support specific tags to switch specific things.

if par=4:3 and width <721 matrix=601
if par=16:9 and width <721 matrix=601
if width <721 matrix =601 else matrix=709
would this work?
No, because custom h264 PAL encodes are often 1024x576.

madVR also tells me I get 1 dropped frame every 21 minutes. This would mean approx. 3 per our. But the strange thing is that I get 20-30 dropped frames per hour. You might have an idea what could be the cause of this?
Well, when you get those frame drops, are any of the queues near empty (see madVR debug OSD -> Ctrl+J)?

Unfortunately, I have made it a habit to get rid of the DVD version of a film as soon as I get the Blu-ray release, so I don't have many left to compare.

Sample 1: Blu-ray (http://www.abload.de/img/blu198uxb.jpg) DVD (http://www.abload.de/img/dvd1-2wlo8u.jpg)
Sample 2: Blu-ray (http://www.abload.de/img/blu207uem.jpg) DVD (http://www.abload.de/img/dvd2f1u5y.jpg)
I had to shift the position on them slightly as they didn't match identically, but it appears that 720x576 to 1024x576 is what studios assume.
Thanks! So it is as I feared: There's no way to know which scaling/AR is needed for any given content... :(

Yep - it comes as a surprise to many - even though it's an inherent part of ITU 601 - the core SD digital video standard. It's a direct result of 13.5MHz sampling. Sorry if it seems a bit pedantic - but when I saw 1050x576 being slightly dissed, I had to pipe up.
It's not pedantic at all. I'm very interested in such things.

Yes - though NTSC is slightly more confusing to get a grip on because of the change from 486 to 480 active lines with the introduction of DV and MPEG2 (though ISTR D1/D2 and I think D3 captured 486 lines). I've not worked extensively with NTSC but I believe it is based on 711x486 (but with 6 lines cropped when analogue NTSC was digitised I'm not sure what has happened). It's a lot less clear though
Ouch.

At the end of the day it's going to be a very small geometric distortion, and I suspect there are significant numbers of DVDs mastered in both ways. However ITU 601 is really clear - and all SD digital video based on 720x576 should be ITU 601 compliant - and anything handling ITU 601 content should really follow the standards I would suggest. Just because others don't doesn't mean everyone shouldn't...
From my point of view, following the standards is very important. However, making the majority of content look right is even more important. So for me the key questions are:

(1) Do users today play more content which needs 720x576 -> 1024x576 scaling, or do they play more content which needs 720x576 -> 1050x576 scaling?
(2) What do the majority of DVD studios do today?
(3) What do the majority of broadcasters do today?

(these are not questions I expect you to be able to answer)

It seems to me that probably the majority of newly released DVDs these day probably need 720x576 -> 1024x576 scaling. This is an educated guess, though, and would need to be confirmed first. I've not sure about (3). There's a good chance that the majority of broadcast material might need 720x576 -> 1050x576 scaling. But it's hard to know for sure.

So what all this leaves us in is a total mess... :( I think it would be a bad idea if I just scaled all 720x576 content to 1050x576 now because my impression is that it would produce stretched images for many newer DVDs. But then simply ignoring the whole issue might not be such a good idea, either. Oh well. Not really sure what to do now...

If I use DXVA2 Native decoding in LAV Video, I am only able to select Video as a source type, Film is not available - Video appears twice when hitting the keyboard shortcut. It doesn't appear to be a problem with the label either, it's definitely not being deinterlaced as film content.
madVR's IVTC algorithm currently still runs on the CPU (SSE2 code). Because of that it can't be activated when using Native DXVA2 decoding. I might move the IVTC algorithm to the GPU at some point in the future, but not too soon.

Request: add a text file to the madvr.zip file that states miscellaneous stuff.

In particular the peculiarities of DXVA2 scaling, decoding, deinterlacing, w/e. It's confusing as not only must this information be chased down, it's subject to change. And if anyone does not follow the hundreds of pages in this thread, important notes can be missed.
Which exact peculiarities are you interested in? DXVA2 processing in madVR should behave mostly similar to other renderers.

I implemented an AVX2 copy back function which works fine on Haswell. It doesn't provide any performance improvements over SSE4.1. To date I haven't found an implementation faster than the QuickSync implementation (either SSE4.1 and AVX2).
Copy back should be done on 2 threads using SSE aligned addresses.

You must use the VS2012 compiler or Intel compiler 12.1 (maybe 13.0, didn't check) or newer.
The instructions used are:
VMOVNTDQA: streaming load 256bit. Used via the _mm256_stream_load_si256 intrinsic function.
VMOVDQA: aligned store 256bit. Used via the _mm256_store_si256 intrinsic function.

See the code here (http://sourceforge.net/p/qsdecoder/code/HEAD/tree//trunk/IntelQuickSyncDecoder/QuickSyncUtils.cpp) (gpu_memcpy_avx2 function).
FWIW, I'm using _mm_stream_si128 instead of _mm_store_si128. That's because I'm not copying from GPU -> CPU RAM. Instead I'm directly copying GPU -> GPU.

[kasper93]

@madshi
madVR doesn't work good with mpc and microsoft dxva decoder at least on HD5870 with 12.10 driver.

Playback starts fine, but madvr freeze after seek: see https://dl.dropbox.com/u/16282309/mad/madVR-freeze.report.mpc.dxva.7z
and log: https://dl.dropbox.com/u/16282309/mad/madVR.log.mpc.dxva.7z

ffdshow DXVA and LAV doesn't have seeking problem. MPC and Microsoft DTV-DVD Video Decoder have.

[alexacolor]

Sorry if already discussed: When running on old video card (Radeon 550 PS2.0) just a black screen. No any errors. All interfaces are created without errors. How can I know that the video can not be played (black screen)?

[DragonQ]

Yep - that's what should happen with properly mastered SD video that is mastered to that international standards (i.e. ITU 601) An HD 16:9 1920x1080 or 1280x720 source should be downscaled to 702x576 and sit in the middle of the 720x576 frame - as can be seen by BBC One HD and BBC One SD. I'd hope Channel Four and ITV1 HD and SD were similar. (Particularly as Channel Four is played out by the same people as play out BBC channels - Red Bee Media - formerly BBC Broadcast)
That may be what should happen with regards to the broadcast, but the software isn't treating it properly.

Maybe it should be an auto-detection thing - if the outer x number of columns are blank, assume it's ITU 601 and scale accordingly. If they're not blank, assume the whole frame is meant to be 16:9 and scale accordingly.

[pandy]

Create an empty file with the name "YCbCr" in the madVR folder... ;)

Big THX Madshi! i love undocumented features! :D :thanks: :D

[6233638]

So what all this leaves us in is a total mess... :( I think it would be a bad idea if I just scaled all 720x576 content to 1050x576 now because my impression is that it would produce stretched images for many newer DVDs. But then simply ignoring the whole issue might not be such a good idea, either. Oh well. Not really sure what to do now...It's still less than ideal, and I don't know if it would be possible, but the best solution I can think of, would be to have an option such as:

Automatically activate ITU scaling when pillarboxing is detected if in doubt, activate scaling if in doubt, deactivate scaling
Of course, this assumes you are able to figure out some way to detect when there is a small amount of pillarboxing on the side of the image.

A simpler solution would simply be to have a global preference for what you want to do with all SD content, and a keyboard shortcut to toggle between the two though.

[pandy]

Something that a LOT of people get wrong...


Absolutely certain about 576/50i (aka "PAL") being 702 samples wide. Comes directly from 13.5MHz sampling of a 52us active line.

Ok - let starts some math - ITU-R BT.1700 (supersede BT.470)
tells us that active video for 625 line system can have 52.3us (64 - 11.7us).

System based on BT.601/656 use 13.5MHz sampling ie 1 pixel have 1/13.5MHz length ie active video length in digital pixels is equal: 52.3/(1/13.5)=(approx) 706 pixels so no 702, no 704, no 708 or 710 or 720 but 706 pixels - thus story is even more complicated and it should be 1044 not 1050 video.

Why not 52us - in digital world time control is very precise and many vendors offer hardware capable to produce 52.3 not 52us video which is allowed by video standard .

[THX-UltraII]

Well, when you get those frame drops, are any of the queues near empty (see madVR debug OSD -> Ctrl+J)?I just raised the option 'show frames in advance' from 4 => 16 and now I get 2-5 dropped frames during a 2 hour movie! That s pretty nice I think when you keep in mind that I bitstream

[THX-UltraII]

When you use a ISF calibrated digital front projector (like my Sony HW50) do I just check the option 'disable calibration for this display'? (can t remember the exact name of that option but it is the first radio button you can choose)

[nevcairiel]

You should check "My display is already calibrated" and select for what colorspace it was calibrated, most likely BT709
Of course this means your device was properly calibrated against a standard test signal, and not the output of some broken cablebox or something.

[leeperry]

I'd say that you should always assume 720x576 video is ITU 601 compliant. It's the only proper standard for 720x576 video that I know of...

That means the 4:3 or 16:9 video is within the 702x576 central area. There is no other offical standard.

Of course some mastering may not follow ITU 601 and not follow any official standard and instead map the 720x576 image to be 4:3 or 16:9. That is non-standard.

I guess there's no real way of knowing...
TBH, I usually get a FS picture with 25fps FS DVD content using a 4:3 DAR but sometimes(mainly NTSC IIRC) it did have tiny vertical black bars so yeah OK, I will leave the AR at 4:3 but will slightly stretch the picture horizontally until it'll become FS if need be :cool:

anyway, after the story of HD being encoded to BD with non-specs-compliant primaries, yet another uncertain spec to deal with :o

I think it would be a bad idea if I just scaled all 720x576 content to 1050x576 now because my impression is that it would produce stretched images for many newer DVDs. But then simply ignoring the whole issue might not be such a good idea, either. Oh well. Not really sure what to do now...
add an "ITU-compliant scaling" hotkey that would stretch horizontally by a few percents? ^^

[pandy]

Guys if You All trying to be so precise, pro and accurate then please check BT.1700 and BT.801 test signal No. 3. - there is 706 pixels in active video line.

[Sneals2000]

Guys if You All trying to be so precise, pro and accurate then please check BT.1700 and BT.801 test signal No. 3. - there is 706 pixels in active video line.

Isn't BT 801 testing both the full 720 sample line and the 702 active line? I thought it was there to check whether full and 4:3/16:9 active were both being passed or not?

There are black/white/black transitions at the edge of the 720 line 601 frame, and again at the edge of the 702 line active line area?

If you see two pulses at the edge of frame, the full 720 line payload is surviving, if you only see the inner pulses, you're only seeing the 702 central section surviving? Or am I misreading this? Isn't the first pulse sample 0-5, black from 6 to 9 (with active 702 samples starting at sample 8?) and then another pulse sample 10-15 ?

I don't think that test signal defines 4:3/16:9 active as 706 lines does it?

[Sneals2000]

That may be what should happen with regards to the broadcast, but the software isn't treating it properly.

Maybe it should be an auto-detection thing - if the outer x number of columns are blank, assume it's ITU 601 and scale accordingly. If they're not blank, assume the whole frame is meant to be 16:9 and scale accordingly.

That won't work in all cases. There's no requirement for correctly scaled ITU 601 to have black samples in the 9 samples either side of the 702x576 "4:3/16:9" frame. As more and more content is originated HD, then this is increasingly likely to be the case (16:9 1920x1080 or 1280x720 HD should be downconverted to fill the 702x576 centre section), however SD originated content can have content in the edges of frame (such as vision mixer mattes, DVE borders etc.)

Assuming that the presence of picture content outside the 702x576 central section implies non-ITU 601 compliance is not a safe assumption.

[DragonQ]

Assuming that the presence of picture content outside the 702x576 central section implies non-ITU 601 compliance is not a safe assumption.
OK but is there a better way?

[Sneals2000]

It's not pedantic at all. I'm very interested in such things.


Phew! Don't want to offend. Love MadVR!


From my point of view, following the standards is very important. However, making the majority of content look right is even more important. So for me the key questions are:

(1) Do users today play more content which needs 720x576 -> 1024x576 scaling, or do they play more content which needs 720x576 -> 1050x576 scaling?
(2) What do the majority of DVD studios do today?

Can't really comment - and to be honest it's tricky to know.

(3) What do the majority of broadcasters do today?


Assuming they're using reasonably standard SD broadcast kit I'd expect 702x576->1024x576 (or 720x576->1050x576) scaling is the right approach - as broadcasters are likely to closely follow ITU 601 - or try to.

Of course some kit and software may not be fully compliant - but I would expect compliance to be an aim.

However as more and more channels are originated in HD, with their SD variants just a straight downconvert at the end of the playout chain, the only device that will dictate their compliance (or non-compliance) will be the HD->SD downconverter, which actually makes things a lot simpler as this becomes the only real place (apart from distribution/emission encoding) where things could get scaled incorrectly.

I would expect all mainstream broadcast downconversion products to be fully ITU 601 compliant - so the HD to SD downconversion will be to the central 702x576 area in a 720x576 frame.

(these are not questions I expect you to be able to answer)

It seems to me that probably the majority of newly released DVDs these day probably need 720x576 -> 1024x576 scaling. This is an educated guess, though, and would need to be confirmed first. I've not sure about (3). There's a good chance that the majority of broadcast material might need 720x576 -> 1050x576 scaling. But it's hard to know for sure.

So what all this leaves us in is a total mess... :( I think it would be a bad idea if I just scaled all 720x576 content to 1050x576 now because my impression is that it would produce stretched images for many newer DVDs. But then simply ignoring the whole issue might not be such a good idea, either. Oh well. Not really sure what to do now...

Not sure there is an answer. Make it an option? If people mainly use MadVR for TV viewing then 702x576 scaling is likely to be the correct assumption?

Be interesting to know what real DVD and Blu-ray players do when they upconvert.

[Sneals2000]

OK but is there a better way?

No - I don't think there is a way. It appears that some non-ITU 601 scaled content has black samples either side as well, and ITU 601 content can legitimately have content outside the edges AIUI.

[mandarinka]

From my point of view, following the standards is very important. However, making the majority of content look right is even more important. So for me the key questions are:

(1) Do users today play more content which needs 720x576 -> 1024x576 scaling, or do they play more content which needs 720x576 -> 1050x576 scaling?
(2) What do the majority of DVD studios do today?
(3) What do the majority of broadcasters do today?

(these are not questions I expect you to be able to answer)

It seems to me that probably the majority of newly released DVDs these day probably need 720x576 -> 1024x576 scaling. This is an educated guess, though, and would need to be confirmed first. I've not sure about (3). There's a good chance that the majority of broadcast material might need 720x576 -> 1050x576 scaling. But it's hard to know for sure.

Hmm, hard to say conclusively, but as you can see, the pecularities of ITU scaling are largely unknown to people, including really experienced persons :) - for example, all PC players ignore it and "do it wrong" (853x480, 720x540 for ntsc, etc...). I think that the closer the DVD authoring was to amateur territory, the more likely it is that ITU scaling was not used. Friends told me that they saw anime dvds (series form 2000s, made on computers) that didn't use ITU scaling. Said friends tried to find shapes that were supposed to be circular and to check both scaling approaches to see which will produce more precise circle.

I tried this myself several times (but in my case, I used NTSC DVDs of older anime). In my experiments, in all DVDs I tried (and where I found usable frames for checking) I discovered that they were most likely to have been created assuming ITU scaling. (Edit: Actually I think I found one case where it was inconclusive, too. I couldn't tell which was the right way there).

That is, for NTSC a 4/3 source looked right at 720x527, not at 720x540. A 16/9 source looked correctly at 875x480 and not at 853x480. Of course, it is still just anecdotal evidence, but I think that professional authoring teams do use ITU.
(The dvds were old anime material, but included both older releases from early 2000s and more recent remaster releases). Anyway, now I always assume that DVDs use ITU scaling. it might be an opinion, but I chose to err on the side of specifications :)

[DarkSpace]

Not sure there is an answer. Make it an option? If people mainly use MadVR for TV viewing then 702x576 scaling is likely to be the correct assumption?

I agree that an option on whether or not to use ITU scaling might be the best alternative. I sometimes encode movies myself (for example, I once converted an swf animation to an image sequence and then encoded that into a video; I don't have either the animation or the final video any more, though), and when I do, I take great care to use the mathematically correct (non-ITU compensated) Pixel Aspect Ratio. So, understandably, I wouldn't want anyone or anything to mess with those values I calculated.
However, I also have some (not too many, enough) DVD movies that definitely do not use the full frame (looks like they crop 2.5 pixels from both left and right), so I'd assume ITU scaling should be used for them. I don't have the BDs for comparison.
Also, I don't know how BluRays handle SD content, is it encoded with ITU scaling instead of "pure Pixel Aspect Ratio" at all? Personally, I'd assume that since BD was created with Digital Video in mind, the SD content on BDs might just as well use "simple", non-ITU scaling.
Maybe (I doubt it, though), there could also be rules that only apply when the input is MPEG-2 and one of the 2 standard resolutions. Though, I believe that Aspect Ratio correction should actually be the Splitter's work...