[FFmpeg-soc] SVQ3 depacketizer

Martin Storsjö martin at martin.st
Wed Jun 30 18:55:04 CEST 2010


On Wed, 30 Jun 2010, Ronald S. Bultje wrote:

> On Wed, Jun 30, 2010 at 4:45 AM, Martin Storsjö <martin at martin.st> wrote:
> >
> >> > +    if (end_packet) {
> >> > +        av_init_packet(pkt);
> >> > +        pkt->stream_index = st->index;
> >> > +        pkt->pts          = sv->timestamp;
> >> > +        pkt->flags        = sv->is_keyframe ? AV_PKT_FLAG_KEY : 0;
> >> > +        pkt->size         = url_close_dyn_buf(sv->pktbuf, &pkt->data);
> >>
> >> Neat, this is exactly what I meant, that could be used to save some
> >> memcpys for the xiph depacketizer, too. But this lacks a pkt->destruct =
> >> av_destruct_packet - at the moment, you're leaking every packet.
> >
> > Ah, yes, as I mentioned in the status mail comments yesterday (but forgot
> > when I reviewed this, but valgrind reminded me) - you need to add padding
> > at the end of the packets, e.g. put_buffer with
> > FF_INPUT_BUFFER_PADDING_SIZE zero bytes, then subtract the same amount
> > from the size returned by url_close_dyn_buf.
> >
> > For this, I guess it would be handy with a put_zero function (or similar)
> > that writes a certain amount of zero bytes, so we wouldn't have to
> > allocate an array just to get some padding to write. Or perhaps we should
> > just loop with put_byte(, 0)?
> 
> Generic problem with the dyn_buf API. I'd say, please fix
> close_dyn_buf() to automatically add padding to the returned buffer,
> that's much more user-friendly.

True, that would be a neat way of handling it. It isn't needed in all 
cases where one uses dyn buffers though, so I'm not sure if one may want 
to skip doing it in those cases, or just always add padding to dyn 
buffers, to keep the API small and concise.

// Martin


More information about the FFmpeg-soc mailing list