Ah yes. A good case of RTFM!
From the docs on AVAssetWriterInput::readyForMoreMediaData:
Clients writing media data from a real-time source, such as an instance of AVCaptureOutput, should set the input's expectsMediaDataInRealTime property to YES to ensure that the value of readyForMoreMediaData is calculated appropriately. When expectsMediaDataInRealTime is YES, readyForMoreMediaData will become NO only when the input cannot process media samples as quickly as they are being provided by the client. If readyForMoreMediaData becomes NO for a real-time source, the client may need to drop samples or consider reducing the data rate of appended samples.
In our case, the real time source is our render engine producing sweet graphics!
We're in the VFX world and tend to get a little over-eager when we start a project. I had the stream at 4K without enough optimizations. In MV-HEVC we are doubling that up sort of). While our render cycle is fast enough, we haven't had enough optimization on the HLS tooling done and it was causing the readyForMoreMediaData to become NO.
When you spam the adapter with buffers it's not ready for, it appears to hang and, AFAICT never return.
For now we've have opted to drop the frames as required to stay up with the stream.
/// Called every (1 / framerate) seconds (with a little wiggle)
/// from our plugin interface
void HLSInterface::writeFrame()
{
CMTime pts = CMTimeMake(
m_frameIndex++ * m_frameRateDuration,
m_frameRateScale
);
if (![m_video readyForMoreMediaData])
{
// We can't use this buffer, skip it for now. Ideally
// this never happens but we can't trust the input
// adapter not to explode if we overload it
return;
}
// We can accept buffers, tagged or otherwise, so do
// the thing
// ...
}
Topic:
Media Technologies
SubTopic:
Streaming
Tags: