Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
26th July 2008, 20:08 | #1 | Link |
Registered User
Join Date: Apr 2002
Posts: 279
|
A simple x264 bitrate question
I am trying to compress ts files captured from DVB-T broadcasts to something a little smaller. At the moment the files (h.264 video and ac3 audio) take about 3.3G for 40 minutes so HD space gets consumed pretty quickly.
I am not after the greatest quality - I could live with the files getting down to say 1G for 40 minutes. The files have these properties: Video #0 ID : 4113 (0x1011) MenuID/String : 1 (0x1) Codec : AVC Codec/Family : AVC Codec/Info : Advanced Video Codec Codec profile : High@L4.0 Codec settings, CABAC : Yes Codec_Settings_RefFrames : 4 Width : 1920 pixels Height : 1080 pixels Display Aspect ratio : 16/9 Frame rate : 25.000 fps Chroma : 4:2:0 Interlacement : Top Field First I thought I could demux the video (I am using dgavcindex) and recompress with x264 with something like x264.exe --bitrate 4500 --level 4.1 --bframes 1 --b-rdo --weightb --direct auto --subme 5 --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --me dia --thread-input --progress --no-psnr --no-ssim --output etc. The source is fed in via avcsource("xxx.dga") While it works, the filesize is greater than the original! I have even tried bitrate 300 and the file is larger than the original ts file! For example a 300Mb ts files goes out to a 600mb .264 file. Also no matter what bit rate I choose, the video has random macro blocking in it but not what you would expect from high compression, but blocks of video around the edges of the image during motion. No idea what that is. (see attachment). The files are 1920x1080(i) - should I have a LanczosResize(1920,1080) in the avisynth script or just let the size default? Thanks Larry |
26th July 2008, 20:53 | #3 | Link | |
Registered User
Join Date: Apr 2002
Posts: 279
|
Quote:
Not trying to encode the video as progressive that I am aware of. My avisynth script only has LoadPlugin("c:\apps\dgavcdec\DGAVCDecode.dll") AVCSource("c:\x264\NCIS HD_20080713203000_cut_cut.dga") |
|
26th July 2008, 21:16 | #5 | Link | |
Registered User
Join Date: Apr 2002
Posts: 279
|
Quote:
I didn't know about --interlace. I thought that since the file was interlaced to start with, x264 would not try to make it progressive? Doing a quick check, adding --interlace upped the CPU time considerably - is that normal? |
|
26th July 2008, 21:20 | #6 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
I mean the standard output. That you see on your screen.
Quote:
|
|
26th July 2008, 22:46 | #7 | Link | |
Registered User
Join Date: Apr 2002
Posts: 279
|
Quote:
OK - took a bit of time. Here is the x264 log C:\x264>start /belownormal /b /w x264.exe --threads 0 --8x8dct --bitrate 4500 --level 4.1 --bframes 1 --b-rdo --weightb --direct none --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --me hex --interlace --thread-input --progress --no-psnr --no-ssim --output ncis-2.264 ncis.avs avis [info]: 1920x1080 @ 25.00 fps (417 frames) x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow! x264 [info]: slice I:12 Avg QP:16.50 size:113114:00 x264 [info]: slice P:385 Avg QP:21.48 size: 21643 x264 [info]: slice B:20 Avg QP:25.00 size: 7860 x264 [info]: mb I I16..4: 51.3% 36.7% 12.0% x264 [info]: mb P I16..4: 27.0% 0.0% 2.6% P16..4: 29.7% 3.7% 0.4% 0.0% 0 .0% skip:36.6% x264 [info]: mb B I16..4: 2.8% 0.0% 0.2% B16..8: 95.9% 0.5% 0.6% direct: 0.0% skip: 0.0% x264 [info]: final ratefactor: 22.35 x264 [info]: 8x8 transform intra:3.5% inter:77.5% x264 [info]: kb/s:4722.8 encoded 417 frames, 1.71 fps, 4723.83 kb/s Here is an image captured from the playback of that conversion Thanks Larry |
|
26th July 2008, 22:58 | #8 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Yes, if you want to deinterlace, you must do it first! Otherwise your video remains interlaced and the "--interlaced" switch is required...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
26th July 2008, 23:02 | #9 | Link |
Registered User
Join Date: Apr 2002
Posts: 279
|
My goal is just to compress the DVB-T captures a bit to save space without reducing quality. A 40 minute show in original capture takes 3.3G and that adds up. My goal was to get down to about 1G. The transmissions originate in 1080i so I would be happy to keep that resolution.
|
26th July 2008, 23:07 | #10 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
You got exactly two choices:
* Deinterlace before encoding and encode as progressive * Keep it interlaced and encode as interlaced (--interlaced) The first option might be the better choice compression-wise and speed-wise...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 26th July 2008 at 23:17. |
27th July 2008, 03:28 | #11 | Link |
Registered User
Join Date: Jan 2004
Posts: 849
|
Are you using MPC to decode the final output? If so the first image looks exactly like mine does if DXVA encoding partially fails (I know, weird). It plays, but blocks appear around edges, especially during motion. It is suspected to be hardware limitation of some cards and no fix is forthcoming (except changing settings), there is also no hard and fast rule as to what breaks it, but MeGUI's profiles seem safe from this.
So go to MPC settings and disable built it h264 decoder, and let ffdshow handle it.
__________________
Geforce GTX 260 Windows 7, 64bit, Core i7 MPC-HC, Foobar2000 |
28th July 2008, 13:27 | #12 | Link | |
aka XaS
Join Date: Jun 2005
Location: France
Posts: 1,122
|
Quote:
And did you actually use --interlace ? x264's help says it should be --interlaced Actually, maybe your incorrect command-line triggered the bug lexor mentions (I only read the DXVA thread in diagonal though).
__________________
Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS |
|
29th July 2008, 00:57 | #13 | Link | |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
There isn't a factor of 10 in the valid range, so x264 can dwim.
Quote:
|
|
29th July 2008, 01:53 | #14 | Link | |
Registered User
Join Date: Apr 2002
Posts: 279
|
Quote:
1. It seems to only occur on that particular file (the video artifacts). I tried some other DVB-T captures I have and the problem did no occur 2. I didn't know the level had to be 40 or 41 - thought since the profiles are noted as 4.0 or 4.1 that is what x264 would expect (it didn't complain) 3. I did --interlace and also removed it and allowed x264 to default. But I am now having two other problems. Ihave a dual core Athlon 64 but when I fire up x264 it says using MMX2 SSE2 Slow - not sure what Slow means. Shouldn't it also use other options in the CPU? I have a video that is quite long (2 hours) - about 1/2 way through x264 hangs (program is not responding - this is Vista Home Premium) and needs to be cancelled. I am trying to do some binary searching to find which segment of the file is bad so I can isolate it and upload it for testing. I will post the command line when I get home - using the latest stable build of x264.exe Larry |
|
29th July 2008, 01:56 | #15 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
"SSE2Slow" is the subset of SSE2 optimizations which are faster than MMX on the Athlon 64. This was specifically tweaked to give Athlon 64s the absolute maximum performance possible out of the current optimized functions.
|
29th July 2008, 05:48 | #16 | Link | |
Registered User
Join Date: Apr 2002
Posts: 279
|
Quote:
Larry |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|