Widescreen Gaming Forum

Posted: **20 Jan 2009, 01:18**

I've never used Avidemux so I don't know how it works or what audio/video sync. issues you might have. I also don't use Vegas so I can't help you out there.

I do all of my video stuff with Avisynth (with various effects), x264, neroaacenc, mplayer (sometimes) and VirtualDub.

Posted: **20 Jan 2009, 10:24**

I may have to give megui or x264 another shot see if they can work with my plugin or fix the issues I have.

Got HandBrake today!

Wonderfull so far. I had issues with it at first, the video did not have speed issues, audio was in sync but I had some jerkyness or pause in the video usually right when some very fast panning motion was going to happen.

I read up on it in there wiki and they said to fix the frame rate isntead of use same as source, Its supposed to only effect mixed frame rate content but did that and cranked up the B Pyramid number, Motion Estimation numbers, and a few other things and it looks like it resolved it.

HandBrake is not neary as good at giving a max quality file at a low size if you put in a larger than needed target file size. It gave me a file 2x larger than my XVID file.

So now I am experimenting with average bit rate numbers to find a good balance of quality & speed.

Off the top of your head know a good ABR for 1280x720 footage like these HD game videos to where it would appear to the eye the same as lossless?

2000 was way too low

Just did 6000 and its almost there, I think 8000 should be just about right and give me a file probably about 33mb vs the maxed out xvid of 90mb

I'll have to run a test of a target file size in xvid when I found where I like it to see just how much better the h264 is.

Edit: I am happy with ABR of 8000 it made a 40mb file, I ran a target file size test for XVID and it looks the same to me! I know your going to kill me and say its not possible but it does.

So now I am purposely doing a low target file size where the video should be noticeably bad and see how much better the H264 codec can do.

Posted: **21 Jan 2009, 02:41**

I read up on it in there wiki and they said to fix the frame rate isntead of use same as source, Its supposed to only effect mixed frame rate content but did that and cranked up the B Pyramid number, Motion Estimation numbers, and a few other things and it looks like it resolved it.

It depends on the source. If your source is a videogame, then use the same framerate as the source. I.E. If you capture at 30 FPS, make sure you keep it at 30 FPS. If you do the motion blur technique where you capture at 150 or 300 FPS, then you'll use Avisynth to take every 5th or 10th frame (150 / 5 = 30 and 300 / 10 = 30).

The mixed content they refer to has to do with DVDs. NTSC movie DVDs are 29.970 FPS, but drop down to 23.976 FPS for progressive content. Interlaced content stays higher. PAL is simply 25 FPS. You shouldn't mess with the framerate unless you are ripping DVD movies. Getting into that, though, will usually require additional steps. You simply can't convert 23.976 FPS to 25 FPS (or vice versa) and have it be smooth.

HandBrake is not neary as good at giving a max quality file at a low size if you put in a larger than needed target file size. It gave me a file 2x larger than my XVID file.

It's all in the settings. I've never used HandBrake, but according to their website, they link against x264. So the quality is all in the settings still.

So now I am experimenting with average bit rate numbers to find a good balance of quality & speed.

Off the top of your head know a good ABR for 1280x720 footage like these HD game videos to where it would appear to the eye the same as lossless?

I use CRF rather than ABR. ABR will require multiple passes to get the same quality. There are benefits to both, though. ABR will allow you to target a specific filesize. If you want your final filesize to be 200 MB, then you can easily target that with ABR. You will have to make multiple passes for the video to look good. This also requires extra time to encode because of the additional passes.

With CRF, you target a specific quality instead (CRF = Constant Rate Factor). You won't know the final filesize of the target, but you only need to make one pass to get quality that is 99.9% on par with ABR.

Typical settings that are used for bitrate settings varies on the resolution. For great looking 720p content, you'll want to target the 10-12MB range. And for 1080p, you'll want to target 12-15MB. This typically isn't ideal for the internet. YouTube is just going to cut the bitrate down to 600KB or so. If you stream the file yourself or host it on some higher-quality streaming site, then it will be more worth it.

When making my videos, I usually set CRF between 22 and 25. The lower the number, the better the quality. Naturally, encoding time will increase, as well as the filesize. There's a tradeoff for everything.

Edit: I am happy with ABR of 8000 it made a 40mb file, I ran a target file size test for XVID and it looks the same to me! I know your going to kill me and say its not possible but it does.

It all depends on your settings. If you're using maxed out settings with XVID, and terrible settings for H.264, then XVID might definitely look better. You'll really need to play around with settings.

Here's an example of reasonable/mid-quality settings with x264:
--bframes 3 --b-pyramid --ref 4 --crf 25 --weightb --subme 7 --8x8dct

Here's an example of unreasonable/insane-quality settings with x264:
--bframes 16 --b-pyramid --direct auto --ref 16 --crf 24 --partitions all --weightb --me tesa --subme 9 --mixed-refs --8x8dct --no-fast-pskip --no-dct-decimate --trellis 2 --qpmin 0

Posted: **21 Jan 2009, 07:00**

I was much closer to insane settings than I was lax settings.

Also you just said something that goes against what I have been taught/read.

I was told a 2 pass method gives better quality than a single pass method, Thus why target file size and ABR can do better with a smaller file size, this is also why probably they added a way to force a 2 pass on CBR just recently to Avidemux.

The first pass is to just analyze the file and the 2nd to encode it. I do not mind 2 pass, Im churning these out with a 3.6ghz q6600 so the first pass takes very little time.

I will have to check out what you say and see how it goes though. I think handbrake does not use a quantizier or % of quality like some other programs it just uses a bit rate setting. However its very cool in that all it really does is generate the code for you so I can manually add in any setting I want that the GUI does not populate.

Off the top of my head since handbrake is kind of teaching me some of the code this is about what I used.

-bframes 9 -b-pyramid -ref 9 --subme 9 -mixed-refs me-range 32 me-umh trelis-0 Something along those lines. I do not use no dct decimate as it makes the file larger so if your shooting for a low file size it would make the quality worse in most of what I read its only recommended if you find artifacts from it. Using a CRF like you do it would not hurt it would just make the file larger.

trellis 2... I never mess with trellis I keep it at stock and I cant really find hard evidence on what good/harm it will do to raise it.

cqm - I hear this can make one of the largest impacts of all I just used the default but I am going to try out sharktooths matrix.

Posted: **21 Jan 2009, 08:10**

I was told a 2 pass method gives better quality than a single pass method, Thus why target file size and ABR can do better with a smaller file size, this is also why probably they added a way to force a 2 pass on CBR just recently to Avidemux.

If you're using ABR, then like I said before, you need to use 2 passes. CRF is not ABR, though, so it doesn't need 2 passes. It does things differently.

The reason why you need two passes with ABR is common knowledge. The first pass analyzes the frames for bit distribution, and the second pass takes that information and uses it.

With CRF, though, each frame is analyzed and a constant rate factor is applied to it. This means that you have a constant quality factor.

I'll quote some information from the link below.

--qp

The first of three possible ratecontrol methods. Set x264 to encode the movie in Constant Quantizer mode. The number you give here specifies the P frame quantizer. The quantizer used for I and B-frames is derived from ipratio and pbratio. CQ mode targets a certain quantizer, which means final filesize is not known (although it can be reasonably accurately estimated with some methods). A setting of 0 will produce lossless output. qp produces larger files than crf for the same visual quality. qp mode also disables adaptive quantization, since by definition "constant quantizer" implies no adaptive quantization.

--bitrate

The second of three ratecontrol methods. Encode the video in target bitrate mode. x264 will attempt to encode the video to target the given bitrate as the final average. The parameter given is the bitrate in kilobits/sec. (8bits = 1byte and so on). This setting is usually used in conjunction with pass for two pass encoding. Target bitrate mode means the final filesize is known, but the final quality is not (although it's possible to estimate with a reasonable degree of accuracy). It is generally not recommended to use bitrate mode without 2pass encoding.

--crf

The final ratecontrol method: Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain 'quality'. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. It is not extremely exact, but reasonably close (and will average out to be accurate over a large number of videos).
CRF achieves this by reducing the quality of less important frames. In this case, frames in complex or high-motion scenes, where quality is more expensive (in terms of bits) and/or less visible, will have their quantizer increased. The bits saved in cuts like this are redistributed to frames where they will be more effective. CRF mode gives almost exactly equivalent quality to 2pass at the same bitrate; the difference is that you cannot choose the output bitrate.

As you can see, CRF will give almost exactly (I'd say 99.9%) the quality of using bitrate, but you only need to do one pass, and you can be guaranteed the quality. With bitrate, you'll need to play around with the right bitrate to get the quality you want. With CRF, you can set it to 22 or 25 and get a specific quality. It's much better to use CRF.

Sure, you may not know the final filesize, but you can be sure of the quality. For me, it's all about the quality. I don't need to specify a bitrate.

Check out this for descriptions of the settings:
http://mewiki.project357.com/wiki/X264_Settings

Posted: **21 Jan 2009, 08:32**

cool so whats your recommended CRF? Im thinking of giving 20 a shot and tunring on some of the more advanced options to see what I come up with.

And handbrake does have a crf setting looks like I just have to use a different preset mode.

I may be on my way to writing a good guide soon if I keep learning like i am now.

So do you have any take on custom matrices?

I was going to try out the high quality one from here: http://forum.doom9.org/showthread.php?p=887125#post887125

Posted: **21 Jan 2009, 12:56**

20 is actually pretty high. A good range is 22-25. 18 is virtually indistinguishable from any lower setting to the eye.

As for the matrix settings, I use Avisynth for all of my alterations. Seriously, you need to look into Avisynth. It's probably one of the greatest things for video editing. It's a scripting language with a ton of different plugins.

Example script:

a = BlankClip(length=15, width=1920, height=1080, pixel_type="YV12", fps=30, color=$000000).KillAudio()
b = RawSource("cod4_jump_1080p300.y4m").AssumeFPS(300)
c = BlankClip(length=15, width=1920, height=1080, pixel_type="YV12", fps=30, color=$000000).KillAudio()

bv = b.MVAnalyse(isb=true, truemotion=true, blksize=16, blksizeV=16, overlap=2, pel=2, search=3, idx=1)
fv = b.MVAnalyse(isb=false, truemotion=true, blksize=16, blksizeV=16, overlap=2, pel=2, search=3, idx=1)

b = b.MVFlowBlur(bv, fv, blur=100).TemporalSoften(1, 255, 255, 50, 2)

b = b.SelectEvery(10, 1)
b = b.FadeIn(15)
b = b.FadeOut(15)

return (a + b + c).AddGrain(12, 0, 0)

This will add a fade-in to the beginning and a fade-out to the end. It will then analyze and calculate motion blur, and do temporal softening. Once the blurring is done, it will choose every 10th frame (drop it down to 30 FPS). Once everything is done, it will add some film grain to the scene.

There are so many other things you can do with Avisynth.

Posted: **21 Jan 2009, 22:37**

Im really making great progress with HandBrake. I got over the big obstical. There program uses CRF but it does not use traditional CRF numbers, instead there GUI uses a % of quality slider.

The code it generates is -q .xx where xx is the %

I tried -crf and got invalid syntax. I found out via google and much reading that they use a formula.

(51-CRF)/51 = %

So I made a handy spreadsheet to do it and now I can easily use what I want.

So I used a CRF 21.5 ish and thats 57% and it gave me almost exactly the same file size as my 8000kb/s ABR file.

But now I can get it done in one pass like you said. Seems the experts at Doom9 still say you can pack a bit more quality in a ABR file, so those who are extremly picky like to run a CRF pass to see what the ABR is and then do a 2nd pass at that ABR instead of actually using CRF for the final encode.

I cant see any difference, so a single pass CRF is fine for what I am doing.

Posted: **22 Jan 2009, 02:48**

The difference in quality is impossible to tell with your eyes. And when using ABR, you don't know what quality you're going to get with every frame. This is why you need to do two passes. Even then, you're still targeting a specific filesize and not quality. It's just better to use CRF.

I have no idea what arguments HandBrake uses. I use x264 directly. This way I can always be using the latest x264 (changes are pretty frequent), and I can use my own 64-bit version. The 64-bit version of x264 is 12-15% faster than the 32-bit version (which is probably what HandBrake comes with). You can use avs2yuv to pipe an avs script into 64-bit x264.

Really, you'll just need to play around with all of this stuff yourself. :)

My typical process:

Fire up game
Dump frames at 150 or 300 FPS
Create an Avisynth script with ImageSource(), AssumeFPS(), and ConvertToYV12()
Use mplayer to play the avs script and dump it to a yuv4mpeg (y4m) file
Use RawSource() to load the y4m
Do anything else I want with the clip in Avisynth
Use avs2yuv to pipe the script to 64-bit x264 and encode the video
Import the .264 file into mkvmerge, set settings, and save as a .mkv file
Done

Doing audio is a separate process:

Use a song or dump the audio from the game
Encode the audio to AAC using neroaacenc
neroaacenc saves it as a mp4, so use mp4box to extract the raw AAC track
Delete the mp4 file since you have the AAC file
Import the .aac file into mkvmerge, set settings, and save the .mkv file

You can open the existing .mkv file you have, or wait until both processes are complete and import the .264 and .aac file at the same time.

I use these methods because I can specifying every little argument for each program along the way to fine-tune everything. I just have far more control over the process. I can use other programs if I want, and even insert different steps along the way. I can understand the ease of using a single program, but then you don't learn much, if there are problems, you don't know exactly where the process failed, etc.

Posted: **22 Jan 2009, 07:59**

Yeah I read into how to compile your own 64bit version its supposed to be about 10% faster but offer less options if you use the 64bit version.

Using the pipe method I am not sure.

Man 150 or 300fps game files? Mine are massive at only 30fps, I wonder if my computer would explode trying to write 5 times the amount of data while recording at that rate, also since you cut it down to probably 30fps anyways is there a real noticeable advantage?

Also I did my research on trellis like I said. I have multiple sources that say Trellis is not a good idea for CRF or any other kind of constant quantizer as it can give odd and unpredictable results. If anything use Trellis 1 they say.

I ran a test on my file Trellis-0 47mb file

Trellis-2 41mb file that I think looked slightly worse, but it could be my imagination. That a big difference in file size though almost 1/5th other options do not make nearly the same impact other than increasing the CRF by a good amount.

So here is a question for you, the command to make the video more web compatible so that it can download in progressive scan mode. I know this helps if you host your file directly but do you think this aids or worsens things for youtube? I cant seem to find the answer on google.

I also gave the custom matrices a try, it works magic I think. Was a pain to find out how to find the *nix path my file though.

I have enough under my belt to write a good easy to follow guide for novices to use to make great H264 files with HandBrake.

I much look forward to your X264 guide though as its all command line based I dont know how to use it, or even how to run it.

Are these native x64 builds here any good? - http://forum.doom9.org/showthread.php?t=89979 or do you think making your own or using the pipeline method is better.

Posted: **22 Jan 2009, 11:59**

Yeah I read into how to compile your own 64bit version its supposed to be about 10% faster but offer less options if you use the 64bit version.

You don't lose any options with a 64-bit x264. You have the same arguments and capabilities as before. The only area that really suffers is when dealing with Avisynth. You need a 64-bit Avisynth to use with a 64-bit x264. While 64-bit builds of Avisynth do exist, almost all of the useful plugins are 32-bit only. This is why you use the avs2yuv pipe. The pipe basically reads the Avisynth script and pipes it to x264. This lets you use 32-bit Avisynth with 64-bit x264. There is some performance loss, but it is still faster than using a 32-bit x264.

Also, if you compile it with ICC instead of GCC, you can gain even more performance.

Man 150 or 300fps game files? Mine are massive at only 30fps, I wonder if my computer would explode trying to write 5 times the amount of data while recording at that rate, also since you cut it down to probably 30fps anyways is there a real noticeable advantage?

Like I said, you capture at a high framerate to calculate the motion blur. The higher the FPS, the more accurate and better looking the motion blur is. There is definitely a visual difference on the final output.

Also I did my research on trellis like I said. I have multiple sources that say Trellis is not a good idea for CRF or any other kind of constant quantizer as it can give odd and unpredictable results. If anything use Trellis 1 they say.

If you want maximum quality, you should use the line I posted before. Using trellis 2 will give you better results. Your sources might be outdated or inaccurate. Keep in mind that other arguments affect it, as well. However, for maximum quality, the line I provided is really as far as you want to take it.

So here is a question for you, the command to make the video more web compatible so that it can download in progressive scan mode. I know this helps if you host your file directly but do you think this aids or worsens things for youtube? I cant seem to find the answer on google.

Progressive as opposed to interlaced? Always go progressive. Games are recorded in a progressive manner, so leave them that way. Making them interlaced will only make playback worse. If you have interlaced content, deinterlace it.

Are these native x64 builds here any good? - http://forum.doom9.org/showthread.php?t=89979 or do you think making your own or using the pipeline method is better.

If you want to use someone else's builds, then use either of these:
http://x264.nl/
http://techouse.project357.com/

I prefer to compile my own for Windows using ICC. If you use Linux and want to use Avisynth, then you'll need to use Wine and pipe that to x264.

Posted: **22 Jan 2009, 14:14**

Not progressive scan, it is some method of streaming the file.

I think it means it can stream and play rather than have to download completely first before it can play not sure.

The Trellis stuff is new, and its people that make the programs on Doom9 for some of it. I cant see how it was a higher quality with a lower file size and I think it looked worse.

I'll try your exact config though to see what it comes out like.

Edit: man its slow :P

I actually added one thing that I know is slowing it down I put Merange of 32 wich is what I use for umh, but for tesa the default of 16 would have probably been fine and much faster.

The encode finished with a file of 25mb, a bit smaller than my previous files (again trellis 2 at work mostly I think) I can not see any quality improvement but I do not have a sharp eye and its just a fraps capture. With some true HD footage it would make more of a difference I think.

I'll have to see what happens if I try to fraps at 150fps, I do not think it will work well, my games do not even run that fast.

If it works, do I just drop the framerate down when I encode it or is there some special filter you are running in avisynth for an effect?

Posted: **23 Jan 2009, 02:50**

Not progressive scan, it is some method of streaming the file.

I think it means it can stream and play rather than have to download completely first before it can play not sure.

There's different things that can affect streaming, but I wouldn't call it progressive. ;) The container format, various atoms, etc. can affect streaming and compatibility. However, if you just upload videos to YouTube, other hosting sites, or host it yourself, you don't need to do anything special. If you're going to stream it yourself, use a MP4 container because I don't think JW FLV Media Player supports MKV.

The Trellis stuff is new, and its people that make the programs on Doom9 for some of it. I cant see how it was a higher quality with a lower file size and I think it looked worse.

I actually hang out with the developers of x264 directly and deal with them on a daily basis. I've seen many people come and ask questions about it and the answers are usually pretty clear. :)

I actually added one thing that I know is slowing it down I put Merange of 32 wich is what I use for umh, but for tesa the default of 16 would have probably been fine and much faster.

16 is actually the default for any setting. tesa will provide a higher quality than umh, but it's a lot slower. merange will greatly slow down your encode time, especially with tesa. Using umh and the default of 16 is more than fine. Switching to tesa can provide better quality, but there's really no need to raise merange.

The encode finished with a file of 25mb, a bit smaller than my previous files (again trellis 2 at work mostly I think) I can not see any quality improvement but I do not have a sharp eye and its just a fraps capture. With some true HD footage it would make more of a difference I think.

I'm sure some of it has to do with you being able to know exactly what to look for. It's like MP3. I can't stand the MP3 format because I can easily hear the defects in it over something like AAC (far superior format). This is because I know just what to listen for. Likewise, with videos, I know just what to look for, as well.

I'll have to see what happens if I try to fraps at 150fps, I do not think it will work well, my games do not even run that fast.

If it works, do I just drop the framerate down when I encode it or is there some special filter you are running in avisynth for an effect?

As I said before, it depends on if the game has a built-in method of dumping frames. Call of Duty, Counter-Strike, World in Conflict, Team Fortress 2, and several other games have built-in methods of recording. Using these methods, the game doesn't actually run at full speed. It will render each frame slowly. What you do is record a demo, and then play it back later and dump the frames of it.

The script I used I showed earlier. You use ImageSource() to load the images in at a specified framerate. You calculate the motion blur from this and then you cut it down to 30 FPS (or others if you want). It should be outputting 30 FPS before you encode it.

Posted: **23 Jan 2009, 07:09**

Cool thanks for all the help dopefish.

Im doing pretty well now, todays experiment was with psy-rd and psy-trellis. :P

The first time I coded at all with HandBrake I had some jumpy frame rate issues associated with very fast motion when I panned my view. I think when I raised the merange to 32 thats what fixed it. So not sure but I think there is some merit in raising the merange up for very high motion stuff.

I think I still have my samples that show this behavior. UMH is pretty fast even with the higher range so I do not mind, but yeah running a 32 TESA is like shooting yourself in the face, twice.

Posted: **23 Jan 2009, 07:39**

Cool thanks for all the help dopefish.

No problem.

Im doing pretty well now, todays experiment was with psy-rd and psy-trellis. :P

psy-rdo + trellis = greatness

I actually have a bunch of screenshots from when they first implemented psy-rdo and I was comparing it against fgo. fgo was better to preserve noise at high bitrates, but psy-rdo is good for everything else.

The first time I coded at all with HandBrake I had some jumpy frame rate issues associated with very fast motion when I panned my view. I think when I raised the merange to 32 thats what fixed it. So not sure but I think there is some merit in raising the merange up for very high motion stuff.

It could help out for sure. Using tesa with the default of 16 will probably be better than umh with a range of 32.

I think I still have my samples that show this behavior. UMH is pretty fast even with the higher range so I do not mind, but yeah running a 32 TESA is like shooting yourself in the face, twice.

If you have decent hosting, just host a file yourself with JW FLV player. Otherwise, YouTube, NoobFlicks, WeGame, etc. will just hurt the quality. If you upload it to NoobFlicks, they actually keep the original file so people can optionally download that.

Posted: **24 Jan 2009, 16:19**

Hmm I wanted to start my guide but I found one small problem. HandBrake can not open FRAPS files. The ones I had used before were first opened and edited in Sony Vegas and rendered out as HuffYUV.AVI files.

So I need to find an easy way to make the files work with HB. Im thinking Avisynth is going to be the way to do this with a free tool.

Have any hints for me? Avisynth can work as a frame server cant it? or is that DGindex that I am thinking of.

Edit: nevermind it was VirtualDub I was thinking of and it did not work. But VirtualDub would make an easy to use free program that can process the file between the FRAPS original and something HB can compress.

Your supposed to be able to use X264 from VirtualDub according to this: http://teek.info/guides/video/x264encode.html

However I do not have it as an option in my drop down.

Posted: **24 Jan 2009, 19:11**

You can use DirectShowSource() to open the FRAPS video with Avisynth. FFmpegSource() might work, too.

Posted: **24 Jan 2009, 20:09**

You can use DirectShowSource() to open the FRAPS video with Avisynth. FFmpegSource() might work, too.

Yep, I was using

AVISource("C:FrapsMoviesMirrorsEdgeOpening.avi", Audio=False)
ConvertToYV12()

as per what Lord Mulder told me to do to get the file to work in Avidemux, it has a built in proxy function to work with Avisynth and it worked as far as opening the file but then of course I have no audio, also when I rendered the file I still had the issues I have been having with Avidemux where the file starts off too fast for a few seconds.

So I have been trying all day to find a way to use that same functionality with HB. I have tried a few different frame serving methods with VirtualDub, and tried to use that script above with HB.

I'll try directshowsource and see if it works. I was told not to use that unless I had too.

Edit: not working both Avidemux & HB wont open my .avs file with the DirectShowSource script.

Edit2: not sure how Avidemux does it with the proxy but the HB guys told me you can not use a frame server with the program due to the fact that it requires some kind of platform specific thing that it does not use.

so I am trying to slowly get to the point where I can do things the way you do.

Im looking at this part of things:

Create an Avisynth script with ImageSource(), AssumeFPS(), and ConvertToYV12()
Use mplayer to play the avs script and dump it to a yuv4mpeg (y4m) file
Use RawSource() to load the y4m
Do anything else I want with the clip in Avisynth
Use avs2yuv to pipe the script to 64-bit x264 and encode the video
Import the .264 file into mkvmerge, set settings, and save as a .mkv file
Done

For now I want to keep it simple so no need for filters, and I wont be doing the y4m convert since I have no massive 300fps file like you do (tho small question, assumefps to drop it to 30fps right, but it changes the length of the clip, so how do you get your sound to match again?)

I have been using Avisynth a bit now. I did not even know how to use it since its command based but after I found out all you have to do is make a text file and save it as a .avs its been easy. So to experment I make a script and open it with media player classic.

Still its only a middle man, say I load up my FRAPS file with this code

Code: Select all

AVISource(&quot;C:FrapsMoviesMirrorsEdgeOpening.avi&quot;, Audio=False)

   ConvertToYV12()

It opens in my player but not my encoding programs...

So I want to send it off to x264 directly like you, x264 is also command line based right? So how do you run it without a GUI?

As for your final step of MKVmerge I heard thats a good one and better than its MP4 equivalent. Have any reason you prefer MKV to MP4?? For what I am doing not sure if it matters ether should work.

Just a few more steps to complete the process and once I have the basics I should just be able to experiment and use guides off google to get better.

Posted: **25 Jan 2009, 08:07**

AVISource("C:FrapsMoviesMirrorsEdgeOpening.avi", Audio=False)
ConvertToYV12()

as per what Lord Mulder told me to do to get the file to work in Avidemux, it has a built in proxy function to work with Avisynth and it worked as far as opening the file but then of course I have no audio, also when I rendered the file I still had the issues I have been having with Avidemux where the file starts off too fast for a few seconds.

You can use AVISource(), as well. There are many ways to open it.

I always work with audio outside of any program. It's often faster to work with that way, too. So you dump the video to one file, and you dump the audio to another. Then you mux them together later. It's a typical process.

I've never had any experience where the file starts out too fast. If it really bothers you, just use Trim() to cut off the beginning part.

For now I want to keep it simple so no need for filters, and I wont be doing the y4m convert since I have no massive 300fps file like you do (tho small question, assumefps to drop it to 30fps right, but it changes the length of the clip, so how do you get your sound to match again?)

Converting it to y4m really only has some benefits. If you want to apply effects to the video, they can slow down the processing immensely. If you're going to encode it multiple times, like one for 1080p and one for 720p, then you're really going to hurt your encoding time since it's going to apply those effects both times. It would be more beneficial to make one pass with the effects and output the video to y4m, huffyuv, etc. Now you have your high quality, lossless source with the effects already applied. With y4m, you can encode the file directly with x264 (either 32-bit or 64-bit). To resize the video, simply create a simple avs script with LanczosResize() in it and either use that avs file directly with 32-bit x264 or pipe it to 64-bit x264 with avs2yuv (still quicker than using 32-bit x264 directly).

As for the AssumeFPS(), you use this on your source. If your source video is 300 FPS, then when you load the video in you use AssumeFPS(300). When you cut it down, you don't specify another AssumeFPS(). You use SelectEvery() to pull every 10th frame, which automatically drops it down to 30 FPS. This causes absolutely zero issues with audio sync. The audio doesn't know anything about the FPS of the video, nor does it need to. The audio is going to play over 1 second, so whether there are 30 FPS or 300 FPS in that one second, it won't affect the audio. It won't change the length of the clip at all.

Still its only a middle man, say I load up my FRAPS file with this code

...

It opens in my player but not my encoding programs...

Yeah, you can play it directly to check any effects you apply, how it will look, etc. If you want to use it as a source to encode with, you can almost always just open the .avs file from inside the program.

So I want to send it off to x264 directly like you, x264 is also command line based right? So how do you run it without a GUI?

Just run: x264 -o outputfile.264 inputfile.avs

If you're using a 64-bit x264, then run:
avs2yuv -raw "inputfile.avs" - | x264 -o outputfile.264 - 1920x1080

Replace 1920x1080 with whatever resolution the video is, make note of the hyphens, and replace with whatever options you want.

This will encode to a raw H.264 bitstream that you will import into a MP4 or MKV container.

As for your final step of MKVmerge I heard thats a good one and better than its MP4 equivalent. Have any reason you prefer MKV to MP4?? For what I am doing not sure if it matters ether should work.

MKV has a smaller overhead than MP4, it supports far more features, maintains better audio/video sync., supports chapters, etc., etc., etc. There are a lot of good reasons to use it.

The only drawback I've seen so far is that there doesn't seem to be any players that support streaming it online yet. (I haven't looked in months). You can easily pull the raw video and audio out of MP4 and MKV files and switch containers that they use. So it's not like if you use MKV that all hope is lost. This makes it easy for me when I do want to stream something online. I use MKV for everything I have, and when I want to stream it, I simply extract the video and audio out of the MKV file and remux it a MP4 for online streaming.

Posted: **25 Jan 2009, 12:17**

Cool info yet again.

Considering the nature of my problem I ran into yet another program today. StaxRip, this one is interesting its like the mix of Avidemux because it has a player/editor/filters and HandBrake because its simple to use.

Now whats interesting about this one is that it uses Avisynth for input, It also uses MKVmerge, MP4Box, and those others too. So its like the auto version of what you do almost.

So it generates logs and shows you the script of what it does and thats making it easy for me to learn the script for the programs.

Only issue I have with it is you cant edit the script directly in the gui like HandBrake can. So it came with an older version of x264 for example and back then the subme highest setting was 7, and also psy-rd did not exsist. There is a window where you can add code, but adding subme 9 made it still default to the gui's 7, also psy-rd failed totally due to the older version of x264.

No biggie though, I just swaped out the x264 file the program uses, it has its own local version in its program folder.

To get around the subme & psy-rd issues both of them were fixed in the latest beta of the program that uses a newer x264.exe. However I noticed how it keeps allll the extra files after the encode.

I have a .wav file from the demuxing, two .avs scripts one for the input and the 2nd I guess for all your filters before the encoding, I did not see the x264 script but did not look super close yet.

So my idea is, if the gui wont let me edit it, if it produces the script before the action starts I could just go edit the scripts and have a full auto semi manual way of doing things. It would make a great learning tool.

Last question for tonight.

Code: Select all

Just run: x264 &lt;options I listed before&gt; -o outputfile.264 inputfile.avs

When I have multiple x264.exe like I have now dont I need to specify a path to the exe or something for that to work?

Widescreen Gaming Forum

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos

Guide: YouTube HD 720P Videos