Why encoding videos to .mp4 containers using h.264 codecs takes time?

[NoUserName]

Please let me ask if using one of the Hexacore Core i7's or going for dual-socket Xeon server system, but I do not mean a server by the real meaning of the server, but I mean to use a motherboard that support dual sockets for core i7 processors?

Thanks :)

[NoUserName]

  Quote

Conclusions

The unfortunate truth is that, right now, hardware-accelerated video transcoding on the PC is a mess.

Support for black-box encoders is spotty. We saw output quality at the same settings vary wildly depending on the conversion software used. Not only that, but none of the black-box encoders we used matched the quality level of unaccelerated software conversion. Sometimes, the differences were glaring, with the black boxes producing a ton more artifacts and adding ugly jaggies around hard object edges. The only upside, really, is the encoding speed. For some folks, maybe that's all that matters. Maybe it's simply about getting a big video down to a manageable file size in as little time as possible. If you're going to be watching the output on a 4" smartphone, perhaps that isn't a bad approach. Artifacts may not be visible or noticeable on that small a display, making encoder quality very much a secondary concern.

It's a shame, though. Four long years have passed since Elemental released Badaboom 1.0, and we're still facing a heavily fragmented ecosystem with vast inconsistencies in performance and image quality.

There may be hope on the OpenCL front. As we've seen, the OpenCL-accelerated version of x264 can produce relatively consistent output on different hardware. However, only a portion of the encoding pipeline is accelerated, with much of the work still being done on the CPU. On our test rig, substituting the Radeon HD 7750 for a much quicker Radeon HD 7850 didn't substantially reduce encoding times?they were still just over 30 seconds. It's possible some optimization work remains to be done. After all, we were using a beta, and the x264 developers haven't released a public version of their OpenCL-accelerated software yet. Still, we're not completely sold on the effectiveness of OpenCL acceleration here.

For the time being, the best option for quick, high-quality video transcoding is unfortunately to buckle down, get yourself a fast CPU, and run the best software encoder you can find (which may be Handbrake).

If performance matters to you more than quality, then using QuickSync in MediaConverter might be a suitable option. Encoding times will be very short, and image quality, while poorer than with Handbrake, will be adequate, especially if you'll be viewing the video on a smaller screen. Other hardware transcoders were slower than our CPU in MediaConverter, though, and we were generally unimpressed with the image quality of the hardware solutions in MediaEspresso.

[Luis Mazza]

  On 21/08/2012 at 23:00, NoUserName said:

Actually I've borrowed a copy of Premiere Pro from a friend and cut of the internet connection and activated it using his serial and tried its presets and it is really very much disappointed as it is encoding 1 hour video file in about 15 minutes to it is .h264 with 480x270 using the lowest bit rate by premiere, so the adobe premiere will not work for me either and I ended up removing it from my computer and reinstalling my windows "this is the reason for my late reply now".

I did not understand quite any single word of this comment .. lol , I am sorry but it is my poor knowledge so I would be too much appreciatd for you if you make it...

You have to compare apples to apples. How can you test a program like Premiere that takes years to master by the best professionals and say something like that? One checkmark you tick wrong can triple render time. :s

I'm sorry, I have lots of other things to do. Good luck!

[NoUserName]

  On 21/08/2012 at 17:20, mikiem said:

I'd suggest checking out one of the mpg2 cut editing apps, like those from Womble or maybe the free Cuttermaran -- they'll let you eliminate the parts you don't want without re-encoding so no quality loss. Then import the edited mpg2 into one of the Chinese video converters that can do batch processing -- most have very similar quality & speed. The problem with NLEs [non-linear video editors] is that they're set up to edit video, with processing/encoding secondary, so they're universally slower than more specialized apps.

I've checked both tools and really can not beat mpg2cut under any circumestances.

Also mpg2cut does not do an encoding at all but it is just edit the file and remove or add parts.

  On 22/08/2012 at 00:03, Luis Mazza said:

I'm sorry, I have lots of other things to do. Good luck!

I am sorry if I said something goofy but I just told what happened with me.

I am sorry if I am that newbie and said such stupid things, please accept my apologize.

[NoUserName]

when I explored the Xeon cpu here:

http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Order=BESTMATCH&N=100006676&isNodeId=1&Description=xeon&x=0&y=0

There are a lot of them.

Which one you are suggesting or in other words what spacifications I should look after?

[NoUserName]

Regarding the adobe premiere consumed time I did checked it once againand the result was:

- for a file length 20 minutes it encoded in 03:12 minutes using the smallest of everything in h.264 profile like video and audio bit rate and the quality of course was not good.

this is the reason why I said premiere will not work for me for the poor quality when using lowest settings for h.264 and consumed time and the size of course.

- Not that I did not checked it.

[br0adband]

Here's the general problem that I haven't seen mentioned once:

GPU encoding sucks.

Seriously, it does. It's nice that Intel has created this whole QuickSync thing but, when it comes to actually creating output, the output sucks every time, regardless of whatever quality or encoding settings you might be using. Since the days of Badaboom for Nvidia Geforce/Quadro GPUs and ATI's Avivo software for their Radeon GPUs, there hasn't been one single GPU-assisted video encoder that ends up with content worth actually spending the time and GPU cycles to create in the first place. Every single one of them sucks, and nothing has really improved in the past 5-7 years in that respect.

The x264 developers tried to work with Intel when Sandy Bridge was coming into being to find a way to possibly use GPU-assisted processing to speed up x264 but it never went anywhere (there's a ton of info out there over at Doom9 on this situation). Intel's engineers basically had the 'we know everything there is to know' attitude and the x264 developers were taking the 'if you know everything then why are you even contacting us?' angle in response.

Regardless of what did or didn't happen, QuickSync still produces horrible output even with the best quality settings the encoder mechanism is capable of producing, and that's a sad thing indeed.

You're better off just sticking with x264 (command line) or one of the GUI frontends as already mentioned, or just use HandBrake, period. The resulting quality you'll get from that app is well worth the time invested in creating the encoding in the first place.

[NoUserName]

  On 22/08/2012 at 08:30, br0adband said:

(there's a ton of info out there over at Doom9 on this situation).

Yes I am afraid so.

  On 22/08/2012 at 08:30, br0adband said:

You're better off just sticking with x264 (command line) or one of the GUI frontends as already mentioned, or just use HandBrake, period. The resulting quality you'll get from that app is well worth the time invested in creating the encoding in the first place.

The only good native .mp4 using h.264 I've found good so far were Handbrake and VidCoder and found VidCoder some how consume less time compared to Handbrake and also keep the custome presets while Handbrake do not keep the custome preset after you create it, because when you choose the preset you find that it does not affect the encoded files even if you make that particular preset default.

But does the CLI will reduce the time, this is the only factor.

One last thing.

Please I am seriously considering buying a dual socket cpu and upgrade the motherbaord.

Please advise as I am searching since yesterday on this topic and can not make up my mind for a one.

Thanks

[articuno1au]

As best I am aware, you cannot dual socket i7s.

You'd need to go a Xeon system (which is pretty much an i7 anyway, but with dual socket ability and a slight difference in registry bias).

Those systems can be quite pricey. I'm not suggesting you stay away from QuickSync. I just think that you should only spend money on things you know will help you out.

Video encoding is time consuming and painful.

Speed/Size/Quality. Pick 2. >.<

[Luis Mazza]

Encoding with the lowest bitrate.... wtf do you mean? You can set bigger bitrates and thus having speedier encoding... did you know that? Did you also set your gpu accordilgly on Premiere Pro? You are like blaming your vehicle for not knowing how to drive. I think you should stay away from professional software because you clearly have no patience to learn.

Period.

[Brandon Live Veteran]

What is the source format you're starting with?

[iKenndac]

Post deleted. How did I miss the six whole pages of this thread?! :wacko:

[NoUserName]

  On 22/08/2012 at 10:52, articuno1au said:

As best I am aware, you cannot dual socket i7s.

You'd need to go a Xeon system (which is pretty much an i7 anyway, but with dual socket ability and a slight difference in registry bias).

Those systems can be quite pricey. I'm not suggesting you stay away from QuickSync. I just think that you should only spend money on things you know will help you out.

Video encoding is time consuming and painful.

Speed/Size/Quality. Pick 2. >.<

I've realized that during encoding using the vidcoder that the cpu is consuming about 65:72% and sometime jump to 80:81% ... this is according to the gadgets of the cpu in windows 7 and the task manager was reporting the same.

So does upgrading to a workstartion with dual xeon will make it any better?

  On 22/08/2012 at 17:59, Luis Mazza said:

Encoding with the lowest bitrate.... wtf do you mean? You can set bigger bitrates and thus having speedier encoding... did you know that? Did you also set your gpu accordilgly on Premiere Pro? You are like blaming your vehicle for not knowing how to drive. I think you should stay away from professional software because you clearly have no patience to learn.

Period.

No need for "wtf" ... we are still speak as gentlemen here :)

I've mentioned earlier that videos should be in the smallest sizes as possible and this is the reason for the thread from the first place to achieve the goal od good quality as possible with the speed of encoding.

So again no need for the "wtf".

Regarding having a patient to learn, thanks for the advise and I will follow it.

  On 22/08/2012 at 18:27, Brandon Live said:

What is the source format you're starting with?

.TS and .MPEG-2

  On 22/08/2012 at 18:34, iKenndac said:

Post deleted. How did I miss the six whole pages of this thread?! :wacko:

Thanks a lot for reading :)

I've realized that during encoding using the vidcoder that the cpu is consuming about 65:72% and sometime jump to 80:81% ... this is according to the gadgets of the cpu in windows 7 and the task manager was reporting the same.

So does upgrading to a workstartion with dual xeon will make it any better?

[NoUserName]

Thanks for your help.

Please it seems that I reported a wrong information regarding CPU usage.

Please I've recorded a video for the whole process and what system monitoring says as well in the attached video.

Choose HD quality.

I think that HDD maybe the reason for this slow performance if I am not mistaken.

So please tell me your opinion regarding this issue and shall I go for the SSD option 1st before go to xeon.

So what kind of a Motherboard I should stick to in case I will buy a SSD drive and does the brand vary or all are the same?

I will buy the biggest size of course which is 256 GB as far as I know.

Thanks a lot and too much appreciated