Search options (Page 2 of 3)

I use a USB capture device from Magewell.

PC1 (Intel NUC) runs the Slingbox viewing software and feeds into the capture device. Capture device outputs into PC2 (Gigabyte Brix Pro) which runs a modified version of MPC-HC. Modified because it communicates over the LAN with the Slingbox viewing software (SlingFront) to auto restart the capture in full screen mode at an appropriate framerate according to the source being viewed (which SlingFront knows of course, I obviously modified this software too).

Repeat 4 times (Well actually 7, as I'm about to set the same up in our summer house).

I'm nuts I know, at least my wife thinks so, but it's more fun than buying 7 new TVs with motion interpolation.

Not so much a fan of TVs as of football, and football looks shit at 25/30fps. I need different rooms to watch in to cover all situations - kids running about making too much noise, wife watching something else, etc.

But ultimately I'm just having fun setting it all up and perfecting it

I wondered why sometimes my live TV capture setup was cutting off a load of the image at the top and bottom of the screen....turns out that depending on what is on the screen when the video stream starts it'll decide the cropping based on that.

You could maybe look at the source code for MPC-HC and see how it's coded there, as they support the scenario you describe. I actually capture a 50/60 fps source at 25/30fps using MPC-HC and use SVP to interpolate back to 50/60fps in a similar manner.

I modified the MPC-HC source code for some other uses so I can confirm it was pretty easy to setup a build environment and compile the latest source.

Seconded.

Actually, I can't really notice any difference with the new version but I want to put on record my thanks for continuing to support and improve the project.

Top of my wishlist for a new version would be some focus to be put on improving the interpolation for sports viewing; it's pretty good for the most part, but there are a few scenarios in particular where it isn't so great and various artifacts become obvious, such as (in a football match):

1) sequences where the ball is moving fast.
2) close-up shots of a player when he is running with the crowd in the background and the camera is panning to follow his movement.

If there is interest in focusing on this I am happy to find some samples. I tend to watch only live TV with SVP so I don't have any ready made recordings, but I'm sure with a bit of effort I could find or capture some.

Anyway, it's more than usable as is, so keep up the good work.

I mostly watch live football with SVP.

The biggest problem is ghosting, in particular when you have a close up shot of a player running against a static background such as the crowd it can look awful, with blobs and outlines and all sorts appearing. For normal viewing of the pitch it works very well in my experience.

The default shader seems to be best and have the minimum artifacts - even the 'complicated' one which is supposed to reduce ghosting doesn't help, in fact it seems to add a bunch of edge artifacts without making the ghosting any better.

A lesser problem is that when the ball moves fast it just appears to no longer be motion interpolated at all, but reducing the motion vectors grid to 6 makes this a lot better.

Depending on the shader used, you can make a fast moving ball appear as three balls at once, though not with the default shader.

I'd like to see the developers try and tune SVP for sports viewing, taking account of the above. But then I would say that because like I say, I use it mostly for watching football (that's real football, not that American rubbish by the way )

It's here:

http://forum.doom9.org/showthread.php?p … ost1668162

Well I don't know to be honest, I'm not knowledgeable on how this stuff all fits together.

All I know is that in my configuration it behaves as if the audio is being passed straight through by the player from the capture device to the audio output device with no consideration given to any video delays that may be introduced directly or indirectly by the player along the way.

So that's one issue.

But if you're having issues with a file-based setup, then it seems like there must be another issue in that even where there is a filter that is supposed to sync things up, it's not working, as you say maybe the time stamps for the video frames are not being adjusted properly or something so whatever is meant to keep them in sync doesn't know they are even out of sync.

Well I've found that by quitting SVP manager and just toggling the ffdshow ahead buffers on and off you can enable/disable the audio sync problem so I suppose the error is inside AVIsynth/ffdshow.

I agree with you though, whatever is delaying the video frames should delay the audio too, otherwise an implicit assumption is being made that the hardware/threads/script combination isn't causing a noticeable video delay - but under some circumstances it is.

2) yes, I have reduced this from 3 to 1, as I found (by enabling AVISynth OSD) that it didn't need the extra two. It didn't make a significant difference though.

3) I will take a look. Is that a different buffer to the ffdshow ahead buffer?

But even so, is it not a potential flaw that depending on the hardware/threads etc the audio can be delayed due to the video latency?

I'm not really concerned about having a video latency of even up to 1s, if it makes things for SVP as good as possible, but I feel there needs to be a way of controlling the audio delay - but in such a way that it can be tuned on a per-profile basis, and also works for capture cards not just video files.

Would generate.js be the place to put in a call to SetAudioDelay too? Is that the place where it creates the AVISynth script that gets used?

I appreciate your help by the way!

Further update to this.

I noticed that the issue only occurs with a 25fps capture source and not with the 29.97fps capture source.

With the latter, it appears to remain in sync. Further, the actual latency of the video seems about half when the source is 29.97.

I don't think it's SVP though - I quit SVP manager and I can reproduce the issue simply by toggling the AVISynth Forward buffer. Turn off this buffering and the audio syncs, turn it on it gets messed-up as described.

Should/does AVISynth 2.6 alpha 5 work with SVP - maybe I could try that? Though I checked their changelists and couldn't see a relevant fix.

None of the audio processors or built-in MPC-HC audio switcher has any effect on the audio delay, simply gets by passed. Presumably that's because it's a capture rather than a file.

My ugly workaround was to to stop capturing audio on MPC-HC and instead use VAC's Audio Repeater to capture the audio from the device and forward it to the output. Audio repeater allows the buffer to be set. Better still it can be launched and iconised to the taskbar from the command line so I managed to hack in a call to ShellExecute in MPC-HC source to make MPC-HC launch it when the capture starts.

Works well but like I say, ugly solution and I'd prefer it if the latency for 25fps capture sources was similar to 29.97, rather than be 750ms with Auto threads (4 threads I think).

Trouble with reducing to 2 threads is it means I have to dial down the SVP settings to avoid glitches. With Auto threads I can get a better result by being less conservative.

Thanks - well I tried the ffdshow audio processor, which support a Delay but ran into another problem - basically it seems to be set up ok in the filter graph, ie it says that it is taking the correct input and outputting it to the TV but no sound comes through.

The audio processor is definitely receiving the signal though because in the configuration panel if I tick 'Volume' and show levels I can see the L and R channels fluctuating.

For some reason though no sound actually goes to the audio device.

I will try the AC3Filter then.

Maybe the issue is because the capture is uncompressed audio or something.