On Wed, 21 Jun 2006 15:24:35 +0200
Christian Bodenstedt <[EMAIL PROTECTED]> wrote:
[...]
> Your patch seems to have the same effect like the changes I applied to my
> local copy. But my changes didn't take care about buffer sizes, so I
> didn't want to post a patch ;-)
>
> > At very first glance, it seems the problem is that there isn't a clean
> > way to known buffer sizes in audio/video frames, at least at encoding
> > step.
>
> You are talking about the buffer "outframe->video_buf" which is
> provided through the third parameter of "*encode_video(...)", aren't you?
>
> I was stumbling over "outframe", too (and I didn't manage to find any
> documentation on it). To go on I'll need some informations:
> - In which function will "outframe->video_buf" be allocated?
it is allocated in alloc_buffers(), found in src/encoder.c
both outframes passed as third parameter of encode_audio and encode_video
methods of encoder modules (I'm speaking NMS-ish here) are private video
frames hold by encoder code. They NEVER enter and/or exit the main transcode
frame ringbuffer.
Proper encoder code usage is to allocate such private frames before to do any
encoding and deallocate after all encoding is done, so such frames are
supposed to be always avalaible.
> - If it's already allocated when *encode_video() is entered:
> - what is its size?
it's size it always enough to fit a full decoded frame in RGB or YUV444
format, so it will always be >= (vob->im_v_width * vob->im_v_height * BPP/8)
(where BPP==24)
So, if in x264 we can safely assume
assert(sizeof(x264_encoded_frame) <= sizeof(yuv_raw_frame))
we can safely stop to worry about maximum size *in encoder module*
Of course in general sense we need a cleanup here.
At moment of writing alloc_buffers() allocate SIZE_RGB_FRAME bytes for encoded
frame size, and that's insanely high in the common case; ASAP I'll update
src/encoder.c code to use libtc/tc_fuctions.c:tc_{a,v}frame_new
in order both to reuse existing code and to save some memory.
Above statements still will be valid, so it will still safe to assume that
destination video frame buffer is at least big as source video frame buffer
Or, in C-speak:
assert(outframe->video_size >= inframe->video_size)
Documentation will be updated too ASAP.
> - How can I find out this size?
This isn't yet enforced, but at every call outframe->video_size will hold
the size of outframe->video_buf.
I'll patch CVS HEAD in the next few hours/days to enforce this.
> - Where is the documentation on this topics?
Good question.
encoder.c code has the bare minumum documentation. It really should find some
time to update and enhance such docs, most notably the memory management, but
not only this.
Best regards,
--
Francesco Romani - Ikitt ['people always complain, no matther what you do']
IM contact : (email first, Antispam default deny!) icq://27-83-87-867
known bugs : http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase
tiny homepage : http://fromani.exit1.org (see IDEAS if you want send code!)
