Fixes an issue where media-playback would not compile with older FFmpeg
versions due to the fact that the AV_PIX_FMT_VIDEOTOOLBOX was
unavailable until version 54.31.100 of libavutil (FFmpeg 2.8).
Fixes mantis issue 1045.
Closesjp9000/obs-studio#1089
(This commit also modifies the following modules: UI,
deps/media-playback, coreaudio-encoder, decklink, linux-alsa,
linux-pulseaudio, mac-capture, obs-ffmpeg, obs-filters, obs-libfdk,
obs-outputs, win-dshow, and win-wasapi)
Adds surround sound audio support to the core, core plugins, and user
interface.
Compatible streaming services: Twitch, FB 360 live
Compatible protocols: rtmp / mpeg-ts tcp udp
Compatible file formats: mkv mp4 ts (others untested)
Compatible codecs: ffmpeg aac, fdk_aac, CoreAudio aac,
opus, vorbis, pcm (others untested).
Tested streaming servers: wowza, nginx
HLS, mpeg-dash : surround passthrough
Html5 players tested with live surround:
videojs, mediaelement, viblast (hls+dash), hls.js
Decklink: on win32, swap channels order for 5.1 7.1
(due to different channel mapping on wav, mpeg, ffmpeg)
Audio filters: surround working.
Monitoring: surround working (win macOs linux (pulse-audio)).
VST: stereo plugins keep in general only the first two channels.
surround plugins should work (e.g. mcfx does).
OS: win, macOs, linux (alsa, pulse-audio).
Misc: larger audio bitrates unlocked to accommodate more channels
NB: mf-aac only supports mono and stereo + 5.1 on win 10
(not implemented due to lack of usefulness)
Closesjp9000/obs-studio#968
(This commit also modifies the deps/media-playback, obs-ffmpeg, and
win-dshow modules)
More fixes due to ffmpeg renaming some constants and deprecating
AVFMT_RAWPICTURE and AV_PIX_FMT_VDA_VLD.
Latter replaced by AV_PIX_FMT_VIDEOTOOLBOX per ffmpeg dev advice.
Closesjp9000/obs-studio#1061
If there is no network connection, OBS crashes after 5 minutes idling
with following crash:
*** longjmp causes uninitialized stack frame ***: obs terminated
======= Backtrace: =========
/lib64/libc.so.6(+0x6f1e3)[0x7f8f95f901e3]
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f8f96018ba7]
/lib64/libc.so.6(+0xf7add)[0x7f8f96018add]
/lib64/libc.so.6(__longjmp_chk+0x29)[0x7f8f96018a39]
/usr/lib64/libcurl.so.4(+0xa5d5)[0x7f8f979b75d5]
/lib64/libpthread.so.0(+0x10e30)[0x7f8f962cae30]
/lib64/libc.so.6(__poll+0x2d)[0x7f8f95fff46d]
/usr/lib64/libglib-2.0.so.0(+0x4a64c)[0x7f8f91b5564c]
/usr/lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x7f8f91b5575c]
/usr/lib64/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5f)[0x7f8f9706c1ff]
/usr/lib64/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0xfa)[0x7f8f9701defa]
/usr/lib64/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x9c)[0x7f8f970258fc]
obs(main+0x5ac)[0x4773dc]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f8f95f41700]
obs(_start+0x29)[0x478389]
Internet search [1] revealed that this is a libcurl bug that can be worked
around by asking curl not to install signal handlers.
[1] https://stackoverflow.com/a/10755612
(This commit also modifies deps/media-playback)
Before, the media-playback library would detect whether something was
seekable by checking the filename for "://", which is unideal because
there are other cases where targets may not be seekable. So instead, an
explicit "seekable" property (off by default) is now in place in the
media source when not in "local file" mode. Seeking will only be
enabled if local file mode is on, or if "seekable" is explicitly checked
by the user.
Closesjp9000/obs-studio#1022
The recent changes in 88ae9af causes av_read_frame to check for
m->stopping, and fail with AVERROR_EXIT if true, which would happen
after each reset. Moving mp_media_prepare_frames to a line after
m->stopping is reset to false fixes the issue.
With certain media files (wmv in particular), the very last frame will
have a timestamp of AV_NOPTS_VALUE. This could cause the media to stick
on that frame indefinitely. Instead, use the estimated next timestamp
that was calculated in the previous frame.
Media files that have a very low framerate or very long interval between
frames would cause the media playback to stall indefinitely until the
next frame is played. This adds a 200ms timeout to ensure that the
media can be destroyed without being forced to wait indefinitely for the
next frame.
Certain functions such as avformat_open_input and av_read_frame can
block, causing the program to someone wait very long periods of time
when a network URL is used with the media source. The
interrupt_callback member variable in AVFormatContext allows safely
canceling IO operations when trying to shut down or stop the
media-playback interface.
(Note: This commit also modifies deps/media-playback)
Allows buffering network-based media sources where supported. Default
is two megabytes of buffering.
Currently, when media-playback is used with a network address, video has
to wait for the first keyframe before it starts decoding. This is
probably not wise because the first packet of video may contain
additional header information, and because audio is forced to wait and
buffer while waiting for a keyframe, potentially causing a lot of audio
to get backed up unnecessarily which could inadvertently cause sync or
audio playback issues.
So, instead of waiting for a keyframe before decoding starts, decode
right away, and make it wait for a keyframe before calling the video
callback instead.
When media returns frames with negative linesizes, it means they're
inverted RGB formats and start from the last line of the image and move
back to the top via the negative linesize number. This would cause a
crash because this wasn't being taken in to account, and it would
traverse in to invalid memory.
Fixes potential decoding errors with FFmpeg's new decode API. Because
avcodec_send_packet may process multiple packets, you must call
avcodec_receive_frame continually until no more frames are left.
Failure to decode is unfortunately quite common with certain file types,
and is most of the time safely recoverable. There's no reason to
actually output a log message for this unless really needed.
Intended to replace libff as the media playback library. Intended to
use less threads and be more extensible. It was nearly impossible to
modify libff without bursting a vein.
In some cases the result of the compatability check is wrong.
For example the format "mpegts" only shows "mpeg2video" as an
encoder even though other codecs such as h.264 are supported by
ffmpeg's muxer for that container and are used within that container
in some applications.
Closesjp9000/obs-studio#804
FFmpeg by default decodes VP8/VP9 via its internal encoders, however
those internal encoders do not support alpha. Encoded alpha is stored
via meta/side data in the container, so the only way to decode it
properly is via forcing FFmpeg to use libvpx for decoding.
(Note: This commit also modifies the ipc-util/seg-service modules)
When compiling the final project, always compile
ipc-util/get-graphics-offsets/graphics-hook/inject-helper/seg-service
with static MSVC runtimes to prevent the need of requiring the MSVC
runtimes for both architectures.
(Also modifies obs-ffmpeg to handle empty frames on EOF)
Previously the demuxer could hit EOF before the decoder threads are
finished, resulting in truncated output. In the worse case scenario the
demuxer could read small files before ff_decoder_refresh even has a chance
to start the clocks, resulting in no output at all.
How to crash:
1. Use recent ffmpeg shared libraries.
2. Add a ffmpeg_source, a small static picture (e.g. jpeg) with loop
3. After a while of high cpu usage, it crashed. Seems reproduced more
easily on faster computer
Closes#533
There's no need to duplicate the packet as the reference count will be 1
after the av_read_frame call. Duplicating causes heap corruption when a
synthetic clock packet is duplicated and assigned the buffer from the
stack-based temporary packet which is then double-freed by the decoder
thread.
avformat_free_context() only frees the memory used by an AVFormatContext
but it does not close the opened media file. This causes a leaked file
descriptor every time a media source frees a demuxer. Using
avformat_close_input() instead frees the context and closes the media
file.
Fixes warnings with deprecated packet functions (av_free_packet and
av_dup packet, which were replaced by av_packet_unref and av_packet_ref
respectively)
Just in case glSwapIntervalEXT and glSwapIntervalSGI aren't available
for whatever reason. This entire patch is most likely completely
redundant on modern mesa drivers.
This allows plugins to update and cache data files from a remote source.
Here are the steps that occur when the API initiates an update check:
1.) It checks to see if the local files are greater than the cached
files. If the local version is newer (for whatever reason), it
replaces the cached version(s) with the local version.
2.) A packages.json file is downloaded from the specified URL. That
packages.json file contains a version number and a list of files to
be updated.
3.) If the downloaded package version is greater than the cached
version, executes step 4-5 on each file.
4.) Checks the version for the file to update in packages.json, and if
the version is greater than the cached version, proceeds to step 5,
otherwise repeat step 4-5 for other files.
5.) Calls the callback given to the update function (if any) with the
file information (file name, buffer, etc), and if the callback
returns true, allows the cached file to be updated and replaced,
otherwise goes back to step 4-6 for the rest of the files.
NOTE: Files are never modified directly. All file saving/modification
is performed in a temporary directory, and then files are moved to their
destination. This should eliminate any possibility of file corruption
(or at least dramatically reduce the possibility).
If the first guessed pts is less than the start_pts, it could
lead to a negative PTS being returned.
Change the behavior so that the first frame's pts, if zero, is
set to the start_pts. If more than one frame is less than the
start_pts, the start_pts is determined invalid and set to 0.
Valid start_pts example:
start_pts = 500
first frame (pts = 0)
pts = 500 (< start_pts)
pts -= 500 (offset by start_pts)
ret 0
second frame (pts = 700)
pts = 700 (no change, > start_pts)
pts -= 500 (offset by start_pts)
ret 200
Invalid start_pts example:
start_pts = 500
first frame (pts = 0)
pts = 500 (< start_pts)
pts -= 500 (offset by start_pts)
ret 0
second frame (pts = 300)
pts = 300 (< start_pts, start_pts set to 0)
pts -= 0 (start_pts is now 0)
ret 300
ff_clock_init expects a parameter with a pointer where it stores the
address of the newly allocated ff_clock, but ff_demuxer_reset does not
provide this parameter. That somehow writes the pointer to the ff_clock
into the packet->base->buf field on the stack of the ff_demuxer_reset
function. This later causes a segmentation fault when the packet is freed.
Closesjp9000/obs-studio#448
This was the reason why game capture could not hook when the hook was
run at administrator level and the game/target was below administrator
level: it was because the plugin created a pipe, and the hook tried to
connect to that pipe, but because the pipe was created as administrator
with default access rights, the pipe did not allow write access for
anything below administrator level, therefor the hook could not connect
to the plugin, and the hook would always fail as a result.
This fixes the issue by creating the pipe with full access rights to
everyone instead of default access rights.
Certain input streams (such as remote streams that are already active)
can start up mid-stream with a very high initial timestamp values.
Because of this, it would cause the libff timer to delay for that
initial timestamp, which often would cause it to not render at all
because it was stuck waiting.
To fix the problem, we should ignore the timestamp difference of the
first frame when it's above a certain threshold.
Now that we're using the timestamps from the stream for playback,
certain types of streams and certain file formats will not start from a
pts of 0. This causes the start of the playback to be delayed. This
code simply ensures that there's no delay on startup. This is basically
the same code as used in FFmpeg itself for handling this situation.
Removed code where if a PTS diff was greater than a certain
threshold it was forced to the previous PTS diff. This breaks
variable length frame media like GIF.
Always use -fPIC when not on WIN32 or APPLE and not just with gcc.
This allows for building obs with clang on linux and FreeBSD
without explicitly specifying -fPIC as compiler flag to cmake.
This adds utility functions for determining which
codecs and formats are supported by loaded FFMpeg
libraries. This includes validating the codecs that
a particular format supports.
Skip decode refresh scheduling if the abort flag is
set when the timer fails to start. This avoids extraneous
refresh scheduling when tearing down the decoders.
Fixes a bug where get_format was overloaded by our own version
when forcing the codec to load with a HW decoder and not
reset to the original get_format if it failed to load.
In the same manner that PNG doesn't appear to work properly
with multiple threads, TIFF, JPEG2000 and WEBP also appears
to not render correctly (use of FFmpeg's ff_thread_* routines)
if decode is called before the automatic thread detection
has returned a suggested thread count for the decoder.
If this is omitted and you use an input that requires the network
you get a warning message about future versions not automatically
doing this for you.
This attaches clocks to packets and frames and defers
the start time until that particular frame is presented.
Any packets/frames in the future with the same clock
will reference that start time.
This fixes issues when there are multiple start times
in a large buffer (looped video/images/audio) and different
frames need different reference clocks to present correctly.
Enables clocks to wait if the main sync clock has not been started yet. An example of this is a video stream (video/audio) being synced to the video clock. If an audio frame gets produced before the video clock has started it will wait.
Add referencing counting to determine when to release a clock Due to no fixed ownership of clocks (packets, frames, decoders and refresh thread all may own a clock at some point).
The bug was undetected because it accidentally fell into an error case that slept the correct amount of time. pthread_cond_timedwait takes an absolute time in the future to wait until. The value we were passing was always in the past so it was immediately failing with a TIMEDOUT error code.
This lets the decoder make decisions based on whether it is a hardware decoder or not. Specifically, hardware decoders are more strict as to which frames can be dropped in an h264 stream.
FFMpeg has an issue where png decoding will not correctly
begin until its optimal-thread-detection finishes in
multi-threaded mode. This unfortunately is after decoding
has begun.
Originally I made the "win_pipe" stuff for named pipes on windows but it
was argued that it should be available to all modules and
programs/libraries that the modules might communicate with.
It cannot really be put in to libobs due to the fact that there would
hypothetically be things unrelated to libobs that might want to use it,
so I felt the best option was just to create a simple static library
specific for interprocess communication.
Non-windows versions of these functions are still yet to be implemented.
- Implement the RTMP output module. This time around, we just use a
simple FLV muxer, then just write to the stream with RTMP_Write.
Easy and effective.
- Fix the FLV muxer, the muxer now outputs proper FLV packets.
- Output API:
* When using encoders, automatically interleave encoded packets
before sending it to the output.
* Pair encoders and have them automatically wait for the other to
start to ensure sync.
* Change 'obs_output_signal_start_fail' to 'obs_output_signal_stop'
because it was a bit confusing, and doing this makes a lot more
sense for outputs that need to stop suddenly (disconnections/etc).
- Encoder API:
* Remove some unnecessary encoder functions from the actual API and
make them internal. Most of the encoder functions are handled
automatically by outputs anyway, so there's no real need to expose
them and end up inadvertently confusing plugin writers.
* Have audio encoders wait for the video encoder to get a frame, then
start at the exact data point that the first video frame starts to
ensure the most accrate sync of video/audio possible.
* Add a required 'frame_size' callback for audio encoders that
returns the expected number of frames desired to encode with. This
way, the libobs encoder API can handle the circular buffering
internally automatically for the encoder modules, so encoder
writers don't have to do it themselves.
- Fix a few bugs in the serializer interface. It was passing the wrong
variable for the data in a few cases.
- If a source has video, make obs_source_update defer the actual update
callback until the tick function is called to prevent threading
issues.
Colin Edwards
pkviet
Richard Stanway
Thomas De Schampheleire
jp9000
Shaolin
derrod
Richard Stanway
Kurt Kartaltepe
Gol-D-Ace
sorayuki
Christoph Hohmann
kc5nra
Momcilo Medic
fryshorts
GoaLitiuM
Ethan Lee
martell
BtbN