Hybrid(Windows/Linux/Mac): Input -> x264/x265/Xvid/VP8/VP9

[Selur]

I installed a clean 2014.02.25.2(full) then simply changed/substitution the x264 and 2013.12.06.2.exe file (it was working correctly)

okay, I understood, that
a. you installed the 2014.02.25.2
b. you replaced the x264.exe
but I got no clue that you did with the "2013.12.06.2" version

Then let other users check

as soon as others report problems with the x264 binaries I'll look into it, but atm. I can't reproduce the problem you are having with the binaries.
And tracking the problem also doesn't really work since the x264 version you liked to has 41 patches applied to it,...

[Gravitator]

a. you installed the 2014.02.25.2 - yes
b. you replaced the x264.exe - yes
but I got no clue that you did with the "2013.12.06.2" version - 2014.02.25.2.exe >replaced to> 2013.12.06.2.exe


after it was successfully completed coding, try to use / click on "config apply: x264 Hybrid Default" and repeat coding (My system so could crash on MP4BOX version 2014.02.14.1) - do not forget to enable the filter > Anti-Aliasing:daa
-------------
Series of different factors does not allow me to explain the problem (easy to use video recording)
-------------

[Selur]

What so you mean by "2014.02.25.2.exe >replaced to> 2013.12.06.2.exe"
a. normally the installer should not be present inside the Hybrid folder.
b. simply copying another installer into the Hybrid folder will not change anything
-> confused

Would be nice if someone could try to reproduce this.

Cu Selur

[Gravitator]

This is not the installers! himself "hybrid.exe" - I renamed them to avoid confusion
(tomorrow will write video)

[Selur]

okay, then this does not help me at all, since like I wrote I will look into problems of the current version and not into problems of old versions. (I can confirm that the x264-10bit.exe seems to be broken)

[Gravitator]

The first session is successful, then you can see in the log file as I applied the standard / default settings and then was complete the collapse of the coding
Here's a look (I have divided inside two sessions, through the asterisks)
x264 + (click) default settings = crash
-----------
Hopefully, this time

[Selur]

btw. I would recommend to use the 'clear' builds from http://komisar.gin.by/ which are not that heavily patched as the once you linked to.

[Gravitator]

I scattered, and did not notice that clicked on defaul setting (half day)
- About this property by ask of users not in a hurry and carefully check your complaints

[Selur]

The crash with the default setting might be due to your switching between versions, older versions might not be able to handle newer versions defaults,..

[Gravitator]

He Russian? > http://komisar.gin.by/ Does it ever in our forum Vhelp?

[Selur]

Russian: I think so
afaik Komisar is not active here, he is however a member of the Doom9 forum

[Gravitator]

Why hybrid on Vhelp (89mb) weighs less than the site selur.de (89.2mb)?

[Selur]

might be that I updated the version on my homepage,...

[Gravitator]

Good evening,
Selur, make it possible to automatically mark "debug report" the number of the used version of the program - to no question on the used version of Hybrid

[Selur]

each line of the HybridDebugOutput.txt does contains the version number

2014.02.28 - 16:02:29_Windows 7-64bit_2014.02.25.2 - level 9:

"date - time_OS-32/64bit_VersionNumber - DebugLevel:" .....

-> nothing to do

[Gravitator]

each line of the HybridDebugOutput.txt does contains the version number

2014.02.28 - 16:02:29_Windows 7-64bit_2014.02.25.2 - level 9:

"date - time_OS-32/64bit_VersionNumber - DebugLevel:" .....
-> nothing to do

then why do you say that I am using an older version of the program, while it was new.
(OK, forget)

------------
the upcoming holiday

[deadrats]

@Selur

i was playing around withthe cli cuda app you include with Hybrid and i noticed that your cuda cli supports gpu deinterlacing yet you don't expose this within your gui, why is that?

[Selur]

why is that?

Hybrid will use it if 'auto deinterlace is deactivated an interlaced encoding (Cuda->Frame->Interlaced encoding) isn't enabled. (check the Cuda H.264 command line)
+ When writing the Cuda.exe, I always hoped someone would write a free DGDecNV alternative, which would not require Avisynth and it's probably only worth the effort, if you do no other filtering since keeping the content interlaced throughout the filtering will slow down stuff.
It's not exposed inside the 'Filtering'-tab since it's not in the filtering code of the application, but part of the Cuda H.264 specific code.

Sadly a free NVIDIA->Raw Pipe output application never happened, DGDecNV also doesn't support raw output (which would make it Avisynth independent), since DG doesn't think enough people want it, so it's not worth his time. Hoped for the same thing when QuickSync appeared, but nobody aside from me seems to have any use for such a tool. (neither q264 or QSTranscode support it and I doubt the upcoming DGDecIM will).
Since neither mencoder nor ffmpeg support GPU acceleration either I kind of gave up on the subject (to be precise on linux gpu accelaration during playback is possible with ffplay/mplayer but not during decoding if stdOut is used as output method).

[Gravitator]

Add selected fixation 10bit mode for x265; 10 bit mode is disabled after applying any preset (not convenient to walk and every time change)

[Selur]

will fix (seems like 8bit encoding slipped into the default settings) -> fixed locally.

[deadrats]

@Selur:

thanks for the explanation, it's not that no one other than you has any interest, i was just thinking the other day how long CUDA as a programming framework has been around and how little it has permeated the desktop, specifically the video editing arena on the desktop. i think there was lots of interest, i think probably the biggest obstacle to actually seeing any real penetration, even more than i blame DS and the FUDmeisters, was that most programmers find it really difficult to think in gpu terms. from the first computer science classes you take (when i was a kid the progression was BASIC-.FORTRAN->PASCAL-C) up until you get a bachelors degree, all classes are structured to teach how to do x86 programming with x86 compilers. even if you wanted to you can't take a gpgpu programming class until you're going for a Master's or PH.D. in CS or engineering.

this is why gpu's have made such a huge impact in HPC, because all the people writing that code have advanced degrees and thus access to those classes.

incidentally, if you want to see the best gpu powered encoder currently available to the average end user, download the demo for sony movie studio, the main concept avc encoder offers a 2 pass cuda and open cl powered encoder (open cl is for amd cards only) that is smoking fast on even older hardware and offers really good quality.

[Selur]

Main problem with the whole gpu stuff is that it has tons of dependencies, which you otherwise don't need and also you have to check to use really specific versions of stuff and last but not least you also often need specific driver versions,... then when you finally find something that works with you hardware and you try to read more about it lot's of documentations are bad or simply old and to not really match your setup.
-> I really do not like writing ggpu stuff not, that I wouldn't be able to grasp the concepts, but it really always is such a hassle unless and for a hobby project not really worth the time. (especially if you already have a normal life and a hobby project)

+ haven't seen an easy to use debugger for shader code

[DarrellS]

I read that Cuda spends too much time accessing your memory for it to be that efficient. When I was testing the Cuda encoder, I found that x264 superfast was just as fast if not faster than Cuda. X264 looked better and the file sizes were way smaller than Cuda. Infact, Cuda encoded files were almost twice as big as the original file that you were trying to compress. Maybe if I had a better graphics card, Cuda would have been better but if I had a better processor then x264 would've been faster still.

Now it seems like we're stepping back in time with a slow encoder but the file sizes are so much smaller that if this technology had been around in 2000, the computer world would be a lot different today. There would be no need for 3TB drives since full length movies would be only a few MBs instead of a few GBs.

[deadrats]

I read that Cuda spends too much time accessing your memory for it to be that efficient. When I was testing the Cuda encoder, I found that x264 superfast was just as fast if not faster than Cuda. X264 looked better and the file sizes were way smaller than Cuda. Infact, Cuda encoded files were almost twice as big as the original file that you were trying to compress. Maybe if I had a better graphics card, Cuda would have been better but if I had a better processor then x264 would've been faster still.

Now it seems like we're stepping back in time with a slow encoder but the file sizes are so much smaller that if this technology had been around in 2000, the computer world would be a lot different today. There would be no need for 3TB drives since full length movies would be only a few MBs instead of a few GBs.

i think what you're referring to is that for gpgpu computing the primary limiting factor, in many cases way more limiting than the number of gpu "cores" is memory bandwidth, in the HPC arena that is the number one complaint Nvidia hears from programmers, that their apps are memory bandwidth bound.

i recently had a first chance experience with that, my system suffered a failure that i could not resolve and i was forced to downgrade, i went from an i7 3770k using the integrated gpu to an x6 1045t and i had a choice of video cards to use a quadro 600 or a 9600 gso. i initially went with the quadro, reasoning that because they both had 96 cuda cores the quadro with it's professional drivers, newer gpu (it supports DX11 while the 9600gso is only DX10) and more ram (1gig versus 768mb) that the quadro would be faster with gpgpu applications, like gpu filtering, gpu decoding and encoding.

unfortunately the whole system was slow as s--t, so i decided to swap in the 9600gso. amazingly enough the 9600gso has way more memory bandwidth due to it's 192bit path versus the quadro's 128bit path and in cuda powered encoding and filtering it's twice as fast. in fact, and i can't figure out why this is, unless the quadro drivers where slowing the whole system down, with the 9600gso, even x264 encoding was much faster (130fps vs 80fps using the exact same test encoding script) even without --opencl.

very odd but the difference between the two cards is like night and day.

[deadrats]

@Selur:

thought you may find this useful:

http://blogs.nvidia.com/blog/2014/03/05/cuda-6-available/

[Gravitator]

Drop GUI after choosing any encoder

[Selur]

@Graviator: can't reproduce.
Also try to check if this only happens if you load a source (a specific?) beforehand or if this also happens if no source if loaded.
Seems like the crash occurs during AvisynthScript generation.
-> Post a debug output level 9, may be that shows the problem.

[Gravitator]

@Graviator: can't reproduce.
-> Post a debug output level 9, may be that shows the problem.

here

[Selur]

sadly that didn't help either

-> can anybody else reproduce this problem?

[deadrats]

just a heads up, Divx has updated their cli encoder:

http://labs.divx.com/divx265