[FFmpeg-devel] [PATCH 2/5] ffmpeg: use the write_uncoded_frame() API.
michaelni at gmx.at
Mon Jan 27 15:13:06 CET 2014
On Mon, Jan 27, 2014 at 08:51:21AM +0100, Nicolas George wrote:
> Le septidi 7 pluviôse, an CCXXII, Michael Niedermayer a écrit :
> > The user provides a AVFrame to an encoder and the (raw) encoder
> > would do the magic encapsulation of the AVFrame into a AVPacket
> > If a user wants to send a AVFrame directly to a muxer then this
> > would call the uncoded_frame API which takes a AVFrame and this would
> > then do the magic encapsulation if needed (thats identical your API)
> > (strictly speaking the uncoded frame API could call the rawvideo
> > encoder or share code with it to do it)
> Oh, now I understand what you meant: an additional helper API, and not a
> replacement for the proposal.
> I do not like it, because the resulting packet is not a real packet and
> therefore needs to be handled very carefully. Handling that in the API would
> require quite a few checks, and that still would not prevent the application
> from doing things that are legitimate with a real packet but completely
> broken with that kind of pseudo packet.
I am not sure if your analysis of this is correct.
You can implement AVFrame in AVPacket by wraping the AVFrame in a
AVBuffer using av_buffer_create(). then i think
ref/unref/dup/free functions should be fine
side data functions should mostly be fine
functions that grow/shrink data make no sense on raw video
One function that is not safe would be av_buffer_make_writable() but
that is aguable a flaw in the buffer API that i belive affects
existing code already (for the same reason as here).
Also if this is done putting the AVFrame into AVBuffer.opaque also
seems safer than AVBuffer.data == AVFrame.data
because fewer bad things can happen if the data gets serialized
and deserialized into a new packet, opaque would just be lost in
that case, which is detectable while old pointers in .data could
> But if the use is completely
> optional this is not a blocking issue.
> And, unless I am mistaken, deciding on this issue is not blocking for this
> patch series (except maybe #2).
> Nicolas George
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel