+ Reply to Thread
Results 1 to 27 of 27
You can make a file as small or big as you want because:
file size = bitrate * running time
Also, and for those veteran Videohelpers I know this has been done to death, but: your file is only 6GB because it has ALREADY had the shit compressed out of it. You want to take something that is 1/300th of it's full size and make it, what? 1/600th!? Of course, you are going to be losing quality (because your source file is compressed and you're applying lossy compression AGAIN).
Echoing Cornucopia you cant expect to reduce the size of any video file without some loss but things you could do is post a mediainfo report of the file in question to see if there are added extras in the file like several soundtracks and a whole host of subtitles in every known language to human kind. These can be removed and will reduce the file size a tad. In fact anyone who has a problem with a video or audio file should as a matter of course post a MediaInfo report,this simple act would save a lot of time in idle chatter and comments on what to do...BeyonWiz T3 PVR ~ Popcorn C200 and A-500 ~ Samsung ES8000 65" LED TV ~ Windows 7 ~ Yamaha RX-A1030 ~ QnapTS851-4G
A file of 6 gb needs to be reduced while maintaining as much quality as possible.
And, netmask56 already asked you to post mediainfo.
In theory you have following options to reduce video file size.
1) Reduce Frame Size.
2) Reduce Bit Rate(s).
3) Reduce Frame Rate.
4) All of Above.
In practice, it may give you little different result than calculated by theory.
By trial-n-error you can settle somewhere in between.
The same is true for reducing the frame rate. Fewer frames per second requires less bitrate. But your video will get jerky.
I can see the debate and discussion is well under way.
I will be able to report these shortly. For now can we work with what I think is a screen capture and that's why the large size-- like the old capture cards.
Playback would be for CRT computer and resolution I normally get from AGK is 700x300 on average.
I'll post the MediaInfo shortly.
Since I have been away from this for a while I remembered Handbrake working with MKV files made with Makemkv. But my cpu temp hit the roof using that.
I am remiss in not updating that from, what? 2005. I just updated it now.
System under discussion
AMD Athlon II x3 450 Regor 3.2 Ghz
MSI 880GM-E41 mainboard
Kingston DDR3 Hyperx/fb 2x2Gb
Seagate Baracuda 1Tb SATA HD
Logisys 480w Power supply
using onboard video by ATI
I have a couple of systems and this is the newest (now a couple years old as well)
but even on this, using Handbrake on an MKV, I was getting a steady temperature climb to the point where I just quit the job. I returned to .AVI using older programs. I simply did not execute any jobs in it after that. Now there is another job to do and so I'm pursuing the question once more.
The only help at the time was 'use less cores' on the cpu. But I'm afraid I don't know anything
about it. There seems no way to have Handbrake execute more slowly. If it takes four times as long that's no big deal. I don't knwo the procedure if there is one.
How hot did your CPU get?
Admittedly the specs seem to indicate you can't run an X3 450 quite as hot as you might be able to run an Intel CPU. The maximum operating temperature is listed as 75 degrees. Although I've had my old core2 CPUs running at close to that plenty of times. My E6750 has been sitting on 60 degrees for most of the day now (core temp close to 70 degrees). According to RealTemp at least, I've still got 30 degrees of headroom, although I try to keep core temp to a maximum of 80 degrees as I don't trust temperature monitoring programs to be completely accurate. Plus I've set the BIOS CPU temperature alarm to go off at 80 degrees and it's unbelievably annoying.
I don't know of too many programs which allow you to "slow them down" given the object of the exercise tends to include the opposite goal. VirtualDub? It has a speed limit slider which I "think" works even when using an "external encoder" (ie the x264 commandline encoder). If it was me though, I'd consider a better CPU cooler if it's all that's required to encode at maximum speed.
Last edited by hello_hello; 1st Jul 2014 at 03:44.
If your CPU is overheating you need to fix your computer -- add more cooling. You should be able to run it full out for hours and hours without problems.
You can limit the number fo threads x264 uses in Handbrake by entering threads=1 (or whatever number you want) in the Extra Options field on the Video tab.
Then we are focusing on Handbrake for this MKV job.
So long as I know that, we can proceed. I have a new pipe cooler called the Big Shuriken which I can install. Not as big as I thought though. More like the "Large" Shuriken.
HH and others can I ask for some settings in Handbrake to get started. Or Vidcoder so I don't have to mess with screen settings changes again. The Vidcoder discussion is mainly for improvements and less for how-to. But if I can find the right processes, Vidcoder is easier to work with for tired eyes.
The exact settings you'll use depends in part on what you intend to do with the resulting video. Is if just for watching on your computer? Do you plan on watching it o smart phone, a Blu-ray player that support MKV files, some other media player device? For upload to youtube? As an intermediate for further editing? The nature of the source video can matter too. Is it progressive or interlaced? Clean computer animation compresses very well. Noisy handheld camcorder video not so well.
For general usage try the Regular -> High Profile preset with constant frame rate and see how it turns out.
Last edited by jagabo; 1st Jul 2014 at 12:03.
Computer use only in VLC as an example. I don't think any editing is needed.
And I normally use low screen resolution of 800x600 which is adequate on old Windows XP.
This is not a CAM or anime. Live action only. I still have to get the Media Info but I don't know if even that describes things like de-interlacing.
MediaInfo data is here:
Unique ID :
Complete name : C:\Documents and
Format : Matroska
Format version : Version 2
File size : 6.79 GiB
Duration : 2h 9mn
Overall bit rate : 7 479 Kbps
Writing application : HandBrake 0.9.9
Writing library : libmkv 0.6.5
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 9mn
Bit rate : 7 000 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.135
Stream size : 6.25 GiB (92%)
Writing library : x264 core 130 r2273 b3065e6
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0
/ analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 /
mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 /
deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 /
lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 /
bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1
/ b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 /
keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr /
mbtree=1 / bitrate=7000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 /
qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 2h 9mn
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 417 MiB (6%)
Language : English
Default : Yes
Forced : No
Simple stereo is all that is needed.
If you really only need 800x448 you can reduce the file size by quite a lot. The audio is only 6 percent of the current file size. Not worth worrying about.
How about using the presets in Handbrake-- one of the Ipad ones or something? Just to get started I used the optimize for Internet to see what that does.
I see the cropping box and such but can you give some help on making the actual size settings? Constant Quality and all that?
In MeGui there is a calculator if I recall. Based on the MediaInfo chart what is the calculation and where to plug in the numbers? I'm willing to do the work when I know where to start.
Doing a couple random tests and not really knowing what will work I first adjusted the Constant quality all the way down. I got the blocky artifacts. The other thing I did a value of 51-- selecting Ipod gave the same file value as the original 6 Gb.
The instructions in Handbrake say the lower the values, the greater the quality, yes? So at the other end of the slider-- high value should give small file size.
In other Handbrake experiments with MKV I have always gotten the blocky effect in a few frames-- unusable output. Yet I see very small files made with x264 without this problem.
Original file is 6 gb
My normal two hour file size should be in the neighborhood of 1.7 Gb. Is this doable without the blocky content showing up?
Else, how would MeGUI handle this?
I will do another experiment with Constant Quality and High value while awaiting any answer. I also have a discussion to reread which I printed out some time back.
Since you don't have much in the way of playback restrictions you should probably just use the Regular -> High Profile preset in Handbrake.
When using Constant Quality encoding the file size is unpredictable -- aside from that fact that the lower the RF value the larger the file will be (and the better the quality). If you NEED a fixed size use Avg Bitrate encoding. Use a bitrate calculator to determine what bitrate will give the size you want. Use the 2 Pass Encoding option to get better quality when using bitrate based encoding.
Once again, nobody can tell you for sure what bitrate you need to maintain quality. With quality based encoding most people who want good quality use values around 18 to 20. If you perform a quality based encoding at say, 18, and the file happens to turn out with an average bitrate of 2000 kbps, and then go back and perform at 2-pass bitrate based encoding at 2000 kbps, the two files will look almost identical. Ie, the CRF and bitrate encoding give the same quality when the bitrates match. The difference is: Bitrate based encoding gives the bitrate you specify but you don't know what the quality will be. RF encoding gives the quality you specify but you don't know what the bitrate will be.
I had a sample going at '33' with no other settings touched. the tutorial I was going to review is mostly about audio and not much help. I had to shut down the computer and I don't know if handbrake will save the job in a queue or someplace in order to resume.
As to overheating, I'm just not looking at it. Though there is a setting from fast to slow down in the lower left corner Handbrake, when set to slow is really slow-- half a day or more for this 2 hour 9 minute piece.
The job is set to mp4 because I didn't know any better.
One other suggestion: Don't encode an entire 2 hour movie to test what different settings do. Use a short 1 minute sequence that's representative of the movie. A mix of still and action shots, bright and dark shots.
CPU over heating seems like a hardware problem as jagabo already said it before. Alternatively, you can try different version of handbrake (hosted on VH, here already in tool section) rather than one you are using now, I guess it is 099.
As you already started this post and stated MeGUI. I would say you should give MeGUI a try by going through various guides here. MeGUI also considered as a high-ranking tool.
If you are familiar with x264 CLI (Commandline version), you should try encoding video by x264 encoder (only the free choice available) and audio by AAC encoder separately and mux video and audio stream into .mp4 or .mkv
Just in case of trying different tools, CPU overheats, it is hardware problem for sure that you need to address first.
Normally I refrain from answering as I am outdated with most current tools & do not keep up myself with updating.
If you want to run short encodes to test for file sizes..... ie run compression tests...... it's probably easier to use an Avisynth based encoder GUI..... ie MeGUI. Then you can run your own compression tests pretty much the same way AutoGK does it.
You'll need to use the File/Open menu to open an MKV for encoding and from there MeGUI should step you through the process of indexing the video, extracting the audio and creating a script for encoding. The final part of that process is using the Script Creator to set your desired cropping and resizing etc. Before saving the script, you can switch to the AVS Script Creator's script tab and manually add something like this to the end of the script:
which will encode 5% of the video
would encode 10% etc.
The more you encode the longer it takes and the more acurate it's likely to be, but that'd give you a fair idea of the final file size for the whole encode, (assuming the same encoder settings are used). If you're not happy with the final size, create a new script, adjust the resizing if need be, adjust the encoder quality if need be, and run another compression test. It'd at least be better than running multiple full encodes.
More often, I tend to use a similar method for Xvid encoding (although I don't do much of that these days). I create a script, encode up to 20% of the video at around 75% quality, then whatever the resulting bitrate, I use it for a 2 pass encode. The encode should be around 75% quality and the file size will be whatever it needs to be.
For x264 encoding I normally pick the quality I want to use along with my preferred resolution and let the file size be whatever it needs to be. Once you've done a bit of encoding that way you'll have a rough idea of the resolution/quality to use for a particular file size..... on average..... as they will vary quite a bit.
Last edited by hello_hello; 4th Jul 2014 at 01:38.