Guide: Live stream and capture simultaneously

So why would you want to do this? Usually people live stream to services such as Twitch but also want to keep a local recorded file to submit to SDA or just to have a higher quality file for YouTube. Without a proper setup it can be tough to properly coordinate. The ultimate goal of this guide is to produce local raw video at SDA standard while being able to live stream to our viewers. I'll only be focusing on DirectShow cards since it's easier to manage. I'll try and cover Elgato and similar hardware encoding devices at a later date.

I assume you have followed one of my previous guides depending on your situation.

Interlaced guide. Mainly for retro consoles and uses composite or S-Video.

Progressive guide. Mainly for newer consoles with Component or HDMI output. Xbox, PS3 or similar.

What makes this process so much easier is AmaRecTV. Basically, AmaRec has a live plugin that outputs your video as another DirectShow source. This is a complete life saver because typically a DirectShow device can only be used by one program at a time. AmaRec takes control of your "real" capture card feed and simultaneously outputs another "capture card" that you can feed into your streaming program (XSplit or OBS). Let's get on to the config!

In your AmaRec folder you should have an exe called live_setup300.exe (might slightly differ based on your version). Please note that the latest 3.10 is bundled with 3.00 of the live setup. Run that exe and you should see this. All pictures can be clicked to enlarge the image.

Just click the forward arrow more times and it should install without problems. Now open up AmaRecTV and go to the Graph3(Live) tab. We should now see something like this.

Click the Live Enable box and then you can configure the resolution and frame rate that you want to send to your streaming program. Resolution should match what you set in the device tab (usually 720x480 for SD). Regardless of whether you are handling interlaced or progressive content, the frame rate should always be 60. Below is an example. I am using a PS3 set to 720p. I input 1280 720 and select 60.

Note: I have noticed that you can get slightly less CPU load if you use a lower resolution (for example down scaling 720p to 480p) but it's probably not worth it.

That's us pretty much set for progressive video but we need to do some more steps for interlaced video. We need to do these steps because we want to supply a nice deinterlaced image to our viewers on stream. Go to the Graph 2(Preview) tab and enable "Top field first" and "for Retro Game" (as shown below).

This is an acceptable configuration for most all retro games. However, there is a table on the AmaRec blog about what mode you should use based on the console and resolution.

I should also note that you might want to consider selecting 4:3 in the Aspect Ratio but this is personal preference based on your source (this is only if you are dealing with SD sources).

Next, go to the Recording tab and just make sure Filter Processing is set to Off. We do not want our source file to be deinterlaced as we will do this in Yua. It also means that even if you chose the wrong deinterlacing method under Preview, your source video will still be fine. Apply these settings then press OK. Your preview window in AmaRec should now be deinterlaced.

Now we want to open our streaming program. I'm sure most of you can figure this out. I'll quickly go over XSplit first.

Go to File > Add Camera > AmaRec Video Capture. You should now see something like this:

Don't worry the writing at the bottom left will go away after 5 seconds or so. It's just to notify you of the resolution and frame rate chosen. XSplit v2.0 added a feature where you can assign an audio source to a DirectShow device. I still use v1.3 for various reasons so no screenshot here unfortunately. Just right click AmaRec Video Capture and I'm sure you can find your way to adding the audio source called "AmaRec Audio Capture" and assign it. You can also elect to play it through the speakers or just to the stream.

Now let's look at OBS.

Add your scene and then right click in the Sources window and go to Add > Video Capture Device and give it a name. Like XSplit, we just add AmaRec Video Capture and AmaRec Audio Capture. I'm also a big fan of making sure you tell OBS the resolution and frame rate via Custom Resolution. A friend of mine once didn't do this and AmaRec kept popping up with "frame rate of the video capture card does not suit a preset value. Neither recording nor a live function functions normally".

Like XSplit, you can elect to play it through speakers or just to the stream.

That's pretty much it. Now just stream at whatever settings you want and use AmaRec as you normally would. Obviously keep in mind that you are now recording and streaming so your computer might not be up to the task. Make sure you do some trial runs before doing serious attempts and you aren't dropping frames etc.

1080p60 Battle (MagicYUV vs x264vfw)

I've known about MagicYUV for quite some time but never really paid much attention to it. I decided to look on the website and it makes some interesting claims:

"It provides faster-than-realtime performance for FullHD and 4K resolutions on contemporary PC hardware. Multi-threaded by design enabling efficient utilization of multi-core CPUs. This combined with an advanced SSE optimized coder/decoder engine makes MagicYUV one of the fastest mathematically lossless video codecs of it's kind."

Sounds quite interesting, doesn't it? I thought so to. I decided to compare it to the July 2014 x264vfw build to see if these claims were true. Firstly, here is the configuration and setup. We'll be using a 1080p60 capture card (YUY2) and an Xbox 360. AmaRecTV will be the capture program. The system in question is nothing fancy. An old i5 2500k, 8GB RAM and a dedicated internal WD Black 1TB hard drive for capture. Below are the codec configurations.

During initial testing, I was unable to have MagicYUV keep a stable frame rate when the buffer size was set to 128 in AmaRecTV. x264vfw also had this issue with --keyint 1 applied. This buffer size is just too small when dealing with such high data rates and real time compression. To give each codec a chance, I set the buffer size to the maximum 512 to mitigate hard drive bottle necking. This thankfully lead to no further issues and testing was much easier.

First let's talk about how x264vfw performed. If you read my previous posts, you know what I am going to say. It just works. If you want even better compression ratios you can disable/enable the --keyint value. Setting this to 10 gives a fair trade off between editing accuracy and compression. Only in very high motion scenes will x264vfw even come close to MagicYUV. Most of the time it's not even close. Please pay close attention to the CPU usage figure in the below screenshot (click to enlarge).

Now let's move onto MagicYUV. The claim of being the fastest lossless codec is definitely true... and they are true by a huge margin. It knocks every other true lossless codec out of the park that I tested months ago in my 1080p60 lossless article.

That 24% is not just a low reading. That 24% stays no matter what content you capture. I've seen it peak to 25% once but that was it. That's pretty amazing actually. Even x264vfw at lower CRF values has a hard time beating that. The only problem is well... not a problem. It's just like every other true lossless codec in that the data rates are always high. Compare the file sizes of the above screenshots. With x264vfw I've captured over 5 minutes and just about to hit 19 GB. I've not even hit 4 minutes with MagicYUV and I'm already close to 22 GB.

In conclusion, MagicYUV performs really well but personally I feel it still falls slightly short of x264vfw. The sheer configuration options available in x264vfw is what swings it for me. Not only that but MagicYUV is currently not part of FFmpeg. This means it won't import into popular encoding programs like nate's Yua for SDA speedrun submission. However, if it does get integrated into FFmpeg and compression ratios improve I will definitely consider MagicYUV over x264vfw.