Guide: Capture SDA Acceptable Video (includes live streaming)

2014-03-05 04:00:54 pm

The Dork Knight himself.

Well I wasn't saying I wanted those tests rofl, more like suggestions if you choose to tackle the odd framerates and audio pitch issue. I still wish I could clone my system for other people to use cause I haven't run into any of these issues yet.

/me frantically searches for a piece of wood to knock

Bigmanjapan

Edit history:

Bigmanjapan: 2014-05-14 05:04:39 am

2014-05-14 03:39:42 am

Can anyone guide me in which form segmented run should be uploaded?
Should all the segments be compiled in one video file or I can send every part in individual file? If second option is acceptale, should I put StatID (SDA logo etc.) only in the first and the last parts of the run or does every segment need StatID in the beginning/ending?

nate

2014-05-15 07:32:09 pm

all options are acceptable. it depends on personal preference (yours and others'). most people, when encoding more than one segment, put the statid on each segment (the third line as "segment 11" or whatever), which makes it much more annoying for people to steal them.

lecorbak

Edit history:

lecorbak: 2014-05-29 04:39:08 pm

lecorbak: 2014-05-29 04:27:38 pm

2014-05-29 04:08:00 pm

Vanilla H is mai waifu

when I try to record with AmaRecTV, it says the error "ACMStreamOpen", it's been 2 hours i'm on it, and nothing works.

EDIT : OK, I finished to resolve the problem
I installed "lameACM-3.99.5" and used this encoder for audio.
you should write something for this error.

honorableJay

2014-05-29 06:10:16 pm

The Dork Knight himself.

Well for recording audio in runs that will be submitted to SDA the format required for audio is Uncompressed. Unless someone knows of a rule change, the last time I checked using MP3 compressed audio in source files is not acceptable.

As for your error itself, that's honestly the first time I've ever heard of that happening. The only thing I can think of is some other program was trying to grab the audio stream from your capture card and was interfering with Amarec itself.

lecorbak

2014-05-31 06:15:24 am

Vanilla H is mai waifu

Quote:

Well for recording audio in runs that will be submitted to SDA the format required for audio is Uncompressed. Unless someone knows of a rule change, the last time I checked using MP3 compressed audio in source files is not acceptable.

so I just recorded a great run for nothing, great.

nate

2014-06-01 09:10:54 am

if mq and hq sound fine after it goes through yua then there's probably no problem. high enough bitrate mp3 is indistinguishable to a human from lossless. "high enough" also depends heavily on the source, e.g. nes versus ps3. that rule is just there because lossy formats should not be used as sources because another round of lossy compression will have suboptimal results because it will pick up on the compression artifacts people can't hear and enhance those. but again it's not certain that people will be able to tell even then. sda rules about video are meant to ensure a good viewing experience rather than geeking out about technology or math or something. also in this case it's an easy one because there's no reason to record to mp3. there isn't the huge space requirement like there is for uncompressed hd video.

Bigmanjapan

Edit history:

Bigmanjapan: 2014-07-11 06:21:58 am

2014-06-04 02:07:43 am

Edit: solved

TheThrillness

Edit history:

TheThrillness: 2014-07-11 05:32:43 am

TheThrillness: 2014-07-11 05:32:35 am

TheThrillness: 2014-07-11 05:32:21 am

2014-07-11 05:31:34 am

thethrillness.blogspot.com

Added a new tutorial that covers capturing progressive video (480p, 720p) from Component or HDMI using AmaRecTV. It's not really that comprehensive yet but I'll add in more as I go along. Let me know if I missed something obvious out.

http://www.thethrillness.com/2014/07/capturing-and-encoding-video-for-sda.html

HDL

Edit history:

HDL: 2014-10-12 12:54:14 pm

HDL: 2014-10-12 12:53:16 pm

2014-07-21 11:41:07 am

Nice guides, but unfortunately they assume Windows. To really cover bases and help everyone I strongly suggest expanding the guides with information on OS X and Linux.

Sadly I'm not able to contribute detailed information regarding Linux, but I've taken the initiative to make this easy for OS X users:

https://kb.speeddemosarchive.com/Mac_Recording_and_Streaming
https://forum.speeddemosarchive.com/post/the_mac_os_x_thread.html

TheThrillness

Edit history:

TheThrillness: 2014-12-06 01:00:01 am

2014-12-06 12:59:19 am

thethrillness.blogspot.com

Been thinking about making x264vfw the staple codec over Lagarith (interlaced) for months now and I finally decided to change it.

1. Less CPU load. People with weaker systems should have no trouble now. This isn't much of a problem with SD stuff but it is when you start to introduce HD.

2. Better compression. The move from Lagarith to a low CRF value is a good move as the subjective assessments see no visual difference. Encoders obviously will care about Lossless video more than the human eye but even after encoding a CRF video, the detail loss is nothing.

3. With points 1 and 2, we should now be moving over to fewer dropped frames (something I've seen a decent amount of in the tech support area). If you had a single drive setup with Lagarith, some PC setups would cause dropped frames. Having a drastically lower hard drive writing rate thanks to x264vfw should be able to cope with Windows processes and write a file without dropping frames. Of course disable as much processes as you can and don't have anti virus or similar running.

4. More colorspaces! Since x264vfw has the "Keep input colorspace" option, you are no longer limited to YUY2/RGB as Lagarith was. Granted this isn't much of a problem but always nice to have for future designs.

5. Great configuration potential. If you did for some reason need Lossless capture, x264vfw will still barely beat Lagarith. You can fine tune stuff like --keyint to suit your needs when it comes to editing in Yua or similar. For perfect frame seeking, set it to 1 (but compression will be hit). Don't think you need precise editing? Completely remove --keyint and see a huge compression boost. I've found that setting --keyint to 10 is a good compromise between compression and editing capability. Feel free to experiment yourself.

I should note that having Zero Delay ticked is very important. If you don't tick this then the audio will be slightly behind the video. It's not totally awful but you can tell for sure. It's a shame because not having this ticked is insanely good for compression.

Been thinking about making x264vfw the staple codec over Lagarith (interlaced) for months now and I finally decided to change it.

1. Less CPU load. People with weaker systems should have no trouble now. This isn't much of a problem with SD stuff but it is when you start to introduce HD.

2. Better compression. The move from Lagarith to a low CRF value is a good move as the subjective assessments see no visual difference. Encoders obviously will care about Lossless video more than the human eye but even after encoding a CRF video, the detail loss is nothing.

3. With points 1 and 2, we should now be moving over to fewer dropped frames (something I've seen a decent amount of in the tech support area). If you had a single drive setup with Lagarith, some PC setups would cause dropped frames. Having a drastically lower hard drive writing rate thanks to x264vfw should be able to cope with Windows processes and write a file without dropping frames. Of course disable as much processes as you can and don't have anti virus or similar running.

4. More colorspaces! Since x264vfw has the "Keep input colorspace" option, you are no longer limited to YUY2/RGB as Lagarith was. Granted this isn't much of a problem but always nice to have for future designs.

5. Great configuration potential. If you did for some reason need Lossless capture, x264vfw will still barely beat Lagarith. You can fine tune stuff like --keyint to suit your needs when it comes to editing in Yua or similar. For perfect frame seeking, set it to 1 (but compression will be hit). Don't think you need precise editing? Completely remove --keyint and see a huge compression boost. I've found that setting --keyint to 10 is a good compromise between compression and editing capability. Feel free to experiment yourself.

I should note that having Zero Delay ticked is very important. If you don't tick this then the audio will be slightly behind the video. It's not totally awful but you can tell for sure. It's a shame because not having this ticked is insanely good for compression.

ballofsnow

2014-12-06 10:42:48 am

Have you thought about using qp instead of crf?

Mystery

2014-12-06 11:46:16 pm

Why use qp?

TheThrillness

2014-12-07 12:57:50 am

thethrillness.blogspot.com

snow, I used to use qp but Mystery converted me to crf. Like maybe qp performs slightly better than crf in regards to how an encoder sees the data rather than the human eye but any slight visual improvement is not worth it since CRF is able to chop off such a large capture data rate.

ballofsnow

2014-12-07 07:56:08 am

I meant qp for the intermediate file when capturing. crf for the final of course.

Quoting myself from another thread:

Quote:

I don't like the idea of using CRF for intermediate files. CRF will give extra bits to low motion scenes, and less bits to high motion scenes. I'd rather keep the quality the same throughout with CQP, and then CRF on the final encode. Maybe it doesn't matter at a value of 10 for either, but that's my preference.

Mystery

2014-12-07 03:25:08 pm

Well, if you just compensate with a low enough crf factor, there is just going to be more than enough bits available for the encoder of the final encode. I mean, sure, in theory, it sounds like qp would be better from an encoder perspective, but in reality, I very doubt it is so. You could also try messing around with the qcomp factor if you're really worried about the low/fast scene bit allocation ratio.

iWO

2014-12-19 08:31:25 am

laria fresca, vino puro ...

do you know some program that can cut mp4 files with frame accuracy?
I'm using vdub but there are two problems with it - if I wanted to publish on sda I should be able to send the films through net, so uncompressed .avi is not an option and if I compress it (with yua/anri) then I have to choose - either send already cut video and another one uncut or be able to cut it perfectly after compression. I want to avoid double compressing of same material because it takes ages - it's indisputable.

Another problem I have with vdub is, when I cut anything (without recompressing - direct copy) it split it into lots of 2GiB files - is there any way to avoid this behaviour, so it would keep one file instead of tens*2GiB?

Mystery

2014-12-19 09:20:04 am

If you're not going to work with avisynth or avi files (or capture), then virtualdub is a lost cause. You would be better off with avidemux.
That said, you can use an intermediate compression step with handbrake before cutting it by setting keyframes relatively close. Edit with avidemux or use avisynth + vdub. Then send it to yua.
Or, you can just cut the original and compress it using x264vfw using a high crf factor (and a fast present - think veryfast or higher), then mux the audio and video with mkvtoolnix. Then send it to yua.

iWO

2014-12-20 05:57:21 am

laria fresca, vino puro ...

I have nothing to vdub but it splits files into 2GiB chunks, do you know how to prevent it?

Mystery

Edit history:

Mystery: 2014-12-20 06:00:10 am

2014-12-20 05:59:45 am

It's a limitation of the AVI file format, so don't use vdub. There may be some way to change it, but I don't know of any such way.

iWO

2014-12-20 06:03:07 am

laria fresca, vino puro ...

so how else can I precisely cut my work?
and why .avi files produced by fraps are > 2GiB

Mystery

2014-12-20 06:05:26 am

Quote from iWO:

so how else can I precisely cut my work?

I already told you. Don't use vdub.

Quote:

and why .avi files produced by fraps are > 2GiB

Different versions of the avi file format. It's a legacy format so not every programs supports > 2 GB avi files.

iWO

2014-12-20 06:14:53 am

laria fresca, vino puro ...

i'll try avidemux and see how it works

ballofsnow

Edit history:

ballofsnow: 2014-12-20 10:00:36 am

ballofsnow: 2014-12-20 10:00:25 am

2014-12-20 09:59:38 am

I think you need to take a step back and ask yourself why you need to be splicing mp4s and manually adjusting keyframe intervals.

What are you trying to accomplish exactly, and what are your restrictions?

Quote from iWO:

if I wanted to publish on sda I should be able to send the films through net, so uncompressed .avi is not an option and if I compress it (with yua/anri) then I have to choose - either send already cut video and another one uncut or be able to cut it perfectly after compression. I want to avoid double compressing of same material because it takes ages - it's indisputable.

Normally one would keep the source/capture files around for the entirety of the project (at least). When it comes time to submitting a final product you then decide whether to send a single (appended) video (per quality version) or send them in segments. And then based on that decision, use the source files to encode everything in the appropriate manner.

It should be that simple - unless you have some kind of restrictions that you haven't told us yet.

I think you need to take a step back and ask yourself why you need to be splicing mp4s and manually adjusting keyframe intervals.

What are you trying to accomplish exactly, and what are your restrictions?

[quote="iWO"]if I wanted to publish on sda I should be able to send the films through net, so uncompressed .avi is not an option and if I compress it (with yua/anri) then I have to choose - either send already cut video and another one uncut or be able to cut it perfectly after compression. I want to avoid double compressing of same material because it takes ages - it's indisputable.[/quote]

Normally one would keep the source/capture files around for the entirety of the project (at least). When it comes time to submitting a final product you then decide whether to send a single (appended) video (per quality version) or send them in segments. And then based on that decision, use the source files to encode everything in the appropriate manner.

It should be that simple - unless you have some kind of restrictions that you haven't told us yet.

iWO

Edit history:

iWO: 2014-12-23 08:43:14 am

2014-12-22 09:55:25 am

laria fresca, vino puro ...

> What are you trying to accomplish exactly, and what are your restrictions?
a)
it's simple: trying to send approximately 1h40m uncompressed 1024x768 (or at least 800x600) video is bit mad, don't you thinks so?
It's about 4GiB/min and with fraps codec compressed it's still 2GiB/min
that's why I want to send it compressed so it would take 2 or max 4[GiB] instead of 400
b)
I rather to keep it as individual levels, because that's what I actually do - single segment for whole game is way too much and I will have to cut it anyway because slips are inevitable within 100 minutes where in 5-15 it's much more bearable - eventually I'll be able to pull of whole level with acceptable play quality and good time