[FFmpeg-devel] [PATCH] movenc.c fix (Was: Can av_write_frame() modify pkt.data?)

[Aurelien Jacobs]

Baptiste Coudurier wrote:

> Hi,
> 
> Aurelien Jacobs wrote:
> > Luca Abeni wrote:
> > 
> >> Luca Abeni wrote: [...]
> >>> I'll test h.264 (encoded through libavcodec + x264 with default
> >>> options) in mp4, mov, matroska, and flv. Is this enough, or
> >>> should I add some more tests?
> >> Ok, here are the two possible patches (BTW, I just realized that
> >> the first one looked smaller because it only fixed the mov muxer,
> >> and did not fix the flv and mkv muxers...).
> > 
> > The patch passing a ByteIOContext to ff_avc_parse_nal_units() is
> > better IMO. It avoid one malloc/copy step for every packet.
> > 
> 
> True, but IMHO it is one step away from moving this code into a
> bitstream filter.

Maybe yes. But this function is pretty simple, and converting it to
a bitstream filter should be simple anyway.
This biggest problem will be to auto-insert the bitstream filter
when it is needed.

> Also this code could not be used also as standalone. Yes, I know this is
> not intended since not part of public API, but there are some very
> useful, at least to me, functions into FFmpeg codebase
> (ff_find_start_code being one, this one will too).

I'm not sure what you mean by standalone (it's current version already
depends on ByteIOContext), but anyway, point taken.

> Also patch using ByteIOContext more complex IMHO.

Not that much complex. And the resulting code is simpler and faster.
I reviewed the patch carefully, and it is safe and clean.

Now have a look at the updated attached patch. It simply splits
ff_avc_parse_nal_units into 2 functions. One doing the basic work
with a provided ByteIOContext, and the other encapsulating the
call with the necessary dyn_buf so that caller don't need to
mess with a ByteIOContext when it don't already have one.

It should address all your remarks. It don't move away from converting
to a bitstream filter and it's still usable standalone (as much as
current code is).
It also retains advantages of original Luca's patch. It avoids useless
malloc/copy for each packet, and thus it's faster.

Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: do_not_realloc_pkt_data_2.diff
Type: text/x-patch
Size: 6251 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080725/8432f9d3/attachment.bin>