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.
Generally the muxer will ignore these, but there's one specific case
where it cannot: Since we flush before keyframes, the mov (MP4) mux
will not be able to set a proper duration based on the next frame
(usually it just does next_dts - dts), and thus guesses that it will be
the same as the previous one. If we dropped a frame between those two,
the duration of said last frame will be wrong -- and the keyframe
(starting in the next fragment) will get the wrong pts, possibly
seemingly even going backwards.
If we lose a frame between the last frame and the keyframe, the pts
of the keyframe will still be a bit wonky, but according to wbs
(who wrote the mux), it's much better like so.
Put a global lock around glFenceSync/glDeleteSync calls, to workaround apitrace bug #446. (Replaying Nageru calls using apitrace can be very useful, and it should not have any appreciable performance impact in practice.)
At some point, it was indeed more convenient to mux separately to everybody,
but muxing needs to know more stuff these days, so it was getting increasingly
ugly. This code follows roughly what VLC does to extract the header and various
block boundaries.
projects / nageru / log