I had a couple of tutorials a while back when I was streaming SC2 and other games almost daily to help other users I just updated these tutorials for 2013.
You can still make use of some older tutorials like VAC tuts and things but today I am focusing on some video editing information.
You do not need to be an XSplit user to make use of these tutorials, just if you have a FLV you want to "convert" but I have paid special attention to a need XSplit users have because the FLV videos have VFR (Variable Frame Rate) and thus many other conversion methods will result in a audio/video sync issue.
What is special about my techniques?
> 100% Free Programs (real programs not some spyware infected crapware) > 100% Quality Preserved from the original file. > No Re-Encoding and thus no time wasted with the computer being busy. > Files are muxed with time stamps and thus 100% audio & video sync. > Split large files into smaller shorter clips without having to use a video editor.
If you just want to split files or learn about the VFR issue first watch this tutorial.
Convert FLV to MKV
If you want to edit your videos in a popular editor like Sony Vegas or Adobe Premiere use this tutorial.
Convert FLV to MP4
If anybody has comments/questions post them as comments on the videos as I do not really frequent the TL forums often anymore and it may help other viewers.
FLV, MP4, MKV these are just video containers. So basically it's about remuxing the video and audio content from one container into another container.
Good tutorial on using mkvtoolnix to remux the file. Actually there are many other free video editing software with more user friendly GUI, like AviDemux, XMedia Recode. Though they are designed for more sophisticated video processing tasks, you can simply choose "video-copy", "audio-copy" to remux everything from original video files to another container.
On January 15 2013 13:48 eleaf wrote: FLV, MP4, MKV these are just video containers. So basically it's about remuxing the video and audio content from one container into another container.
Good tutorial on using mkvtoolnix to remux the file. Actually there are many other free video editing software with more user friendly GUI, like AviDemux, XMedia Recode. Though they are designed for more sophisticated video processing tasks, you can simply choose "video-copy", "audio-copy" to remux everything from original video files to another container.
Yes I used to be a avid user of AviDemux but like I said these tutorials are focused on one particular problem XSplit users have with videos being VFR just muxing with other programs always results in a fixed frame rate and sync errors.
I updated the tutorials to these as both tuts here incorporate time codes.
My fav encoding program is MeGUI since at one point AviDemux stopped working for me (was years ago)
On January 15 2013 15:10 Kavik wrote: You can also just go into the settings for your Local Recording "channel" and set the file type to MP4.
edit: This is still useful stuff to know, not trying to take anything away from the tutorial as a way to convert FLV into MP4 or MKV in general.
I myself stream live and just let XSplit save a local copy, when doing this it can only be in FLV.
If your not streaming you can indeed do a local copy in MP4 but in that case if I was not streaming I would just capture in much higher quality using FRAPS or similar and not use XSplit I think most others would do the same.
If you try to stream and do a local copy at the same time, that is quite a task. Even with "Very Fast" as the preset and my 2600K overclocked to 4.8ghz most games will get severe lag and the cpu will reach 100% load because its encoding the stream, encoding the local copy, and playing the game all at the same time.
Is that really how it works? I don't see why it would need to encode two copies-- I always thought it just takes the data you're uploading and basically saves/streams a copy directly to your hard drive (which explains the FLV format), which might add an extra potential point of slowdown if your hard drive can't keep up with the amount of data being produced (or maybe the software can queue it up indefinitely? I don't really know).
On January 15 2013 21:11 z0rz wrote: Is that really how it works? I don't see why it would need to encode two copies-- I always thought it just takes the data you're uploading and basically saves/streams a copy directly to your hard drive (which explains the FLV format), which might add an extra potential point of slowdown if your hard drive can't keep up with the amount of data being produced (or maybe the software can queue it up indefinitely? I don't really know).
Correct me if I'm wrong :D
Yes its how it works.
If you want to stream to say Justin.TV and go into your streaming options for that broadcast you can enable "save a local copy" and it will save a copy of your stream and this file is FLV and ONLY FLV.
If you do not stream to a live site and instead use the broadcast option for "Local Recording" you can save a MP4 or FLV (configured independently than "save a local copy")
But it will act as another "stream" and requires a total separate encoding if your doing that and your Twitch.TV stream at the same time. If your not streaming, why not use one of the many local game capture software for near losless quality and then just edit/encode later as needed for more quality and better game performance.
Right, I'm pretty sure that's WHY you can only save a copy in FLV format while you're streaming-- that's the only format Justin/Twitch.tv will accept. You are building the file realtime and uploading it directly to Justin/Twitch servers in FLV format so they can use it immediately without any conversion. The separate encoding would make sense if you were saving a different format than the one you were streaming.
In fact, I recently ran some test streams on my old Q6600 PC and had XSplit save the files. I don't think there's ANY way a Q6600 can handle *two* 720p encoding tasks while also playing SC2.
Could you make a tutorial about cutting vods and joining segments back to a single file? Basicly simulating cutting off adbreaks or afk parts of a broadcast to make a youtube ready video file. I know how this is done with VirtualDub and ffmpeg. But having a tutorial out there would be great for some people.
Hi guys, Just wanted to clarify this a bit. Hope that's alright
On January 15 2013 16:11 ViciousXUSMC wrote: I myself stream live and just let XSplit save a local copy, when doing this it can only be in FLV.
Yes, FLV is the only format for live streaming atm. The option to 'save a local copy' in the live stream settings is designed to save an identical copy of what is being livestreamed, hence the FLV format is also the only option. The advantage of using this setting, is that it's virtually free, since we're writing the livestream to the harddrive, it is not being double encoded.
On January 15 2013 16:11 ViciousXUSMC wrote: If your not streaming you can indeed do a local copy in MP4
To clarify, here "local copy" is a reference to 'Local Recording' which basically does the same as a live stream but stores it locally (only).
On January 15 2013 16:11 ViciousXUSMC wrote: but in that case if I was not streaming I would just capture in much higher quality using FRAPS or similar and not use XSplit I think most others would do the same.
XSplit or any other software using x264 cannot do lossless recording, but I would argue that most people would not be able to see any difference between a proper x264 recording and a lossless fraps. It's more a matter of what you prefer, rather than 'always do this'. Fraps is easy on the cpu but hard on the hard drive, and x264 is the opposite. In some cases it would make a lot of sense to record in x264 and use the cpu to end up with a smaller file recording. Please try a 'maxed out' Local Recording (unlimited bitrate, custom CRF, etc) and compare it visually to that of Fraps. I think most would not be able to tell the difference. As stated, use what makes sense in your work flow.
On January 15 2013 16:11 ViciousXUSMC wrote: If you try to stream and do a local copy at the same time, that is quite a task. Even with "Very Fast" as the preset and my 2600K overclocked to 4.8ghz most games will get severe lag and the cpu will reach 100% load because its encoding the stream, encoding the local copy, and playing the game all at the same time.
This is referred to as dual streaming, or essentially one live stream and one local recording at the same time, hence the double encoding and load on the cpu. With this scenario, you can stream in one quality (bitrate and/or resolution) while recording at higher bitrate/quality locally. This is only recommended if you have very good hardware or a dual computer setup.
On January 15 2013 21:11 z0rz wrote: Is that really how it works? I don't see why it would need to encode two copies-- I always thought it just takes the data you're uploading and basically saves/streams a copy directly to your hard drive (which explains the FLV format),[...]
This post is why I wanted to clarify the above. ViciousXUSMC was describing two scenarios. One where the local copy saved is simply copied from the live stream, and one where there's two streams at the same time. Local copy is what you describe in the above quote.
On January 15 2013 21:11 z0rz wrote: which might add an extra potential point of slowdown if your hard drive can't keep up with the amount of data being produced (or maybe the software can queue it up indefinitely? I don't really know). Correct me if I'm wrong :D
You're not . Your next post is also correct, but there was potential for some misunderstanding in the past posts between you and ViciousXUSMC .
I want to shed some light on the hard drive referral too. Sometimes people compare the work load of XSplit's local recording to that of Fraps. Fraps is lossless/uncompressed video which means the file sizes are really big, but the the upside is that it doesn't require a lot of cpu calculations, so overall they just stress the hard drive (though doing that costs a little bit of cpu cycles). When XSplit save files in x264 format it's compressed and this means the file sizes are (much) smaller but they cost a lot more cpu to generate. A typical hard drive can easily write 50 megabyte per second. When you live stream you typically do so at bitrates of 500-3000 kbps which is 62,5 to 375 kilobytes (forgetting the 1024 denotation/conversion, this is ~0,0625 to 0,375 megabyte) per second. No hard drive should be even moderately stressed by saving a x264 stream.
EPT
