Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 11th May 2010, 11:22   #2601  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Quote:
Originally Posted by madshi View Post
Hmmmm... I've stopped playing Direct3D games a few years ago (due to lack of time), but I don't remember having ever seen games tear. Maybe newer games are different? Maybe they need ultra fast reaction times with 0 lag. In that situation maybe it's preferable to tear over having a small lag caused by proper VSyncing? Don't know...
Yes, i think you are on to something. Lag would stop frames being generated too far in advance.

Most players of first person shooters turn off "vsync", so frames are written straight to the front buffer. You get as many frames, or part of frames, as are possible and minimum lag.

In other games you can turn on "vsync" (use of backbuffer), but that means, @60Hz, if the game is capable of generating >60fps you get 60fps. If the frame rate drops below 60fps you end up with 30fps. So this can be underdesirable not just because of lag but because 30fps is not fluid.
Jong is offline   Reply With Quote
Old 11th May 2010, 11:29   #2602  |  Link
djsolidsnake86
Registered User
 
Join Date: Mar 2010
Posts: 139
i tried with ffdshow decoder and divx decoder h264
djsolidsnake86 is offline   Reply With Quote
Old 11th May 2010, 11:33   #2603  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
@madshi, the one interesting thing that all the commercial players seem to do that no open source renderers do is that for Blu-ray disc playback (and, for TMT only, DVD playback too) they render EVR onto an overlay surface.

This (according to some quite sophisticated tests done by others (not me!) over at AVS Forums) has the advantage, at least with the latest ATI cards that if you output YCbCr the video is rendered to a YCbCr surface and is output without any conversion to/from RGB at as close as possible to the original values off disc.

I realise one of the main purposes of madVR is to control this conversion to RGB. I'll be honest, we are not sure if setting YCbCr 4:2:2 output avoids chroma upsampling as well (that would be an interesting test to do) and even then I guess madVR probably does a better job than most if not all displays. But I wondered if you were aware of how they are able to use an overlay surface but also use EVR rather than the very old overlay mixer and what you think of this approach! In principle, it seems to come as close as possible on a PC to offering "bit perfect" video output into a high end display or scaler.
Jong is offline   Reply With Quote
Old 11th May 2010, 11:57   #2604  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by djsolidsnake86 View Post
i tried with ffdshow decoder and divx decoder h264
And the crash occurs with both? Then please upload a small sample for me. Thanks.

Quote:
Originally Posted by Jong View Post
@madshi, the one interesting thing that all the commercial players seem to do that no open source renderers do is that for Blu-ray disc playback (and, for TMT only, DVD playback too) they render EVR onto an overlay surface.

This (according to some quite sophisticated tests done by others (not me!) over at AVS Forums) has the advantage, at least with the latest ATI cards that if you output YCbCr the video is rendered to a YCbCr surface and is output without any conversion to/from RGB at as close as possible to the original values off disc.

I realise one of the main purposes of madVR is to control this conversion to RGB. I'll be honest, we are not sure if setting YCbCr 4:2:2 output avoids chroma upsampling as well (that would be an interesting test to do) and even then I guess madVR probably does a better job than most if not all displays.

But I wondered if you were aware of how they are able to use an overlay surface but also use EVR rather than the very old overlay mixer and what you think of this approach! In principle, it seems to come as close as possible on a PC to offering "bit perfect" video output into a high end display or scaler.
First of all: I'm not sure how the commercial players are doing that technically. But I'm not really interested in trying to find out, either.

As you say, I'm not sure if ATI's YCbCr 4:2:2 output is "lossless" in the same way e.g. an SDI modded DVD player would output YCbCr 4:2:2. Maybe it is, maybe not. But even if it is:

As you probably know, video is usually compressed in YCbCr 4:2:0. HDMI doesn't support this format (nor does DVI or SDI). Basically it's impossible to transport the original data unchanged from one device to the next with any digital transport that I know. So chroma *always* has to be upsampled to at least 4:2:2. It's possible (maybe even probable) that ATI is upsampling to 4:4:4 and then downsampling to 4:2:2 again.

The "final" aim of madVR is to beat everything else out there, including high end video processors. madVR might not be there yet in some aspects, but that is to be expected, because madVR is still very much a work in progress. I've also read that there are several projectors (even "new" models) which work better with RGB input than with YCbCr input. If madVR output YCbCr, someone would have to convert that back to RGB sooner or later, because all displays are RGB in the end. And the conversion from YCbCr to RGB can easily go wrong. E.g. imagine TMT plays back DVDs, upscales them to 1080p and then outputs them as YCbCr. The display doesn't know this was a DVD. The display will "guess" that this is a HD source and consequently it will likely use Rec.709 to do the YCbCr to RGB conversion. But the correct conversion would be Rec.601, because the source was SD. This is a real problem. Basically if the source device plays SD content and upscales it to HD resolution, you should not output YCbCr. Or if you do, you will get wrong colors.

I prefer to do this all in madVR and feed the display with "final" data, which doesn't need to be processed at all, anymore.

One problem I see with the EVR over Overlay solution is that it once again depends a lot on GPU drivers behaving correctly. As you probably know, being dependent on GPU drivers is every HTPC owner's worst nightmare, because things like that can break with any new driver revision. It may change from one GPU model to the next and from one OS to the next. One aim of madVR is to eliminate as much dependence on the GPU driver, OS, GPU model etc as possible.
madshi is offline   Reply With Quote
Old 11th May 2010, 12:01   #2605  |  Link
djsolidsnake86
Registered User
 
Join Date: Mar 2010
Posts: 139
yes, both
i will send you a preview files soon
djsolidsnake86 is offline   Reply With Quote
Old 11th May 2010, 12:42   #2606  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Quote:
Originally Posted by madshi View Post
As you probably know, video is usually compressed in YCbCr 4:2:0. HDMI doesn't support this format (nor does DVI or SDI). Basically it's impossible to transport the original data unchanged from one device to the next with any digital transport that I know. So chroma *always* has to be upsampled to at least 4:2:2. It's possible (maybe even probable) that ATI is upsampling to 4:4:4 and then downsampling to 4:2:2 again.

The "final" aim of madVR is to beat everything else out there, including high end video processors. madVR might not be there yet in some aspects, but that is to be expected, because madVR is still very much a work in progress. I've also read that there are several projectors (even "new" models) which work better with RGB input than with YCbCr input. If madVR output YCbCr, someone would have to convert that back to RGB sooner or later, because all displays are RGB in the end. And the conversion from YCbCr to RGB can easily go wrong. E.g. imagine TMT plays back DVDs, upscales them to 1080p and then outputs them as YCbCr. The display doesn't know this was a DVD. The display will "guess" that this is a HD source and consequently it will likely use Rec.709 to do the YCbCr to RGB conversion. But the correct conversion would be Rec.601, because the source was SD. This is a real problem. Basically if the source device plays SD content and upscales it to HD resolution, you should not output YCbCr. Or if you do, you will get wrong colors.

I prefer to do this all in madVR and feed the display with "final" data, which doesn't need to be processed at all, anymore.

One problem I see with the EVR over Overlay solution is that it once again depends a lot on GPU drivers behaving correctly. As you probably know, being dependent on GPU drivers is every HTPC owner's worst nightmare, because things like that can break with any new driver revision. It may change from one GPU model to the next and from one OS to the next. One aim of madVR is to eliminate as much dependence on the GPU driver, OS, GPU model etc as possible.
Yeah, I understand that. Just thought I'd throw it out there!

I do find it interesting they are doing something none of the opensource renderers do and it does have advantages. For example, in confirmation of your comment on GPU driver, the current 5xxx drivers (or maybe the hardware, we do not know) have a small error when they convert RGB to YCbCr (much smaller than a 601/709 conversion error). Because a YCbCr overlay never needs to go through RGB this error is not present when playing Blu-ray's in disc mode (or, for TMT, DVDs). Banding is also much improved, because video is not expanded and then re-compressed to video levels. Of course in theory you could use RGB output to bypass 'the bug', but currently that has other even more serious issues when using conventional renderers, not least it is always expanded at some point (although it can be recompressed if desired).

I am aware of the potential for colorspace error when upscaling. In fact there is no colourspace error with DVD in TMT. It must be doing a colorspace conversion along with upscaling. Of course that is not needed for Blu-ray, but I agree there is a good chance that chroma is being upsampled to 4:4:4 before being downsampled again.

Last edited by Jong; 11th May 2010 at 12:54.
Jong is offline   Reply With Quote
Old 11th May 2010, 13:35   #2607  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Maybe for some reason this EVR + overlay solution is needed to satisfy those nasty Blu-Ray copy protection rules? Maybe that's why all the commercial software uses the same solution? Just a guess, though...
madshi is offline   Reply With Quote
Old 11th May 2010, 13:47   #2608  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Yes, it does prevent screen copy. Although it is not the same as PVP. XP does not have PVP yet it also uses the same approach.

Anyway, I do like the idea of bypassing all Windows "desktop mixing"! Of course madVR (without Aero) will also do this. But, when we are searching for perfection I am nervous of passing RGB unless I know my display cleanly handles RGB input. I realise all displays end up with RGB, but as almost all consumer sources will normally supply YCbCr. RGB is normally there mainly for "old -fashioned" DVI compatibility. I fear some displays are optimised for this. For instance, nearly all displays are applying some post-processing. Do we know this is not done internally in YCbCr? I am sure there are displays that "passthrough" RGB cleanly, but all, or which?!
Jong is offline   Reply With Quote
Old 11th May 2010, 13:54   #2609  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
ok, thanks for the detailed explanations Jong, it makes a lot more sense to me now! I agree that HR is not anything special but using its jitter figure, you can somehow "surf" on the VSYNC fliptime...even though it'll never be as smooth as mVR anyway
Quote:
Originally Posted by Jong View Post
Regarding Reclock though, it is not the cause of the problems. As Madshi said:ALL renderers are very tightly constrained in windowed mode.

Only an overlay surface, or exclusive mode or Aero frees up those constraints.

Furthermore, when those constraints are released, Reclock actually helps current renderers to be less time sensitive by positioning average start of presentation as early as possible in the vsync cycle to give it maximum time to complete.
ok! allow me to rephrase: Reclock's timings are too tight to be obeyed in windowed mode on XP...better?

but apparently Aero can/would/will help to overcome this problem? together w/ HPET's tightness of course.
Quote:
Originally Posted by Jong View Post
Ignoring for a minute Madshi's plans to pre-render multiple frames in advance (which I agree would be awesome

Sometimes playback starts in, or very near, judder and Reclock cannot avoid that. A renderer that correctly controls vsync can hold onto the frame and present it at a safe spot, so judder can be avoided completely, even at the start or after a seek or pause.
I can discuss about audio or colorimetry until the end of days, but I'm glad you're so much into VSYNC because it's just very annoying to me

good news is: madshi understand where the issue lies, and could possibly offer a way to make Reclock work EVEN in windowed mode? or am I asking for the impossible here?
Quote:
Originally Posted by madshi View Post
I've stopped playing Direct3D games a few years ago (due to lack of time), but I don't remember having ever seen games tear.
if you don't set Crysis in "ultra high" mode, I've also never seen a videogame tear or judder...it very much looks like a "hardware VSYNC interrupt" unstoppable train as you said, unlike Reclock in windowed mode on XP
Quote:
Originally Posted by madshi View Post
So you dislike both Aero and exclusive mode? Don't worry, I'm not planning to drop non-Aero windowed mode. I want to have all modes work as good as possible.
well, one hotkey to go windowed<>FS and we'll be in business.
leeperry is offline   Reply With Quote
Old 11th May 2010, 14:01   #2610  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Quote:
Originally Posted by leeperry View Post
good news is: madshi understand where the issue lies, and could possibly offer a way to make Reclock work EVEN in windowed mode? or am I asking for the impossible here?

.........

if you don't set Crysis in "ultra high" mode, I've also never seen a videogame tear or judder...it very much looks like a "hardware VSYNC interrupt" unstoppable train as you said, unlike Reclock in windowed mode on XP.
I think in windowed mode (without Aero) we will never be much better than Reclock. As I say, maybe madVR may have 3-4ms more time to play with, but that is unlikely to help when Windows scheduling goes haywire! With Aero, even that 3-4ms is erroded, so I'm honestly not sure whether madVR in Aero mode would be better or worse than Reclock in exclusive mode.

Games in ultra-high mode will be smooth as long as the PC is man enough! Even with vsync enabled, you will not get judder like the synchonised judder we have been discussing, but if the PC frame rate drops below the refresh rate at any time the frame rate drops to refresh rate/2, which is unlikely to be fluid. They do not have a magic solution to Windows scheduling, maybe, as Madshi suggests, because they cannot in practice render many frames in advance for fear of lag.

Last edited by Jong; 11th May 2010 at 14:07.
Jong is offline   Reply With Quote
Old 11th May 2010, 14:11   #2611  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by Jong View Post
I think in windowed mode we will never be much better than Reclock. As I say, maybe madVR may have 3-4ms more time to play with, but that is unlikely to help when Windows scheduling goes haywire!

Games in ultra-high mode will be smooth as long as the PC is man enough! Even with vsync enabled, you will not get judder like the synchonised judder we have been discussing, but if the PC frame rate drops below the refresh rate at any time the frame rate drops to refresh rate/2, which is unlikely to be fluid. They do not have a magic solution to Windows scheduling, maybe as Madshi suggest because they cannot in practice render many frames in advance for fear of lag.
I never spoke about getting rid of Reclock, to be perfecly clear...as I do need a way to playback audio over KS(KMixer on XP is ) and I also occasionally need to play 25fps@48/96Hz

I'm not too worried about windows scheduling, as I run all the background processes in low prio on single cores and my media player in high prio on the 4 cores...I've also changed the NT affinity system to give 96X more prio to high over low...my issue lies more in the VSYNC fliptime problem as far as I can see

oh sure, but a fully capable computer on a non-too demanding game will never tear or judder IME...but again, I always run games in high prio, and this thing's supposed to help too: http://solariz.de/660/aoc-fps-boost-...er-english.htm

it's a dirty hack, but I think it works
leeperry is offline   Reply With Quote
Old 11th May 2010, 14:24   #2612  |  Link
Mark_A_W
3 eyed CRT supporter
 
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
Quote:
Originally Posted by madshi View Post
Hmmmm... I've stopped playing Direct3D games a few years ago (due to lack of time), but I don't remember having ever seen games tear.

Interesting,

I don't game anymore (I grew up), but I do stare at CAD all day long, spinning models around with my spaceball. Tearing is endemic in CAD systems. They don't even try to eliminate it.

The typical framerate on a big model may be around 10fps, but varying hugely dependent on load. Matching up to V-sync must be just too hard.


(BTW I've posted on the ZP development forum that an Exclusive mode interface is really, really needed.)
Mark_A_W is offline   Reply With Quote
Old 11th May 2010, 14:38   #2613  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Jong View Post
But, when we are searching for perfection I am nervous of passing RGB unless I know my display cleanly handles RGB input. I realise all displays end up with RGB, but as almost all consumer sources will normally supply YCbCr. RGB is normally there mainly for "old -fashioned" DVI compatibility.
Don't forget PC usage and games! Many displays and even projectors are also being optimized for game (e.g. PS3) usage. And I think Xbox and PS3 probably rather default to RGB output, I'd guess?

Quote:
Originally Posted by Jong View Post
I fear some displays are optimised for this. For instance, nearly all displays are applying some post-processing. Do we know this is not done internally in YCbCr? I am sure there are displays that "passthrough" RGB cleanly, but all, or which?!
From what I've read in the projector forums, more projectors are having problems with YCbCr than with RGB. AFAIK, none of the current projectors has any problems with being fed with RGB, while I know of at least 2 projectors which have problems with YCbCr and where experts recommend to feed them with RGB instead.
madshi is offline   Reply With Quote
Old 11th May 2010, 14:47   #2614  |  Link
Jong
Registered User
 
Join Date: Mar 2007
Location: London, UK
Posts: 576
Quote:
Originally Posted by leeperry View Post
I'm not too worried about windows scheduling, as I run all the background processes in low prio on single cores and my media player in high prio on the 4 cores...I've also changed the NT affinity system to give 96X more prio to high over low...my issue lies more in the VSYNC fliptime problem as far as I can see
In such a well managed system, Reclock or madVR, with working vsync correction, should be equally good at fixing judder, apart from the possibility with Reclock (1 in 5?) of 1-2 seconds judder at the start, or after a seek or pause.

Once MadVR is working as madshi intends, it will solve that initial judder problem and will either have slightly greater resilience (which you may not need), or massively greater, depending on whether he manages to pre-render several frames, as he intends.
Jong is offline   Reply With Quote
Old 11th May 2010, 15:53   #2615  |  Link
Razoola
Registered User
 
Join Date: May 2007
Posts: 454
Games still tear if vsync is disabled (though triple buffering helps). Games never tear if vsync is enabled correctly.

The difference comparing games to video is your less likly to see the tearing in games due to the much higher framerates and panning that is hardly ever at a constant speed like with video. Your also more concentrated at looking at things to shoot inside the picture than the overall picture. Point being Tearing in games does not stand out as much as tearing in video your watching.
Razoola is offline   Reply With Quote
Old 11th May 2010, 17:52   #2616  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
Bug report(s):

(1) When opening or re-opening videos ~5 times with 0.12 and KMP (it doesn´t matter how long you let it play, e.x. 10 seconds) I get the following error:

madVR reports:
- creating gpu 3dlut volume texture failed
- creating gpu 3dlut volume texture failed

madVR settings are:
PC levels
[x] use 3dlut
luma up - bicubic75
luma down - spline64
chroma resampling - bicubic75
(everything else unchecked)

This happens in e.x. windowed-mode _with 3dlut enabled_ and is reproducable every time, even with different files. I´ve replaced madVR.ax 0.12 with madVR.ax 0.11 and there´s absolutely no problem. No crashes anymore.

(2) Another strange behaviour that I came across with madVR (doesn´t happen with EVR or Haali):

When opening or re-opening videos with mpc-hc (tried 4 of the latest builds and one from 2009, just to be sure) the memory usage increases with every video that is loaded. I haven´t tested when or where this ends, but I´ve stopped at a memory usage of about 3.5GB (6GB RAM total). This really doesn´t look like intended behaviour to me. Maybe this is somehow connected to (1). Like with (1) when I did replaced madVR.ax 0.12 with madVR.ax 0.11 the problems are gone. The available system memory gets released after the next video is loaded, like with EVR or Haali.

Here´s also a debug log (madVRdebug.rar) which I stopped right after (1) occured, re-loading the same video exactly 5 times:
http://rapidshare.com/files/386112452/log.rar.html

And even if that sounds like a broken record, thanks again for giving us such a great tool to work with! If you need anything more to track the error(s) down, just ask.

Last edited by iSunrise; 11th May 2010 at 17:58.
iSunrise is offline   Reply With Quote
Old 11th May 2010, 18:09   #2617  |  Link
djsolidsnake86
Registered User
 
Join Date: Mar 2010
Posts: 139
there is an incompatibility with madvr and directvob sub, that make the video crash at the start, anyone experienced this?
djsolidsnake86 is offline   Reply With Quote
Old 11th May 2010, 18:12   #2618  |  Link
namaiki
Registered User
 
Join Date: Sep 2009
Location: Sydney, Australia
Posts: 1,073
I could produce the memory leak above, and MadVR eventually crashed, though the crashing might have had more to do with me using all MPC-HC's internal filters.

Windows 7 64-bit MPC-HC 32-bit svn1871
File was H.264

Problem signature:
Problem Event Name: APPCRASH
Application Name: mpc-hc.exe
Application Version: 1.3.1871.0
Application Timestamp: 4be774c9
Fault Module Name: madVR.ax
Fault Module Version: 0.12.0.0
Fault Module Timestamp: 4bde9186
Exception Code: c0000005
Exception Offset: 0000ac43
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 3081
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


Quote:
Originally Posted by djsolidsnake86 View Post
there is an incompatibility with madvr and directvob sub, that make the video crash at the start, anyone experienced this?
I had a crash with a 632x480 file. I think it's to do with the video's resolution. Didn't crash when set the option for resized to 640x480 by ffdshow video.

Last edited by namaiki; 11th May 2010 at 18:15.
namaiki is offline   Reply With Quote
Old 11th May 2010, 18:52   #2619  |  Link
djsolidsnake86
Registered User
 
Join Date: Mar 2010
Posts: 139
my files that crash are : 712x304 pixels
djsolidsnake86 is offline   Reply With Quote
Old 11th May 2010, 20:50   #2620  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
VSFilter Input Pin
Code:
Filter : DirectVobSub (auto-loading version) - CLSID : {9852A670-F845-491B-9BE6-EBD841B8A613}

- Connected to:

CLSID: {04FE9017-F873-410E-871E-AB91661A4EF7}
Filter: ffdshow Video Decoder
Pin: Out

- Connection media type:

Video: YV12 712x304 23.98fps

AM_MEDIA_TYPE: 
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 324672
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(712,304)
rcTarget: (0,0)-(712,304)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 89
dwPictAspectRatioY: 38
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 712
biHeight: 304
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 324672
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
__________
VSFilter Output Pin
Code:
Filter : DirectVobSub (auto-loading version) - CLSID : {9852A670-F845-491B-9BE6-EBD841B8A613}

- Connected to:

CLSID: {51B4ABF3-748F-4E3B-A276-C828330E926A}
Filter: Video Mixing Render 9 (Renderless)
Pin: VMR Input0

- Connection media type:

Video: YV12 1024x304 (89:38) 23.98fps

AM_MEDIA_TYPE: 
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 466944
cbFormat: 1152

VIDEOINFOHEADER:
rcSource: (0,0)-(712,304)
rcTarget: (0,0)-(712,304)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 89
dwPictAspectRatioY: 38
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: -304
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 466944
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
I seem to have run into a problem similar to djsolidsnake86 with VSFilter and madVR in the past.

Just now I tested it again artificially by resizing a video to 712x304 in FFDshow. CRASH. The above are VSFilter's input/output pins when trying to connect a 712x304 video from FFDshow to VSFilter to VMR9. This of course could be different then VSFilter's Output Pin to madVR, but I thought I'd post it anyway.

madVR seems very finicky about how it is feed non-MOD16 width video. If the decoder pads the video to MOD16, it's happy, but if the decoder outputs non-MOD16 video directly and expects the video renderer to pad as necessary, it can sometimes cause madVR to crash. Odd anamorphic aspect ratios can also cause a crash. I suspect this is the same or similar problem as the Youtube FLV sample which caused a crash when using CoreAVC as the decoder.

Here is the debug log (10 seconds): http://www.mediafire.com/?wlumyjyzjmn

Last edited by cyberbeing; 11th May 2010 at 20:54.
cyberbeing is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

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

Forum Jump


All times are GMT +1. The time now is 06:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.