- 21 9月, 2015 3 次提交
-
-
由 jp9000 提交于
-
由 jp9000 提交于
Using gzdopen will not work properly if the C standard library used to get the descriptor is not the same library as the one that was compiled with zlib. When this is the case, it causes zlib to fail to write a file, and would report a C standard library error. Use gzopen and gzopen_w instead to ensure that the file is opened and closed by zlib itself, ensuring that zlib and the libobs do not have to share the C standard library between each other.
-
由 jp9000 提交于
-
- 20 9月, 2015 6 次提交
-
-
由 jp9000 提交于
After some more testing, utvideo not only gives better encoding performance, but also better compression and better decoding performance. It's pretty much superior all around over huffyuv.
-
由 jp9000 提交于
So certain high-profile individuals were complaining that it was difficult to configure recording settings for quality in OBS. So, I decided to add a very easy-to-use auto-configuration for high quality encoding -- including lossless encoding. This feature will automatically configure ideal recording settings based upon a specified quality level. Recording quality presets added to simple output: - Same as stream: Copies the encoded streaming data with no extra usage hit. - High quality: uses a higher CRF value (starting at 23) if using x264. - Indistinguishable quality: uses a low CRF value (starting at 16) if using x264. - Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a user tries to select lossless, they will be warned both via a dialog prompt and a warning message in the settings window to ensure they understand that it requires tremendous amounts of free space. It will always use the AVI file format. Extra Notes: - When High/Indistinguishable quality is set, it will allow you to select the recording encoder. Currently, it just allows you to select x264 (at either veryfast or ultrafast). Later on, it'll be useful to be able to set up pre-configured presets for hardware encoders once more are implemented and tested. - I decided to allow the use of x264 at both veryfast or ultrafast presets. The reasoning is two-fold: 1.) ultrafast is perfectly viable even for near indistinguishable quality as long as it has the appropriate CRF value. It's nice if you want to record but would like to or need to reduce the impact of encoding on the CPU. It will automatically compensate for the preset at the cost of larger file size. 2.) It was suggested to just always use ultrafast, but ultrafast requires 2-4x as much disk space for the same CRF (most likely due to x264 compensating for the preset). Providing veryfast is important if you really want to reduce file size and/or reduce blocking at lower quality levels. - When a recording preset is used, a secondary audio encoder is also spawned at 192 bitrate to ensure high quality audio. I chose 192 because that's the limit of the media foundation aac encoder on windows, which I want to make sure is used if available due to its high performance. - The CRF calculation is based upon resolution, quality, and whether it's set to ultrafast. First, quality sets the base CRF, 23 for "good" quality, 16 for "very high" quality. If set to ultrafast, it'll subtract 2 points from the CRF value to help compensate. Lower resolutions will also lower the CRF value to help improve higher details with a smaller pixel ratio.
-
由 jp9000 提交于
-
由 jp9000 提交于
Seems that most decoders that don't read the h264 header tend to expect 601 instead of 709.
-
由 jp9000 提交于
For game capture, if a game is running at for example 800 FPS and limit capture framerate is off, it would try to capture all 800 of those frames, dramatically reducing performance more than what would ever be necessary. When limit capture framerate is off, instead of capturing all frames, capture frames at an interval of twice the OBS FPS, identical to how OBS1 works by default. This should greatly increase performance under that circumstance.
-
由 jp9000 提交于
Use the actual parameter from the x264 params for CRF, and also make sure to specify that CRF is meant to be 0 if CBR is enabled.
-
- 19 9月, 2015 7 次提交
-
-
由 jp9000 提交于
-
由 jp9000 提交于
-
由 jp9000 提交于
-
由 jp9000 提交于
Sets the color range/space for FFmpeg output encoders that support it.
-
由 jp9000 提交于
This also adds the ability to detect whether it stopped due to lack of space or not -- particularly useful for the FFmpeg output due to lossless file format support.
-
由 jp9000 提交于
For the FFmpeg output, the encoder ids are sort of superfluous. They really should be optional. If they're not set, it should use the encoder name string instead to determine the ids automatically.
-
由 jp9000 提交于
-
- 18 9月, 2015 5 次提交
-
-
由 jp9000 提交于
-
由 jp9000 提交于
It seems that certain encoders (quicksync) do not have proper back-end support in the windows media foundation libraries for certain CPUs. Quicksync doesn't appear to support CPUs that are not haswell (4xxx) or above. It's really annoying, but there's not much we can do about it until we implement our own custom quicksync implementation. This check simply makes it attempt to spawn an encoder to check to see whether the encoder can actually be created before registering an encoder.
-
由 jp9000 提交于
It's not impossible that this sort of thing could happen, although unlikely.
-
由 jp9000 提交于
The encoders were stopping before processing was completed, which could cause the output to access data that's potentially invalidated.
-
由 jp9000 提交于
The previous commit (672378d2) was supposed to fix issues with the encoder releasing while data was still being processed, but did not account for when the encoder has never started up. That was my fault. Furthermore, the way in which it was waiting to drain events was incorrect. The encoder may still be active even though there aren't any events queued. The proper way to wait for an async encoder to finish up is to process output samples until it requests more input samples.
-
- 17 9月, 2015 7 次提交
-
-
由 jp9000 提交于
After I made it so that the encoder internal data gets destroyed when all outputs stop using it (fa7286f8), the media foundation h264 encoder started having crashes on shutdown. After a lot of testing, I realized that the reason it started happening is almost assuredly because active encoding events had not yet been completed. After making it wait on those events by calling DrainEvents(true), the crashes stopped. So asynchronous actions were clearly still occurring and it was shutting down while data was still being processed, thus leading to a crash.
-
由 Jim 提交于
Clean up Intensity Pro 4K commit a bit
-
由 kc5nra 提交于
Adds a VideoToolbox based H264 encoder for OSX, which most notably allows the use of hardware encoding (Quicksync). NOTES: - Hardware encoding is handled by Apple itself internally. The plugin itself has little control over many details due to the way that Apple designed the VideoToolbox interface. Generally however, quicksync is used if available on the CPU, and quicksync is almost always available due to the fact that macs are exclusively Intel. - The VideoToolbox does not seem to implement CBR, so it won't be available. These encoders are generally not recommended for streaming.
-
由 jp9000 提交于
Implements hardware encoders through the Media Foundation interface provided by Microsoft. Supports: - Quicksync (Intel) - VCE (AMD) - NVENC (NVIDIA, might only be supported through MF on Windows 10) Notes: - NVENC and VCE do not appear to have proper CBR implementations. This isn't a fault of our code, but the Media Foundation libraries. Quicksync however appears to be fine.
-
由 jp9000 提交于
API changed from: obs_source_info::get_name(void) obs_output_info::get_name(void) obs_encoder_info::get_name(void) obs_service_info::get_name(void) API changed to: obs_source_info::get_name(void *type_data) obs_output_info::get_name(void *type_data) obs_encoder_info::get_name(void *type_data) obs_service_info::get_name(void *type_data) This allows the type data to be used when getting the name of the object (useful for plugin wrappers primarily). NOTE: Though a parameter was added, this is backward-compatible with older plugins due to calling convention. The new parameter will simply be ignored by older plugins, and the stack (if used) will be cleaned up by the caller.
-
由 jp9000 提交于
The private type data is the type_data variable that's provided when object types are registered by plugins.
-
由 jp9000 提交于
This is useful for allowing the ability to have private data associated with the object type definition structures. This private data can be useful for things like plugin wrappers for other languages, or providing dynamically generated object types.
-
- 16 9月, 2015 5 次提交
-
-
由 Palana 提交于
Selecting any supported FFmpeg format where ff_format_desc_extensions returns NULL would crash the std::string constructor, so we pass an empty extension instead (rtsp is one candidate format that triggers the crash, on my machine at least)
-
由 Palana 提交于
-
由 Palana 提交于
This allows changing e.g. the number of segments in a hls playlist and its caching behavior with: "hls_allow_cache=1 hls_list_size=0"
-
由 Palana 提交于
This is used by some muxers that set AVFMT_NOFILE and doesn't seem to hurt muxers that don't set it; notable this makes the hls muxer output its m3u8 playlist with the proper filename in the proper directory
-
由 Brian S. Stephan 提交于
cleaning up my previous commit a bit. we can just keep the appropriate BMDPixelFormat as a data member and keep StartCapture() a bit clearer. this might also be helpful if (when?) the detection code needs to be more robust or configurable
-
- 15 9月, 2015 2 次提交
-
-
由 Jim 提交于
Capture BMI Intensity Pro 4K video
-
由 Brian S. Stephan 提交于
detect the device type when initializing the device instance and determine whether to capture YUV or RGB. tested with a Blackmagic Intensity Pro and a Blackmagic Intensity Pro 4K in the same machine, capturing at the same time, on Linux
-
- 14 9月, 2015 4 次提交
-
-
由 jp9000 提交于
This prevents encoders (hardware encoders in particular) from being continually active when all outputs disconnect from an encoder. This is mostly just a temporary measure; the encoding interface may need a bit of a redesign. It will also definitely needs to be able to flush at some point. Currently when an output is stopped, the pending data is discarded, which needs to be fixed.
-
由 jp9000 提交于
Allows objects to be created regardless of whether the actual id exists or not. This is a precaution that preserves objects/settings if for some reason the id was removed for whatever reason (plugin removed, or hardware encoder that disappeared). This was already added for sources, but really needs to be added for other libobs objects as well: outputs, encoders, services.
-
由 jp9000 提交于
-
由 jp9000 提交于
If the FFMPEG_AVCODEC_LIBRARIES variable does not exist, it will generate a cmake error, so check to make sure the variable exists before executing this code.
-
- 13 9月, 2015 1 次提交
-
-
由 Mathias Panzenböck 提交于
This fixes the compile error: "'AVDISCARD_NONINTRA' undeclared" when using a libavcodec version earlier than 55.67.100. Closes jp9000/obs-studio#469
-