[FFmpeg-devel] [PATCH] h264.c: add HW acceleration hooks

[Gwenole Beauchesne]

On Thu, 26 Feb 2009, Michael Niedermayer wrote:

>>>> Generally, actually all cases, AVHWAccel::end_frame() is sending the
>>>> control blocks to the accelerator, and does the actual decoding. We
>>>> could ignore errors as the original VDPAU code though.
>>>
>>> iam not asking to ignore them but rather asking what exactly
>>> the return -1 at that point is supposed to achive?
>>
>> You are right, it's probably just more useful to return the usual
>> get_consumed_bytes(). OK to replace the return -1; with an
>> av_log(ERROR,..)?
>>
>> On the other hand, decode_frame() usually returns -1 on errors and let the
>> callee manage whatever it wants.
>
> yes but you are returning it from the middle, this has to be reviewed for
> memleaks and such stuff and tested
> i suspect you didnt test it ...

I indeed did not test the error path. Now, I have (Grey.ts):

==1799== 112 (8 direct, 104 indirect) bytes in 1 blocks are definitely 
lost in loss record 17 of 35
==1799==    at 0x4024759: realloc (vg_replace_malloc.c:306)
==1799==    by 0x408F8E6: (within /usr/lib/libX11.so.6.2.0)
==1799==    by 0x4090335: (within /usr/lib/libX11.so.6.2.0)
==1799==    by 0x4092084: _XlcCreateLC (in /usr/lib/libX11.so.6.2.0)
==1799==    by 0x40AF776: _XlcDefaultLoader (in /usr/lib/libX11.so.6.2.0)
==1799==    by 0x4098952: _XOpenLC (in /usr/lib/libX11.so.6.2.0)
==1799==    by 0x4098A49: _XrmInitParseInfo (in /usr/lib/libX11.so.6.2.0)
==1799==    by 0x4080BA4: (within /usr/lib/libX11.so.6.2.0)
==1799==    by 0x4082745: XrmGetStringDatabase (in /usr/lib/libX11.so.6.2.0)
==1799==    by 0x40612CE: XGetDefault (in /usr/lib/libX11.so.6.2.0)
==1799==    by 0x5177190: _XcursorGetDisplayInfo (in /usr/lib/libXcursor.so.1.0.2)
==1799==    by 0x51773BB: XcursorSupportsARGB (in /usr/lib/libXcursor.so.1.0.2)
==1799==
==1799==
==1799== 340 bytes in 5 blocks are definitely lost in loss record 22 of 35
==1799==    at 0x4024669: malloc (vg_replace_malloc.c:149)
==1799==    by 0x8188B10: new_pid (demux_ts.c:2168)
==1799==    by 0x818D799: ts_parse (demux_ts.c:2763)
==1799==    by 0x81905EC: demux_open_ts (demux_ts.c:665)
==1799==    by 0x814D55F: demux_open_stream (demuxer.c:875)
==1799==    by 0x814D896: demux_open (demuxer.c:1002)
==1799==    by 0x808D8D7: main (mplayer.c:3198)
==1799==
==1799==
==1799== 360 bytes in 3 blocks are definitely lost in loss record 23 of 35
==1799==    at 0x4024669: malloc (vg_replace_malloc.c:149)
==1799==    by 0x8117C63: vf_get_image (mp_image.h:215)
==1799==    by 0x8113F66: mpcodecs_get_image (vd.c:341)
==1799==    by 0x820D768: get_buffer (vd_ffmpeg.c:591)
==1799==    by 0x835CB01: alloc_picture (mpegvideo.c:182)
==1799==    by 0x835CF2E: MPV_frame_start (mpegvideo.c:878)
==1799==    by 0x84633E8: frame_start (h264.c:2211)
==1799==    by 0x846A556: decode_slice_header (h264.c:3843)
==1799==    by 0x848521B: decode_nal_units (h264.c:7486)
==1799==    by 0x848581E: decode_frame (h264.c:7687)
==1799==    by 0x8325E4C: avcodec_decode_video (utils.c:529)
==1799==    by 0x820C4F7: decode (vd_ffmpeg.c:782)
==1799==
==1799== LEAK SUMMARY:
==1799==    definitely lost: 708 bytes in 9 blocks.
==1799==    indirectly lost: 104 bytes in 4 blocks.
==1799==      possibly lost: 0 bytes in 0 blocks.
==1799==    still reachable: 1,102,641 bytes in 301 blocks.
==1799==         suppressed: 0 bytes in 0 blocks.

which is exactly the same as without return -1;

==1804== LEAK SUMMARY:
==1804==    definitely lost: 708 bytes in 9 blocks.
==1804==    indirectly lost: 104 bytes in 4 blocks.
==1804==      possibly lost: 0 bytes in 0 blocks.
==1804==    still reachable: 1,102,641 bytes in 301 blocks.
==1804==         suppressed: 0 bytes in 0 blocks.

which is equivalent to the SW only path.

==8363== LEAK SUMMARY:
==8363==    definitely lost: 384 bytes in 7 blocks.
==8363==    indirectly lost: 224 bytes in 14 blocks.
==8363==      possibly lost: 29,372 bytes in 819 blocks.
==8363==    still reachable: 1,135,012 bytes in 2,806 blocks.
==8363==         suppressed: 0 bytes in 0 blocks.