[Libav-user] Problem with h264_videotoolbox and AV_PIX_FMT_YUV420P
kernrj at gmail.com
Sat Feb 18 01:44:21 EET 2017
On February 17, 2017 at 5:18:09 PM, Steve Green (steve.green at flosports.tv)
I assume you want to see screenshots? These are produced after the long
journey to a Wowza server and back out the other side in jwplayer. I could
capture the raw YUV and a key frame of H264 if that would help.
No need, I see the issue.
Attached is the original picture, and the results of supplying 1-byte
aligned and 16-byte aligned YUV to avcodec_encode_video2().
On Feb 17, 2017, at 5:02 PM, Richard Kern <kernrj at gmail.com> wrote:
On February 17, 2017 at 4:53:03 PM, Steve Green (steve.green at flosports.tv)
This is the basic pipeline that I have:
BGRA frames -> sws_scale() -> YUV frames -> avcodec_encode_video2() ->
.. and this works perfectly with x264 and most of the time with
h264_videotoolbox. The issue with h264_videotoolbox happens when I try to
stream at 854x480. From looking at the output, it appears that someone
along the way is not happy with width not being a multiple of 16. There is
a very clear shift/wrapping of pixels.
As an experiment, I changed my use of av_image_fill_arrays() to align on 16
bytes (with a sufficiently larger buffer) and the resulting image is
improved but still not correct. The basic shift is gone and the image is
legible but the colors are off and I can see an artifact over the image.
Can you post a frame grab of the unaligned and 16-byte aligned output?
Given that x264 works and h264_videotoolbox doesn't, I’m tempted to point
fingers at either VTCompressionSession or CVPixelBuffers + YUV, which would
explain why I want to try AV_PIX_FMT_VIDEOTOOLBOX. I’ve read pretty much
everything I can find on this but I cant find a single mention of
16-byte-multiple widths or strides.
Any idea how to go about debugging this?
Libav-user mailing list
Libav-user at ffmpeg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libav-user