A simple x264 bitrate question

[lchiu7]

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

[Dark Shikari]

Can you post the encoding log?

Also, are you deinterlacing the video, or are you trying to encode the interlaced video as progressive?

[lchiu7]

Originally Posted by Dark Shikari

Can you post the encoding log?

Also, are you deinterlacing the video, or are you trying to encode the interlaced video as progressive?

Is the log file a standard output? If so what is it called? I couldn't see any log.

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")

[Dark Shikari]

Originally Posted by lchiu7

Is the log file a standard output? If so what is it called? I couldn't see any log.

Yes, the standard output.

Originally Posted by lchiu7

Not trying to encode the video as progressive that I am aware of.

Might I suggest you look at your encode commandline you posted, and the lack of --interlaced in it?

[lchiu7]

Originally Posted by Dark Shikari

Yes, the standard output.
Might I suggest you look at your encode commandline you posted, and the lack of --interlaced in it?

Still couldn't see a file with a name that looked like a log.

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?

[Dark Shikari]

Originally Posted by lchiu7

Still couldn't see a file with a name that looked like a log.

I mean the standard output. That you see on your screen.

Originally Posted by lchiu7

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?

x264 has no way of knowing what form your input is in.

Originally Posted by lchiu7

Doing a quick check, adding --interlace upped the CPU time considerably - is that normal?

Yes, interlaced encoding and decoding is slower.

[lchiu7]

Originally Posted by Dark Shikari

I mean the standard output. That you see on your screen.
x264 has no way of knowing what form your input is in.Yes, interlaced encoding and decoding is slower.

So if actually wanted to de-interlace I should do it in the avisynth script before passing the frame to x264?

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

[LoRd_MuldeR]

Originally Posted by lchiu7

So if actually wanted to de-interlace I should do it in the avisynth script before passing the frame to x264?

Yes, if you want to deinterlace, you must do it first! Otherwise your video remains interlaced and the "--interlaced" switch is required...

[lchiu7]

Originally Posted by LoRd_MuldeR

Yes, if you want to deinterlace, you must do it first! Otherwise your video remains interlaced and the "--interlaced" switch is required...

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.

[LoRd_MuldeR]

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...

[lexor]

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.

[DarkZell666]

Originally Posted by lchiu7

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

Isn't it supposed to be --level 41 ? (instead of 4.1)
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).

[akupenguin]

Originally Posted by DarkZell666

Isn't it supposed to be --level 41?

There isn't a factor of 10 in the valid range, so x264 can dwim.

And did you actually use --interlace? x264's help says it should be --interlaced

Any option can be abbreviated to a unique prefix, thanks to getopt. --in works too, so long as I don't add another option that starts with --intra or the like.

[lchiu7]

Originally Posted by akupenguin

There isn't a factor of 10 in the valid range, so x264 can dwim.

Any option can be abbreviated to a unique prefix, thanks to getopt. --in works too, so long as I don't add another option that starts with --intra or the like.

Some further data

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

[Dark Shikari]

Originally Posted by lchiu7

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?

"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.

[lchiu7]

Originally Posted by Dark Shikari

"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.

Cool. So I know that's going as fast as it can (not that it's that fast at the moment).

Larry