[Libav-user] Encoding H263+ video

[David Longest]

> Alex Wrote:
>
> Note that in terms of allocations and encoder logic, you can use nv21 input instead of yuv420p. The resulting video will be crap, but the encoder should not > crash/fail, and you can expect to receive a movie file as output. You can even extract nv21 frames from this movie:
>
>     ffmpeg -i video.h263v2 -pix_fmt yuv420p -vframes 1 foo-1.yuv
>
> You can even use ffplay to see the resulting frame:
>
>     ffplay -pixel_format nv21 -video_size WxH foo-1.yuv
>
> So, please check if your problem is reproduced without the "extra step" of nv21 to yuv420p conversion.
>
> BR,
>
> Alex


Alex,

I just tried creating an AVFrame and setting the pixel format to PIX_FMT_YUV420P while still providing NV21 data. When passing this frame to avcodec_encode_video2, I will still get the crash unless I allocate the input packet's data field beforehand. I get the following stack trace.

ffmpeg.so (ff_h263_encode_picture_header+860): Routine put_bits in ffmpeg/libavcodec/put_bits.h:160
ffmpeg.so (ff_MPV_encode_picture+3192): Routine encode_picture in ffmpeg/libavcodec/mpegvideo_enc.c:3421
ffmpeg.so (avcodec_encode_video2+184): Routine avcodec_encode_video2 in ffmpeg/libavcodec/utils.c:1409

Below I have added some more information that may be helpful with this issue.
* The incoming data is raw NV21 video data coming in at a resolution of 320 x 240
* I am using libavcodec 54.59.100 directly when encoding the data.
* The encoder context setup is as follows:
    - bit_rate: 262144
    - bit_rate_tolerance: 100000
    - gop_size: 10
    - time_base: {1,25}
    - width: 240
    - height: 320

Thanks,
David