Log in

View Full Version : Rev 408 very slow to encode...


DigitalDivide
24th January 2006, 15:20
I downloaded x264 rev 408 and encoded a movie as usual using MeGUI - HQ Slower profile. Normally an encode takes about 20hrs on my pc. I let it run all night and when I come home from work it's all done. However, with rev 408 my encodes using the same settings as always, seems to be taking about an extra 5 or 6 hours. I noticed that the fps goes down to 1.5 while encoding. Has anyone else noticed this?

The only item that has changed is that I installed rev 408 and using SAR for the first time. Does using SAR add to the encoding time?

MetalPhreak
24th January 2006, 15:31
Not SAR specifically but if you're encoding anamorphically(sp?), then you'll have a larger video frame to encode - hence more calculations on MV's etc.

bond
24th January 2006, 16:30
Not SAR specifically but if you're encoding anamorphically(sp?), then you'll have a larger video frame to encode - hence more calculations on MV's etc.when using sar you normally have a smaller video size

DigitalDivide
- whats your video resolution in the slowed down encode and whats the res with the normal encode
- which compile are you using with the slowdown (link) and which one did you use without slowdown
- whats your input framerate?
- whats your output format (mp4, mkv)?

MetalPhreak
24th January 2006, 16:36
when using sar you normally have a smaller video size

How do you get that? For example a recent encode of mine: Sin City (R2 PAL):
Anamorphic: 704x544
Non-anamorphic: 704x368

Edit
----
Remembered that it will be bigger if resizing horintally to something like 1024x544 in my case mentioned above. But who does this?

bond
24th January 2006, 17:03
on a pal dvd the video resolution is 720x576.
during playback this gets anamorphically resized to something like 1024x576

therefore when encoding a clip which should be anamorphically resized during playback you normally have a smaller res than when resizing the clip before encoding

MetalPhreak
24th January 2006, 17:15
@bond
Seems you posted while I was editing my post. Enough arguing about apples and oranges. If it is not the size of the video frame slowing it down it *might* (though I'm guessing) be due to the recent bugfix with regard to MV's, but I doubt it.

DigitalDivide
24th January 2006, 18:39
I downloaded 408 from here
http://forum.doom9.org/showthread.php?t=89979 and selected the light version. Then just copied over the new files. I am encoding to .mkv. My source is NTSC by the way.

Unfortunately I'm at work right now and can't get all the info to you. Might be difficult as I don't think I saved the MeGUI log however, but I'll know when I get home.

I believe the last revision I used which was quicker was 403 or so. I'll have to check if I have that version sitting somewhere. Sometimes I back it up before copying over a newer revision.

I'll be encoding another movie tonight so I will try to provide the info if I am not able to provide it when I get home. I could probably do a test using small sample with both 408 and 403 with and without using SAR.

bond
24th January 2006, 18:49
I downloaded 408 from here
http://forum.doom9.org/showthread.php?t=89979 and selected the light version. Then just copied over the new files. I am encoding to .mkv. My source is NTSC by the way.sharktooths compiles are including patches for testing, i wouldnt recommend using it for whole backups

therefore also try the pure 408 compile from here: http://x264.nl/ and see if it also slows down

DigitalDivide
24th January 2006, 19:41
Originally Posted by Bond
sharktooths compiles are including patches for testing, i wouldnt recommend using it for whole backups

therefore also try the pure 408 compile from here: http://x264.nl/ and see if it also slows down

See I didn't know that! If I select the x264 Installer, does that only install the codec or does it also install MeGUI? I don't want to update MeGUI at the moment. BTW the rev on the link is now 409. I'll try 409 and see if that makes a diff. Thanks!

bond
24th January 2006, 19:50
See I didn't know that! If I select the x264 Installer, does that only install the codec or does it also install MeGUI? doesnt install megui afaik

xDrJx
24th January 2006, 20:16
doesnt install megui afaik

installs megui-x264 as "x264 command line interface encoder"

DigitalDivide
25th January 2006, 02:27
WHen I right click the file to check the properties I get a Pixel Size of 720x480 and a display size of 854x480.

Well here's the log from MeGUI

Next job job2-1 is a video job. encoder commandline:
"C:\Program Files\x264\x264.exe" --pass 1 --bitrate 2132 --stats "D:\Projects\Lord of War\Lord_of_War.stats" --bframes 3 --b-pyramid --subme 1 --analyse none --me dia --threads 2 --sar 720:607 --progress --no-psnr --output NUL "D:\Projects\Lord of War\Lord_of_War.avs"
successfully set up video encoder and callbacks for job job2-1
----------------------------------------------------------------------------------------------------------

Log for job job2-1

avis [info]: 720x480 @ 23.98 fps (175176 frames)
x264 [info]: using SAR=720/607
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:1460 Avg QP:16.37 size: 46116
x264 [info]: slice P:71095 Avg QP:18.17 size: 17330
x264 [info]: slice B:102621 Avg QP:20.11 size: 6397
x264 [info]: mb I I16..4: 35.3% 0.0% 64.7%
x264 [info]: mb P I16..4: 25.0% 0.0% 0.0% P16..4: 63.9% 0.0% 0.0% 0.0% 0.0% skip:11.1%
x264 [info]: mb B I16..4: 2.7% 0.0% 0.0% B16..8: 49.5% 0.0% 0.0% direct:17.7% skip:30.1%
x264 [info]: final ratefactor: 19.00
x264 [info]: kb/s:2141.6

Actual bitrate after encoding without container overhead: 2142.67

----------------------------------------------------------------------------------------------------------
job job2-1 has been processed. This job is linked to the next job: job2-2
Next job job2-2 is a video job. encoder commandline:
"C:\Program Files\x264\x264.exe" --pass 2 --bitrate 2132 --stats "D:\Projects\Lord of War\Lord_of_War.stats" --ref 10 --mixed-refs --bframes 3 --b-pyramid --subme 6 --b-rdo --weightb --trellis 1 --analyse all --8x8dct --me umh --threads 2 --sar 720:607 --progress --no-psnr --output "D:\Projects\Lord of War\Lord_of_War.mkv" "D:\Projects\Lord of War\Lord_of_War.avs"
successfully set up video encoder and callbacks for job job2-2
----------------------------------------------------------------------------------------------------------

Log for job job2-2

avis [info]: 720x480 @ 23.98 fps (175176 frames)
x264 [info]: using SAR=720/607
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:1460 Avg QP:16.22 size: 43918
x264 [info]: slice P:71095 Avg QP:17.74 size: 16642
x264 [info]: slice B:102621 Avg QP:19.60 size: 6819
x264 [info]: mb I I16..4: 31.0% 52.6% 16.4%
x264 [info]: mb P I16..4: 6.5% 9.0% 2.1% P16..4: 42.1% 17.3% 10.2% 0.4% 0.2% skip:12.2%
x264 [info]: mb B I16..4: 0.6% 1.0% 0.2% B16..8: 52.8% 2.0% 2.2% direct: 2.2% skip:39.0%
x264 [info]: 8x8 transform intra:51.6% inter:52.8%
x264 [info]: ref P 53.3% 16.8% 9.5% 5.1% 3.7% 3.5% 3.0% 1.8% 1.5% 1.6%
x264 [info]: ref B 63.2% 16.5% 6.3% 4.0% 2.3% 2.1% 2.0% 1.4% 1.1% 1.1%
x264 [info]: kb/s:2131.9

Actual bitrate after encoding without container overhead: 2132.92
desired video bitrate of this job: 2132 kbit/s - obtained video bitrate: 2135.67064749692 kbit/s
----------------------------------------------------------------------------------------------------------
job job2-2 has been processed. This job is linked to the next job: job2-3
Next job job2-3 is a mux job. mp4box commandline:
"C:\Program Files\MKVtoolnix\mkvmerge.exe" -o "D:\Projects\Lord of War\Lord_of_War-muxed.mkv" --aspect-ratio 0:720/607 -A -S "D:\Projects\Lord of War\Lord_of_War.mkv" --language 0:eng -a 0 -D -S "D:\Projects\Lord_of_War T01 3_2ch 448Kbps DELAY 0ms.ac3" --language 0:eng -s 0 -D -A "D:\temp\VTS_01_0.idx" --no-clusters-in-meta-seek
successfully set up muxer and callbacks for job job2-3
----------------------------------------------------------------------------------------------------------

Log for job job2-3

mkvmerge v1.6.5 ('Watcher Of The Skies') built on Dec 7 2005 18:53:31
'D:\Projects\Lord of War\Lord_of_War.mkv': Using the Matroska demultiplexer.
'D:\Projects\Lord_of_War T01 3_2ch 448Kbps DELAY 0ms.ac3': Using the AC3 demultiplexer.
'D:\temp\VTS_01_0.idx': Using the VobSub subtitle reader (SUB file 'D:\temp\VTS_01_0.sub').
'D:\Projects\Lord of War\Lord_of_War.mkv' track 1: Using the MPEG-4 part 10 (AVC) video output module.
Track 1 of 'D:\Projects\Lord of War\Lord_of_War.mkv': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 854/480.
'D:\Projects\Lord_of_War T01 3_2ch 448Kbps DELAY 0ms.ac3' track 0: Using the AC3 output module.
'D:\temp\VTS_01_0.idx' track 0: Using the VobSub subtitle output module (language: en).
Warning: 'D:\Projects\Lord of War\Lord_of_War.mkv': A track with the ID 0 was requested but not found in the file. The corresponding option will be ignored.The file 'D:\Projects\Lord of War\Lord_of_War-muxed.mkv' has been opened for writing.

The cue entries (the index) are being written...
Muxing took 290 seconds.

----------------------------------------------------------------------------------------------------------
Muxjob ended and deletion of intermediate files is activated
Found intermediate output file 'D:\Projects\Lord of War\Lord_of_War.mkv', deleting...

And here's my AVS file.

# Created with Gordian Knot
#
# http://gknot.doom9.org

# PLUGINS
LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\Program Files\GordianKnot\AviSynthPlugins\UnDot.dll")


# SOURCE
mpeg2source("D:\Projects\Lord_of_War.d2v")

# CROPPING
crop(4,0,-4,-2)

# RESIZING
LanczosResize(720,480)

# DENOISING: choose one combination (or none)
Undot()

Zero1
25th January 2006, 02:44
Probably unrelated to your problem, but an observation. How about trying a 32/27 as your SAR?

DigitalDivide
25th January 2006, 03:10
Probably unrelated to your problem, but an observation. How about trying a 32/27 as your SAR?

To be honest I'm at a total lost for how to get the correct SAR. I thought the SAR suggested by MeGUI would be correct? I've read and been told so many things I'd be pulling out my hair if I wasn't already bald! Hence why I just use the suggest SAR from MeGUI. I'd love it if someone could walk me through working out the correct SAR using my example above. I'm not sure how you got 32/27? Also are there different calculations for movies that are 1.85 and 2.35 and 2:40?

DigitalDivide
25th January 2006, 15:22
Well I downloaded the 409 revision from http://x264.nl/ as per Bond. This seems to be better. I'm sitting between 2.5 and 3 mbps this morning after hving it running overnight. It's still running but so far it is faster. I've also changed undot to removegrain(mode=1).

bond
25th January 2006, 18:55
Well I downloaded the 409 revision from http://x264.nl/ as per Bond. This seems to be better. I'm sitting between 2.5 and 3 mbps this morning after hving it running overnight. It's still running but so far it is faster. I've also changed undot to removegrain(mode=1).this means there is propably a bug in one of the patches sharktooth uses

CruNcher
26th January 2006, 00:03
Alex_W is aware that there are bugs somewhere inside his patches that causeing this problems

http://forum.doom9.org/showthread.php?t=105489 <- it started with this
http://forum.doom9.org/showthread.php?t=106176 <- continued with this
http://forum.doom9.org/showthread.php?t=106279 <- and now this :D

so please as Bond said don't use Sharktooth build for "production" it's only for testing :) everyone should be aware of this now i hope

@DigitalDivide
Can you see a Quality improvement for the 5-6 h additional encoding time, either visualy or mathematicly ?
or can you see also the problems that Omicron and Selur allready reported in the above posts ?

DigitalDivide
26th January 2006, 02:11
@DigitalDivide
Can you see a Quality improvement for the 5-6 h additional encoding time, either visualy or mathematicly ?
or can you see also the problems that Omicron and Selur allready reported in the above posts ?

No, I don't see the blockiness and I don't see any quality improvements with the extra time. As a matter of fact I just looked at an encode which just completed using 409rev and so far I have to say it's the best encode I've done so far.