Allow hotplugging of USB cards, instead of just exiting when something goes away.
Note that there are still limitations; e.g., you cannot start with 0 USB cards
and add them later, and you cannot have more cards than your initial --num-cards
parameter. This is primarily useful for if a cable falls out during broadcast.
Before, zoom and fade were too distinct; zoom was done with
live_signal always being SBS and a “zoom_poi” variable to
tell where we were zooming, while fade had its own fake signal
type. Make en explicit notion of transitions with to/from signals
instead (when transitions are in play, live_signal is just ignored,
at least for most purposes).
Use the new libavformat functionality for marking keyframes.
Note: This depends on code only recently in mainline avformat;
the commit in question is dbbaad3 in libav, 4e7a921 in ffmpeg,
merged Jun 23.
This removes our need for manually flushing before each keyframe
to to make sure we get the fragment boundaries correct. In turn,
this means we no longer need to interleave ourselves.
The lack of flushing (and that we start using libavformat's interleaving
queue again) also means that the muxer no longer has to guess at the
duration of the last frame in each fragment, which would sometimes
cause non-monotonic pts, which would confuse players in various ways.
In particular, 4.6.0 was just released, so we ask people to use that
instead of patching their kernel. Also, Mesa 11.2.x is now in unstable,
and should progress to testing soon.
Add back manual interleaving, but this time in Mux.
We need to interleave ourselves because we flush; otherwise, audio will
typically start 100 ms or so into the stream, and everything becomes bad.
Thankfully, we have only two streams to interleave, so we can choose
something quite simple, and this is still not bothered by the deadlocks
that arose from doing it in QuickSyncEncoder. (Hopefully we can soon find
keyframe boundaries without flushing, but it requires changes in avformat.)
Also fixes an issue where plugged packets would cause the boundaries
to fall in the wrong places.
Packets cannot be compared based on dts/pts alone; they also need
to take the timebase into account. (Right now, this is harmless,
but we need more precise packet sorting in the next commit.)
Encode audio as soon as we get it, instead of manually interleaving.
I honestly can't remember why this design was chosen back in the day,
but it doesn't appear to make much sense as long as the mux can interleave
for us. It (hopefully) fixes a deadlock I've seen a few times, where the
mixer hangs on begin_frame() because there are no free surfaces,
but saved_codeddata() (which is freeing them, after save) is stuck
waiting for more audio from the mixer.
Fix an issue where a ResamplingQueue could reach unbounded length.
This would happen if we stared asking for samples before the first insert,
causing the correction factor to become NaN and everything to go south.
This would also seemingly eventually cause panic messages when we believed we
were out of data in the same queue.
Based on the speedcontrol patch series from x264-obe, but bugfixed,
reworked and pulled out so that it can run with vanilla x264.
Note that vanilla x264 right now has a bug that this patch exposes;
you want the patch called “Fix corruption with reconfig which changed
SPS (like change of --ref)” (currently in x264-sandbox).
This is rather painful and should not be needed, but evidently Qt
can build up unbounded signals/slots queues if we send too often
(and “too often” is seemingly mere hundreds of messages per second).
When doing a cut, do the shutdown in a separate thread.
Alleviates problems with dropped frames in the mixer because shutdown
takes too long. We still have a problem with audio going to a somewhat
random of the two files, though.
The texture upload from the dequeue threads (and then using fences) _should_
work, but there are seemingly driver bugs galore here; AMDs drivers crash
outright, while NVIDIA's are much more subtle, crashing after only days,
and running under apitrace shifts the behavior enough that I don't see it.
Let's try to do all of this from the main thread instead; Nageru is still
multithreaded OpenGL in many places, but with some luck, it will the last of
the NVIDIA crashes (generally manifesting themselves as libGL.so.1 free()ing
some stray pointer that was never actually allocated).
Make QuickSyncEncoder get its textures from ResourcePool.
This fixes a problem where the ResourcePool would not be aware
that a given texture had been deleted (and a new one come back
using the same texture number), and thus happily continue
to give out cached FBOs from it, even though OpenGL had unlinked
those FBOs when the texture was deleted.
projects / nageru / log