In f7434e60fc I made this a non-critical
error but after some more testing with a stream with a lot of missing
references, it works fine when not restarting VideoToolbox fully when
this happens and actually results in better playback.
In case a frame is marked as dropped, do not abort VideoToolbox decoding
when the imageBuffer is NULL, as that is a valid case that can happen
for lossy RTP streams for example.
Fix#28420
* OpenGL compatibility only for macOS.
* OpenGLES compatibility everywhere else but visionOS
Given this, every decoded buffers will be compatible for all available
Darwin compatible vout renderers.
Metal device is mandatory to handle P010 chroma on mobile/tv devices.
The Metal device API can only be used in ObjC context hence a new ObjC source file had to be created to handle the device detection.
Only OpenGLES isn’t compatible with `x420` formats. Other renderer
implementation using Metal or AVSampleBufferDisplayLayer can display
this chroma just fine.
Those functions can be useful in other places.
One useful case will be to attach color properties properly in the cvpx converter's output image buffers in a future fix without duplicating this mapping code.
VideoToolbox decoder doesn't attach all color properties to image buffers.
Current display modules handle tonemap without them.
Attaching additional color properties to image buffers is mandatory for native image buffer display on macOS in order to have proper colors tonemap when AVFoundation APIs are used to render them and prevent flickering while using multiple displays with different colorsync profiles
Enforce the restart of VideoToolbox when a data / codec error happens.
Usually, it was triggering a fallback (typically on avcodec) every time
an error happened within the played stream, which can happen when
corrupting the input stream.
It was done to protect the decoder against non-playable files for which
the decoder would announce the support but would not be able to decode a
single frame ever. VideoToolbox seems to behave correctly on those files
now so we can make it a default.
Remove the picture flushing workaround since the described behaviour is
obsolete after 34a548cc02, which flushes
the pictures from the video output before flushing the decoder.
It also ensures that we don't call decoder_UpdateVideoFormat which will
update the video output without video context, leading to potential
spurrious failures with OpenGL interop expecting one.
Co-authored-by: Alexandre Janniaux <ajanni@videolabs.io>
We don't need to know it's a pointer and can save 2 characters.
No functional changes. This is simply renaming "dec->p_fmt_in",
"decoder->p_fmt_in", "dec.p_fmt_in" and "packetizer->p_fmt_in"