Ok, so im trying to rip a dvd. I first tried it in windows, with 2 pass encoding, which should take longer right? Took about...3-4 hours to finish.
now im trying to rip the same dvd in linux, using the HandBrakeGTK gui frontend. Im trying to do a one pass encode, but have fast deinterlacing, and have a different container format (mkv instead ogm)...and its been 6 hours and its only half finished?
is there a reason why its taking so long? Is it the GUI? I know im not using the same exact settings, but i doubt that encoding to mkv or having fast deinterlacing is causing it to take 10 hours longer then over the windows version.Cause if its taking 12+ hours per dvd...on a one pass encode, that means i have to dedicate a day to ripping one dvd...which i really dont want to do
any suggestions?
Why does the linux version takes so long?
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
-
redraiderbum
- Enlightened
- Posts: 132
- Joined: Thu Jun 21, 2007 3:53 am
It shouldn't be the GUI because it's just a wrapper for the CLI version. You didn't post any of your other settings, which would have been helpful.
Is it possible that you are using constant quality rather than ABR? CRF can only be one pass, but it can be significantly longer than two pass ABR. I'm assuming this is some sort of dual boot setup so it is a fair comparison?
Also, are you running a 32-bit or 64-bit distro? I ask because, for reasons beyond my comprehension, when I ran a 32-bit distro on a 64-bit processor x264 did not recognize the cpu optimizations so it ran REALLY slow.
Deinterlacing can add a significant amount of time to an encode, it depends on the video encoded, but usually it doesn't triple the encode time. If you know how to use the CLI you could try that to make sure it's not the GUI. At the CLI it should tell you if the cpu optimizations are being recognized; it'll say something like:
If none of that works, I'm going to need a lot more info... What distro, type of processor, all encode settings (they should be in that que window). I will setup to test it if you can't get it working.
Is it possible that you are using constant quality rather than ABR? CRF can only be one pass, but it can be significantly longer than two pass ABR. I'm assuming this is some sort of dual boot setup so it is a fair comparison?
Also, are you running a 32-bit or 64-bit distro? I ask because, for reasons beyond my comprehension, when I ran a 32-bit distro on a 64-bit processor x264 did not recognize the cpu optimizations so it ran REALLY slow.
Deinterlacing can add a significant amount of time to an encode, it depends on the video encoded, but usually it doesn't triple the encode time. If you know how to use the CLI you could try that to make sure it's not the GUI. At the CLI it should tell you if the cpu optimizations are being recognized; it'll say something like:
Look for it just above the ETA line, above is what you want. If it says:x264[cpu capabilities]:3dNow, SSE1, SSE2
That's the problemx264[cpu capabilities]:none
If none of that works, I'm going to need a lot more info... What distro, type of processor, all encode settings (they should be in that que window). I will setup to test it if you can't get it working.
whoops, i forgot to add at the end that i was using the same (or similiar) settings...my bad!
so on windows, i did 2 pass, OGM + xvid + vorbis, anamorphic par , everything else automatic or default (no interlacing
and on linux, i did 1 pass mkv + xvid + vorbis , anamorphic par , everything else automatic or default (fast interlacing)
but even when i tried it on linux with OGM + xvid + vorbis and no interlacing when i was just trying out the handbrakeGTK gui...it was still taking a massive amount of time compared to the windows version
and i am running a 32 bit processor on a 32 bit distro, so i doubt that was a problem
and here is the exact string that handbrakeGTK is saying that its using:
so on windows, i did 2 pass, OGM + xvid + vorbis, anamorphic par , everything else automatic or default (no interlacing
and on linux, i did 1 pass mkv + xvid + vorbis , anamorphic par , everything else automatic or default (fast interlacing)
but even when i tried it on linux with OGM + xvid + vorbis and no interlacing when i was just trying out the handbrakeGTK gui...it was still taking a massive amount of time compared to the windows version
and i am running a 32 bit processor on a 32 bit distro, so i doubt that was a problem
and here is the exact string that handbrakeGTK is saying that its using:
and JUST in case someone says i have a crappy computer..... it took 3 hours in windows and i have a 2.1 ghz cpu and a gig of ram, so i doubt its my computer being slow-i "/media/cdrom0/VIDEO_TS" -t 1 -o "/home/mark/Desktop/cfhs_band_day.mkv" -e xvid -E vorbis --crop 0:0:0:0 --deinterlace=1 -p -b 1000 -B 160 -R 48 -6 mono
Polygon wrote:and on linux, i did 1 pass mkv + xvid + vorbis , anamorphic par , everything else automatic or default (fast interlacing)
Okay, yadif certainly isn't fast deinterlacing. You really don't see a significant speed up when you take deinterlace=1 out of your command line?Polygon wrote:-i "/media/cdrom0/VIDEO_TS" -t 1 -o "/home/mark/Desktop/cfhs_band_day.mkv" -e xvid -E vorbis --crop 0:0:0:0 --deinterlace=1 -p -b 1000 -B 160 -R 48 -6 mono
Oh, just wonderful. So the guy doing the Linux front-end doesn't even bother keeping his released builds synced or check his widgets against documentation.Polygon wrote:I selected "original" interlacing in the HandbrakeGTK gui...and it had a (fast0 next to it so id thought id try it.
And his sourceforge CVS is empty, so there's no way of knowing if he's fixed it in his local code.
To be fair to the dude working on the HBGTK frontend (me) I would say that he is a hobbyist programmer who writes a lot of specific use software for his own limited personal use. He is also currently employed away from his home in a country where the only internet service is a couple crappy sat dishes shared by a couple thousand people. His job pays him based on salary so he tends to be working 10-12 hour days, 7 days a week. He currently working towards his CS degree, and enrolled in a class that is just kicking his @ss right now. In between all of this he's managed to port all of the WinGUI code to Linux, which ended up being harder than he thought, the GTK forms handle quite a few things differently than WinForms, especially since some of the threading code that works in Windows causes the Linux version to become unresponsive during certain operations. He is also working on expanding the code base beyond the WinGUI version to work more like the MacOS version.
If there is no CVS setup and the Sourceforge account is no more than a place to store the uploaded files, then please forgive him. I don't think he is very familiar with how to use these things to begin with.
Oh and if there are any descrepencies between the options in the Linux version and the other two versions, they will definitely be fixed before I upload any more updates. Notice the README says "ALPHA". Plus, I think I'm going to need to rewrite the queue system as well, too many people having weird problems that I think has something to do with mono's way of handling linux threads.
If there is no CVS setup and the Sourceforge account is no more than a place to store the uploaded files, then please forgive him. I don't think he is very familiar with how to use these things to begin with.
Oh and if there are any descrepencies between the options in the Linux version and the other two versions, they will definitely be fixed before I upload any more updates. Notice the README says "ALPHA". Plus, I think I'm going to need to rewrite the queue system as well, too many people having weird problems that I think has something to do with mono's way of handling linux threads.
jbrjake wrote:Oh, just wonderful. So the guy doing the Linux front-end doesn't even bother keeping his released builds synced or check his widgets against documentation.Polygon wrote:I selected "original" interlacing in the HandbrakeGTK gui...and it had a (fast0 next to it so id thought id try it.
And his sourceforge CVS is empty, so there's no way of knowing if he's fixed it in his local code.
If that is your intent, then I think you may want to consider developing this gui in a more coordinated fashion with the rest of the development team, so we have something approaching symmetry between the gui's at least from a feature accuracy perspective.th3rmite wrote:He is also working on expanding the code base beyond the WinGUI version to work more like the MacOS version.
Frankly, since you have pretty much developed this on your own, with little or no coordination with the rest of the HB development team, there is little help we can offer any users of your gui and it appears from above that you are a very busy person.
So I see you finally set up an SVN.
I also see you haven't fixed the deinterlacing bug yet
There are a bunch of other bugs I see as well, like the Classic preset using x264 instead of ffmpeg. You should always work off the latest code. You're now dozens of revisions behind. As a developer on the project, it's very frustrating to fix a bug, but know it's still being distributed to hundreds of people. Everyone else follows the Trac timeline to keep up to date.
I'm especially concerned about the x264 options. You really should have consulted either me or dynaflash, or at least looked at our code in the Mac GUI. We worked through, months and months ago, all sorts of errors and edge cases, and it'd behoove you to learn from example instead of reinventing the wheel. I've already had to warn Scott not to integrate your options panel, because it simply does not work the same as the Mac one. I included a whole section in the wiki on synonymous x264 option names to aid in replicating the Mac advanced tab. Also, if you're going to retain copyright of your source files and maintain it as a separate project, could you please mention in a comment that you're copying the presets and their word for word written descriptions from the HandBrake project?
It's okay that you don't have time to be on the forum regularly, but understand that this leaves all of the rest of us with the burden of supporting your work. For this reason, it would be incredibly beneficial if you kept your interface's behavior consistent with the rest of the project. It's the only way tech support for a cross-platform application can work.
I'm also concerned that you don't show interest in relevant development threads. Are you aware of the stdout/stderr change? Are you preparing for the new CLI preset system I just checked in, or the short names for filter parameters that went in weeks ago?
We're all hobbyist programmers here. What's important is collaboration.
I also see you haven't fixed the deinterlacing bug yet
There are a bunch of other bugs I see as well, like the Classic preset using x264 instead of ffmpeg. You should always work off the latest code. You're now dozens of revisions behind. As a developer on the project, it's very frustrating to fix a bug, but know it's still being distributed to hundreds of people. Everyone else follows the Trac timeline to keep up to date.
I'm especially concerned about the x264 options. You really should have consulted either me or dynaflash, or at least looked at our code in the Mac GUI. We worked through, months and months ago, all sorts of errors and edge cases, and it'd behoove you to learn from example instead of reinventing the wheel. I've already had to warn Scott not to integrate your options panel, because it simply does not work the same as the Mac one. I included a whole section in the wiki on synonymous x264 option names to aid in replicating the Mac advanced tab. Also, if you're going to retain copyright of your source files and maintain it as a separate project, could you please mention in a comment that you're copying the presets and their word for word written descriptions from the HandBrake project?
It's okay that you don't have time to be on the forum regularly, but understand that this leaves all of the rest of us with the burden of supporting your work. For this reason, it would be incredibly beneficial if you kept your interface's behavior consistent with the rest of the project. It's the only way tech support for a cross-platform application can work.
I'm also concerned that you don't show interest in relevant development threads. Are you aware of the stdout/stderr change? Are you preparing for the new CLI preset system I just checked in, or the short names for filter parameters that went in weeks ago?
We're all hobbyist programmers here. What's important is collaboration.