RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY

[RoseM]

Hello

Someone could see why the audio of the file below isn't recognized by the program?

http://www.mediafire.com/download/5wndl415r97o84z/09-30_12-25-28_Globo_HD_SP.ts

Thanks

[Atak_Snajpera]

Hello

Someone could see why the audio of the file below isn't recognized by the program?

http://www.mediafire.com/download/5wndl415r97o84z/09-30_12-25-28_Globo_HD_SP.ts

Thanks

Because this format is not supported by eac3to tool.

Audio #1
ID : 274 (0x112)
Menu ID : 59200 (0xE740)
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Muxing mode : LATM
Codec ID : 17
Duration : 1mn 11s
Bit rate mode : Variable
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz / 24.0 KHz
Compression mode : Lossy
Delay relative to video : -400ms

Probably ffmpeg will be able to convert that audio stream.

[slalom]

Hi Atak

Here is an error for v.1.17.4

Exception EConvertError in module RipBot264.exe at 0000949A
" is not a valid floating point value

Do you know what this is?

[Atak_Snajpera]

1.17.4 ???

[slalom]

You think 1.18.1 is ok with this error?

[Atak_Snajpera]

at least you can try.

[RoseM]

Because this format is not supported by eac3to tool.

Audio #1
ID : 274 (0x112)
Menu ID : 59200 (0xE740)
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Muxing mode : LATM
Codec ID : 17
Duration : 1mn 11s
Bit rate mode : Variable
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz / 24.0 KHz
Compression mode : Lossy
Delay relative to video : -400ms

Probably ffmpeg will be able to convert that audio stream.
As I am half lay, I'll try another program to convert my TS.

Thanks for the response.

[slalom]

at least you can try.
I'll get back to you, thanks

[hidef_rec]

Hi Atak

Here is an error for v.1.17.4

Exception EConvertError in module RipBot264.exe at 0000949A
" is not a valid floating point value

Do you know what this is?

I'm getting this error in both v.1.17.4 and the latest 1.18.1. Have been using RipBot264 for a few years and never had any issues.

[slalom]

Same error appeared on version 1.18.1

[Atak_Snajpera]

How does info.txt file look like?

[hidef_rec]

How does info.txt file look like?
For a short video I was testing...
File 'D:\video.mkv': container: Matroska [duration:467559000000 segment_uid:afb9a5d10e4c1bf48edc6e8348964fd3 is_providing_timecodes:1]
Track ID 0: video (MPEG-4p10/AVC/h.264) [number:1 uid:4189225827455225746 codec_id:V_MPEG4/ISO/AVC codec_private_length:61 codec_private_data:01640029ffe1002967640029acd940f816f93c054808080a000007d200017701c4c0002625a0000e4e1d449b07c60c658001000568e93b3c8ffdf8f800 language:eng pixel_dimensions:986x720 display_dimensions:986x720 default_track:1 forced_track:0 enabled_track:1 packetizer:mpeg4_p10_video default_duration:41708332 tag_bps:4000897 tag_duration:00\c07\c46.341000000 tag_number_of_frames:11181 tag_number_of_bytes:233222805 tag__statistics_writing_app:mkvmerge\sv7.1.0\s('Good\sLove')\s64bit\sbuilt\son\sJul\s27\s2014\s13\c06\c55 tag__statistics_writing_date_utc:2014-10-08\s15\c45\c50 tag__statistics_tags:BPS\sDURATION\sNUMBER_OF_FRAMES\sNUMBER_OF_BYTES]
Track ID 1: audio (AC3/EAC3) [number:2 uid:6035514932527546256 codec_id:A_AC3 codec_private_length:0 language:eng default_track:1 forced_track:0 enabled_track:1 default_duration:32000000 audio_sampling_frequency:48000 audio_channels:1 tag_bps:192000 tag_duration:00\c07\c47.488000000 tag_number_of_frames:14609 tag_number_of_bytes:11219712 tag__statistics_writing_app:mkvmerge\sv7.1.0\s('Good\sLove')\s64bit\sbuilt\son\sJul\s27\s2014\s13\c06\c55 tag__statistics_writing_date_utc:2014-10-08\s15\c45\c50 tag__statistics_tags:BPS\sDURATION\sNUMBER_OF_FRAMES\sNUMBER_OF_BYTES]
Tags for track ID 0: 7 entries
Tags for track ID 1: 7 entries

[slalom]

I didn't get an Info.txt but here is the mkvinfo

File 'E:\****.mkv': container: Matroska [duration:2610656000000 segment_uid:9510c5e2ef10ba07bb597290b8337f70 is_providing_timecodes:1]
Track ID 0: video (MPEG-4p10/AVC/h.264) [number:1 uid:1600451728 codec_id:V_MPEG4/ISO/AVC codec_private_length:47
codec_private_data:01640028ff01001b27640028ac52140780227a9bff000100016a0202036d856bdef80801000528f90809cb02000000
language:eng pixel_dimensions:1918x1078 display_dimensions:1918x1078 default_track:1 forced_track:0 enabled_track:1 packetizer:mpeg4_p10_video
default_duration:41708375]
Track ID 1: audio (AC3/EAC3) [number:2 uid:1915434653 codec_id:A_AC3 codec_private_length:0 language:eng default_track:1
forced_track:0 enabled_track:1 default_duration:32000000 audio_sampling_frequency:48000 audio_channels:6]

[BlockABoots]

If using HEVC (x265x) encoding can you save the output file as an mp4 file as this option seems to disappear when selecting HEVC and only mkv if available?

[Atak_Snajpera]

@slalom
Have you tried reinstalling required components?

[slalom]

I have tried on 2 PCs, same message

[Atak_Snajpera]

Does this happen with all files or with just this one?

[slalom]

There are 3 files with this problem

[Atak_Snajpera]

Can I get 3 samples then ? :)

[ShogoXT]

Hello! Thanks for such a awesome program.

I was wondering if anyone could help me figure out how to properly IVTC this anime? I cant seem to get it completely solved.

Most scenes look good, but some horizontal lines looked completely broken, such as here on the sides of the neck and hat:
http://i.imgur.com/cvviNNo.jpg

I made sure to search as much as i possibly could before coming here. After reading a great deal about TFM, Tdecimate, etc from websites and readmes I kept playing with the script to see if it would help, like this:
#Deinterlace
Loadplugin("C:\Ripbot264\Tools\AviSynth plugins\TIVTC\TIVTC.dll")
video=tfm(video,mode=5,order=1,slow=2)

#Decimate
Loadplugin("C:\Ripbot264\Tools\AviSynth plugins\TIVTC\TIVTC.dll")
video=TDecimate(video,mode=1,hybrid=1)

Hasnt helped too much so I must be doing something wrong. Could anyone help me correctly identify how these sources are setup so I can make them look nice?

EDIT: I thought I had a source link ready, but then the website made me require an account to get the link. Any recommended sites for say a 1gb file?

[slalom]

I'm getting this error in both v.1.17.4 and the latest 1.18.1. Have been using RipBot264 for a few years and never had any issues.
Try with latest Avisynth 2.6.0
http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/

that worked for me

[Atak_Snajpera]

@ShogoXT
You do not have to send us whole file. 100 MiB sample with this problem will be enough. Use DGSplit.
Regarding hosting file. Have you tried mega.co.nz or mediafire.com ?

[hidef_rec]

Try with latest Avisynth 2.6.0
http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/

that worked for me
Worked for me as well :). Thanks.

[ShogoXT]

@ShogoXT
You do not have to send us whole file. 100 MiB sample with this problem will be enough. Use DGSplit.
Regarding hosting file. Have you tried mega.co.nz or mediafire.com ?

https://mega.co.nz/#!6I4V3QoQ!oO-FFbAF6ggR7wPdlLKGxz2K4RteV04fr0tXS_-k18s
That work ok? Part of the source right? Thanks again.

[Atak_Snajpera]

https://mega.co.nz/#!6I4V3QoQ!oO-FFbAF6ggR7wPdlLKGxz2K4RteV04fr0tXS_-k18s
That work ok? Part of the source right? Thanks again.

Those artefacts are already in source. I think that denoising filter may reduce visibility of those odd lines. Start experimenting with 16 - 16 values (mono/color).

[ShogoXT]

Those artefacts are already in source. I think that denoising filter may reduce visibility of those odd lines. Start experimenting with 16 - 16 values (mono/color).

Thanks, Il give it a shot!

So you dont think its leftovers from interlacing? The first picture was post IVTC -> 24fps. I had thought it was just leftovers of this: http://i.imgur.com/XDKi7bt.jpg (Source pic)

Do you have a recommendation for a program that gives me a lot of media information on sources? Mediainfo seems like its limited helpfulness.

[Atak_Snajpera]

Thanks, Il give it a shot!

So you dont think its leftovers from interlacing? The first picture was post IVTC -> 24fps. I had thought it was just leftovers of this: http://i.imgur.com/XDKi7bt.jpg (Source pic)

Do you have a recommendation for a program that gives me a lot of media information on sources? Mediainfo seems like its limited helpfulness.

I see similar artefacts in untouched still frame
http://i.cubeupload.com/s5ihPw.png

[ShogoXT]

I see similar artefacts in untouched still frame http://i.cubeupload.com/s5ihPw.png

Hmmm I wonder if I did something to mess up the source? Basically the vobs were setup so ALL episodes were together in one play file. Other DVDs had other odd setup schemes. I had to split them up by chapters. Used to use DVD Decrypter, but the resulting files would lead to audio sync issues on Ripbot. Used MakeMKV for a while too, but it couldn't separate by chapters. Now im currently using DVDFab on passthrough mode to MKVs for the source.

The denoise helped a little, I keep playing with those settings, but some high motion scenes look bad. I will have to run more samples and check back.

Thanks again.

EDIT: Im not very smart.... I finally found out what its called. Dot Crawl? Chroma artifacts just as you said. I wonder how I setup filters to get rid of it. From what ive read I have to do it before IVTC....

[8ternity]

Hi, Atak,


ripbot 1.18.1:
after the job is done the output file is totally missing... :confused:
Twice. :mad: 2 lost hours.

I noticed in the input file name multiple dots "." which are converted by ripbot to " " - could that be the problem?

Input is disk F, output is root of the disk D.

I had some projects it does that to me from a while.

I was thinking that Torrent program is holding the conversion but not. what ive done, is remuxing the project in m2ts in a different name and convert it again from the m2ts/mkv file.

Regarding the "." it does not matter. I convert from a while.

[slalom]

Don't do the job again, use mkvmerge to replace the old video file with the new.

[thahandy]

So, trying RipBot again from 1.17.3 to current version 1.18.1 but i still get this error every time. At time i didn't bothered and moved on to next program, but this time i want to use/try RipBot


Exception EFOpenError in module RipBot264.exe at 000235DA
Cannot open file "R:\Temp\RipBot264temp\job1\test.log". The system cannot find the file specified

For some reason test.log isn't being written in the job1 folder, but executing test.exe was successful because its creating a info.txt file

Creating a fake test.log file is not giving me the error anymore, but providing me a "new job" Decoding Error window,with the text inside the test.log

Can you tell what RipBot for file is expecting?
Any Debug function present in RipBot?


I'm using Windows XP x64, so i don't expect any access issues.
(ya, i know its a suspended OS)

[Atak_Snajpera]

first of all make sure you have avisynth 2.60 installed. I suppose avisynth has not ben correctly installed.

[skylinekiller]

For the life of me I cannot get the audio Profile 5.1 AAC 384. I like to use this because it seems to be the highest AAC rate that is compatible to PS3. The highest RipBot goes is 320. I can't seem to find a place to change this in the ini file either. I am very surprised this hasn't been added to the coding yet.


Any help is greatly appreciated.

[Atak_Snajpera]

320 kbps is enough for 5.1. Everything beyond that level is a pure placebo effect.
Nevertheless You can manually inject higher value in EncodeAudio.cmd (open in notepad and replace 320 with 384)

[skylinekiller]

Where is this located? I can't see in in the RIPBot Directory. Do I have to do this every time? The 348 just seems much louder than 320 in my opinion.

[Atak_Snajpera]

Create job and then go to ripbot264temp/job1/ folder
BTW. Increasing bitrate DOES NOT increase volume.

[ceth]

Hello there, and thx for the fantastic piece of software.

I'm trying to distribute encode a DNxHD (VC-3) encapsulated in a mov container.
Ripbot cannot open it as it tries to open with directshowsource.
The file opens successfuly with a script using QTinput. I can load it into ripbot using this avs script but then no distributed encoding (not supported I guess).

Questions:

1°) is there a way to manualy set ripbot source filter so I can use QTinput instead of directshowsource it tries to use ?

2°) I tried a workaround, creating an intermediate source file encoded with lagarith but then ripbot fails at the ffmsindexing step (I tried both with avi and mkv container for this lagarith encoded file)

edit: indexing step fails too if using an UT file instead of lagarith
edit2: and when using magicYUV, or HuffYUV (ffdshow), or FFV1, or even uncompressedYV12, file loads successfuly but no distributed encoding, only solo (tested both avi and mkv with each of those codec).

Any help would be appreciated.


------


edit3:

So I finally managed to use a lossless compressed source for distributed encoding, however I encountered several drawbacks that made the distributed encoding a lot longer than if I just made a solo encoding using my fastest pc (or if I segmented the encoding myself to manually distribute it on my 2 PC). I think those drawbacks could be removed so I will list them below:

- the only lossless format I could use as source that was compatible with distributed encoding was x264 lossless. Being slower to create than lagarith or magicYUV, that was a first time loss. It would be very nice if lagarith and/or magicYUV could be supporter for distributed encoding

- creating the job task was very long due to a very long file indexing when selecting it as source (for info my x264 lossless source file weights 22.4GB for 23min, 2048x1152px, 30fps). I guess this is necessary but it would be nice if some speedup could be found for this indexing step (maybe it would have take less time if it was lagarith or magicYUV ? Idk)

- when starting the encoding task, the source file is copied to ripbot shared temp folder, which for a 22GB file already takes some time even with a somewhat optimized configuration (= source file on a fast hdd and ripbot temp folder on a ssd), and takes longer if you have all on the same hdd (I had to do that as 1st attempt with ripbot temp on ssd failed at the end of the indexing -> job done but nothing was encoded), but then this source copy is indexed again ! Is it really necessary to do that ? Couldn't we have a shared source folder so that no copy is need and indexing is only done once, when creating the job task ? This would have already saved me a lot of time for this encoding.

- next step, distributed encoding starts. But contrary to my previous test using a 2GB xvid that was divided in multiple chunks, this time with the x264 lossless source file ripbot only create 2 chunks ! Even worst, the chunks are not the same size (18k and 24k frames respectively) and the longer is asigned to the slower pc :( This obviously made the 3x faster pc spend 80% of the encoding time doing nothing, for both the 1st and 2nd pass.

So what about a paramater to manualy force the number of chunks ? And what about the possibility to inform ripbot about the speed it can expect for each encoding client so that it can create and assign chunks accordingly ? (like a 100 value for the fastest client, then a 2x slower you would set 50 etc. The ripbot creates 50% smaller chunks for the slower pc).

Another suggestion, I haven't seen an option to add an already compressed audio and just set it to "copy" in the job task (not a big deal though, I think the above is more important).

I hope those suggestions can help improving ripbot if you are still working on it. Feel free to tell me if I missed something and could have speed up my distributed encoding task with the current ripbot version.

[agressiv]

It's best to split paths between multiple spindles. Keep your directory with original files on a separate physical disk than your temp directory.

One thing that is unavoidable from an I/O perspective is if you are converting audio, it's doing that in the background while the file is being indexed.

That slows it down immensely if you don't have an SSD.

It's bad enough where I pre-encode my audio and just do a copy stream because the performance is so bad, even on a 2-disk RAID-0.

Personally, I wish the encoding audio bit didn't start until after the chunks are split.

The number of chunks is determined by what method you are using. If you are using CRF, it will do it at 1-minute chunks. If you are doing 2-pass or forced bitrate, the chunks are much larger.

[ceth]

Thanks for the reply. Yes I know and agree with the dedicated physical disk for temp & source files. I had it this way at the begining but as said encoding failed to start after indexing (not related wih the fact I had temp on a separate drive though, I think. Because my initial test worked well this way). However, as said, I wonder if we could do without the need to make this source copy (to temp folder, when encoding) and this 2nd indexing. I don't see why it would be required when indexing was already done at the task creation step.

Also I agree any disk access during indexing will hurt indexing a lot (much longer). Although I was encoding the audio separately for this encoding, so no audio encoding went disturbing the indexing here, it is just this 22GB indexing was very long (several minutes, even when it was doing it with the source copy on the ssd when the temp folder was still set there).

About chunks, I see, I didn't thought about this indeed (my encoding was 2-pass bitrate based). It is possible my initial test with the 2GB xvid that produced a lot more chunks was a single pass encoding. But only 1 large chunk per client for a 2-pass, is it normal ? And if yes is it really the best we can do ? I would personally trade a bit of final target bitrate drift for having more chunks that minimize the time lost when you have 1 client ending its job when the other one just started encoding its last chunk (the more chunks the smaller they are, so when that situation happens the other client(s) only idle for a short time waiting for the last client to finish its last chunk, optimizing the overall gain of the distributed encoding).

And as said, with only 2 chunks, not the same size, and the longer one being given by ripbot to the slowest client, this is not good. For this first try with ripbot, the distributed encoding took a lot more time than if I just encoded on my fastest PC. Being able to weight workload distribution according to the encoding efficiency of each client seems a required feature to me. If not done automatically (by doing a preliminary benching step before determining the chunks distribution), at least being able to tell ripbot client2 is 2.5x slower on average than client1, so ripbot can do the more optimized chunks distribution for encoding, esp. if there are case where the encoding can only be made using only 1 chunk per client (it is then crucial the chunks size are made according each client encoding power).

[Atak_Snajpera]

I confirm that UT Video crashes indexer in latest fms 2.20. I've already created bug report for them here -> https://github.com/FFMS/ffms2/issues/180

In 2-pass mode chunks are 10 times longer than in Constant Quality mode (10 min vs 1min). This is simply a trade off between quality and encoding efficiency. 1 min chunk in 2-pass mode would flatten overall bitrate distribution to much. Instead of pure VBR you would end up with something what looks more like ABR. Dynamic scenes would get more or less similar amount of bits as static ones (talking head and so on). In CQ mode you do not have worry about that because encoder adjusts bitrate on fly in single pass according to CRF value and video complexity. Is there any reason why you have to use 2-pass mode? Are you going to store your video on CD/DVD/BD?

[ceth]

Thank you for this quick reply :) 10mins chunks for 2-pass, that explains why I only had 2 chunks then. I always used 2-pass as in my mind it was the best solution for optimized compression/quality ratio. I will experiment with single pass the next time, as it is a big advantage for distributed encoding if chunks are 1min. This is for youtube export anyway, so given how youtube compression (still) kills quality, having a slight quality loss for the file I upload should not make a big difference in the end.

Good news if UT video support should (hopefully) be back soon. Can we expect ripbot to support lagarith and/or magicYUV anytime soon ? It seems those are the fastest lossless codec.

Also what about the need for 2 indexing (1st when loading the source at the task creation, then 2nd when starting the encoding), and the need to do this source copy in the ripbot temp folder ? Couldn't it be skipped ? It takes a lot of time when working with large lossless source files.

[slalom]

And as said, with only 2 chunks, not the same size, and the longer one being given by ripbot to the slowest client, this is not good. For this first try with ripbot, the distributed encoding took a lot more time than if I just encoded on my fastest PC. Being able to weight workload distribution according to the encoding efficiency of each client seems a required feature to me. If not done automatically (by doing a preliminary benching step before determining the chunks distribution), at least being able to tell ripbot client2 is 2.5x slower on average than client1, so ripbot can do the more optimized chunks distribution for encoding, esp. if there are case where the encoding can only be made using only 1 chunk per client (it is then crucial the chunks size are made according each client encoding power).
I had to do a few videos with 2 chunks created.

All you have to do, is edit file EncodingClient.ini and change the order of the clients, so the second is the fastest, (or the third)

[ceth]

Good trick, thank you ! I will also check if you can edit the chunks to make it better correspond to the client encoding power. I guess a 75% chunk and a 25% one (15min & 5min for a 20min video) shouldn't hurt bitrate distribution too much.

edit: manual editing the encoding cfg files to adapt the chunks size manually doesn't seem possible. So I guess that would be a nice option to have in ripbot.

[Atak_Snajpera]

2-pass mode is ONLY useful if you want specific size (CD/DVD/BD) For rest cq mode is better because :
1. Single pass means faster encoding
2. You do not have to guess what bitrate to choose.

SUMMARY
Forget about 2pass and use cq like most guys here.

[ceth]

I don't need a specific size indeed, however the smaller file the better (to shorten uploading time). Hence why I used a target average bitrate.

The advantage of a 2-pass is you can control the resulting filesize, and then "maximise what you have" (= obtain the best quality you can obtain with your chosen resulting filesize).
While 1pass CQ should be able to have the same quality as a 2-pass, it would require a perfect guess to do it with the same resulting filesize.

Now given how long the 1st pass was, the trade-off may indeed be in favor of a 1pass CQ if the encoded video doesn't result in a significantly heavier file (for **at least equal quality**), as it will be faster have 100/200MB more to upload than the time it takes for doing a 1st pass. But you must be sure of the resulting file size increase, as with CQ it should all depend on the complexity of what is being encoded, thus you could obtain a significantly larger file than expected (which will never happen with a 2 pass bitrate based encoding).

But yes, if you always encode very similar content, I think you can guess-timate the resulting file size with a good error margin (= enough to be sure the time gained at the encoding, saving a 1st pass, will be greater than the increased upload time).

edit:

So I just made some testing:

- file indexing with the 21.3GB lossless x264 source file on HDD (Samsung SpinPoint F3 (HD103SJ) 1 To) took 11min15s (cpu load around 3%)
- file indexing with source on SSD (samsung 840pro 120GB) took 4min30s (cpu load around 10%)
- source copy to ripbot temp at encoding start (I let the temp on HDD, so this was SSD->HDD copy) took 4min50s
- source copy (re)indexing at encoding start to 4min03s (so this indexing was done using the original source file on the SDD, good thing)

Conclusion: if you process large (lossless?) files, keep your source on SSD^^ (although this may be problematic for its life if you do lot of encoding everyday)

Now about the CQ vs 2-pass:

Before I go on let me explain the content of my video: this is racing game. Being races there is a high degree of repetitiveness through the video content, as this is the same lap being repeated again and again. Things that changes from lap to lap are cars around mine, but also sometime the view too (as this is an edits race highlights. So for a few seconds the view can be switched to rear view, or helicopter view, or fixed track view etc. But more than 80% of the time it is the same cockpit view).

My initial 2-pass encoding was done with a 8Mbps bitrate.
It resulted in a 1.28GB encoded file for YT upload (video length is 23min exactly).
And the distributed encoding took 2h15min (although this was with the bad chunks assignation, making my fastest PC idle 70-80% of the whole encoding time).

I tried to find the CQ value to get an as close as possible average bitrate (so as close as possible file size too). For this I used a 21sec sample I used when trying to find the best paramters for my 2-pass encoding. I found that using a CQ of 25.5 was giving a very close bitrate on that sample (8025Kbps).

Distributed encoding of the whole lossless source file with CQ 25.5 took 34min07s (encoding only, without temp copy & re-indexing). Resulting file was... 959MB, or 5.8Mbps average bitrate (which obviously induced a visible quality loss, less road details, more blurry overall, altough the diffence after YT recompression may to have been that significant compared to my 8Mbps 2-pass upload, but that's just to say).

Conclusions:

- source copy to ripbot temp + re-indexing took 9min, for an encoding(only) that lasted 34min (+ 4min indexing at task creation). So 47min total instead of 38min total if no copy & re-indexing was made (possible ?)
- 1pass CQ is very unpredictable regarding file size. 959MB vs 1.28GB, this is a 27% drift in the expected file size.
- the 2pass version upload took 180min (didn't check exactly, this is the (exact) YT prediction I remember, so real upload time should not be too far from this), 27% of this represents 48min. So this has to be compared with the time gain between a 2pass and 1pass CQ. If we take the rough approximation of 2x encoding time for 2pass, then it's clear we are in a range where 1pass is not necessarily faster in overall (encoding + upload).

* I would have to check with a longer sample (like 1 race lap ?) if CQ could be set to reach a better guesstimation of the final file size. Though this process would have to be done at each new encoding I guess, as I expect too high variability in results from on race track to another.
* I should retry a 2pass with a better chunk distribution to compare encoding time vs 1pass.
* my setup constist in a Q6600@3.4 (constant) and a 4770K that should be @4.1 (non constant as 4.1 is the turbo frequency, with this temporary overclock that is just a preset overclock from the motherboard). The Q6600 was load at almost 100% while the 4770K was around 70% all the time (maybe due to hyperthreading ?). Despite this, the 4770K already encodes between 2x and 2.5x faster ! :)
* content having high repetitiveness, I guess having smaller chunks for 2-pass could still make sense (yes this is a very particular case, I admit).

[skylinekiller]

I am able to encode to .mp4 without stream on a single file, but the option is not available for Batch. Is it possible to encode without audio using BATCH?

Thank you

[skylinekiller]

ATAK,
most of my encodes are BD/BRrips to .mp4 I was under the impression 2 pass was always better for consistent quality. Can you elaborate a little more on the CRF setting? I have a beast of a machine so my encodes don't take long either way. I currently use a multitude of programs to do .mp4 encodes and the average 2 hr movie takes about 2 hrs for two pass with filters. The Ripbot takes about 20 mins for 2 pass. I use RipBot when I am not too concerned about quality in exchange for the speed. I really like it and want to learn more about it
i7 Extreme 3970C 3.5Gh 64GB Ram

[ceth]

I have done some other test:

I first tried CQ 25.5 with a sample representing 1lap of this race video. This resulted in a 5693kbps video, not far from the 5835kbps I had obtained when encoding the full race with CQ 25.5.
With some calculation I ended finding CQ 23.43 should be the value to get the closest to a 8Mbps bitrate. This was indeed the case for the 1lap sample as I ended with a 8004kbps with this CQ value.
So I encoded the full race @CQ 23.43 and the result was a 8193kbps bitrate. This is a good result, representing a drift from target bitrate of only 2.5%.

The 2pass encoding at exactly 8Mbps took 180min to upload, 2.5% more data represents only 5min increase in upload time, so it is definetely worth it to encode using CQ instead of 2pass, even if you have to "waste" a few min to do a sample check to verify the result of the chosen CQ value. The quality of the CQ encode was even slighlty better then the 2pass for a similar ending bitrate (at least on the reference image I used to do all my comparisons). And this test also confirms using 1lap sample allows fairly accurate estimation of the result with the full video (full race).

For those wondering why I'm so picky about the resulting bitrate, this is not only to be able to foresee the upload time but also because my other quality test seem to show that youtube encoder has sweetspot bitrates at which the YT encoding result will be better. I tried to upload a 10Mbps 2pass encode and the result after YT re-encode was significantly lower quality than with the 8Mbps 2pass upload.

End for the fun part, I tried adding a 2.8Ghz OC'ed athlon64 (singlecore) to my server farm:
- Q6600@3.4Ghz -> 6fps approx.
- 4770K@4.1Ghz -> 12fps approx.
- A64@2.8Ghz -> 0.5fps !

Not worth it, ahaha. Esp. since you cannot start a job on a server and finish with another. But anyway the 2 other PC went through 22 chunks while the A64 only encoded 60% of a single chunk^^

[Atak_Snajpera]

Tomorrow I will upload new encoding client with workaround for crashing ffindex with ut video. It turns out that we just have to force libav demuxer while indexing. Haali does not work well in this case.

[ceth]

Nice !

Any chance you can have a look at DNxHD support in the mean time ? It is encapsulated in mov.
I have uploaded a sample here: http://www.mediafire.com/download/c2na47m4oa44cha/DNxHD+sample+for+ripbot.mov

The problem is ripbot tries to open it using directshowsource. The fix should be to use QTInput("filename") instead, in the getinfo.avs (and any other script used by ripbot that loads the source video ofc). A popup box asking for framerate should be required too, as I need to call ChangeFPS() too right after QTinput(). This is how I load it in virtualdub using an avisynth script.

Direct support from ripbot would be awesome as it would save the need for a intermediate recompression to another lossless format. It seems DNxHD is the only lossless format you can output from Sony Vegas. It makes your Vegas project render really fast, and then you can tweak your final AVC or whatever encoding better than you could with Vegas directly, and use the power of ripbot to speed up this final encoding.