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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 26th July 2008, 20:08   #1  |  Link
lchiu7
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
Attached Images
 
lchiu7 is offline   Reply With Quote
Old 26th July 2008, 20:22   #2  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Can you post the encoding log?

Also, are you deinterlacing the video, or are you trying to encode the interlaced video as progressive?
Dark Shikari is offline   Reply With Quote
Old 26th July 2008, 20:53   #3  |  Link
lchiu7
Registered User
 
Join Date: Apr 2002
Posts: 279
Quote:
Originally Posted by Dark Shikari View Post
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")
lchiu7 is offline   Reply With Quote
Old 26th July 2008, 20:57   #4  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by lchiu7 View Post
Is the log file a standard output? If so what is it called? I couldn't see any log.
Yes, the standard output.
Quote:
Originally Posted by lchiu7 View Post
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?
Dark Shikari is offline   Reply With Quote
Old 26th July 2008, 21:16   #5  |  Link
lchiu7
Registered User
 
Join Date: Apr 2002
Posts: 279
Quote:
Originally Posted by Dark Shikari View Post
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?
lchiu7 is offline   Reply With Quote
Old 26th July 2008, 21:20   #6  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by lchiu7 View Post
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.
Quote:
Originally Posted by lchiu7 View Post
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.
Quote:
Originally Posted by lchiu7 View Post
Doing a quick check, adding --interlace upped the CPU time considerably - is that normal?
Yes, interlaced encoding and decoding is slower.
Dark Shikari is offline   Reply With Quote
Old 26th July 2008, 22:46   #7  |  Link
lchiu7
Registered User
 
Join Date: Apr 2002
Posts: 279
Quote:
Originally Posted by Dark Shikari View Post
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
Attached Images
 
lchiu7 is offline   Reply With Quote
Old 26th July 2008, 22:58   #8  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,891
Quote:
Originally Posted by lchiu7 View Post
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 26th July 2008, 23:02   #9  |  Link
lchiu7
Registered User
 
Join Date: Apr 2002
Posts: 279
Quote:
Originally Posted by LoRd_MuldeR View Post
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.
lchiu7 is offline   Reply With Quote
Old 26th July 2008, 23:07   #10  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,891
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 26th July 2008 at 23:17.
LoRd_MuldeR is offline   Reply With Quote
Old 27th July 2008, 03:28   #11  |  Link
lexor
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
lexor is offline   Reply With Quote
Old 28th July 2008, 13:27   #12  |  Link
DarkZell666
aka XaS
 
DarkZell666's Avatar
 
Join Date: Jun 2005
Location: France
Posts: 1,122
Quote:
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).
__________________

Q9300 OC @ 3.2ghz / Asus P5E3 / 4GB PC10600 / Geforce 8600 GTS
DarkZell666 is offline   Reply With Quote
Old 29th July 2008, 00:57   #13  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
Quote:
Originally Posted by DarkZell666 View Post
Isn't it supposed to be --level 41?
There isn't a factor of 10 in the valid range, so x264 can dwim.
Quote:
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.
akupenguin is offline   Reply With Quote
Old 29th July 2008, 01:53   #14  |  Link
lchiu7
Registered User
 
Join Date: Apr 2002
Posts: 279
Quote:
Originally Posted by akupenguin View Post
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
lchiu7 is offline   Reply With Quote
Old 29th July 2008, 01:56   #15  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by lchiu7 View Post
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.
Dark Shikari is offline   Reply With Quote
Old 29th July 2008, 05:48   #16  |  Link
lchiu7
Registered User
 
Join Date: Apr 2002
Posts: 279
Quote:
Originally Posted by Dark Shikari View Post
"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
lchiu7 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:21.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.