0.56.04 madness build - features plus encoding changes

[Luk]

Re: 0.56.03 MADNESS build - features plus encoding changes

Freehuhn: We all know that Quicksync is fast, but everyone here is thinking the "streaming"-way. Quicksync is awful for streaming purposes, but can be useful when recording locally and frees up CPU resources.

 

[Kharay]

Re: 0.56.03 MADNESS build - features plus encoding changes

the quality with x264 is not better because you have to use a very bad preset for recording 120 hz.

btw this is just offtopic if you you can make a posting a point out how bad quicksync is.
very fast x264 at way more than 120 fps for nearly zero cpu usage is not bad at all...

Right... well, obviously the message is not going to sink any time soon with you. So... good luck, have fun!

 

[DeMoN]

Re: 0.56.03 MADNESS build - features plus encoding changes

recordingwise lossless is the way to go.

ffdshow uncompressed yv12 is very fast for example. And it saves quality. Because you can then encode after recording and then with good settings ..

The only thing you need for uncompressed is very fast HDD write speed which easy can be archived with a RAID 0.
Otherwise use the Lagarith codec @ YV12, [x] multithreading
it has excellent lossless compression. 30 fps @ 1280x720 need only about 15 mbyte/s.

I have a RAID 0 which can write 350 mbyte/s and is able to record 2048x1152 video in RGB uncompressed with 50fps.
But I record in 30fps, yv12.

Why? Because I upload for youtube and there is 30fps maximum

But local I dont see much sense in going higher than 30fps too. 30 vs 60fps is good visible on high motion scenes, but is rather for enthusiasts necessary. For normal viewing a 30fps video is more than enough and saves space.
But 120 fps? Why? 60fps is even on high motion already very very smooth.

 

[freehuhn]

Re: 0.56.03 MADNESS build - features plus encoding changes

that's why i say recording not streaming.

Free, open source software for live streaming and recording

did i get the recording part wrong ?

i mean i just said what's not working with the new test build and i have to hear "why did you use quicksync?"
sry i reported a crash my fail...

 

[paibox]

Re: 0.56.03 MADNESS build - features plus encoding changes

You guys (not freehuhn) need to calm the heck down, consider this your unofficial warning.

freehuhn: I'm not quite sure why QuickSync would stop working. Does it still work in older versions? It's still available and working for me, but I'm on a 3770K myself, which means I can just use it in D3D11 headless mode, so I'm not a very good comparison. Try dropping by the chat and asking Palana about it, he might be able to help you debug what might be wrong.

 

[dehixem]

Re: 0.56.03 MADNESS build - features plus encoding changes

OBS 0.56.02 is crashing way too often :-(
It happens when I change scenes during livestreaming for a long time on the same scene (I've had this issue in particular for at least one or two months now).

In this case it just crashed when Amnesia AMFP was loading a new area... of course the mp4 got corrupted and got lost.
Here is log + dump, please look into this.

OBS has encountered an unhandled exception and has terminated. If you are able to
reproduce this crash, please submit this crash report on the forums at
http://www.obsproject.com/ - include the contents of this crash log and the
minidump .dmp file (if available) as well as your regular OBS log files and
a description of what you were doing at the time of the crash.

This crash appears to have occured in the 'c:\windows\system32\kernelbase.dll' module.

**** UNHANDLED EXCEPTION: 80000003
Fault address: 000007FEFD853C72 (c:\windows\system32\kernelbase.dll)
OBS version: Open Broadcaster Software v0.554b
Windows version: 6.1 (Build 7600) 
CPU: Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz

Crashing thread stack trace:
Stack            EIP              Arg0             Arg1             Arg2             Arg3             Address
00000000001CEFF8 000007FEFD853C72 000007FEDFEA5870 000000000000EA60 00000000001CEF58 00000000001CF1B0 kernelbase.dll!0x7fefd853c72
00000000001CF000 000007FEDFD1D323 0000000000001389 00000000777A9AA6 00000000001CF078 0000000200000030 obsapi.dll!OSTerminateThread+0x33
00000000001CF030 000000013F2DD999 0000000000001389 00000000001CF1B0 0000000000000111 0000000000000000 obs.exe!OBS::Stop+0x59
00000000001CF0B0 000000013F2FDA8E 0000000000000070 FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF 00000000777A9B43 obs.exe!OBS::OBSProc+0xa8e
00000000001CF240 00000000777A9BD1 0000000000C87850 000000013F2FD000 00000000FFFFFED1 0000000000010552 user32.dll!0x777a9bd1
00000000001CF300 00000000777A6AA8 00000000000504AE 0000000000000111 0000000000001389 000007FEFBFF0A29 user32.dll!0x777a6aa8
00000000001CF390 00000000777A6BAD 00000000045D6620 0000000000000001 0000000000000000 0000000000000001 user32.dll!0x777a6bad
00000000001CF3E0 000007FEFBFF0BBF 0000000000010552 0000000000000001 00000000045D6620 000007FEFDF82421 comctl32.dll!0x7fefbff0bbf
00000000001CF420 000007FEFBFF47FE 000000000000FF00 0000000000030000 0000000000000202 0000000000000000 comctl32.dll!0x7fefbff47fe
00000000001CF4E0 00000000777A9BD1 00000000001CF7C8 000007FEFBFF3B20 0000000000C87850 0000000000C8AEF0 user32.dll!0x777a9bd1
00000000001CF5A0 00000000777A98DA 0000000000000000 0000000000000000 000007FEFBFF3B20 0000000000000001 user32.dll!0x777a98da
00000000001CF620 00000000777A67C2 0000000000060555 0000000000060555 000007FEFDF82164 00000000005D1000 user32.dll!0x777a67c2
00000000001CF6B0 000000013F2D1CD9 0000000000000000 0000000000000000 000000013F2B0000 0000000000000000 obs.exe!WinMain+0x9c9
00000000001CFC50 000000013F347150 0000000000000000 0000000000000000 0000000000000000 0000000000000000 obs.exe!strstr+0x1ac
00000000001CFD00 000000007768652D 0000000000000000 0000000000000000 0000000000000000 0000000000000000 kernel32.dll!0x7768652d
00000000001CFD30 00000000778BC541 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x778bc541

A minidump was saved to C:\Users\Kevin\AppData\Roaming\OBS\crashDumps\OBSCrashDump2013-09-07_2.dmp.
Please include this file when posting a crash report.

List of loaded modules:
Base Address                      Module

How am I supposed to provide you with a dump if the upload attachment module makes the webpage crash ?

Cheers.

 

[Sapiens]

Re: 0.56.03 MADNESS build - features plus encoding changes

Arguing about x264 vs QuickSync compression efficiency so completely misses the point in the context of what freehuhn is doing that I wonder if some of you even read and understood his posts before replying. He doesn't need a demonstration, he needs you to pay attention.

It doesn't matter that x264 is more efficient if the cost of that efficiency is an unacceptable performance impact during a recording. QuickSync may not compress his output video as well but who cares when it allows him to maintain performance? He isn't streaming! He can just record at a higher bitrate and offset QuickSync's inefficiency. File size will still be completely manageable and his PC won't tank.

Quite simply there are more factors to consider than simply which encoder is more efficient. The options presented here are:

1) Use x264, compress video more efficiently, take an unacceptable performance hit, or
2) Use QuickSync, compress videos less efficiently, take no performance hit at the expense of slightly larger output files

If you still think option 1 is the better choice then you need to go home, because you're drunk.

 

[DeMoN]

Re: 0.56.03 MADNESS build - features plus encoding changes

The best way is and stays recording lossless instead of lossy. Most performance you can get with that.

 

[Xphome]

Re: 0.56.03 MADNESS build - features plus encoding changes

The best way is and stays recording lossless instead of lossy. Most performance you can get with that.

If you have fast and large storage devices. My HDDs are too slow and I don't have that much space.

 

[Sapiens]

Re: 0.56.03 MADNESS build - features plus encoding changes

The I/O and file size demands of truly lossless recording make it a very poor choice for the vast majority people when light compression can yield practically indistinguishable results at a fraction of the file size. "But you only need RAID0" is not particularly compelling.

 

[DeMoN]

Re: 0.56.03 MADNESS build - features plus encoding changes

Then buy a HDD

A good HDD costs 50 €... Unbelievable cheap nowadays..

http://geizhals.de/seagate-barracuda-72 ... 86480.html

And with that you can get a Seagate barracuda 7200.14 which is capable to write 196 mbyte/s..

That is more than enough room to record lossless. With that is even uncompressed yv12 possible in 2048x1152 resolution ..

The I/O and file size demands of truly lossless recording make it a very poor choice for the vast majority people when light compression can yield practically indistinguishable results at a fraction of the file size.

It is clearly distinguishable. But thats not the most important behind that.

The most important thing is quality versus filesize.

Why you want less quality in higher filesize, because your pc is too bad? That consumes HDD space even more.

If you want to edit your recording, you would re-encode a lossy source. That would further decrease quality, makroblocks would be detected as detail by encoder, which further kills quality (or raises up filesize if quantizer based encode)

But you only need RAID0" is not particularly compelling.

you just need a HDD which is not of metal age.

 

[Muf]

Re: 0.56.03 MADNESS build - features plus encoding changes

Kharay, please stop abusing the forum's post report functionality.

 

[Xphome]

Re: 0.56.03 MADNESS build - features plus encoding changes

With a CRF setting of 15 it looks very good to me, so good that it could easily fool me that it was live gameplay instead of a recording, while keeping the file size reasonable. Performance impact at the time of the recording, Bioshock Infinite 1920x1080 max settings, was not noticeable.

EDIT: But I guess we should end this discussion.

 

[Sapiens]

Re: 0.56.03 MADNESS build - features plus encoding changes

DeMoN perhaps I'm explaining myself poorly. I don't care if you prefer to record lossless video any more than I care if freehuhn prefers to record at 120 FPS. I personally find both a bit ridiculous in general but if doing so meets your needs then by all means have at it. However I also think that presenting your personal preferences as some sort of "best practice" is misguided, and potentially does a disservice to people you may be trying to help.

 

[DeMoN]

Re: 0.56.03 MADNESS build - features plus encoding changes

but if you re-encode your CRF15 recording you'll have higher filesize, the encoder detects the artefacts as detail. you may not see them. but the encoder does.
And you used a very fast preset to hold cpu usage relatively low. so the filesize is alone because of that much higher as it could be. It uses too much cpu.

Further thing is: In which container does it write? AVI? AVI is not suitable container for h.264.

Q11: What'st the difference between VFW and CLI?
A: VFW is Video For Windows, an ancient tech created by microsoft (copying some stuff from quicktime), full of quirks and not able to support modern codecs. x264VFW is a ugly hack to make x264 work (more or less) with VFW, hence softwares like virtualdub and its modifications. The use of x264VFW is NOT recommended. x264 VFW is no longer officially supported.
CLI is a general term that means Command Line Interface. The classic console (command prompt) command which is generic and has no limitations like VFW.

Q19: Can i use VirtualDub or any other VFW based editor to encode with x264?
A: Yes, using a x264 VFW build but VFW is so obsolete and limited x264VFW is no longer mantained by the x264 devs and because VFW and AVI are not properly able to handle h.264 features without some "hacking" that could compromise compatibility, playback and/or editing.

The thing about applying the same hacks as was used in ASP is that ASP is bad enough to do that to, but H.264's featureset is much more expansive in regard to B-frames, the B-pyramid, etc. Using said hacks to put H.264 in AVI often isn't sufficient enough to ensure that the audio remains synced, in the case of numerous B-frames and especially the B-pyramid. The only way around it is to disable those features, but that results in benefit being lost. It'll still perform well, but not as well as it could have.

but you're right, we should end this discussion.
I just can highly recommend you to record lossless. Fast HDD isnt that expensive ..

DeMoN perhaps I'm explaining myself poorly. I don't care if you prefer to record lossless video any more than I care if freehuhn prefers to record at 120 FPS. I personally find both a bit ridiculous in general but if doing so meets your needs then by all means have at it. However I also think that presenting your personal preferences as some sort of "best practice" is misguided, and potentially does a disservice to people you may be trying to help.

I just recommend you to record lossless and encode afterwards to lossy, because it is the best for your performance while recording and the best quality vs filesize afterwards ..

thats a fact. And HD drives are so damn cheap now. I just cant believe that this is your argument to consume unnecessary more space of your at the moment metal age HDD.

But ok. Just wanted to say you that again. But ok we can end this now when it is wanted ^^

 

[Xphome]

Re: 0.56.03 MADNESS build - features plus encoding changes

Further thing is: In which container does it write? AVI? AVI is not suitable container for h.264.

MP4 before since it wasn't possible to save recordings in FLV with date and time as filename, which is now possible with this test version thus I've changed it to FLV. OBS can't save recordings to AVI so that was never an option (not that I would have chosen it).

thats a fact. And HD drives are so damn cheap now. I just cant believe that this is your argument to consume unnecessary more space of your at the moment metal age HDD.

Using OBS instead of other software like Dxtory consumes less space, not the other way around.

 

[Krazy]

Re: 0.56.03 MADNESS build - features plus encoding changes

Get back on topic. This thread is only for talking about the test build, and reporting bugs with it. Any posts from here on out that aren't on topic will receive warnings from me.

freehuhn, have you tried to get in touch with Palana, yet? He's the QSV wizard here.

 

[freehuhn]

Re: 0.56.03 MADNESS build - features plus encoding changes

Does it still work in older versions?

0.554b works fine as long as CFR is not checked. i got it madness working on the desktop without a game running and only when aero is enabled. obs shows about 40 fps (normal aero) the output got this:
Frame rate mode : Variable
Frame rate : 120.013 fps
Original frame rate : 120.000 fps
Minimum frame rate : 111.111 fps
Maximum frame rate : 125.000 fps

It's still available and working for me, but I'm on a 3770K myself, which means I can just use it in D3D11 headless mode, so I'm not a very good comparison.

the problem only happens with 120 fps

egur (ffdshow QSV decoder dev.) stated (long ago) that d3d11 is slower in upload but i it is still pretty fast.

Try dropping by the chat and asking Palana about it, he might be able to help you debug what might be wrong.

my clue is that the qsv encoder got inforamtion he didn't like at all where maybe high5.2 should be used:

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC

5.1
1,920×1,080@120.5 (16)
2,560×1,920@51.2 (9)
3,840×2,160@31.7 (5)
4,096×2,048@30.0 (5)
4,096×2,160@28.5 (5)
4,096×2,304@26.7 (5)

and the output got this
Maximum frame rate : 125.000 fps

if this is the first information sended to the encoder he can't encode it because it is 5.2 and it looks like qsv can't encode at 5.2

edit: added english wiki link

 

[Camfak]

Re: 0.56.03 MADNESS build - features plus encoding changes

for the same reason people play on 120 hz displays is much smoother and there is only a little motion blur left.

if you think "the human eye can't do anything with 120 hz"

just have a look at this
http://www.testufo.com/#test=framerates

with my 120 hz lightboost monitor i can see the white dots on the ufo clearly

on an normal lcd is just a white unsharp line and mostlikely the hole ufo is unsharp(ofc it looks even better on a 120 hz crt)

What are you doing with your 120hz recordings? You only watch them yourself on your computer? Or is it just a hobby recording and such?

Or are you this guy?
http://www.blurbusters.com/hfr-120fps-v ... recording/

 

[freehuhn]

Re: 0.56.03 MADNESS build - features plus encoding changes

i watch them. i play around with them (madvr smoothmotion, decimation, motion blur test)