VideoHelp Forum
+ Reply to Thread
Results 1 to 19 of 19
Thread
  1. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    i was going to post this in the other thread but i realized that a) i had technically thread-jacked that thread and b) it had kind of, sort of degenerated into me making fun of a couple of posters and i can't help but feeling like my making fun of them is in some small way partially my fault

    anyway, i have spent the past day downloading about 100gb of uncompressed and losslessly compressed sources, including the full 4k DCP Tears of Steel package and after playing around with more yuv and y4m sources than i care to remember and trying different workflows, i settled on this test as a representative of what sort of quality one can expect with my particular setup and a really high quality source.

    for those that don't know, my current setup is an X6 1045t, 8gigs ddr3 and a 9600GSO. i will be revisiting this test in a month or so, i am expecting to come into a few bucks and i plan on picking up a haswell with 16gigs ddr3, a r7 260x and probably a couple of 10k WD hard drives..

    deciding on a source wasn't easy, i decided to listen to the criticism against using a 4k source that had already been encoded with x264 and also to the criticism against using a source that would require resizing.

    i finally settled on the y4m version of Elephant's Dream, 1280x720 resolution available here:

    https://media.xiph.org/video/derf/

    the workflow was simple enough to replicate, download the 4gb archive (in .xz format), extract the archive to end up with a 21gb y4m, use ffmpeg to mux it into an avi container and then use that as source. in terms of encoding speed, the results i got should be taken with a high grain of salt; with this source my hard drives easily bottlenecked the whole system, to work with these kind of sources a raid-o is a must and i'm definitely i may just pick up a couple of cheap SSD's to raid together for the new build.

    having said this the gpu assisted encodes flat out smoked x264, it wasn't even close. using Media Coder to convert to x264 ultra fast took over 90 minutes to encode the 10:53 long clip.

    now i know that the x264 apologists will point out the following; the hard drive's were a bottleneck and didn't allow x264 to reach anywhere near it's full potential. i agree, in fact with ultra fast, cpu usage was barely above idle, i suppose i could have used Media Coder's segmental video encoding feature to increase cpu load but that would also have increased the load on the hard drive.

    but such excuses for x264 ignore this reality, the gpu tests encodes, all finished in under 45 minutes and the cpu load with them wasn't more than about 20% and the gpu load, as measured by GPU-z was between 20%-30% most of the time with gpu memory usage in the 300mb range. furthermore, the gpu encoders would be just as bottlenecked by the hard drive configuration i currently have and more importantly the gpu has slower ram than my system (ddr2 versus dd3), has significantly less ram than my system (768mb versus 8gb) and with these gpu encoders there is a memory copy from the system ram to the gpu ram which according to jack offs like the x264 developers is so slow that it negates any performance benefit gained by running the encoder on the gpu. newer encoders built to run on more modern gpu's are capable of directly accessing system ram eliminating this supposed bottleneck.

    the biggest problem i saw with the Open Cl encoders was the inability to hit the target bit rate, the Main Concept OCL encoder overshot the target bit rate by 500 kb/s and the Sony OCL encoder undershot by about 500 kb/s.

    i also threw in 3 different x264 encodes, ultra fast, medium and very slow, as a way of seeing at what point, if any, x264 beats the gpu accelerated encodes. i also did a x265 encode, all encodes were kept at their 1280x720p24 resolution/frame rate and i chose a target bit rate of 4mb/s, primarily because that is the resolution/bit rate combo i usually see when people want to either "backup" "their" blu-rays or when they make a movie available for download in hi-def.

    i tested with the demo for Sony Movie Studio Platinum 13, namely Sony's GPU powered AVC, Main Concept's OCL AVC and Main Concept's CUDA AVC. additionally i tested with Media Coder for the x264 and x265 tests as well as Media Coders CUDA encoder. i would have liked to have thrown in a test of NVENC, the hardware gpu encoder found in Maxwell and Kepler class nvidia gpus but i do not have such a card available.

    when i build the new system in a month or so i will be revisiting this thread and updating the results with fresh OCL tests from Main Concept via Movie Studio and i also plan to do a test of the hardware encoding chip found in newer AMD cards, namely VCE v2,

    here is the Media Info output:


    Complete name : E:\EDIT\elephants_dream_480p24.y4m\elephants_dream _720p24.y4m
    Format : YUV4MPEG2
    File size : 20.2 GiB
    Duration : 10mn 53s
    Overall bit rate : 265 Mbps

    Video
    Format : YUV
    Duration : 10mn 53s
    Bit rate : 265 Mbps
    Width : 1 280 pixels
    Height : 720 pixels
    Display aspect ratio : 16:9
    Frame rate : 24.000 fps
    Color space : YUV
    Chroma subsampling : 4:2:0
    Scan type : Progressive
    Compression mode : Lossless
    Bits/(Pixel*Frame) : 12.000
    Stream size : 20.2 GiB (100%)

    and the test encodes:


    as for which one came out the best, i guess that's open to interpretation. personally i don't see much of a difference between any of the encodes and in all honesty with a source of this quality i didn't expect to. some of you may find some frame here or there where one encoder seemed to have an advantage but deciding which is better is no easy feat. is an encoder's job to reproduce as faithfully as possible the source it's given or is it's job to produce the best looking output it can.

    these two are not mutually inclusive, an encoder with aggressive psychovisual enhancement algorithms will usually produce the best looking results but by definition it won't be the most faithful to the source, as is easily proven via objective math assessments such as PSNR and SSIM.

    likewise a basic encoder plus some really good filters, like neat video, may produce the cleanest looking output but not be representative of the source.

    only when one decides what's more important, producing the best looking output possible or reproducing the source as accurately as possible can one decide which encode is the best.

    the sad thing is that the x264 developers have spent the better part of the decade "educating" the average user into believing that the more pleasing looking encode is superior to the more accurate encode, to the point where most users that are considered knowledgeable now accept it as sacrosanct, gospel, something not to be questioned.

    the x265 folks, led by Tom, seem to have embraced this paradigm with fervor and they are already using it to discount any test where their alpha grade encoder isn't seen to beat x264 by a clear margin.

    the irony is palpable, Jason, in tirelessly promoting his little baby, created and spread a narrative that took on a life of its own; that narrative is now being used against his baby to promote another over-rated over-engineered encoder, an encoder that is meant to supplant x264 in the general public's mind as the best software encoder in it's particular class.

    this is what's great about BS, you can spread it and spread it but eventually it gets too deep and has a tendency to drown the source of it. in the coming years DS is going to be beaten over the head with the same crap he beat his competitors with and i can't wait to see how he reacts.

    i have to get ready for work so i'm only uploading 4 test samples, i will be updating this thread tomorrow with 2 pass Main Concept CUDA and OCL encodes, Media Coder CUDA encodes, x264 medium and very slow, and x265 ultra slow.

    i will also see if i can borrow a buddies licensed copy of Total Code Studio (i think he has version 2.5) and do tests with the official Main Concept suite.

    And as i said, once the new build is done i will be revisiting these tests, i will be updating results for speed once I/O is no longer a major bottleneck.

    if anyone feels like reproducing the above tests, feel free and please post your results and if anyone knows of any other very high quality y4m sources please link to them i'll be happy to run more tests.

    for my part, i pledge to refrain from mocking anyone in this thread as i don't want to skunk it up and derail it, i'd like there to be one unofficial gpu encoding thread here for visitors that want to see for themselves the status gpu encoding.

    thanks for reading.
    Image Attached Files
    Quote Quote  
  2. Originally Posted by deadrats View Post
    as for which one came out the best, i guess that's open to interpretation. personally i don't see much of a difference between any of the encodes and in all honesty with a source of this quality i didn't expect to. some of you may find some frame here or there where one encoder seemed to have an advantage but deciding which is better is no easy feat. is an
    encoder's job to reproduce as faithfully as possible the source it's given or is it's job to produce the best looking output it can.

    these two are not mutually inclusive, an encoder with aggressive psychovisual enhancement algorithms will usually produce the best looking results but by definition it won't be the most faithful to the source, as is easily proven via objective math assessments such as PSNR and SSIM.



    Exactly! You need to decide on an "endpoint" for testing. Decide on what is being tested for this test. Then you can adjust the encoder , setup and testing methodology accordingly. For example, if you were measuring SSIM/PSNR like most encoders are tuned for out of the box, you can set the encoding parameters to reflect that

    Thanks for doing the tests, but title is a bit misleading - I wouldn't call it "comprehensive" testing. Comprehensive would include a range of bitrates and tunings aimed for different scenarios. You can't do SSIM or PSNR plots with 1 data point. But this takes days/weeks of testing. Nobody has time for that , unless it's your job, or you're doing this for a thesis or something

    You "chose" 4Mb/s , but most people don't "choose" 4Mb/s. It might result in 4Mb/s because that's what the content complexity dictates it to be. If you view online, or what poll what people do to make their "backups" , it's not a set bitrate, it's quality based encoding . Complex material might require more than 4Mb/s. Simple material might require less than 4Mb/s

    If I can make yet another suggestion - a better way to do this without a series of encodes would be to start with a "typical" x264 encode. Say CRF 18-22 would be what most people use. Look at that resultant bitrate , then plug that value into the GPU encoders. I wouldn't do SSIM or PSNR testing , because people wouldn't do that either in normal usage scenarios.

    There are many issues with SSIM / PSNR testing. It's the "best" objective measures that we commonly use, but it often doesn't reflect "faithful" to the source either in terms of human perception . I can post some examples if you want , but it's a big topic and I'll try not to pollute your thread either
    Quote Quote  
  3. Originally Posted by deadrats View Post
    having said this the gpu assisted encodes flat out smoked x264, it wasn't even close. using Media Coder to convert to x264 ultra fast took over 90 minutes to encode the 10:53 long clip.
    Obviously, all you uncovered is a problem with Mediacoder. Just as a quick test I downloaded your MC Cuda encode and reencoded it with x264 at the Ultrafast preset (AviSynth, ffvideosource). It tool less than one minute. And half of that was decoding the source.
    Quote Quote  
  4. All tests should be done with commandline variants if there are available.

    For example, using vegas isn't ideal for GPU testing. The reason is it's not really showing the GPU encoder in the best light. Vegas adds another "layer" of complexity. It converts to RGB and back to YUV so it will encode slower. Even if you encode using x264vfw in vegas, you will notice it to be slower than doing it from the commandline version of x264.exe, or even x264vfw though vdub . All other processes can take away from encoding speed.Even routing through avisynth as a frameserver will be marginally slower than not routing through it (--demuxer lavf)
    Quote Quote  
  5. I mentioned this in the other thread, but you can get a rough idea of Mainconcept/Rovi's GPU implmentation of CUDA and OCL with MSU's comparison. The tests aren't perfect, but at least you get some rough idea. The endpoint for them is always SSIM, but quality/speed tradeoffs are measured as well

    They used GTX580, and IvyBridge i7-3770 for all tests, so it's more standardized - no mixed architectures. They also used commandline versions of all encoders so results aren't contaminated by some GUI or wrapper, or other processes

    There are dozens of more charts so go look at the free pdf. For those lazy folk I copied a couple here. (Almost) Everyone knew this already but speedwise they support what jagabo is saying

    Click image for larger version

Name:	1.jpg
Views:	730
Size:	64.3 KB
ID:	24600

    Click image for larger version

Name:	2.jpg
Views:	195
Size:	43.3 KB
ID:	24601
    Quote Quote  
  6. I ran the above quick test on an i5 2500K at stock clock speed. I believe RawSource() in AviSynth can read y4m sources.
    Quote Quote  
  7. Originally Posted by jagabo View Post
    I believe RawSource() in AviSynth can read y4m sources.
    Yes it can.

    And x264 can read .y4m directly too if support is compiled for it (most distributed binaries do )
    Quote Quote  
  8. I now have the same 21 GB y4m file as deadrats. Using an AviSynth script:

    Code:
    RawSource("elephants_dream_720p24.y4m")
    And the x264 CLI encoder via a batch file:

    Code:
    x264.exe --preset=ultrafast --crf=18 --sar=1:1 --output %1.mkv %1
    took 3 minutes and 14 seconds to encode, with only about 25 percent CPU usage on my i5 2500K.
    Quote Quote  
  9. Originally Posted by deadrats View Post
    i was going to post this in the other thread but i realized that a) i had technically thread-jacked that thread and b) it had kind of, sort of degenerated into me making fun of a couple of posters and i can't help but feeling like my making fun of them is in some small way partially my fault
    Funniest thing I've read in ages. I thought you started a new thread after running away from the other one with your tail between your legs once you realised you'd been proven wrong and therefore made a complete git out of yourself.
    Your ability for self-denial is incredible. I kind of envy it in a way.... being able to ignore reality and live in some sort of ignorance induced bliss.
    Last edited by hello_hello; 18th Apr 2014 at 16:52.
    Quote Quote  
  10. Originally Posted by jagabo View Post
    Originally Posted by deadrats View Post
    having said this the gpu assisted encodes flat out smoked x264, it wasn't even close. using Media Coder to convert to x264 ultra fast took over 90 minutes to encode the 10:53 long clip.
    Obviously, all you uncovered is a problem with Mediacoder. Just as a quick test I downloaded your MC Cuda encode and reencoded it with x264 at the Ultrafast preset (AviSynth, ffvideosource). It tool less than one minute. And half of that was decoding the source.
    As we discovered in the "other" thread, MediaCoder has a tendency to appear to be doing one thing while it's doing something else, and it seems not to produce a detailed log file, so there's no way to know for sure what's going on behind the scenes. I wouldn't trust it with my encodes, and I'd definitely not trust it for performing any sort of comparison encodes, but as was also proved in the other thread, when it comes to MediaCoder users, the person driving the software can be as flaky as the software itself.
    I can't test it at the moment, but when I ran a few brief MediaCoder/x264 test encodes previously, it didn't strike me as being particularly slow compared to Avisynth/x264, so I can't imagine what's going on with deadrats setup.

    Originally Posted by deadrats View Post
    having said this the gpu assisted encodes flat out smoked x264, it wasn't even close. using Media Coder to convert to x264 ultra fast took over 90 minutes to encode the 10:53 long clip.
    I can encode at 720p in around "realtime" using my old Q9450 CPU (slightly overclocked) and x264's medium speed preset.
    In fact I'm currently re-encoding a 720p video with QTGMC in single threaded mode (now that's a bottleneck) using the x264 slow speed preset and I'm still encoding faster than that.

    Originally Posted by deadrats View Post
    now i know that the x264 apologists will point out the following; the hard drive's were a bottleneck and didn't allow x264 to reach anywhere near it's full potential. i agree, in fact with ultra fast, cpu usage was barely above idle
    What a load of nonsense. The hard drive is not going to be the bottleneck for encoding speed. I'm not sure I've ever seen anyone claim it would be.
    I can copy a 4GB file from one location to another in minutes. Even copying a 21GB file from one location to another would be measured in minutes, not hours (10 minutes using a single hard drive?). How on earth could the hard drive be the bottleneck for encoding speed if it can copy a file much faster than the CPU/GPU can re-encode it?
    Last edited by hello_hello; 18th Apr 2014 at 17:23.
    Quote Quote  
  11. Originally Posted by hello_hello View Post
    As we discovered in the "other" thread, MediaCoder has a tendency to appear to be doing one thing while it's doing something else, and it seems not to produce a detailed log file, so there's no way to know for sure what's going on behind the scenes.
    did you look for mediacoder's log file in expert mode ? or push f6 ? according to this

    http://forum.mediacoderhq.com/viewtopic.php?f=17&t=8049


    Originally Posted by hello_hello View Post
    Originally Posted by deadrats View Post
    now i know that the x264 apologists will point out the following; the hard drive's were a bottleneck and didn't allow x264 to reach anywhere near it's full potential. i agree, in fact with ultra fast, cpu usage was barely above idle
    A load of nonsense. The hard drive is not going to be the bottleneck for encoding speed. I'm not sure I've ever seen anyone claim it would be.
    In the context of uncompressed material such as y4m , yuv , it can be a bottleneck on single HDD. An 8bit 1080p24 4:2:0 stream will consume about 100MB/s . (that's megabytes /s , not megabits/s)

    You can have a look here for approximate data rates
    http://en.wikipedia.org/wiki/Uncompressed_video#Storage_and_Data_Rates_for_Uncompressed_Video

    But in this specific sample, it shouldn't be a bottleneck unless the HDD is very old, or fragged because it's only 720p24 . His mediainfo report says 265Mbps which would be about 33MB/s
    Last edited by poisondeathray; 18th Apr 2014 at 16:57.
    Quote Quote  
  12. I don't know why deadrats encoded with 15 frame GOPs and no b-frames (maybe because keyframe pumping is so bad with CUDA) but here's an x264 encoding (video only) with:

    Code:
    x264.exe --preset=veryfast --crf=18 --aq-mode=2 --aq-strength=1.8 --sar=1:1 --output %1.mkv %1
    It took my i5 2500K 3 minutes and 7 seconds to encode. The result is a slightly lower bitrate than deadrats' MC CUDA encode (the only one of his encodings I downloaded). That beats Mediacoder's CUDA encoding time by ~15x and still looks significantly better. I'm not going to bother uploading it, but an encoding at the slow preset still only took about 8 minutes and looked even better.

    The only fine tuning I did was the aq settings. Without them the resulting bitrate was about 10 percent lower and some of the low motion shots looked a little worse.
    Image Attached Files
    Quote Quote  
  13. Originally Posted by poisondeathray View Post
    Originally Posted by hello_hello View Post
    As we discovered in the "other" thread, MediaCoder has a tendency to appear to be doing one thing while it's doing something else, and it seems not to produce a detailed log file, so there's no way to know for sure what's going on behind the scenes.
    did you look for mediacoder's log file in expert mode ? or push f6 ? according to this

    http://forum.mediacoderhq.com/viewtopic.php?f=17&t=8049
    No, but I tried it. I haven't looked through it all thoroughly yet, but I at least found proof in the log file MediaCoder was changing the SAR for my encode in the other thread. The one which caused deadrats to retreat into complete denial.
    I can see the different SAR in the x264 commandline (111:110), although I'm still not sure why it's doing it.

    Click image for larger version

Name:	mediacoder.gif
Views:	573
Size:	19.9 KB
ID:	24609


    In the context of uncompressed material such as y4m , yuv , it can be a bottleneck on single HDD. An 8bit 1080p24 4:2:0 stream will consume about 100MB/s . (that's megabytes /s , not megabits/s)
    Well, yes, thinking about it, when it comes to large uncompressed source files I guess it's possible, but if the hard drive is the bottleneck, I assume it's going to bottleneck the GPU in the same way as it'll bottleneck the CPU.
    Last edited by hello_hello; 18th Apr 2014 at 17:47.
    Quote Quote  
  14. Originally Posted by jagabo View Post
    I don't know why deadrats encoded with 15 frame GOPs and no b-frames (maybe because keyframe pumping is so bad with CUDA)
    15 frame GOPs seems to be the MediaCoda/CUDA default.

    Click image for larger version

Name:	cuda.gif
Views:	662
Size:	44.3 KB
ID:	24610

    The B-frames default appears to be 2. You'll need to ask deadrats if/why he changed that.

    Click image for larger version

Name:	cuda 2.gif
Views:	546
Size:	20.5 KB
ID:	24611
    Quote Quote  
  15. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    Originally Posted by hello_hello View Post
    How on earth could the hard drive be the bottleneck for encoding speed if it can copy a file much faster than the CPU/GPU can re-encode it?
    i really wanted to keep this thread skunk free but i just have to point out that if you don't understand why I/O is a bottleneck when working with uncompressed sources then you have no right commenting on any aspect (ratio) of video encoding.

    i'll let pdr, jagabo or someone else explain why I/O becomes a bottleneck with high data rates.
    Last edited by deadrats; 18th Apr 2014 at 20:26.
    Quote Quote  
  16. Deadrats, as if it wasn't obvious already, there is definitely something wrong with Mediacoder on your system. I encoded the y4m file with mediacoder on my Intel Q6600 quad core system with a Nvidia GTX 460 with the CUDA encoder in a little over 8 minutes. And that was with the ym4 file being access on another computer via Gb Ethernet.
    Quote Quote  
  17. Originally Posted by deadrats View Post
    i really wanted to keep this thread skunk free but i just have to point out that if you don't understand why I/O is a bottleneck when working with uncompressed sources then you have no right commenting on any aspect (ratio) of video encoding.
    That's it? The best retort you could manage?
    I guess you should've refrained from stinking the thread up from the get-go with childish comments about making fun of others. I probably would have let you get away with running away from the other thread with your tale between your legs had you not dragged that discussion into this thread yourself.
    I assume "keep this thread skunk free" is deadrats-speak for "nobody should disagree with me".

    As for the irrelevancy of uncompressed sources and aspect ratios..... poisondeathray pointed out there's a chance uncompressed sources could cause the hard drive to be a bottleneck, I had a rethink and replied admitting he was correct. But I'll say it for the record, given the obvious isn't always obvious to you.... therefore I was wrong.
    See how easy it is when you're all grown up to admit you were wrong about something? It didn't hurt a bit.

    But lets face it, you've well and truly proven you can't determine the aspect ratio of a video correctly, so based on your logic, that disqualifies you from having the right to comment on video compression, ever.

    Originally Posted by deadrats View Post
    i'll let pdr, jagabo or someone else explain why I/O becomes a bottleneck with high data rates.
    No need. Concentrate on extracting the obvious from his previous post and refrain from making yourself look even more foolish until you work out why your encoding times are far from typical. It shouldn't be hard. jagabo even explained that he's explaining the obvious, in case it's not obvious to you.

    While he's at it, maybe you could get him to explain why in your case, it's very likely the data rate isn't high enough for the hard drive to be a I/O bottleneck. From there he could explain to you why it's not likely to bottleneck CPU encoding while allowing the GPU to encode at twice the speed even if it was.
    Last edited by hello_hello; 20th Apr 2014 at 17:47.
    Quote Quote  
  18. For funzies I ran a couple of MediaCoder and MeGUI x264 encodes to see if there was anything odd going on in respect to encoding times. I just split off the first 10 minutes of a random 720p video. It didn't seem worth downloading a non-typical video to test a non-typical encoding job.
    Reasonably static scenes as it turned out. Not a lot of action. I used my old E6750 dual core CPU. CRF 23.

    MediaCoder, Very Fast preset, 5 minutes 35 seconds
    MediaCoder, Medium preset, 15 minutes 10 seconds

    MeGUI, Very Fast preset, 4 minutes 42 seconds
    MeGUI, Medium preset, 13 minutes 25 seconds

    The resulting file sizes were very close (0.1MB more for MediaCoder, but that's probably MP4 v MKV container overhead). The average bitrates only differed by 1Kb/s and 2Kb/s, according to MediaInfo. So it appears MeGUI is close to 20% faster than MediaCoder at x264 encoding, at least on this PC at 720p. I made sure MediaCoder's auto de-interlacing and noise filtering were disabled.
    I checked while running the medium speed preset encodes and MediaCoder doesn't seem to work the CPU as hard. Even at Medium, CPU usage still only seemed to average around 90% (it varied between 80% and 100%). When encoding with MeGUI, CPU usage sat between 98% and 100%.

    And......

    MediaCoda/CUDA, variable bitrate (default CUDA settings), 7 minutes 10 seconds
    MediaCoda/CUDA, average bitrate (default CUDA settings), 7 minutes 10 seconds

    (1000Kbps for the latter as that's just a little more than the x264 Very Fast encodes)
    A little quicker than it took jagabo to re-encode 10 minutes of 720p video using MediaCoder/CUDA, but that's to be expected. I was re-encoding a more "typical" 720p video with the source on the hard drive, while jagabo encoded an uncompressed 720p video over a network, so an extra minute or so of encoding time would be expected.

    Even when using an old dual core, it seems for me at least (old 8600GT video card) MediaCoder/CUDA is slower than x264's very fast preset. The x264 encodes look much, much better, but that could be my old video card. If so, it's fortunate x264's quality isn't so hardware dependant.

    How deadrats could run an encode on 10 minutes worth of 720p video, have it take 45 minutes for GPU encoding and 90 minutes for x264 and not realise there's something seriously wrong..... well, it's a complete mystery to me. Maybe those where deadrats' first encodes? That seems to be the only way to explain it.

    Edit. Looking at the x264 commandline, it appears for x264 encoding MediaCoder specifies "threads=2" by default, whereas left to it's own devices, x264 uses "threads=3" (dual core CPU). I don't know if that'd make a huge difference to encoding times and CPU usage.
    Last edited by hello_hello; 19th Apr 2014 at 21:56.
    Quote Quote  
  19. Originally Posted by deadrats View Post
    i will be updating this thread tomorrow with 2 pass Main Concept CUDA and OCL encodes, Media Coder CUDA encodes, x264 medium and very slow, and x265 ultra slow.

    i will also see if i can borrow a buddies licensed copy of Total Code Studio (i think he has version 2.5) and do tests with the official Main Concept suite.
    I guess we're still waiting for the encoding jobs to finish?
    Quote Quote  
Visit our sponsor! Try DVDFab and backup Blu-rays!