AVCHD transcoding with MultiAVCHD... SLOW (just 30% CPU usage)

[borst_one]

Hey,
long story short. I'm trying to transcode holdiay videos (mts files from a sony handycam 1080i) with AVCHD. I managed to understand the settings and how to change bitrate etc. But when I start the transcoding process, the program just uses around 30% of my CPU. I already found out that GPU supported encoding doesn't work with MultiAVCHD but still I would like to use my full cpu power (Got an Phenom II, sixore, 1090T, 6x3,2 GHZ). My first try to transcode 3 files (inital size roughly 10GiB) to a DVD-9 (7950GiB) took 15(!) hours for one of three files! I'm reading and writing from different hard disks and the one I'm writing on is an SSD. Moreover I already chose the fastes 1pass encoding (insane).

I would be very very thankful for a hint, what I am doing wrong or how I might speed up the transcoding process. Other people encode with 24-28 fps with a pc, that hast slower hardware. Oh I'm running Win7 64bit and installed all three needed codecs if that information helps or is needed.
Again, I'd be really grateful for help!

Here's the log from an older try (I already posted it in another thread):
https://forum.videohelp.com/threads/338732-Bluray-making?p=2135086#post2135086

kind regards,

borst_one

[poisondeathray]

Moreover I already chose the fastes 1pass encoding (insane).

Here's the log from an older try (I already posted it in another thread):
https://forum.videohelp.com/threads/338732-Bluray-making?p=2135086#post2135086

[17:23:09] *** Quality : One pass (insane)

"insane" used to correspond to an old set of encoder parameters, very slow, about 5-10x slower than using typical faster settings

multiavchd hasn't been updated in quite a while, but IIRC, there are faster settings you can use


EDIT nevermind, I must be drunk, it's using "ultrafast" settings

[17:23:09] *** Encoding : x264 options: --preset ultrafast -B 4726 --interlaced --direct spatial -I 25 --level 4 -i 24 -b 3 -m 0 -r 4 --ipratio 1.4 --vbv-bufsize 15000 --vbv-maxrate 14000 --qcomp 0.5 --threads auto --thread-input --aud --nal-hrd vbr --sar 1:1 --me dia --b-pyramid strict --slices 0 --weightp 0 --rc-lookahead 0 -o "G:\_TEMP\multiTEMP-20120117\2008-01_Suedafrika.[1920x1080-25.000].264" "G:\_TEMP\multiTEMP-20120117\20120117-172309-uncrop-running.avs"

[fritzi93]

That caught my eye too. Then I saw it was preset ultra fast.

There must be one hell of a bottleneck somewhere. IIRC, multiAVCHD doesn't use AviSynth, which will bottleneck on a 6-core CPU very noticeably with most any filtering; resizing, for instance.

I've only played with multiAVCHD briefly, so maybe this is a stupid question: Why is it resizing twice? PAR?

[01:34:52] *** Original : 1440x1080
[01:34:52] *** Crop : 0
[01:34:52] *** Resize : 1440x810
[01:34:52] *** Uncrop to : 1920x1080

[borst_one]

That caught my eye too. Then I saw it was preset ultra fast.

There must be one hell of a bottleneck somewhere. IIRC, multiAVCHD doesn't use AviSynth, which will bottleneck on a 6-core CPU very noticeably with most any filtering; resizing, for instance.

I've only played with multiAVCHD briefly, so maybe this is a stupid question: Why is it resizing twice? PAR?

[01:34:52] *** Original : 1440x1080
[01:34:52] *** Crop : 0
[01:34:52] *** Resize : 1440x810
[01:34:52] *** Uncrop to : 1920x1080

Hey,

thanks for your reply! Actually there is no other way to set it. So if you choose to resize, it uncrops the video too.
But on a second try of encoding (which I just quit since it was even slower) I used 1280x720 for both options.

But let's talk about the other point you mentioned: AviSynth. AFAIK it's mentioned in the 'must have' list, so that the program is able to function properly. So I don't guess thats the point.

I just tried to take read the media from my SSD and to write on the SSD. That was the only way I didn't check up to now. But also, no change.

And I find so many ppl who are still using MultiAVCHD and they're all happy with the results.

Any other tipps / hints / ideas?

It's not MultiAVCHD and it's not AVISynth as far as I can tell right now.

Again, thanks for help!

cheers

[fritzi93]

Well, if it's using AviSynth to resize, you won't fully use all your cores definitely. It's not optimized for that. But that's not the reason for the encode being *that* slow. I dunno...

As an aside, personally I wouldn't use an SSD for writing large files to, no real advantage in doing so.

Maybe one of the members well-versed in using multiAVCHD will be along to sort this out. Good luck.

[borst_one]

I'm also open for tipps concerning other - more acual - software which will support my CPU.
But it should have similar options to MultiAVCHD. I liked that tool very much, since I could easy set the desired target size and create a strict AVCHD format with strict folders (for all kind of BD players) and so on...
Tools that fully support my CPU don't offer at least the same amount of settings or customization. At least not the tools I found until now

[fritzi93]

AviSynth is fine, it just doesn't multi-thread well. And that's not really your problem.

I presume you want to use multiAVCHD mainly to author your AVCHD with menu. I wonder how it would go if you encoded each clip separately with, say, AVCHDCoder or RipBot (to BD-compliant output). Then author all your assets with multiAVCHD *without* re-encoding.

[borst_one]

Hey firtzi93,

thanks again for your fast replies. And that last one sounds like a smart plan
I guess I'll give it a try! Do I need any special codecs for te AVCHDCoder or the RipBOT? Do you recommend one of those two programs more than the other?

[borst_one]

well,
I tried your recommendations.
Result: AVCHDCodec is the same as MultiAVCHD, just 30% CPU-usage and moreover, I don't find a way to do just a one pass encoding.
And RipBOT. RipBOT acutally works great. Around 30fps while encoding. So quite a nice speed. But I have no possibility to determine a total output size for the files I'm adding. So, the only program that works, doesn't help me at all

[borst_one]

ok the source of the error is definitely the x264.exe
It's the encoder, and thats already all I know. Now the curious part. The x86 version of it works fine but just slow. Activating the x64 version of x264.exe (in the settings, file is also in the tools folder) leads to a direct error concerning the transcoding. The log just gives me:

[01:30:12] *** Encoding : One pass - content: [00:27:02]
[01:30:12] *** Encoding : x264 options: --preset ultrafast -B 8000 -I 50 --level 4 -i 24 -b 3 -m 0 -r 4 --ipratio 1.4 --vbv-bufsize 15000 --vbv-maxrate 14000 --qcomp 0.5 --threads auto --thread-input --aud --nal-hrd vbr --sar 1:1 --me dia --b-pyramid strict --slices 0 --weightp 0 --rc-lookahead 0 -o "C:\Program Files (x86)\multiAVCHD\_TEMP\multiTEMP-20120119\Aegypten_Sheradon_Soma_Bay.[1280x720-25.000].264" "C:\Program Files (x86)\multiAVCHD\_TEMP\multiTEMP-20120119\20120119-013012-uncrop-running.avs"
[01:30:12] *** Speed : 237169.59 fps (elapsed: 00:00:00 - Realtime x 9486.78)

[01:30:12] *** Transcoding failed!
[01:30:12] *** Check ffdshow/avisynth/haali (reinstall)!

and I'm absolutely sure that all tools are installed correctly.
So somehow my MultiAVCHD just cannot deal with the x64 version of x264.

RipBot doesn't have the slightest problem.

I just don't get it (

[fritzi93]

A long shot: uninstall Haali, manually delete its folder in Programs, run a registry cleaner and re-install/reboot.

Sometimes Haali can get corrupted and not even uninstall or re-install cleanly. That's why manually deleting the folder is important. Pretty sure the BDRB bug report thread was the first place I read that it can happen occasionally. Worth a try at this point. And I'm somewhat surprised no one else has chimed in yet on your issue.

[borst_one]

Hey fritz,

Good point with uninstalling haali and reinstalling it. But with your suggested program RipBot x264 works totally fine in x64 mode. Just MultiAVCHD and AVCHDCoder just cannot cope with the x64 versions of it. At least it seems like. As mentioned above, MultiAVCHD always crashes and gives me an error output. AVCHD Coder in contrast to that just doesn't run the x64 version of x264, even though I acitvated 64bit encoding in the options before. I also tried to reinstall ffdshow as 64bit version, no change. I ALSO copied the working x264 64bit version from the RibBOT tools folder to AVCHDCoder and / or MultiAVCHD. No help or change Just errors!

But do you say it still could be related to Haali? Even though RipBot works fine with the 64bit version?

[fritzi93]

No, I don't really expect it to help, but it's easy to do. And I've seen stranger solutions. Just threw that out there. I have to think that either there's something odd with the source files or something wrong with your configuration.

As to configuration: Again, I can't help you specifically with multiAVCHD. However, I've used a number of programs that rely the same auxiliary tools, and I don't think using 64-bit versions is going to be the answer.

BDRB, for instance, works fine with the tested and recommended 32-bit versions, and can use all my six cores at near 100% when encoding. If you can configure BDRB correctly, in my experience all other programs that use the same tools will be fine as well.

So forgive me for stating some obvious points: First of all, no codec packs. Install only the versions tested by jdobbs and linked on the first page of the bug report thread. (Just click BDRB and go to the author's website). Right-click the BDRB executable and if there's a problem, it should offer to fix your configuration. (Assuming you're using Win7). If everything checks out okay, then AVCHDCoder and RipBot will be fine as well.

That should eliminate possible configuration problems. As to the rest, I'm afraid I'm not going to be much help, sorry. Good luck.

[borst_one]

hey fritz,

thanks again for your reply. Even though I opened up a new post related to my speed problem, you're still the only person who replies to my questions. Maybe I choose me name unwisely? No idea.

Well, I thought that x264 64bit is the solution since RipBot, which uses the 64bit version, nearly cranked my CPU and rushed through the encoding-process. Besides that, I have no codec packs installed. Normally I have NOTHING installed in terms of codecs. I only installed Haali, AviSynth and ffdshow since all three tools (RipBot, AVCHDCoder and MultiAVCHD) required those. As you suggested, I'll give BDRB a try. I hope it does offer the same options as MultiAVCHD when it comes to create AVCHD compliant and folder-strict DVD-9s. Without that - like RipBot - the tool is useless for me.

I'll keep you posted!

regards from Germany

[edit]
I'm not allowed to post a new topic about problems with the 64bit versions of x264. So I just added it here. Even though it's a different topic or let's better say the solution for a low cpu usage will most people put on the user's inability to handle the program. Not working x64 codec might be something other people already recognized.
Well, thanks to an amazingly user-friendly admin, I cannot use a new topic for that.
And before I get blamed again, I edited my last post so that i don't get the screwed due to double posting -.-

Hey guys,
I'm trying to transcode holiday videos for a friend. Whilst I was very happy to find tools like MultiAVCHD and AVCHDCoder which offered all the options and settings I needed (joining of mts files, reencoding as strict AVCHD compliant dvd-9) both tools only transcode with the 32bit version of x264. That leads to a cpu usage of just 30% on my AMD PhenomII sixcore. A forum user recommended I should try RipBot. That tool works fine with the 64bit version of x264 and due to that, I'm able to encode the video media with roundabout 32 fps in contrast to 10 fps with AVCHDCoder or just 1.4 (! - yes 1.4) frames with MultiAVCHD.

Both tools offer me the option to active 64bit encoding in the settings but both tools don't work after activating it. MultiAVCHD just says transcoding failed
01:30:12] *** Encoding : One pass - content: [00:27:02]
[01:30:12] *** Encoding : x264 options: --preset ultrafast -B 8000 -I 50 --level 4 -i 24 -b 3 -m 0 -r 4 --ipratio 1.4 --vbv-bufsize 15000 --vbv-maxrate 14000 --qcomp 0.5 --threads auto --thread-input --aud --nal-hrd vbr --sar 1:1 --me dia --b-pyramid strict --slices 0 --weightp 0 --rc-lookahead 0 -o "C:\Program Files (x86)\multiAVCHD\_TEMP\multiTEMP-20120119\Aegypten_Sheradon_Soma_Bay.[1280x720-25.000].264" "C:\Program Files (x86)\multiAVCHD\_TEMP\multiTEMP-20120119\20120119-013012-uncrop-running.avs"
[01:30:12] *** Speed : 237169.59 fps (elapsed: 00:00:00 - Realtime x 9486.78)

[01:30:12] *** Transcoding failed!
[01:30:12] *** Check ffdshow/avisynth/haali (reinstall)!


and ACHDCoder just uses the 32bit version instead of the x64 version. I even tried to overwrite the 32bit versions with the 64bit versions. That solution led to non encoding at all in both tools.

I would be so grateful for an explanation or help!!

cheers from Germany

[poisondeathray]

Because the author(s) didn't include the 64bit pipe . If the author(s) use avisynth in the back end, you need some other programs to pipe it to 64bit x264 . Dean, the mavchd developer is no longer actively developing it, but the avchdcoder developer is still active. You can contact him at doom9 forums and make a request

[borst_one]

Because the author(s) didn't include the 64bit pipe . If the author(s) use avisynth in the back end, you need some other programs to pipe it to 64bit x264 . Dean, the mavchd developer is no longer actively developing it, but the avchdcoder developer is still active. You can contact him at doom9 forums and make a request

hey poisondeathray,

thanks for your replay and the tipp! I'll try contacting him!

[poisondeathray]

Here is the thread for avchdcoder
http://forum.doom9.org/showthread.php?t=146867

[borst_one]

*thumbsup*

[edit]
well... I just registered at doom9.. and since you're not allowed to post or reply before you are registered for at least five days, I have no idea what to do now.

Is there any other tool with the same capabilites like multiavchd which was not mentioned until now? Since nothing works right now I'm still open to test anything...