[Libav-user] Mapping / converting QTCapture's to FFmpeg's pixel format

[Brad O'Hearne]

Thanks for the reply Michel. I've actually tried the following pixel formats on the QT Capture side: 

kCVPixelFormatType_420YpCbCr8Planar
Planar Component Y'CbCr 8-bit 4:2:0. baseAddr points to a big-endian CVPlanarPixelBufferInfo_YCbCrPlanar struct.
kCVPixelFormatType_420YpCbCr8PlanarFullRange
Planar Component Y'CbCr 8-bit 4:2:0, full range. baseAddr points to a big-endian CVPlanarPixelBufferInfo_YCbCrPlanar struct.
kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange
Bi-Planar Component Y'CbCr 8-bit 4:2:0, video-range (luma=[16,235] chroma=[16,240]). baseAddr points to a big-endian CVPlanarPixelBufferInfo_YCbCrBiPlanar struct.
kCVPixelFormatType_420YpCbCr8BiPlanarFullRange
Bi-Planar Component Y'CbCr 8-bit 4:2:0, full-range (luma=[0,255] chroma=[1,255]). baseAddr points to a big-endian CVPlanarPixelBufferInfo_YCbCrBiPlanar struct.

The first two cause the avcodec_encode_video2 line to crash. The last two transmit video properly but are distorted. I have in my mind that the first one is probably the right pixel format (also the one I need to use), but there's some state of the resulting frame / packet that isn't being set properly I'm guessing, and it is causing to dereference a null pointer somewhere inside libavcodec. Does anyone have any idea what might be causing this? Is there some value I need to set before encoding the video? 

Thanks,

Brad

On Feb 4, 2013, at 6:05 PM, Michel Marchand <michel at marex.tv> wrote:

> I'm no expert in ffmpeg but one in broadcast video and normally YCrCb 422 is not full range that is Y ranges from16 to 235 and Cr/Cb are signed and range from 16 to 240 (128 being 0). The Full range term may use the full 0-255 range and that could cause problems but not sure...
> 
> On Mon, Feb 4, 2013 at 7:31 PM, Brad O'Hearne <brado at bighillsoftware.com> wrote:
> Carl, 
> 
> Thanks for the reply. I've tried both PIX_FMT_NV12 and PIX_FMT_NV21 (in fact, those were the ones I originally thought would work based on description). However, when I use either of those formats in place of  PIX_FMT_YUV420P in the following line of code: 
> 
> int returnVal = avpicture_fill((AVPicture*)avFrame, frameBufferBaseAddress, PIX_FMT_YUV420P, width, height);
> 
> then while it executes the avpicture_fill line successfully, the subsequent line of code 
> 
> returnVal = avcodec_encode_video2(_videoStream->codec, &avPacket, avFrame, &gotPacket);
> 
> crashes the whole app with an EXC_BAD_ACCESS error --  and there's no message of any kind written to the console. I have no idea what is causing the crash. Here's the complete block of the code between those two lines: 
> 
> ...   
>  int returnVal = avpicture_fill((AVPicture*)avFrame, frameBufferBaseAddress, PIX_FMT_NV21, width, height);
>     
>     if (returnVal < 0)
>     {
>         if (error)
>         {
>         	NSLOG(@"Frame fill failed.");
>         }
>         
>         return NO;
>     }
> 
>     AVPacket avPacket;
>     av_init_packet(&avPacket);
>     avPacket.data = NULL;
>     avPacket.size = 0;
>     int gotPacket;
>     
>     returnVal = avcodec_encode_video2(_videoStream->codec, &avPacket, avFrame, &gotPacket);
> ...
> 
> That's been pretty standard for most of the other pixel formats I've tried. There have been one or two that didn't crash the app, but had very wacky distortions (like half the image being neon green), but most of them just crash the app outright. 
> 
> Ideas? 
> 
> Brad
> 
> On Feb 4, 2013, at 4:55 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> 
>> Brad O'Hearne <brado at ...> writes:
>> 
>>> "Bi-Planar Component Y'CbCr 8-bit 4:2:0, full-range 
>>> (luma=[0,255] chroma=[1,255]). baseAddr points to a 
>>> big-endian CVPlanarPixelBufferInfo_YCbCrBiPlanar struct."
>>> 
>>> My code (heavily abridged for brevity) hits these high points: 
>>> 
>>> NOTE: frameBufferAddress is a CVImageBufferRef received 
>>> from the QT capture callback: 
>>> 
>>>     int returnVal = avpicture_fill((AVPicture*)avFrame, 
>>> frameBufferBaseAddress, PIX_FMT_YUV420P, width, height);
>> 
>> Could "biplanar" point to AV_PIX_FMT_NV12?
>> (Or something else that is not AV_PIX_FMT_YUV420P)
>> 
>> Carl Eugen
>> 
>> _______________________________________________
>> Libav-user mailing list
>> Libav-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/libav-user
> 
> 
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
> 
> 
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130204/48acfa60/attachment.html>