[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 3)
Wed Feb 18 20:28:20 CET 2009
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
>> 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.
More information about the ffmpeg-devel