0 Members and 3 Guests are viewing this topic.
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.
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.
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.
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
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.
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'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
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.
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.
"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.
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.
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.
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")
SMF 2.0.19 | SMF © 2021, Simple Machines