PPS when it being used by videotoolbox.c, is 3 bytes long. PPS NAL unit, as it appears in the bitstream, is 4 bytes long. On Intel Mac, of course things work in all the above scenarios.
The difference seems to be what is fed into the decoder: This seems to happen, when the bitstream provided for decoding doesn't contain SPS/PPS.įor example, using the provided m1_not_decodable_with_acceleration.ts:įfmpeg -i m1_not_decodable_with_acceleration.ts -vcodec copyįfmpeg -hwaccel videotoolbox -i m1_not_decodable_with_acceleration.h264 -v debug /tmp/img%05d.jpgįfmpeg -hwaccel videotoolbox -i m1_not_decodable_with_acceleration.mkv -v debug /tmp/img%05d.jpg I also didn’t see any differences in the code path leading up to the decoding call. I should also state I couldn’t spot any difference in the arguments passed to videotoolbox when I used lldb on Intel and on the M1, even though on Intel FFmpeg decodes all frames without issues. In either case, VTDecompressionSessionDecodeFrame returns successfully. The result is that the VTContext's frame field stays null, which then triggers a null pointer check down the line.
When decoding fails, image_buffer is null and status is kVTVideoDecoderBadDataErr (-12909). When decoding works, videotoolbox_decoder_callback is called with a non-null image_buffer. This bug does not occur with all videos encoded with h264.Īlthough the issue can be reproduced with the most recent ffmpeg binary (version N-106494-g1291568c98-tessus), when looking at the source code of FFmpeg 3.3, it seems that the failure is caused by a call to VTDecompressionSessionDecodeFrame. hardware accelerator failed to decode pictureĮrror while decoding stream #0:0: Unknown error occurred % ffmpeg -hwaccel videotoolbox -i m1_not_decodable_with_acceleration.ts -an output.ts videotoolbox) to decode the frames of some video streams encoded with h264 fails on recent M1 mac computers.Įnsure you are using a Mac with an Apple M1 chip.ĭownload the attached sample file and use ffmpeg to target it with
0 kommentar(er)
