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 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th August 2019, 12:18   #17161  |  Link
duffbeer
Registered User
 
Join Date: Mar 2019
Posts: 40
Has anyone else tried MDegrain2 since the update to LSmash? On my PC, the encoded output is OK for the first few minutes and then it becomes a slideshow of about 2fps.
duffbeer is offline   Reply With Quote
Old 19th August 2019, 13:56   #17162  |  Link
BLKMGK
Registered User
 
Join Date: Feb 2008
Posts: 145
Quote:
Originally Posted by ReinerSchweinlin View Post
I recognized something:

- The new index files are put into the source directory instead of the TEMP dir.
- after encoding and deleting all the jobs, the files still are recognized as "used" by windows.
- on some machines in the local network, the creating of the LWI Files after "Start" takes several minutes (the lokal machine and two others - all others are finished after a few seconds)
In my case the LWI files used to be in the source directory but now I can no longer find where they're being stored on disk, perhaps this is why they rebuild with each chunk? Jobs that should complete in under an hour easily are taking quite a bit longer. A queue that should've completed overnight is a fraction of the way complete - d'oh! Even looking at task manager and disk stats I cannot see where the LWI file is being created...

BLKMGK is offline   Reply With Quote
Old 19th August 2019, 15:34   #17163  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 454
I just looked and canīt find it either.. Strange...

edit: ahhhhhh :

appdata/local/temp/encodingserver1



... there i found some on one of the machines (which takes up a few seconds for the index files.)

Iīve noticed, that the "master machine" (which is one of the ones in the swarm needing about 5min to build the index files compared to around 20 sec) had about 50% to 80% GPU load on the csrss.exe while the index lwmi was building...

Just checked another machine (small 4 Core Celeron with 64bit win10), which does exactly the same - high GPU load on csrss while the index was built... This machine also takes minutes on the same 20min file I am encoding to build the index file.

Checked third machine: Dual Xeon 5660 - no GPU... this one was done in 5 seconds...


another thing: The video file always is copied completely into the TEMP directory - renamed to video.mkv. (The setting is "off" in the settings). Maybe this is on purpose and good for jobs where the source is stored on a usb-hd or slow SMD share - but doing a lot of jobs from a local harddrive Iīd guess it would be enough to not copy the whole video - it fills up the temp drive a lot (and after all, we have all these nice indexes now...)

Last edited by ReinerSchweinlin; 19th August 2019 at 15:58.
ReinerSchweinlin is offline   Reply With Quote
Old 19th August 2019, 16:40   #17164  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 454
Update:

Tested another PC - old Core2Duo - no GPU: This one also takes a long time to build the index - not much difference to the master machine (i5 kaby Lake)... So "having a GPU" canīt be the issue

It seems, the dual-xeon is so much faster since it has A LOT of cache build in, so it can index much faster - just guessing here.
ReinerSchweinlin is offline   Reply With Quote
Old 19th August 2019, 16:50   #17165  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
Some tips from me.
1) Make sure you have been fully updated and ALL your remote PC have latest version of EncodingServer.exe running

2) Start with new fresh job

Compressed index file is stored in JOB folder as video.mkv.lwi.7z. This file is next automatically decompressed on fly to %TEMP%/encodingserverX by EncodingServer.exe. Then EncodingServer modifies cachefile="" in X.avs file with proper path to extracted index file.
I did this to save few seconds on my slow LAN100/Wi-FI N network (real transfer is only ~10MiB/s). If Index file is 30MiB then I save 3s from starting procedure. In order to save few extra seconds I also compressed ffmpeg.exe with UPX (20MiB vs 60MiB).

Last edited by Atak_Snajpera; 19th August 2019 at 16:53.
Atak_Snajpera is offline   Reply With Quote
Old 19th August 2019, 17:13   #17166  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 560
Quote:
Originally Posted by ReinerSchweinlin View Post
Hey.
Thank you for the offer. I had a closer look into the temp folders... The two audio streams are extracted, audiolist.txt lists two streams and audiostreams.cmd lists to prozess 3 streams.
Whatīs missing is content in "encodeaudio2.cmd" - it has zero bytes.
I think you misunderstood me. I deal with the subs and audio outside of RipBot (another application) and then mux it all with a back to the encoded file from RipBot.
byteshare is offline   Reply With Quote
Old 19th August 2019, 17:19   #17167  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 560
Quote:
Originally Posted by duffbeer View Post
I think you may have misunderstood my problem. The issue I was referring to are with the encoded output file.
Encoding speed seems a little slower but the biggest problem is when I play back a file that was encoded with 1.25 using MDegrain2. The first 10-20 mins play back OK but then it plays at roughly 2fps. The audio is not affected and continues to play correctly.
I have tried the same source files on 1.24.1 and there is no problem so I believe it has something to do with LSmash.

The other big problem since 1.25 is that it takes roughly 2 minutes to auto crop. Generating a new preview frame also takes at least 1 minute. If I do exactly the same thing with 1.24.1 it crops in about 3-4 seconds.

It would be useful to know if anyone else has these issues. I've never had any serious issues with auto updates in the past, but this is the first time I'm going to have to ignore the latest version as it's virtually unusable in it's current form.
1.24.1 still works perfectly for me.

I've been using RipBot since 2012 and I think it's fantastic but the latest update seems totally broken to me.
Quote:
Originally Posted by duffbeer View Post
Anyone else experiencing cropping speed problems and MDegrain2 problems with v1.25?

I tested a VC-1 source and it was perfect but AVC or MPG2 cannot be encoded with MDegrain2 since the last update.

I'm happy to accept there may be a problem with my specific installation but 1.24 works perfectly.
Is there anything else I should do after the auto update has applied 1.25?
Quote:
Originally Posted by george84 View Post
Very simple avs file

Code:
x = ImageSource("testchart1.jpg", 0, 0, fps=24, use_DevIL = true, info=false, pixel_type = "RGB48")
x=ConvertToPlanarRGB(x)
x = z_ConvertFormat(x,resample_filter="bicubic", pixel_type="RGBPS", colorspace_op="rgb:srgb:709:f=>rgb:709:709:f")
x=ConvertToYV12(x)
x = Loop(x,120)
x
is added to RipBot264. It goes to

and never comes back. Windows10, RipBot 1.25.0 with all updates done. AVSMeter processes file without problems.
Problem is not important for me. Just FYI.

Quote:
Originally Posted by howzz View Post
Update:

Strangely. there's a new update that just rolled out a few mins ago. i launched ripbot again and it udpated itself. so i looked into the update log, and looks like either Atak may have enabled a new update for Lmash pushed a new version update to ripbot. either way, Lmash got updated, and now when it gets to Gathering Information/Extracting frames, it does so much faster. i also noticed that it compressed the index with the new update. so instead of the massive 1.25GB index file, .lwi is now 30MB small. and you can tell that when it compressed it because just right after indexing and before Gathering information, you see the ripbot status bar briefly shows Compressing Index. it then quickly proceeds to Gathering information and Extracting Frame and only take 3 or so mins now.

so whatever Atak did. thanks!. or whatever Lmash did, thanks!

==========
2019-08-17 13:38:25 : Update for [lsmash] detected
2019-08-17 13:38:25 : Downloading file http://atak-snajpera.5v.pl/ripbot264update/lsmash.zip to D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\lsmash.zip
2019-08-17 13:38:26 : [SUCCESS] File D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\lsmash.zip saved!
2019-08-17 13:38:26 : CRC32 value has not changed for [7z]. Update is not required.
2019-08-17 13:38:26 : Downloading finished.
2019-08-17 16:37:34 : =========================[UPDATER ACTIVATED]=========================
2019-08-17 16:37:34 : Installing updates...
2019-08-17 16:37:39 : [SUCCES] D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\core.zip has been correctly extracted!
2019-08-17 16:37:48 : [SUCCES] D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\ffmpeg.zip has been correctly extracted!
2019-08-17 16:37:49 : [SUCCES] D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\lsmash.zip has been correctly extracted!
2019-08-17 16:37:49 : Installation complete.
2019-08-17 16:37:55 : Next check after 2019-08-18 13:38:18
2019-08-17 16:38:42 : Next check after 2019-08-18 13:38:18
Quote:
Originally Posted by FuzzyNutz View Post
As of the last few days, playback of some of my blu-ray source videos encoded with RB have occasional flickering, where video frames seem to pause or jump back and forward within fractions of seconds. After the incidents, playback returns to normal and the audio is still synced correct.

Quote:
Originally Posted by brumsky View Post
I'm having an odd issue with ripbot. It's taking 5-15 minutes to start an encode chunk every time. I already did the update which compresses the lwi file down to around 30MBs.

Something I've noticed is that when the encoding client is starting a new chunk. The system process pegs my network connection - currently 1Gbps. While the disk usage is very low. So it'll start disk usage will hit 20-30MBps then drops to 1-2MB/s while the network is pegged at 800-900 Mb/s. it'll stay like that for quite some time. This is going from a R7 1700 to a AMD 3900x via Gigabit ethernet at the moment.

I've also confirmed the system running the encoding server matches the system process behavior.

I've also tried this on another machine same issue - 16c Xeon v4.

I understand that the lwi file is larger in general which takes it longer to copy. This seems abnormally long given the lwi file uncompressed is usually around 1.3GBs for a 4K movie.

Thoughts?
Quote:
Originally Posted by Pino72 View Post
Same for me, the last days were a nightmare....DE that always worked since months suddenly broken, servers not starting at all, big time delays when rendering chunks like you described, a looooong wait for Autocrop and so on.

I hope these issues get fixed soon since I really think ripbot is the best tool to convert uhd 4K hdr files.

At least since today I am able to use DE again on my two machines and even after aborting he picks up where it left....which also seemed broken a day or two ago. Really strange.

Quote:
Originally Posted by ReinerSchweinlin View Post
I recognized something:

- The new index files are put into the source directory instead of the TEMP dir.
- after encoding and deleting all the jobs, the files still are recognized as "used" by windows.
- on some machines in the local network, the creating of the LWI Files after "Start" takes several minutes (the lokal machine and two others - all others are finished after a few seconds)

Quote:
Originally Posted by duffbeer View Post
Has anyone else tried MDegrain2 since the update to LSmash? On my PC, the encoded output is OK for the first few minutes and then it becomes a slideshow of about 2fps.
Quoted all of that since it seems some have not updated RipBot since the 1.25 update. If your LSmash files are not being stored in the job folder and you're not seeing .7z files for LSmash you need to update.
-Close RipBot Open, wait for the update to download files, close, reopen and the update will be installed. You might need to do this more than once if you didn't wait long enough.

Once you're on the most recent update you should then see if this fixed any of your issues.
-Sidenote. It would be helpful to change the point releases with these updates such as 1.25.xx, ie 1.25.02 or something

I did some testing in between 1.25 and the most recent update:
https://forum.doom9.org/showthread.p...66#post1881866
I'll need to do more testing myself to see if:
-Any of the filter combination issues I was having got fixed
-Extracting a frame is faster
-Auto Crop is faster
-See any weird frames jumping around (but audio in sync when it stops) on some files when using QTGMC that I hadn't seen until LSmash.

Last edited by byteshare; 19th August 2019 at 18:16.
byteshare is offline   Reply With Quote
Old 19th August 2019, 17:22   #17168  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 454
Quote:
Originally Posted by byteshare View Post
I think you misunderstood me. I deal with the subs and audio outside of RipBot (another application) and then mux it all with a back to the encoded file from RipBot.
Yes, that was perfectly clear Thanx for the offer! For now I will first deal with those files having only one language - maybe Ripbot will be able to handle it in the future - if not, I will gladly come back to your offer.

@Atak
Thanx. Of course, everything is up to date At least a few hours ago. Started ripbot on every machine three times, waited 5 minutes in between to fully catch all updates - then started to investigate..

I think I found the issue of some machines doing very slow "indexing" mentioned above:

Close the encoding server windows (which is displaying the "indexing" procedure from 0 to 100%) - this did the trick for me - all machines now only take some seconds - the slower ones having the lowest cpu/bandwith... Machines which took minutes before now are starting after a few seconds..

Nice

So it seems the screen-output of ther encoding server window is causing this?
ReinerSchweinlin is offline   Reply With Quote
Old 19th August 2019, 18:18   #17169  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 560
Quote:
Originally Posted by ReinerSchweinlin View Post
Thanx. Of course, everything is up to date At least a few hours ago. Started ripbot on every machine three times, waited 5 minutes in between to fully catch all updates - then started to investigate..
Core should be Version: 2019.08.17
With the above version:
-Extracting a frame is faster
-Auto Crop is faster

Still need to test:
-Any of the filter combination issues I was having got fixed
-See any weird frames jumping around (but audio in sync when it stops) on some files when using QTGMC that I hadn't seen until LSmash.

Last edited by byteshare; 19th August 2019 at 21:09.
byteshare is offline   Reply With Quote
Old 19th August 2019, 20:16   #17170  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 454
@byteshare
Yes, we are on the same page, ah version

Did some more testing - while encoding some old anime, I noticed this:

source video (resized to fit width of the target for better comparison)


encoded video (q22, slow, no filter, resized to match 720p, HEVC, 10 Bit)


Its not exactly the same frame, but that doesnīt matter..

Notice the 1 pixel dots between the soft noise in the picture - and in the middle of the white "snake-like" thing...

These artefacts seem to come from resizing, I have seen them quite a lot when encoding animes..
Attached Images
  
ReinerSchweinlin is offline   Reply With Quote
Old 19th August 2019, 20:57   #17171  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 560
Quote:
Originally Posted by ReinerSchweinlin View Post
@byteshare
Yes, we are on the same page, ah version

Did some more testing - while encoding some old anime, I noticed this:

source video (resized to fit width of the target for better comparison)


encoded video (q22, slow, no filter, resized to match 720p, HEVC, 10 Bit)


Its not exactly the same frame, but that doesnīt matter..

Notice the 1 pixel dots between the soft noise in the picture - and in the middle of the white "snake-like" thing...

These artefacts seem to come from resizing, I have seen them quite a lot when encoding animes..
Link the images from an image hosting site rather than uploading directly to this forum, such as Imgur.com

That said what are you using to resize the video? Have you tried: nnedi3_resize16
Also, are you using other filters?

Last edited by byteshare; 19th August 2019 at 21:01.
byteshare is offline   Reply With Quote
Old 19th August 2019, 21:31   #17172  |  Link
slalom
Registered User
 
slalom's Avatar
 
Join Date: Jan 2010
Posts: 456
Quote:
Originally Posted by Atak_Snajpera View Post
Some tips from me.
1) Make sure you have been fully updated and ALL your remote PC have latest version of EncodingServer.exe running

2) Start with new fresh job

Compressed index file is stored in JOB folder as video.mkv.lwi.7z. This file is next automatically decompressed on fly to %TEMP%/encodingserverX by EncodingServer.exe. Then EncodingServer modifies cachefile="" in X.avs file with proper path to extracted index file.
I did this to save few seconds on my slow LAN100/Wi-FI N network (real transfer is only ~10MiB/s). If Index file is 30MiB then I save 3s from starting procedure. In order to save few extra seconds I also compressed ffmpeg.exe with UPX (20MiB vs 60MiB).
I downloaded and extracted the files from the first page
I ran that to update to the latest files, checked the files with yours
I removed all jobs from previous version
I copied the updated folder everywere and added 5 jobs

Same thing, massive network usage
__________________
E5 2697 v2 @ 3.0GHz on P9X79 Deluxe 24GB
Xeon E5-2680 v2 @ 3.1GHz 16GB
Sony Vaio VPC-F13Z1E/B
slalom is offline   Reply With Quote
Old 19th August 2019, 22:01   #17173  |  Link
BLKMGK
Registered User
 
Join Date: Feb 2008
Posts: 145
Quote:
Originally Posted by Atak_Snajpera View Post
Some tips from me.
1) Make sure you have been fully updated and ALL your remote PC have latest version of EncodingServer.exe running

2) Start with new fresh job
<snip>
started with a fresh job, all CRC are correct, i see indexes being built on each client after each block. i'm currently only running 2x clients with remote access. I'm not sure what to try, these files are small and arent using filters. In 8 hours i processed 4 30min long 720p video that would normally process in under 3mins each

ill try a fresh install when i can lay hands kn the boxes in person, happy to provide anything to troubleshoot though. Still would love to solve my GPU issue filtering too!
BLKMGK is offline   Reply With Quote
Old 19th August 2019, 23:49   #17174  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
I made sure all CRCs matched on both of my machines.

I am still getting high network usage and now the encoding server shows it is creating the index file. Here is print out of it - if it helps.

https://pastebin.com/WB2ACdfg

thoughts??
brumsky is offline   Reply With Quote
Old 20th August 2019, 02:05   #17175  |  Link
FuzzyNutz
Registered User
 
Join Date: Jun 2016
Location: Canada
Posts: 131
flickering frames

Quote:
Originally Posted by byteshare View Post
Quoted all of that since it seems some have not updated RipBot since the 1.25 update. If your LSmash files are not being stored in the job folder and you're not seeing .7z files for LSmash you need to update.
-Close RipBot Open, wait for the update to download files, close, reopen and the update will be installed. You might need to do this more than once if you didn't wait long enough.

Once you're on the most recent update you should then see if this fixed any of your issues.
-Sidenote. It would be helpful to change the point releases with these updates such as 1.25.xx, ie 1.25.02 or something

I did some testing in between 1.25 and the most recent update:
https://forum.doom9.org/showthread.p...66#post1881866
I'll need to do more testing myself to see if:
-Any of the filter combination issues I was having got fixed
-Extracting a frame is faster
-Auto Crop is faster
-See any weird frames jumping around (but audio in sync when it stops) on some files when using QTGMC that I hadn't seen until LSmash.
RipBot264 updated today, yet it's still producing videos with flickering frames or "frames jumping around".
FuzzyNutz is offline   Reply With Quote
Old 20th August 2019, 02:28   #17176  |  Link
BLKMGK
Registered User
 
Join Date: Feb 2008
Posts: 145
I've erased everything, dropped back to v1.24, and turned off auto-updating for now It seems like others are experiencing the same issues with index building I was so I'll wait a bit, hopefully address filtering via GPU not working on clients (for me) later. I suspect the fix won't be super difficult to solve the indexing but I've got a stack of videos waiting for me and cannot proceed at such a slow pace...
BLKMGK is offline   Reply With Quote
Old 20th August 2019, 05:32   #17177  |  Link
userx
Registered User
 
userx's Avatar
 
Join Date: Mar 2016
Location: Austria
Posts: 32
bad sequence header magic

Hello
After last update I'm not able to start a DE job. On local and remote machine EncodingServer runs into
Code:
Encoding started...
""\\USERX-MASTER\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "\\USERX-MASTER\RipBot264temp\job1\Chunks\1.avs" -strict -1 -f yuv4mpegpipe - | "\\USERX-MASTER\Ripbot264temp\tools\x264\x264_x64.exe" --seek 0 --colorprim bt709 --transfer bt709 --colormatrix bt709  --opencl --opencl-device 0 --opencl-clbin "C:\Users\UserX\AppData\Local\Temp\x264_lookahead_1.clbin" --pass 1 --bitrate 3000 --stats "\\USERX-MASTER\RipBot264temp\job1\Chunks\1.stats" --fps 24000/1001 --force-cfr  --min-keyint 24 --keyint 240 --frames 1440 --sar 1:1 --level 4.1 --aud --nal-hrd vbr --vbv-bufsize 25000 --vbv-maxrate 25000 --b-pyramid none --ref 5 --stdin y4m --output NUL -"
y4m [error]: bad sequence header magic
x264 [error]: could not open input file
Has anybody an idea to fix it?
userx is offline   Reply With Quote
Old 20th August 2019, 07:40   #17178  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 560
Quote:
Originally Posted by FuzzyNutz View Post
RipBot264 updated today, yet it's still producing videos with flickering frames or "frames jumping around".
Are you using filters? I've seen the issue with QTGMC.
I'm not having that issue with AVC/HEVC source either without filters or with LSFmod or FastLineDarkenMod.
I need to test with more filters besides QTGMC.
Quote:
Originally Posted by BLKMGK View Post
I've erased everything, dropped back to v1.24, and turned off auto-updating for now It seems like others are experiencing the same issues with index building I was so I'll wait a bit, hopefully address filtering via GPU not working on clients (for me) later. I suspect the fix won't be super difficult to solve the indexing but I've got a stack of videos waiting for me and cannot proceed at such a slow pace...
I'm not having the issue...so maybe something more specific to the default startup commands for the encoding servers?
I'm using:
/port 1000 /minimize /priority low /restart-if-no-progress 8
byteshare is offline   Reply With Quote
Old 20th August 2019, 07:42   #17179  |  Link
byteshare
ByteShare
 
byteshare's Avatar
 
Join Date: Sep 2014
Location: On the Internet
Posts: 560
Quote:
Originally Posted by userx View Post
Hello
After last update I'm not able to start a DE job. On local and remote machine EncodingServer runs into
Code:
Encoding started...
""\\USERX-MASTER\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i
 "\\USERX-MASTER\RipBot264temp\job1\Chunks\1.avs" -strict -1 -f yuv4mpegpipe - | 
"\\USERX-MASTER\Ripbot264temp\tools\x264\x264_x64.exe" --seek 0 --colorprim bt709 --transfer bt709 --colormatrix bt709  --opencl --opencl-device 0 --opencl-clbin 
"C:\Users\UserX\AppData\Local\Temp\x264_lookahead_1.clbin" --pass 1 --bitrate 3000
 --stats "\\USERX-MASTER\RipBot264temp\job1\Chunks\1.stats" --fps 24000/1001
 --force-cfr  --min-keyint 24 --keyint 240 --frames 1440 --sar 1:1 --level 4.1 --aud
 --nal-hrd vbr --vbv-bufsize 25000 --vbv-maxrate 25000 --b-pyramid none --ref 5
 --stdin y4m --output NUL -"
y4m [error]: bad sequence header magic
x264 [error]: could not open input file
Has anybody an idea to fix it?
Are you able to browse to the share and see the file? Could be an issue with the share.
byteshare is offline   Reply With Quote
Old 20th August 2019, 11:40   #17180  |  Link
ReinerSchweinlin
Registered User
 
Join Date: Oct 2001
Posts: 454
Quote:
Originally Posted by byteshare View Post
Link the images from an image hosting site rather than uploading directly to this forum, such as Imgur.com

That said what are you using to resize the video? Have you tried: nnedi3_resize16
Also, are you using other filters?
thanx for your reply!

Iīd rather leave them in the forum - external Image hosting tends to ditch pictures after a while - several older threads are almost unusable because people put the images on imageshack - now they are gone...

Or is there a particular reason why itīs not recommended to save them directly in the forum?

I used the default resize funktion in Ripbot. Looking at the Avisynthscript, it is spline resize - I am not at the pc right now, so Iīd have to check exactly, but I think I remember it was spline36, using some plugin for multihtreading.... The default one.. didnīt change anything. no custom scripts.

No, no filters, just resizing.
ReinerSchweinlin is offline   Reply With Quote
Reply

Tags
264, 265, appletv, avchd, bluray, gui, iphone, ipod, ps3, psp, ripbot264, x264 2-pass, x264 gui, x264_64, x265, xbox360

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 19:53.


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