BlueWhite64 stigma

jjthomas · 01-01-2009, 06:09 AM

If they (BW and S64) do it for profit, then the one that offers the most for the least will win out. If they do it for the community and for the love of doing it, then it really doesn't matter. I do Video and Audio Engineering, 64bit works very nice for me. On the computers I have that work with 32 bit, they have a 32 bit OS on them.

It's all going to be moot in 2010 anyway. CP/M is going to make a comeback and blow *nix out of the water.

-JJ

titopoquito · 01-05-2009, 03:01 AM

Quote:

Originally Posted by SqdnGuns

Someone explain to me the advantage of a standard desktop OS that is 64bit?

Is something going to load a millisecond faster?

I have Slamd64 installed only for video encoding, but I guess the same would be true for BW64. Encoding a video in two pass encoding (xvid or x264) takes LOTS of time. On 64bit I get about 50 % plus fps compared to 32bit, so the encoding time drops by ca. 1/3. That is much if you encode a lot - 4 hours compared to 6 hours makes a big difference for me

I guess there will be other tasks, like highly computational ones (maybe statistics and such) that might profit from 64bit, but I have not tested it.

Alien Bob · 01-05-2009, 09:15 AM

Quote:

Originally Posted by titopoquito

I have Slamd64 installed only for video encoding, but I guess the same would be true for BW64. Encoding a video in two pass encoding (xvid or x264) takes LOTS of time. On 64bit I get about 50 % plus fps compared to 32bit, so the encoding time drops by ca. 1/3. That is much if you encode a lot - 4 hours compared to 6 hours makes a big difference for me

I guess there will be other tasks, like highly computational ones (maybe statistics and such) that might profit from 64bit, but I have not tested it.

Hi titopoquito

Do you have some commandline examples available that can be used as computational benchmarks? Using ffmpeg would be cool.

Eric

SqdnGuns · 01-05-2009, 10:12 AM

Quote:

Originally Posted by titopoquito

I have Slamd64 installed only for video encoding, but I guess the same would be true for BW64. Encoding a video in two pass encoding (xvid or x264) takes LOTS of time. On 64bit I get about 50 % plus fps compared to 32bit, so the encoding time drops by ca. 1/3. That is much if you encode a lot - 4 hours compared to 6 hours makes a big difference for me

I guess there will be other tasks, like highly computational ones (maybe statistics and such) that might profit from 64bit, but I have not tested it.

Thanks.............I only encode once every blue moon but I do see how this is an advantage. I'm going to give SlamD64 a shot when 12.2 is released.

titopoquito · 01-05-2009, 11:28 AM

Quote:

Originally Posted by Alien Bob

Hi titopoquito

Do you have some commandline examples available that can be used as computational benchmarks? Using ffmpeg would be cool.

Eric

Hi Eric, sorry but I use mencoder, not ffmpeg. This multimedia encoding stuff was driving me kind of nuts, and I settled with my working script once I had found it. As you see I am using x264, ogg and matroska as container. If you want, I could also post the same with xvid and avi container format, which worked for me nicely too. Post a reply if you would like to see it

I use the script on MPEG files that I record with Kaffeine from DVB-T and cut with dvbcut. With "German" as default name for the sound as you can see

EDIT: As you can see some stuff is hardcoded that I don't change, like ogg quality, the mentioned German audio and also that the name of the input-mpeg file has to end with "mpg", which has to be omitted when given as parameter. I call it like that:

Code:

dvb-convert.sh "Name of the video without dot ending" 1100 "528:560:8:8"

, depending on the real crop values of course.

Code:

#!/bin/bash

BITRATE=$2
OGGQU="5"


NAME="$1"
CROPPARM="$3"

if test "$3" != ""; then
    CROP=" crop=${CROPPARM},"
else
    CROP=""
fi

mplayer "$NAME.mpg" -ao pcm:fast:waveheader:file="$NAME.wav" -vo null


normalize "$NAME.wav" && oggenc "$NAME.wav" -q "$OGGQU" -o "$NAME.ogg" && rm "$NAME.wav"


mencoder "$NAME.mpg" -o /dev/null \
-ovc x264 -vf ${CROP}pp=ci,harddup -of rawvideo \
-passlogfile "$NAME.log" \
-x264encopts subq=5:frameref=2:bframes=3:me=umh:subme=1:b_pyramid:weight_b:turbo=1:pass=1:psnr:bitrate=$BITRATE \
-of rawvideo -o /dev/null -nosound

mencoder "$NAME.mpg" -o /dev/null \
-ovc x264 -vf ${CROP}pp=ci,harddup -of rawvideo \
-passlogfile "$NAME.log" \
-x264encopts subq=6:partitions=all:8x8dct:frameref=3:bframes=3:me=umh:subme=6:b_pyramid:weight_b:pass=2:psnr:bitrate=$BITRATE \
-of rawvideo -o "$NAME.264" -nosound

mkvmerge "$NAME.264" --track-name 0:"deutsch" --language 0:ger "$NAME.ogg" -o "$NAME _ x264@$BITRATE-ogg@$OGGQU.mkv" --title "$NAME"

titopoquito · 01-06-2009, 06:12 PM

Please take the values I gave with a little bit of caution. I know I had really serious gains in the past, but did a little test to give some real life real video values. It happened like it had to happen, the gain with my chosen video file was much smaller (14,0 fps on my Slackware 12.1 system versus 16,73 fps on Slamd64 12.1, same video file, second pass of a x264 encoding, values taken at 14 % of the whole film so the sample was about 12,5 minutes long).

I suspect the values might differ significantly with the source video files, that's the best vague reason I can give for my result.

titopoquito · 01-16-2009, 08:39 AM

Quote:

Originally Posted by titopoquito

Please take the values I gave with a little bit of caution.

My real life results as a last post for those interested.

I have done two different encodings on the same machine, an AMD Athlon 64 3700+ with 1,28GB RAM. Source material was a recorded DVB-T stream of about half an hour. I used mencoder from mplayer 1.0rc2 with xvidcore 1.1.3, lame 3.97 and x264 snapshot from 20080718.

Encoding 1: 2-pass conversion to x264, video encoding only.
Encoding 2: 2-pass conversion to xvid and mp3 at the same time.

Code:

Encoding 1, x264, video only

        Slackware 12.1    Slamd64 12.1    fps gain in %
pass 1       30,72 fps       37,78 fps             23 *
pass 2       14,87 fps       18,04 fps             21 *


Encoding 2, xvid and mp3 (lame) 

        Slackware 12.1    Slamd64 12.1    fps gain in %
pass 1       48,17 fps       51,74 fps             10 *
pass 2       33,63 fps       40,10 fps             19 *

* computed as Slamd64 value divided by Slackware value. 
If you compute the other way round (to compute a loss against the Slamd64 values) you get of course a little bit lower numbers!

It's only a comparison with one video file, I dunno how much the results may vary with different files. It certainly does not serve as a comparison between xvid and x264, so please don't try to conclude from my results that xvid is X times faster than x264 - the options I used are not equivalent, only similar.

But I think that it might serve as a hint on how much circa your encoding with 64bit might increase. Not that much as I thought first, but it's not neglectable as well.

Thanks for listening. Any questions?

rob.rice · 01-27-2009, 01:36 PM

Quote:

Originally Posted by SqdnGuns

I see 64bit OS as a waste unless you are running a server. Maybe they will become relevant for a desktop OS when all apps are 64bit as well.

ALL THE APPs ARE 64BIT

Your point of view would change drastically.
IF
1.)you had a 64bit compatible computer this means that it has 64bit data paths to at least the hard drive,video adepter and most importantly the memory as well as a 64bit CPU (of course )
2.)you installed a 64bit distro what ever 64bit distro

my 2 cents as long as you have this point of view is that you should stay out of this subforum until you lose your present point of view

I know that I already replied to that post I'm just in one of those moods

XavierP · 01-27-2009, 01:44 PM

@Rob - chill out dude. SqdnGuns is entitled to his opinion, as is every member here. While he may be a bit controversial on occasion, he's not a troll and is helpful - as are you. Telling people to get out of any forum or subforum is never a good idea and gets you tarred with the same brush.

So let's all be friends, eh. I'll even help you out: SqdnGuns, what makes you hold that opinion, since so many other members would clearly disagree?

rob.rice · 01-27-2009, 05:56 PM

Thank You
they could ask me to stay out of the
youbumtoo subforum any time any distro with out root access is not linux

rhomp2002 · 03-19-2009, 12:12 AM

Since Patrick has already complimented Arny for what he has done on BlueWhite64, I would assume that when the time comes, Patrick will just join up with what Arny for one has done and bring it into the fold. Very talented guy, easy to work with and responds very quickly to any questions. Highly recommend this distro. Very nice to work with.

Alien Bob · 03-19-2009, 04:18 AM

PAtrick never complimented arny for the work he has done. He wished him luck in his efforts to create his 64bit port: http://www.bluewhite64.com/e107_plug...ewtopic.php?56 but that was around the time bluewhite64 went public, so nothing was known about how it was created. There is no reason for Bluewhite64 to have any advantages over other 64bit ports like slamd64 (which is what Bluewhite64 is based on), the 64bit Vector or any other version.

They're all derivatives of Slackware.

A Slackware 64bit release, will be Slackware.

Eric

SqdnGuns · 05-20-2009, 11:45 AM

Quote:

Originally Posted by Alien Bob

They're all derivatives of Slackware.

A Slackware 64bit release, will be Slackware.

Eric

And it's nice to see x64 Slackware in Current!! Thanks for the hard work Eric!!

psychicist · 05-24-2009, 07:30 AM

Yes it's great to see x64 Slackware in current, but what does that have to do with Bluewhite64? As far as I know arny has done a lot of hard work as well, why isn't he thanked for that too?

tpreitzel · 05-26-2009, 12:13 PM

Quote:

Originally Posted by psychicist

Yes it's great to see x64 Slackware in current, but what does that have to do with Bluewhite64? As far as I know arny has done a lot of hard work as well, why isn't he thanked for that too?

Agreed... x2

Excellent work and SUPPORT, Arny!