livepeer
StreamBuffer for input
Alternative input system for LPMS. The idea is to allow using of FFmpeg demultiplexers with any input mechanism, such as network packet delivery. In order to do that we have to provide custom AVIOContext with custom read() and seek() operations. This also means that synchronization is needed because we will have to perform input and transcoding in different threads (for example demux - which is a part of transcode - may want more data which is not available yet, then transcode should block until input thread delivers more data)
Well Done.
:-)
Is
loadInputBuffer()planned to be removed in future PR?
I first want to change it into thread (goroutine?) to have synchronisation test. Then it could be removed, or alternatively it could be used to run a few tests of the demuxer kind with the StreamBuffer input?
How do you run tests?
The version that we have right now runs all tests that aren't using pipes through loadInputBuffer. I don't think it should be left this way, more like development help (having various tests and demuxers allowed me to understood requirements of the demuxer wrt to seek() better)
@AlexKordic - this is current version of the LL input/output. It works by having circular buffer on the input side (like we discussed) and packet queue on the output side. ffmpeg.go was modified to use LL input/output with all the tests. Namely, input file is loaded into stream buffer before transcode() is called, and output data is picked from the queue after transcode() ends.
First commit works with all the tests. Alas, second commit fails some. This is primarily because mp4 format muxer requires seek() (to update file size or some such in the header after all write operations are completed), and I don't think we want this because it would kill Low Latency (to allow seek and write we'd have to refrain from sending data until the very end, which is exactly what no-LL version does now).
Apart from that, TestTranscoder_API_AlternatingTimestamps test fails for some reason not entirely clear for me (yet). From what I managed to see, .md5 muxer fails to send any data to custom I/O.
But if you replace go procedures loadInputBuffer/storeOutputQueue with threads receiving/sending the data over the network, Transcoder should work with LL. Alternatively, when I'll be back I want to replace these procedures with file I/O threads myself, to make sure that synchronisation is correct.