Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

For whatever reason xy-VSFilter does, though, try to do a X->YUY2 conversion.

I'm unable to reproduce this, but all my computers support YV12 Overlay. Was there any way to artificially reproduce this on Win7 with GraphStudioNext?

What you describe is usually a sign that Video Renderer and/or Video Decoder does not support re-connections with a different (non-default) color format. A number of poorly designed decoders like FFDShow, CoreAVC, XVID, and others all are unable to re-initialize themselves properly when a different color format is requested on re-connection and output a green screen to xy-VSFilter. I wouldn't be surprised if a similar bug existed in MPC-HC's Overlay Mixer implementation.

I'll have the xy-VSFilter developer take a look, but I somewhat doubt this is an xy-VSFilter bug. My understanding of how xy-VSFilter functions, is that the code you point to should be a non-issue because xy-VSFilter's first connection attempt with the video decoders default format (i.e. NV12 in your case) is always a dummy connection to query the Video Renderer's supported formats. xy-VSFilter then always disconnects -> reconnects with the with the highest preferred format of the Video Decoder which the Video Renderer supports (i.e. YUY2 in your case). The way we've implemented our transform filter re-connections and colorspace changes follow Microsoft's specifications for performing these operations very closely.

In any case, if this really does turn out to be an xy-VSFilter bug, we'd prefer that you allow us to fix it properly ourselves. The colorspace and re-connection logic is a very sensitive and specifically designed portion of xy-VSFilter code, which I wouldn't recommend randomly hacking around. At the very least, please let us review any proposed patch before releasing a 'fixed' build to the public.

As always, I'm late with them changelogs . A new release candidate has been available for a bit now here.

Updated components:

• LAV Filters 0.57.0.0-d8dc0ef
• MPC-HC 1.6.8.7308

General changelog:

• Minor network initialization fix in LAV Splitter.
• Updated MPC-HC to current git HEAD.

Time for me to add a task tray option for LAV Splitter in the settings app, as well as see if I can fit the LAV Splitter's settings screen button in that window somewhere .

For whatever reason xy-VSFilter does, though, try to do a X->YUY2 conversion.

<namaiki> lav video(nv12)-> xyvsfilter(nv12-> yuy2)-> overlay

In a case like this, xy-VSFilter seems to take the job (not sure if it's the initial connection or a possible change after the first contact). The result is a green screen, of course. Why? If we take a look at the longer CBaseVideoFilter::CopyBuffer() function in BaseVideoFilter, we shall see the following piece of code:

Code: [Select]

    else if(subtype == MEDIASUBTYPE_NV12 || subtype == MEDIASUBTYPE_NV21)
    {
        if (bihOut.biCompression != subtype.Data1)
            return VFW_E_TYPE_NOT_ACCEPTED;
        BitBltFromNV12ToNV12(w, h, pOut, bihOut.biWidth, ppIn[0], pitchIn);
    }
Now, with a case of NV12 -> !NV12, you can see that VFW_E_TYPE_NOT_ACCEPTED is returned. This still feels alright, as, while no data has been copied over ("green screen"), we still have successfully returned a failure state. Then we go to DirectVobSubFilter.cpp, to the end of CDirectVobSubFilter::Transform(), to the caller. The following code can be seen:

Code: [Select]

CopyBuffer(pDataOut, (BYTE*)spd.bits, spd.w, abs(spd.h)*(fFlip?-1:1), spd.pitch, mt.subtype);

PrintMessages(pDataOut);
return m_pOutput->Deliver(pOut);
Yeah... that return value... I will try tonight if the following helps at all, or just breaks stuff even more のヮの :

Code: [Select]

     if(FAILED(hr = CopyBuffer(pDataOut, (BYTE*)spd.bits, spd.w, abs(spd.h)*(fFlip?-1:1), spd.pitch, mt.subtype)))
         return hr;

This thread lacked responses, but do note that I did read it the day you posted it . I will try to update the IP geolocation database we used when movax hacked the current system up. We are also looking at other possible ways of making the download system better by possibly moving to a general download mirror selection system like MirrorBrain.

In general, even with such an incorrect geolocation selection, the user shouldn't have a problem in downloading the CCCP itself, as right now the whole system is somewhat stripped from too many alternatives thanks to certain information not going over from parts of the older CCCP crew too well.

Thankfully CPU decoding shouldn't be much of a problem for your CPU, it's not a problem for my olde C2D P8400 either -- and you have double the cores. With MadVR you wouldn't be getting the power savings anyways .

If you need to save power, then you can try QuickSync with EVR(-CP) when needed. Otherwise just using CPU decoding is a better, more stable alternative in general.

True

Thanks

Thankfully CPU decoding shouldn't be much of a problem for your CPU, it's not a problem for my olde C2D P8400 either -- and you have double the cores. With MadVR you wouldn't be getting the power savings anyways .

If you need to save power, then you can try QuickSync with EVR(-CP) when needed. Otherwise just using CPU decoding is a better, more stable alternative in general.

Ha ha yeah.
Thanks it works when I switch to low power mode when only the Intel chip is in use but then MadVR cant use the AMD chip for its processing so it starts to stutter.
Guess I have to choose between software decoding and hardware processing or vice versa.

QuickSync, eh. And a dual GPU setup at it. Sounds like tons o' fun .

Anyways, first of all, the CPU in theory at least seems to have the capability. I know you'd have to be somewhat careful about the drivers, but you should try to find out if you have the newest drivers installed for the Intel side of things, as well as the main decoding library that the QuickSync interface is using.

After checking that, try booting up with just the Intel thing enabled, and seeing how it works then. If that works, or if you just can't do that from the BIOS, then you could try this way of adding a fake screen, as QuickSync needs a screen to be connected to that adapter for the thing to work (this isn't true for Windows 8 and the newest QuickSync open source library, but that isn't going to be in the next release most probably).

In any case, try these things out, and see if you can get it to work. QuickSync is a quirky thing, and having multiple graphics adapters doesn't help at all .

Is pretty much everything in the Hardware Acceleration box ticked except for UHD and MPEG-4? Did you enable QuickSync before loading the video?

No real clue how the AMD graphics drivers work, but is the Intel GPU selected to be used with MPC-HC?

Maybe try a different video as that one has a very odd resolution.

In every single video I try it never uses QuickSync.
I got HD videos and SD videos with different resolutions. I have tried about 10 different videos.