Author Topic: Tutorial: Matroska x264 Encoding 2.3  (Read 53227 times)

0 Members and 1 Guest are viewing this topic.

Offline Daffy

  • V.I.P. Member
  • Posts: 13506
  • WH & NU Founder
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #225 on: August 18, 2011, 12:56:25 AM »
I have serious doubts about that, H.264 (also known as MPEG4-Part10) is a compilation of video compression techniques and H.264 without a codec is "RAW'er" than video compressed by x264 which is a codec based on these video compression techniques and a collection of the parameters it can and should offer you.
There's a reason BluRay's use H.264 at 30mbps rather than x264 as it's less compressed and therefore less has to be decompressed which takes up more space but is still easier on the decoder.

I chose to use MKV instead of MP4 because, yes they're but containers but MP4 is a commercial one and thus a lot more limited as it for instance won't accept FLAC audio and it therefore has more restrictions that are problematic for editors.
Also CRF (Constant Rate Factor) is VBR, except you're telling the codec what quality you're after rather than having to input a guessed bitrate which means it'll be far more accurate in terms of what your standards are.
The codec uses variable bitrates throughout the video and it's more hand-tailored for it.

Although I'm for discussions like this, please refrain from making assumptions like that based on nothing next time, I don't spend hours and hours making a tutorial only to have it doubted without reasonable reasons as to why, if you can't show me a frame-by-frame comparison with the same bitrate and/or similar settings to strengthen what you're suggesting is better, then don't bother.

Offline VaNilla

  • next week m9
  • Veteran Member
  • Posts: 3809
    • View Profile
    • YouTube
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #226 on: August 18, 2011, 07:17:29 AM »
I have serious doubts about that, H.264 (also known as MPEG4-Part10) is a compilation of video compression techniques and H.264 without a codec is "RAW'er" than video compressed by x264 which is a codec based on these video compression techniques and a collection of the parameters it can and should offer you.
There's a reason BluRay's use H.264 at 50mbps* rather than x264 as it's less compressed and therefore less has to be decompressed which takes up more space but is still easier on the decoder.

X.264 is a program designed to encode H.264, I don't see your point. The reason Blu Ray discs are encoded at 30-50mpbs is that it looks a lot better, this is nothing to do with being easier on the decoder as far as I'm aware. This is the same reason you see news programs encoded as low as 15mbps when there is a lack of motion, and up to 50mpbs in sports; nothing to do with decoding. Maybe I've mis-understood the way you're distinguishing X.264 to H.264, because X.264 isn't a codec as you seem to be half suggesting.

I chose to use MKV instead of MP4 because, yes they're but containers but MP4 is a commercial one and thus a lot more limited as it for instance won't accept FLAC audio and it therefore has more restrictions that are problematic for editors.

It's not worth using FLAC audio, most people watching your videos will watch them on YouTube, where audio is recompressed anyway. And most people downloading your videos wont have the hardware to hear a huge difference between AAC vs FLAC; most wont care either.

Also CRF (Constant Rate Factor) is VBR, except you're telling the codec what quality you're after rather than having to input a guessed bitrate which means it'll be far more accurate in terms of what your standards are.
The codec uses variable bitrates throughout the video and it's more hand-tailored for it.

Misread your changes as being changed from VBR to CBR.

Although I'm for discussions like this, please refrain from making assumptions like that based on nothing next time, I don't spend hours and hours making a tutorial only to have it doubted without reasonable reasons as to why, if you can't show me a frame-by-frame comparison with the same bitrate and/or similar settings to strengthen what you're suggesting is better, then don't bother.

It's not based on assumptions, I'm a working editor/media assistant and I do this kind of rendering almost every day. It's not practical to run an uncompressed render all the way into MeGUI just for an MKV vs the ease of rendering an MP4 in my opinion, it's certainly a waste of time for most editors. The only time you would bother rendering out an uncompressed or lossless video in general is to use it in an advanced compression program, and MeGUI doesn't offer a lot of compression versus your standard NLE. Maybe if you're using hugely expensive compression programs that can convert an hour long video down to 500mb, but not here. There's a reason nobody working in the industry actually uses MeGUI or the like, it's not worth it.
« Last Edit: August 18, 2011, 07:28:40 AM by Shadowsniper »

Offline Daffy

  • V.I.P. Member
  • Posts: 13506
  • WH & NU Founder
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #227 on: August 19, 2011, 01:40:13 PM »
X.264 is a program designed to encode H.264, I don't see your point. The reason Blu Ray discs are encoded at 30-50mpbs is that it looks a lot better, this is nothing to do with being easier on the decoder as far as I'm aware. This is the same reason you see news programs encoded as low as 15mbps when there is a lack of motion, and up to 50mpbs in sports; nothing to do with decoding.
The reason BluRay discs are encoded at 20-30 (40 is extremely rare, average bitrate that is it might peak at 50 sometimes sure)are because it's encoded using H.264 Level 3.1 limitations thus limiting the encoding options available for easier decoding but adding extra bitrate to compensate for the quality that would be lost.
The reason why news programs or programs with static cameras/backgrounds are encoded at lower bitrates are because of the reference frames which gather information from the previous frames where the pixels has the same RGB (or whatever color space) values since the same quality can be achieved using those reference frames.
Forcing more bitrate on it then would be futile as the quality would not increase at least to the naked eye and it's therefore logical to not go above that.
You adjust the bitrate depending on what the nature of the source footage is and how the current technology available is able to compress it.
This tutorial and most MKV rips (except WEB-DL things you find on the net which are H.264 Level 3.1) use Level 4.1 because you can use more x264 (H.264 based) options than the 3.1 levels offers you such as the number of reference frames (4.1=9 as opposed to 3.1=5) and from what I've read from the x264 developers (for instance Dark Shikari who wrote the PSY-RDO part of x264) x264 is very much optimized for Level 4.1 encoding.
If you're wondering why I've limited it to L4.1 as well as the developers, it's because almost all hardware accelerated decoding support stops at that level.

Maybe I've mis-understood the way you're distinguishing X.264 to H.264, because X.264 isn't a codec as you seem to be half suggesting.
I'd love to see you explain how x264 isn't a codec as it's even in this list of H.264 based codecs.
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoder_feature_comparison

It's not worth using FLAC audio, most people watching your videos will watch them on YouTube, where audio is recompressed anyway. And most people downloading your videos wont have the hardware to hear a huge difference between AAC vs FLAC; most wont care either.
Sure but what about those who do, should I neglect their expectations for the best possible quality?
Also I would be neglecting the very probably possibility that people are going to upgrade their hardware thus raising the requirement for lossless audio, in other words using FLAC as opposed to MP3/OGG/AAC/WMA means it still holds the same audio quality years from now as opposed to lossy formats.
And when I edit with FLAC audio recompression it means however insubstantial extra effort on my part which is unnecessary.
I think all editors wants to present their video with the best possible quality though someone are willing to go further for this than others this involves no extra effort whatsoever.

It's not based on assumptions, I'm a working editor/media assistant and I do this kind of rendering almost every day. It's not practical to run an uncompressed render all the way into MeGUI just for an MKV vs the ease of rendering an MP4 in my opinion, it's certainly a waste of time for most editors. The only time you would bother rendering out an uncompressed or lossless video in general is to use it in an advanced compression program
You're forgetting that the file formats .mp4 and .mkv are just containers which both contain video coded using a codec based on the H.264 video standards be iit x264 or the one that comes with your NLE (Non-Linear Editing System).
H.264 can be encoded with Vegas and still be used in a .mkv container if remuxed so claiming the lossless rendering is just for a .mkv file has no basis in reality whatsoever.
The point here is that this is a not business/industry environment in which we edit which means we have to encode several version so people with different hardware setups are able to watch it with as good quality as possible.
And when you're going to render a 1080p, 720p and a SD version of a video you don't want to have to wait through Vegas having to render all the filters applied several times as some of them are quite heavy.
Thus rendering the lossless once means you are speed efficient in terms of getting your video rendered and prepared for release making it the favorable option.
Also another advantage of having the lossless .avi rendered means you can re-render new versions if need be and/or when there's options for achieving even better visual quality out there, so some people including me tend to store them on a backup drive just in case.

MeGUI doesn't offer a lot of compression versus your standard NLE.
"A lot of" is a lose term here and too open to interpretation so I won't comment on that.
However it does offer more options and is therefor more flexible than Vegas which is why I choose to use x264 in MeGUI as opposed to Vegas to encode the different versions of the video.
One thing that's also important to mention is that everyone isn't using Vegas or a similar NLE where the options for rendering/encoding are as broad so this actually gives those who for instance use Ulead or Pinnacle's solutions the same options in terms of output quality and/or control over it.

Maybe if you're using hugely expensive compression programs that can convert an hour long video down to 500mb, but not here. There's a reason nobody working in the industry actually uses MeGUI or the like, it's not worth it.
The primary reason the industry uses certain range of software is because everyone in the industry knows them and to introduce a new "unknown" one would be to introduce confusion into the environment.
It's the same reason the industry (at least where I live) use either Adobe Premiere, Avid or Final Cut, because everyone knows them and even though I personally prefer Vegas because of it's logically structured GUI and even more though if a lot of industry editors where given the option to try it without prejudice they would probably prefer it but it would be too much of an inconvenience to get everyone to switch to Vegas and it would cause a halt in the production flow of current projects not even to mention the license costs thus they're sticking to the standards.

Offline VaNilla

  • next week m9
  • Veteran Member
  • Posts: 3809
    • View Profile
    • YouTube
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #228 on: August 19, 2011, 03:36:15 PM »
The reason BluRay discs are encoded at 20-30 (40 is extremely rare, average bitrate that is it might peak at 50 sometimes sure)are because it's encoded using H.264 Level 3.1 limitations thus limiting the encoding options available for easier decoding but adding extra bitrate to compensate for the quality that would be lost.
The reason why news programs or programs with static cameras/backgrounds are encoded at lower bitrates are because of the reference frames which gather information from the previous frames where the pixels has the same RGB (or whatever color space) values since the same quality can be achieved using those reference frames.
Forcing more bitrate on it then would be futile as the quality would not increase at least to the naked eye and it's therefore logical to not go above that.
You adjust the bitrate depending on what the nature of the source footage is and how the current technology available is able to compress it.
This tutorial and most MKV rips (except WEB-DL things you find on the net which are H.264 Level 3.1) use Level 4.1 because you can use more x264 (H.264 based) options than the 3.1 levels offers you such as the number of reference frames (4.1=9 as opposed to 3.1=5) and from what I've read from the x264 developers (for instance Dark Shikari who wrote the PSY-RDO part of x264) x264 is very much optimized for Level 4.1 encoding.
If you're wondering why I've limited it to L4.1 as well as the developers, it's because almost all hardware accelerated decoding support stops at that level.

I don't disagree with you on that, all I was doing is giving the simple reason rather than the drawn out version.

I'd love to see you explain how x264 isn't a codec as it's even in this list of H.264 based codecs.
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoder_feature_comparison

X.264 is open source software designed to encode H.264, that's what I mean. I can see that I didn't make that clear though.

Sure but what about those who do, should I neglect their expectations for the best possible quality?
Also I would be neglecting the very probably possibility that people are going to upgrade their hardware thus raising the requirement for lossless audio, in other words using FLAC as opposed to MP3/OGG/AAC/WMA means it still holds the same audio quality years from now as opposed to lossy formats.
And when I edit with FLAC audio recompression it means however insubstantial extra effort on my part which is unnecessary.
I think all editors wants to present their video with the best possible quality though someone are willing to go further for this than others this involves no extra effort whatsoever.

This is a matter of opinion really, but I don't think the benefit of rendering FLAC versus the highest quality AAC format is worth it. Especially when it's one of few reasons you'd render your file out of Vegas into MeGUI. If you're not using Vegas (I use Premiere Pro/Avid at home) then you don't have to do that to render FLAC audio, so only then does it become a viable option. Even then though I can't imagine most would bother with using FLAC, because it's practically inaudible gain to most people. Nobody ever complains about the quality of audio on Blu-ray discs (also compressed), so why bother to use FLAC for stunting videos? That's my take on it.

You're forgetting that the file formats .mp4 and .mkv are just containers which both contain video coded using a codec based on the H.264 video standards be iit x264 or the one that comes with your NLE (Non-Linear Editing System).
H.264 can be encoded with Vegas and still be used in a .mkv container if remuxed so claiming the lossless rendering is just for a .mkv file has no basis in reality whatsoever.
The point here is that this is a not business/industry environment in which we edit which means we have to encode several version so people with different hardware setups are able to watch it with as good quality as possible.
And when you're going to render a 1080p, 720p and a SD version of a video you don't want to have to wait through Vegas having to render all the filters applied several times as some of them are quite heavy.
Thus rendering the lossless once means you are speed efficient in terms of getting your video rendered and prepared for release making it the favorable option.
Also another advantage of having the lossless .avi rendered means you can re-render new versions if need be and/or when there's options for achieving even better visual quality out there, so some people including me tend to store them on a backup drive just in case.

The problem is that rendering lossless files just to render different file-types potentially adds hours to your overall rendering time. That's why most NLE's give you the option to 'render' clips within the timeline. Not only does this allow you to play back your clips without any lag, but you can speed up the rendering process of your video by using the pre-rendered clips from your timeline. As far as I know the most recent versions of Vegas are capable of doing this too (most other programs certainly are). If not then lossless rendering could be a solution to this problem. However, the time spent rendering a lossless video is usually longer than you would spend rendering out the effects in your timeline, especially when rendering lower quality videos. In fact these days, I don't bother rendering low quality downloads, because most computers are capable of playing 720p videos at least, as long as they're rendered properly. The time spent rendering a 480p video and then uploading it for such a small minority is pointless when it's much easier to watch/download a video from YouTube.

"A lot of" is a lose term here and too open to interpretation so I won't comment on that.
However it does offer more options and is therefor more flexible than Vegas which is why I choose to use x264 in MeGUI as opposed to Vegas to encode the different versions of the video.
One thing that's also important to mention is that everyone isn't using Vegas or a similar NLE where the options for rendering/encoding are as broad so this actually gives those who for instance use Ulead or Pinnacle's solutions the same options in terms of output quality and/or control over it.

Good point, but I don't think the audience Ulead/Pinnacle/WMM targets with their programs are really interested in the extra options MeGUI gives you when they can render a HD WMV/MP4 right out of their software package. And you'd be challenged to find an editor striving for the best quality using any of those programs, let alone the gaming community which predominantly uses Sony Vegas Pro.

The primary reason the industry uses certain range of software is because everyone in the industry knows them and to introduce a new "unknown" one would be to introduce confusion into the environment.
It's the same reason the industry (at least where I live) use either Adobe Premiere, Avid or Final Cut, because everyone knows them and even though I personally prefer Vegas because of it's logically structured GUI and even more though if a lot of industry editors where given the option to try it without prejudice they would probably prefer it but it would be too much of an inconvenience to get everyone to switch to Vegas and it would cause a halt in the production flow of current projects not even to mention the license costs thus they're sticking to the standards.

The reason Sony Vegas hasn't been adopted into the industry (let alone formed a majority) is because of its lack of stability, the lack of speed you have when managing a lot of files, the lack of a three point editing system (which makes Vegas easy to use, but slow to edit with) and its lack of easy integration with local area networks and industry standard programs like After Effects. It's not because of prejudice towards the program, if it offered any advantage over other programs then people would be using it, especially given the price. There's things I love about Sony Vegas (text tool, pan and crop) that are miles better than the same features in programs like Final Cut Pro, but the reason I switched to mainly using Adobe Premiere at home is because of the reasons I gave before, as well as on the fly rendering which Sony Vegas doesn't have.

I think we're going off topic now, but I don't think there's any advantage of using MeGUI versus Sony Vegas for 99% of the people you made the tutorial for. You've made a fantastic tutorial, and some will find it extremely useful, but that's the point I was making :). I don't mean to undermine the work you've put in or anything along those lines, it's just that I think this makes rendering a slower process than it needs to be for most.
« Last Edit: August 19, 2011, 03:50:40 PM by Shadowsniper »

Offline Beat

  • d(^---^)b
  • Board Mods
  • *
  • Posts: 3135
    • View Profile
    • Beat's YouTube page.
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #229 on: August 19, 2011, 07:04:52 PM »
I swear to god I won't EVER.. consider reading that :L! What the hell? :cheersad:

Actually I did read it now, I was so curious... how can someone write so much :|
« Last Edit: August 19, 2011, 07:16:26 PM by Beat »

Offline Daffy

  • V.I.P. Member
  • Posts: 13506
  • WH & NU Founder
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #230 on: August 20, 2011, 05:53:43 AM »
I think we're going off topic now, but I don't think there's any advantage of using MeGUI versus Sony Vegas for 99% of the people you made the tutorial for. You've made a fantastic tutorial, and some will find it extremely useful, but that's the point I was making :). I don't mean to undermine the work you've put in or anything along those lines, it's just that I think this makes rendering a slower process than it needs to be for most.
Sure, I think we can both agree we've given good reasons for why both are good options but the bottom line is that no one is forced to use the method this tutorial gives people, it remains an option and it's up to people to decide which is why I think this was a healthy discussion and I apologize if I came across as harsh or aggressive to begin with which I probably did with good reasons as I spent a long, long time learning how the different parameters within x264 works and what they do to make a tutorial as optimized as possible for the best output quality.

This tutorial has worked and worked well for a lot of people including me (and I think you too) who are interested in the continued use of it, if it remains up to date which I work hard to do.
The difference between the option you're giving to this is that your method offers minor speed improvements while mine offers minor quality improvements and it's up to each and everyone to decide.
I also agree on the point that those who watches a video in SD quality is most likely to do it on YouTube as the differences quality wise are not that substantial but when it comes to HD, especially 1080p YouTube's quality just doesn't cut it compared to a well rendered/encoded local file.
Editors who renders and encodes a 1080p knows this and when they're doing so I think it makes sense for them to encode it with the intentions of getting the best possible output quality to make the effort worthwhile.

Concerning Vegas I agree about the stability issues which makes sense and is quite a shame since if those weren't the case plus the network support and so on for industry related editing Vegas would become a strong candidate but it isn't which is the main reason I've never put any effort working within the industry as I despise how much the NLE's that are used slows down how I edit.
This might be me who's stubborn or even inhabit a diva tendency or two and need to get out of my comfort zone but that's subjective and I don't quote know why I'm soul-searching here now so I'll leave it at this.
I would however like to see as I first stated a frame comparison of the output quality of the two methods at the same bitrate so bias becomes irrelevant but I won't put that burden on you, I'll do it myself to satisfy my own curiosity next time I'm editing a video.

Offline VaNilla

  • next week m9
  • Veteran Member
  • Posts: 3809
    • View Profile
    • YouTube
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #231 on: August 20, 2011, 07:18:50 AM »
Sure, I think we can both agree we've given good reasons for why both are good options but the bottom line is that no one is forced to use the method this tutorial gives people, it remains an option and it's up to people to decide which is why I think this was a healthy discussion and I apologize if I came across as harsh or aggressive to begin with which I probably did with good reasons as I spent a long, long time learning how the different parameters within x264 works and what they do to make a tutorial as optimized as possible for the best output quality.

It's a very well optimized tutorial :). You did come across as harsh but I understand that because here I am telling you that I don't think it's the right method to use, so don't worry about it. I just think focusing on minute details like FLAC for the time taken isn't the right thing to do in the interest of time, but if time isn't an issue for you then obviously there's no problem with doing that.

This tutorial has worked and worked well for a lot of people including me (and I think you too) who are interested in the continued use of it, if it remains up to date which I work hard to do.
The difference between the option you're giving to this is that your method offers minor speed improvements while mine offers minor quality improvements and it's up to each and everyone to decide.
I also agree on the point that those who watches a video in SD quality is most likely to do it on YouTube as the differences quality wise are not that substantial but when it comes to HD, especially 1080p YouTube's quality just doesn't cut it compared to a well rendered/encoded local file.
Editors who renders and encodes a 1080p knows this and when they're doing so I think it makes sense for them to encode it with the intentions of getting the best possible output quality to make the effort worthwhile.

Again I completely agree with you, it's just a question of whether to render in 1080p this way, or direct from whatever NLE you're using. I think 1080p on YouTube looks like ass compared to the original file generally (but still not bad) :P. The interesting thing is that we all use around 12-15 VBR max when it comes to 1080p files, but when you've got a big blu-ray disc or a satellite to broadcast over you can send 50mbps with no trouble, it's a shame we can't buy the compression programs all the major broadcasters use and render 5 minute videos at 50mbps and still have it be about 150mb :(.

Concerning Vegas I agree about the stability issues which makes sense and is quite a shame since if those weren't the case plus the network support and so on for industry related editing Vegas would become a strong candidate but it isn't which is the main reason I've never put any effort working within the industry as I despise how much the NLE's that are used slows down how I edit.
This might be me who's stubborn or even inhabit a diva tendency or two and need to get out of my comfort zone but that's subjective and I don't quote know why I'm soul-searching here now so I'll leave it at this.

Well yeah, there's things about those NLE's which suck hard. I hate doing text in Final Cut Pro because it's an awful tool with awkward controls, and I'd love Premiere Pro's text tool if it weren't for the fact that when you re-open the same text file, it shows the default values for your text controls (size, tracking etc) despite them being set differently. So every time you open the text file, you have to click back on the number in order for it to show up correctly, which is slow as hell. Obviously this is different to FCP as the latter is just a bug, but you see what I mean.

I can relate to you thinking that other programs slow you down, at first I hated using the three point editing in other programs because I couldn't just copy clips exactly where I wanted or fade files without first selecting the correct layer to use, and you can't drag clips over each other to crossfade in any other program. However I find that once you get used to it it makes more sense to have it like that, because then you only have to press one button to make a crossfade, you can copy exactly where you want, and you can replace a whole section of an edit without any effort. You also get tools such as roll tools which don't exist in Sony Vegas, which allows you to to change the in and out points of a clip on the timeline without dragging out the exact length of the clip again on a different layer. I'd never go back to Vegas unless it introduced features like these, because once you get used to them they make things so much easier to edit, making it hard to justify going back to the simplified system Vegas has.

I would however like to see as I first stated a frame comparison of the output quality of the two methods at the same bitrate so bias becomes irrelevant but I won't put that burden on you, I'll do it myself to satisfy my own curiosity next time I'm editing a video.

I've never looked for one honestly, but based on testing I've done by eye in the past I'd say Vegas's MP4 renders look slightly worse than the same thing from MeGUI, but Premiere Pro/FCP/Avid's look better than both.
« Last Edit: August 20, 2011, 07:20:41 AM by Shadowsniper »

Offline PK

  • Misanthrope
  • Senior Member
  • Posts: 1374
  • Satan's Blue
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #232 on: March 02, 2012, 04:13:30 AM »
I remember I read a while back about something using MeGUI + VirtualDub. What is VirtualDub exactly for? And what does it have to do with MeGUI or any .mkv rendering?

Offline Squeak

  • Forbidden Element
  • Veteran Member
  • Posts: 2950
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #233 on: March 02, 2012, 05:56:51 AM »
...still reading.

Offline Shingetsu

  • The Dark Matter
  • Veteran Member
  • Posts: 1428
  • Azurex Studio
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #234 on: July 14, 2012, 10:41:28 PM »
Help me , i has been an Error :

Offline Daffy

  • V.I.P. Member
  • Posts: 13506
  • WH & NU Founder
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #235 on: July 15, 2012, 03:51:26 AM »
Post your script.

Offline Shingetsu

  • The Dark Matter
  • Veteran Member
  • Posts: 1428
  • Azurex Studio
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #236 on: July 15, 2012, 05:06:46 AM »
Here , i tryed in my PC before i re-install windows 7 . it's work , but now it's isn't work

Code: [Select]
DirectShowSource("C:\video.avi")
#Spline64Resize(1280,720)
Converttoyv12()
l = gradfun2dbmod(1.4)
c = gradfun2dbmod(2.2).addgrainc(0.0,1.0)
mt_merge(l,c,c,y=2,chroma="copy second")
« Last Edit: July 15, 2012, 05:10:05 AM by NeverLose »

Offline Shingetsu

  • The Dark Matter
  • Veteran Member
  • Posts: 1428
  • Azurex Studio
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #237 on: July 16, 2012, 07:24:31 PM »
up

Offline Daffy

  • V.I.P. Member
  • Posts: 13506
  • WH & NU Founder
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #238 on: July 17, 2012, 12:06:05 AM »
Make sure you have the AddGrainC and Gradfun2dbmod filters added to the program files\avisynth\plugins directory.
http://www.sendspace.com/file/2lftai

Offline Shingetsu

  • The Dark Matter
  • Veteran Member
  • Posts: 1428
  • Azurex Studio
    • View Profile
Re: Tutorial: Matroska x264 Encoding 2.2
« Reply #239 on: July 19, 2012, 12:29:47 AM »
I Re-Installed windows and now it's work , maybe is error of Ghost version

 

SimplePortal 2.3.7 © 2008-2024, SimplePortal