Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Streaming from the net introduces latency or requires separate thread #1
When feeding a
This forces you to either only decode a frame whenever you are sure that the data for the whole frame is available (as the video decoder can't pause in the middle of a frame) or to run the decoder in a separate thread and busy wait in the
Making sure that enough data is available for decoding a full frame is not straight forward, because we don't know the size of a frame until it has been fully decoded, or we find the
The problem is described in more detail in this blog post towards the end.
This issue is meant for discussion of the problem and possible solutions.
Perhaps a non-blocking-io pattern would be useful here. The demuxer can return either a packet or EAGAIN. If the decoder gets EAGAIN from the demuxer then it does nothing and waits to be called again.
I guess that the wire format doesn't include the data size because doing so would force a frame of latency at the encoder whereas this way the decoder has more implementation options.