[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 3)

[Gwenole Beauchesne]

Le 18 f?vr. 09 ? 19:12, Michael Niedermayer a ?crit :

>>>> I really want start_frame() to be at a location
>>>> where we are assured that frame info is parsed.
>>>
>>> should not be a problem ...
>>
>> It is for e.g. h264.c, reasons kept below.
>
> you can always pass NULL/0 as buf/size if there is no single  
> buffer ...

Then we could have cases where codecs would emit valid buf/size  
information and others don't.

Let's have a look at the codecs to make sure we understand the same  
things, I am a little confused by now. My only requirement: by the  
time start_frame() is called, I want frame information parsed into  
MpegEncContext et al. fields.

* For mpeg12.c: the requirement can be full-filled as early as  
mpeg_field_start(). However, this is called in decode_chunks() and  
this function turns out to be called from mpeg_decode_frame() with  
either the buf argument or extradata (both in that case). So, what  
start_frame() should receive as buf/size: NULL/0?

* For h263dec.c: the requirement can be full-filled as early as  
picture_header is decoded. However, this would have been decoded from  
either s->bitstream_buffer or the original buf argument. I think we  
could simply pass s->gb.buffer / s->gb.size_in_bits/8 to  
frame_start(). So, no problem for this one.

* For h264.c: the requirement can be full-filled as early as the first  
decode_slice_header(). However, decode_nal_units() will not  
necessarily be called with buf from the decode_frame() arguments. NULL/ 
0 for this one?

* For vc1.c: there shouldn't be any problem.

>>> what happens with a buf of random content and buf_size of 1
>>> will it segfault? if not how do you know how much you can copy?  
>>> did i miss
>>> some buf_size parameter somewhere?
>>
>> FFmpeg always sends correct data to users, it won't segfault and  
>> it's not
>> lavc's fault if users can't do a simple subtraction. ;-)
>>
>> so we have start_slice() with a buf+offset and end_slice() with a  
>> buf_end,
>> so we can reconstruct the buf_size.
>
> that should work, excpt why not send
> buf+offset and buf_end in end_slice, is start still needed then?

Still and only for h263dec.c, it only depends on the level of ugliness  
you'd accept. ;-) I am all for a single decode_slice() instead of both  
start_slice(), end_slice() but I still haven't found a beautiful way  
for h263dec.c (and that actually works). If you have ideas...

An alternative is to not pass anything and mandate that the getbit  
buffer is valid at this point (i.e. s->gb.buffer for s- 
 >gb.size_in_bits/8 bytes). However, we wouldn't have the original  
encoded (raw and escaped) bitstream for h264 for example, and that  
size is a maximum not that of the current slice. So, this approach  
can't be a good one.

[back to the h263dec.c problem]
Hmm, it turns out the code snippet I posted earlier was the shortest  
of all alternatives but (i) I have not actually tested it and (ii) it  
doesn't handle msmpeg4 videos. (ii) holds for all HW accelerator for  
Linux I know of anyway. Besides, I don't see any means to get the  
actual slice size without decoding all macroblocks in SW since there  
is no resync_marker.

Thanks,
Gwenole.