Buffers in pool may not always point at the video compositors output #39
Conversation
…utput We received a report of black frames in an applications video content once it was encoded with NextLevel. Investigation revealed a similar issue as NextLevel#38. It appears NextLevelSessionExporter is pulling buffers from the pool that was created, and sending those buffers back to the API. The assumption a buffer pulled from that pool will contain the output of the Metal video compositor is not always correct. This change will pass the pixelBuffer directly, or use the toBuffer if a renderHandler exists.
|
@Developer-Ecosystem-Engineering thanks for the PR! could you explain how these code paths are different? when an optional statement is called, nothing happens, just as your code does. did you observe different results? |
|
Hi @piemonte!
The difference is which buffer we are passing to If the Without this change, there is no default The observable difference is sometimes video files re-encoded by NLSE had black frames prior to the change and now those same video files re-encode no longer black. Perhaps @GrandPoohBear could share one of their sample videos, we are unable to provide the reference video in this case. |
We received a report of black frames in an applications video content once it was encoded with NextLevelSessionExporter.
Investigation revealed a similar issue as #38.
It appears NextLevelSessionExporter is pulling buffers from the pool that was created, and sending those buffers back to the API. The assumption a buffer pulled from that pool will contain the output of the Metal video compositor is not always correct.
This change will pass the pixelBuffer directly, or use the toBuffer if a renderHandler exists. It resolves black frames in video content in our testing, @GrandPoohBear you may want to give it a try.