OT: Video rendering speed in Sony Movie Studio

[andersm]

In situations where the cores spend all their time computing and don't do a lot of I/O hyperthreading doesn't help a lot (in extreme cases it can even hinder overall performance). As long as the OS knows to schedule processes on the physical cores I wouldn't worry about it.

[TerminalJack505]

It would be interesting to know which AMD/ATI GPU you have in your laptop. 

There's a huge difference in horsepower in the mobile GPUs.  At the low end you're talking just 80 GFLOPs of processing power whereas at the high end you're looking at over 2,000 GFLOPs.

If you have one of the low end GPUs then that might be your bottleneck.

[ecat]

It would be interesting to know which AMD/ATI GPU you have in your laptop. 

There's a huge difference in horsepower in the mobile GPUs.  At the low end you're talking just 80 GFLOPs of processing power whereas at the high end you're looking at over 2,000 GFLOPs.

If you have one of the low end GPUs then that might be your bottleneck.

But what features of the gpu does Movie Studio, or any other transcoding sw, actually use?

On a notebook utilising 4 cores of an i7 cpu @ 50%, Dave:

I'm getting just over real time rendering speed, so a 1 hour video takes just under an hour to render.

On my desktop with i5 clocked at 4.2GHz utilising 4 cores @ 90% and an ATi 6950 (rated 2253 GFLOPs according to wiki) I run at about 70% to 80% of real time, so a 1 hour video takes approx  48 minutes to render.

These figures suggest it's about more than the raw gpu flops? Sure a low end gpu may be slower but how much faster would a 4000GFlops 8970 be?

This may be a red herring, but my gpu monitoring software reports only 41% load when running a Movie Studio render.

Edit:
Of course, all these numbers are meaningless if there are significant differences between Dave's video render options and mine.

[Lightages]

Notebooks are notorious for being slower than their desktop counterparts. This due to CPU throttling, GPUs not being the same even if their share a common name or number, inefficiencies in memory busses, hard drive busses, etc. All of these things are because of limited space for traces, for cooling, and to minimize power consumption. So it is probable that some or all of the above are combining to keep the CPU underutilized.

The plain truth is if you want a fast machine you need a desktop with the best motherboard and RAM that works correctly with it.

This company here has a good reputation for putting the right hardware together:
http://www.videoguys.com/Guide/E/Videoguys+DIY9+Its+Time+for+Sandy+Bridge+E+DIY+95+Update/0xe9b142f408a2b03ab88144a434e88de7.aspx

and

http://www.videoguys.com/Guide/C/DIY+Systems/Videoguys+Recommended+Laptops+for+Video+Editing/0x838938d96d9a325815fbc603304f6aeb.aspx

Some helpful information there...

Other helpful hints Dave:
Keep your project files and media on one hard drive that is separate from the OS, render to another HD separate from both even if it is an external USB drive. Keep everything defragmented of course. Try upping the priority of the rendering tasks from normal to high, but never real time as this can lock up your system. Turn off windows search indexing and turn off your antivirus while rendering. Keep the notebook as cool as you can, maybe one of those pads with fans in it.

[mariush]

The video card is mostly used to decode input video, ex if your source videos are mpeg-2 or h264 then the video card decodes and sends raw video frames back.

This is sometimes done with a dedicated part of the gpu chip that's highly optimized for video playback and is basically independent of the gpu (it uses its own resources, not shaders and gpu part that's used for games usually). These hardware video decoders can do more than real time but not much more, usually 50-70 fps.

What slows down things is transferring of the images from this dedicated area to the regular video card memory or to the computer ram.

Less often, the video card is also used to do color conversion, resampling/resizing to different image size etc ... Now you have to convert the image to a texture format, upload it to video card, compile the shaders or cuda/open cl code, download the texture from the video card... again lots of time wasted

Even less often the video card is used to do a part of the  encoding with the rest of the encoding being done on processor.
Unless you use a preset with high-extreme quality options, most often these parts are faster to be done in cpu than on video card.

x264 for example - the open source video encoder in Handbrake - only now added an option to do some motion analysis and encoding on the gpu but a large part of the encoding is still done in CPU.. you can read a good explanation here:

https://github.com/DarkShikari/x264-devel/commit/c902b90bbb6846471a6f22f7377782c89da3052f

Basically, like he says, the little that's done in gpu, is done using a more stupid algorithm that has to do more work than the cpu version, but since it's extra free resources it helps sometimes, leaving the cpu free to do more work.

In Sony Vegas, I suspect that the cpu simply waits after the video card to get the decoded frames or to finish whatever part of encoding it does on gpu, because the constant rate factor presets are just too easy to encode. 

It may be faster than using cpu alone because the gpu may still decode more frames per second compared to whatever the cpu would be able to decode in a second, when other threads also hammer it with the encoding part.

Oh, and there may be other things in play...

With cpu encoding alone, the cpu may be hotter constantly so the laptop may throttle itself down, thereby overall the encoding would be slower.
With gpu decoding, the lower cpu usage may be just low enough not to throttle down the cpu frequency, and it may even give the cpu opportunity to go turbo and raise the frequency of 1-2 out of those 4 cores.

[ve7xen]

So you're encoding to h.264, then reencoding with Handbrake before uploading?

Why not just frameserve from Vegas? You'll get better quality, only have to do a single encode, and should avoid this issue entirely. See http://www.debugmode.com/frameserver/ Haven't tried with Vegas (or Handbrake) but it should work.

[EEVblog]

So you're encoding to h.264, then reencoding with Handbrake before uploading?

Why not just frameserve from Vegas? You'll get better quality, only have to do a single encode, and should avoid this issue entirely. See http://www.debugmode.com/frameserver/ Haven't tried with Vegas (or Handbrake) but it should work.

Never heard of that, will look into it.
EDIT: Just tried it, and it doesn't appear on my Sony Output file list. Fail.

[free_electron]

you may want to invest in a hardware encoder. they are not that expensive ( 150 to 200$ ). Matrox makes a good one.

[ve7xen]

Never heard of that, will look into it.
EDIT: Just tried it, and it doesn't appear on my Sony Output file list. Fail.

I don't understand why frameserving is not a totally standard output method for all NLEs, it is clearly the only sensible way to handle external coders.

That said, you can probably make this method work, there are success reports with Vegas 12 on Win7 64 in the forums. Apparently the install tool isn't intelligent enough to guess the plugin directory for your version of Vegas and having to manually specify that is a stumbling block for some people like me who Next->Next->Next through any such dialogs.

[EEVblog]

you may want to invest in a hardware encoder. they are not that expensive ( 150 to 200$ ). Matrox makes a good one.

Not for Sony though, or even for video editors, just several enocders.
Otherwise I'd love this.

[EEVblog]

you may want to invest in a hardware encoder. they are not that expensive ( 150 to 200$ ). Matrox makes a good one.

Not for Sony though, or even for video editors, just several enocders.
Otherwise I'd love this.

Ah, it seems it does support Adobe Premiere (which I have tried, but did not like, but could try again for this)
http://www.matrox.com/video/en/products/compresshd/encoding/
But it seems Constant Quality mode is only available on the Mac:
http://www.matrox.com/video/en/products/compresshd/telestream/

[NiHaoMike]

you may want to invest in a hardware encoder. they are not that expensive ( 150 to 200$ ). Matrox makes a good one.

Or buy a nice GPU for the same price and get more uses. Or indeed, upgrade to a CPU with Quick Sync and it will beat anything else you can get for the price. (Too bad MythTV doesn't support that yet...) It might also be possible to get a bunch of Raspberry Pis and use those to transcode (since each Raspberry Pi has hardware video decode and encode), but I don't think they can quite compete for performance/$.

If you're going to stick with a laptop, you probably won't be able to economically upgrade the GPU (Expresscard PCIe enclosure + video card might work, but is not cheap) and hardware transcoder cards would have the same problem. CPU upgrades are usually possible, but quite expensive.The Raspberry Pis would work just fine (provided you have Ethernet), but you'll need some scripts to cut up the videos to send to the Pis and then stitch them back together.

One trick you can try is to put the laptop on a stand that has a powerful fan or two (mid range Delta or equivalent recommended, a high end Delta would easily blow a smaller laptop right off the stand) blowing a lot of air into the vents. But you'll most likely have to go for a desktop if you're looking for something that can handle constant load.

[EEVblog]

Or buy a nice GPU for the same price and get more uses.

I don't need more uses, and a faster GPU still means I"m stuck with the same two pass workflow.
A Matrox card would mean I don't have to do a 2nd pass in Handbrake.
Shame it doesn't work for Sony.

[Razor512]

some encoders will not use multiple cores effectively (also not all formats can encode using GPU acceleration.

also most of the GPU acceleration seems to be centered around the AVCHD format, though they do not give many details as to if the main GPU acceleration is using open cl, or CUDA.

If possible, try encoding to different formats to see if any others will cause more cores to be used.

If all else fails, see if you can export using an uncompressed format (if it goes faster), then use a converter such as winavi, or if you have a system with a CUDA enabled videocard, then use a program like badaboom to do the encode the video.

PS, depending on which version of adobe premiere pro  you used, adobe premiere pro cs6 will be very different (they have significantly improved the UI and rendering engine). I use it and render directly to h.264 and then upload to youtube (generally try to keep the size to around 1GB for a 20 minute video)

here are my export settings

[Lightages]

I don't understand the need to do a second pass at rendering. What settings are you rendering to in handbrake?

[EEVblog]

I don't understand the need to do a second pass at rendering. What settings are you rendering to in handbrake?

Sony Movie Studio (and others) do not offer a Constant Quality H.264 encoder. That means either BIG files sizes, or a compromise on compression with changing content. Either is not acceptable.

[Lightages]

I do not have that version  but rather Vegas 12 Pro so I am not sure what you have or don't. I can only assume you have poked around quite a bit looking for solutions. Here is one you might have missed. In the SONY AVC settings there is an option for render to "Memory Stick" with different options. Select one of the highest and then adjust to something like this but select your own preferences. This will give you a H264 render with constant bitrate although with limited rate selection. If you don't have this option then there might be others that do the same thing in your version:

[EEVblog]

PS, depending on which version of adobe premiere pro  you used, adobe premiere pro cs6 will be very different (they have significantly improved the UI and rendering engine). I use it and render directly to h.264 and then upload to youtube (generally try to keep the size to around 1GB for a 20 minute video)

And that's the problem with variable/average bitrate system, you have to guess what the optimal value is for quality vs detailed content for every video.
That's why I switched to using Constant Quality and Handbrake a long time ago. You don't have to worry about that, you get consistent quality every time, and the file is what it has to be, no more, no less.

Adobe Premiere Pro CS6 is $1333 - WTF? 

[EEVblog]

I do not have that version  but rather Vegas 12 Pro so I am not sure what you have or don't. I can only assume you have poked around quite a bit looking for solutions. Here i one you might have missed. In the SONY AVC settings there is an option for render to "Memory Stick" with different options. Select one of the highest and then adjust to something like this but select your own preferences. This will give you a H264 render with constant bitrate although with limited rate selection. If you don't have this option then there might be others that do the same thing in your version:

Yes ,I have looked at and tried all variations. That's not constant quality mode, so the same problems exist.

[Ed.Kloonk]

Dave,

Some random thoughts, if I may..

If you are shooting all the video in the same res, why not consider editing in Vdub or (what I prefer) avi_demux?

You can use a mode called 'copy' which trims videos to the nearest video keyframe to your selection. And you can append extra bits accordingly. The output is a file generates as fast as the hardrives will go as it is essentially a part-file copy.

No where near as polished an editing environment as the tools you use, but wonder if it is worth considering. It's quick and dirty but useful for me with my GoPro that squirts gigs of data and a God-awful Atom-based PC when I'm overseas and just want to send a video back home.

The long way round to my question, why cant you edit that way and just upload what you shot, only trimmed without all that damn re-encoding?

[Ed.Kloonk]

And btw,

I feel your pain with that rotten stream nonsense format on the sdcard from your camcorder. Someone gave me one of those cams last month to figure out and come up with a strategy for managing mega video data on a epic US holiday filming bonanza.


That file format. Why? 

[EEVblog]

The long way round to my question, why cant you edit that way and just upload what you shot, only trimmed without all that damn re-encoding?

Because I shoot in 12Mbps fixed bitrate. A typical 30min video would be 2.7GB in file size. At my upload speed, that would take at least 5 hours to upload as well.
I'd still need to produce the small podcast version as well.

Also, if I used something like Vdub (think I tried it once), I don't get the ability to add any text overlays or other effects as required (minimal as they may be).

[Ed.Kloonk]

The long way round to my question, why cant you edit that way and just upload what you shot, only trimmed without all that damn re-encoding?

Because I shoot in 12Mbps fixed bitrate. A typical 30min video would be 2.7GB in file size. At my upload speed, that would take at least 5 hours to upload as well.
I'd still need to produce the small podcast version as well.

Also, if I used something like Vdub (think I tried it once), I don't get the ability to add any text overlays or other effects as required (minimal as they may be).

Ah. Oki Dokie. Got it.

Thanks. 

[EEVblog]

I feel your pain with that rotten stream nonsense format on the sdcard from your camcorder
That file format. Why? 

It's standard-ish AVCHD, like used on most similar camcorders.

[EEVblog]

Ah. Oki Dokie. Got it.

That's what most people don't understand. I do things the way I do because I produce HD content and I do not have unlimited upload bandwidth, and I do it daily. File size, and extracting the best possible image quality for that given file size is everything. Hence my obsession with Constant Quality format encoders like x264 in Handbrake.