[Request] - Project Source to Monitor

[FerretBomb]

I was wondering if it would be possible to add the ability to use OBS' projector mode to display an un-encoded feed from a video capture source on a monitor.

I just picked up a capture card, and with the bundled software (VideoKeeper) there is next to zero delay (10-20ms at most) or stuttering... to the point I can play DEMANDING rhythm games on its preview.
But with OBS' Projector mode, there's between 300-400ms of delay... enough to make some games much harder, and others outright impossible. Add in occasional hitching/stutter in the Projector feed, and I can only assume this is because OBS is showing the encoded video on the projector, the interstitial steps are causing the delay, with the hitching being occasional duplicated frames (as they do show up in the log afterward).

Would it be possible to repurpose the Projector code, and immediately write the incoming video capture out to a specified monitor, with no compositing or encoding? It'd save from having to drag a TV in and use a splitter or passthrough... less than desirable with three monitors already present, desk-space therefore at a premium, and the bundled software able to do it.

Otherwise, I'll be stuck running a Window Capture of the VideoKeeper software to get the source into OBS, which just seems silly (and probably lower-quality).

 

[paibox]

No, due to DirectShow, this isn't possible.

VideoKeeper itself doesn't use DirectShow at all, and thus doesn't suffer from any of the issues that comes with Microsoft's horrible video filter API. I've tried to get access to the SDK to make a DirectShow-less plugin for (among others) the XCAPTURE-1, but my request was happily ignored.

The delay isn't shouldn't be 300ms though, it should be 80-100ms, are you using the deinterlacing built into their DirectShow filter or something? I would not recommend doing so, as those deinterlacers perform very badly compared to OBS' own deinterlacers.

 

[FerretBomb]

That's a shame. Ah well, time to drag the TV in. :(

Is it possible that the request may have been ignored as it was in English, if you didn't get it translated? They seem to be a JP-centric company, with no support I've been able to find in any other language. So they may just not have been able to read it, or not have anything IN English to send to you as far as the SDK goes.

Nope, I'm using no deinterlacing at all when I was trying to play the rhythm game... had to anticipate and 'guess' well ahead of the markers (Amplitude if you're familiar with it, had to go a full capsule to a capsule and a half before the cap hit the activation marker to get it to register as a correct hit). I was spitballing the 300ms number to be entirely honest, because the lead time seemed inconveniently large, while not being toward the 'ridiculous' levels of a full second. I should record a video and actually see how many frames pass between the marker and the 'fail' indication.

OK, so there will never be a full-speed passthrough in OBS unless you get that SDK. Still, even with DirectShow sitting there like a lump, would removing the compositing and encoding steps appreciably reduce the delay? I mean, it'd need to be done if the SDK was available to get the delay as close to zero as possible, and if there are cap cards out there with direct access it'd benefit them as well, as-is. And even chopping a conservative(?) 50ms off is still almost a 20% improvement. Even more, if my estimate was high. And removing the duped-frame hitching by getting the encoder out of there would provide a smoother experience that could be compensated for, with reliable response.

If it wouldn't be worth the coding time I completely understand, but if it was a quick 10-15 minute toss-together to repurpose the Projector code (activate by right-clicking the video capture source maybe, a new context menu option?), it could be an easy value-add. :)
Then again, it could also result in another 'but why don't I have desktop audio' situation, as with the option to use a recording device for the System channel, but with people asking why it wasn't instantaneous.

 

[paibox]

Removing the encoding and compositing steps would not have any effect, the most you would be able to chop off (theoretically, by outputting the frame somewhere else and then passing it through to OBS) would be one frame, about 16.7 milliseconds.

No, I didn't mail Micomsoft (maybe I should have, actually), but rather the manufacturers of the UB530, the device the XCAPTURE-1 is based on, and they did reply to me in perfect English initially. The duped frame hitching is unfortunately in many cases caused by DirectShow itself as well, the one application handling it a bit different (by dropping the next frame and inserting the previous correct one instead, giving the impression of it being slightly smoother) is VirtualDub.

But yes, the only way to lower the delay by any significant amount would be to take DirectShow completely out of the picture.

 

[FerretBomb]

You may also want to try mailing Startech; I fixed most of the delay by using more up to date drivers for a different device. Apparently the parent company (Yuan) uses semi-universal drivers, and the one for this device works well:
http://www.startech.com/AV/Converte...re-Card-1080p-HDMI-DVI-VGA-Component~PEXHDCAP

Has some oddities in configuration that I'm trying to figure out (like fullscreen scaling by-default), but it fixes a LOT of problems, and gives 'true' blacks now. But it's a bit capricious, apparently /insisting/ on sending 1080p video to OBS for some reason, and if configured to send a lower resolution in the driver (manual forcing to 720x480) it shrinks the video down... and fills the rest of the 1080p source size with green, which cannot be chroma'd out. Not sure if that's on the OBS side or the device at that point.

Still getting erratic video hitching, and have the window to the side... only happens when OBS drops from 30 (or 60) fps to around 5-20 for a second, then goes back to normal. Seems to get worse if I have any of OBS' de-interlacing methods enabled (but is still present without)... especially Yadif (2x). No idea if DirectShow would cause OBS' internal frame counter to spaz out, but it looks like an OBS-side issue on that front, which the 'project raw source' suggestion still might fix.
Also realized that I'm playing a worst-case game, which may be contributing to duped/skipped frames; large amounts of fullscreen motion and sigificant color changes/flashing. I'll have to re-try it with Okami or something that isn't pretending to be a rave.

On the up side, with the new drivers and almost-nil delay, it's playable in the projector mode. Hitching definitely still throws off the rhythm, but I may not have to drag the TV in at this point. :D

 

[Boildown]

Not sure if this is applicable to the projector mode, but you could try some x264 tricks, like using the zero latency tune. http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#Encoder_latency

 

[paibox]

Why on earth would some encoder setting apply to the projector mode? It's just a duplicate of the preview.

FerretBomb, if your FPS in OBS is dropping to 5-20 for a second, something is most likely maxing out your CPU (or some of your cores) at that point in time, I recommend checking the processes using the task manager or so.

On a side note, I did get a hold of some very helpful people at Yuan High-Tech earlier today, they're going to look into some of the issues with the DirectShow filter for the device, and I might get a chance to work with the SDK as well.

 

[FerretBomb]

@paibox, as far as I knew the Projector was showing the post-composited/encoded video which was actually being sent out, allowing it to be used for testing stuff relating to stream video quality, without needing to record or actually put the stream live/online. Is that inaccurate?

Yeah, it's probable that one or more of my cores are maxing erratically. I'm on an old i7-920 without so much as a mild overclock, or tuning the number of x264 threads. Still, it's able to kick along at 1080p@30fps without a problem most of the time, figured backing down to 720p would ensure some performance margin. Appears it's not enough though.

Nice! I'm glad to hear that, man. If we got a Yuan native input plug-in similar to the Datapath VisionRGB, that'd be awesome. And since their drivers appear to be universal, I'd kind of expect their SDK to support a lot of their devices, like that PEXHDCAP up above, along with my Micomsoft, and some of the high-end Yuan cards.

Really, I'm just happy that the updated PEX drivers have added RGB24/32 output to replace the YUY2; it really seems to give much faster capture speeds and better red definition, comparatively.

 

[paibox]

That is indeed inaccurate, the projector is just a duplicate of the preview texture.

As for the core maxing out, it might be some other application that's hogging it, which is always worth looking into and eliminating while streaming. I recently had an issue like that with Skype, which turned out to be the crappy little ad in the main window.

I do sort of expect the SDK to apply to devices such as the PEXHDCAP/SC-500/512 as well, yes, though I can't tell for sure until I see it. Most of the other Yuan High-Tech cards are SDI capture cards, most likely not something widely used by regular consumers.

As for the RGB24/32 output, it's still 16-bit YUV, but I do believe that it fixes the chroma shift present when using YUY2 directly with the PEXHDCAP/SC-500/512.

 

[FerretBomb]

Ah. Good to know... I was using it for a while there while adjusting my settings, looking for artifacting while tweaking my settings. Guess it was psychosomatic then... or I really have no idea WTF was going on. I mean, the encoder IS running when in Preview mode, right? I get a CPU spike commensurate with actually going live or local recording, why I'd never doubted that the Projector was showing encoder output.

Nah, I've already tracked all of that down. Idle CPU bounces between 2-3% stable, unless there's a nasty interaction somewhere between OBS in preview mode specifically and some other program. Or the peak might be super-short, to the point of the monitoring polling rate 'missing' it. I don't have a monitoring application with short-term peak-hold either, so *I* might just have missed it.

Yeah, I uninstalled Skype when I started streaming regularly. Badly coded, insecure bloatware that still sends up a signal flare to anyone who wants to mess with you and has your Skype name.

Interesting. When I swapped to RGB32, I also got a noticeable speed boost over YUY2 mode, with FAR less delay. That's probably just a driver thing, as YUY2 also exhibits the 'green box' issue where the source is presented at native within a 1080p source field, with the rest filled with non-chroma-able green. The other modes work fine, and expand the source to fill (most of) the full source field in OBS' preview.

Man this is wandering off-topic, but I've been curious for a bit... when OBS does chromakeying on a camera, does it perform the chroma before or after down-sampling the cam? Because it kind of looks like 'after'; that or the downscaled camera feed doesn't allow gradient alpha (so anything chroma'd tends to develop noticeable jaggies around the edges when it's scaled down).

 

[paibox]

The encoder is by default running in preview mode so that you can accurately estimate CPU load for when you actually stream, but it can be disabled in Advanced in case you need a light preview mode, but no, the encoded output only makes it to the actual RTMP stream and the file you save your broadcast to.

The "green box" issue with YUY2 is merely a bug with some of the drivers, which is why I'm still using the Xcapture-1 drivers from Micomsoft's site for my card. It really does sound like the drivers you're using are doing some kind of involuntary deinterlacing and slapping it onto a 1920x1080 framebuffer in YUY2 mode, while it gets bypassed when using RGB output.

As for the chroma key, I really couldn't tell you how it works, because I'm not very good with pixel shaders to begin with.