[FFmpeg-devel] [PATCH 2/5] ffmpeg: use the write_uncoded_frame() API.

[Michael Niedermayer]

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.

yes


> 
> 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
crash


> 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).
> 
> Regards,
> 
> -- 
>   Nicolas George



> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


-- 
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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140127/768d6dc7/attachment.asc>