If the bytes retrieved is less than the bytes we expected for the time period
we're rendering, we fill the remainder with silence. Fixes segfault trying to
copy bytes that aren't actually allocated.
Foundation for a fairly simple but likely essential autorecovery process.
Basically the same as what it was in 0.1.x but with a huge improvement: custom
autorecovery intervals. Ironically there isn't any "saving" to be done
just yet, but when there is, this infrastructure will be ready for it.
Updating values rapidly would cause strange jitters as a
byproduct of the viewer trying to update from the renderer while
it was still working. Rather than the viewer trying to access the
the renderer, we now send textures in the initial update signal
to keep everything synchronized.
I was looking for a way to update the length value automatically with signals
and slots (rather than just checking every time the viewer time changes). This
should do the trick.
Both audio and video renderers were working off the same invalidation signal
(i.e. changing audio would also trigger a re-render of the video). This is
obviously suboptimal and now they are separate.
Since we're storing media frames too with no disk space management
at the moment, we'll remove the mediaindex folder too on close
just for this testing period
Many changes were made throughout the codebase to support audio, these are
most of the small changes necessary.
The audio support still is not perfect. I still need to write in resampling
support. After that it should work correctly with all audio types.
Previously, the viewer could be set up with a custom PCM file to test playback
and scrubbing. Now these functions are connected to the audio renderer to
work within the render system.
Major refactoring work to try sharing as much code as possible between the
video renderers and audio renderers, as well as make them as
platform-independent as possible.
commit
For testing the new iteration, the texture cache disk download was written
into the main thread instead of into the separate threads. Now they're back
in separate threads again.
Also I think some of these files probably should have been in the previous
commit.
specific code
The new rendering system is now starting to work as planned, however it is
still not as complete as the iteration before. But this should be a more
robust design moving forward. Work was also done towards splitting off all
OpenGL-specific worker code into a derived class. The hope is to have no
hard dependency on OpenGL and make swapping it out with other backends
straight-forward.
Once again, conceptually this system should work, however it does not seem to
be the most efficient and it wouldn't surprise me if the multithreading was
eventually upgraded to an even more coherent system one day. However for
"core principles" this should be fairly decent.
The new rendering pipeline strives to simplify the nodes themselves as much
as possible and move much of the logic to an external rendering engine. This
change removes all of the responsibilities that no longer belong to the
nodes themselves and will soon be folded into the renderer.
The previous iteration was fairly OpenGL-heavy. It's now been separated into
a base class that is OpenGL independent and a derived class that is
OpenGL-based. Over time this should allow for portability away from OpenGL
if necessary.
Previous iteration used probably an excessive amount of threads to make
everything work. New iteration intends to use precisely the amount of logical
threads available and using a moved QObject rather than a subclassed QThread
itsmattkc