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

[Nicolas George]

Le septidi 7 pluviôse, an CCXXII, Lukasz Marek a écrit :
> I don't understand what you mean by "the API should be just that" :)

The user puts a pointer to the AVFrame in AVPacket.data. That is risky,
since AVFrame can not be simply copied (refcounting) and do not behave like
a normal packet payload, and that is why I do not like it.

> I haven't reviewed your patches deeply, so don't ask me about
> details, and I may miss many things, but one remark I had from the
> beginning is that it seems to be much more complex than it can be.
> 
> I expected it to be a single function like:
> 
> int av_format_write_frame(AVFormatContext *s, const AVFrame *frame);
> 
> Function just check if format supports it and it is passed directly
> to output device. After quick look all required params are
> available.
> 
> I assume muxers cannot omit all crazy staff that is done in
> av_write_frame just like that.
> I don't have opinion about leaving this hackery option or not.

Currently we only have audio-only or video-only devices, but it may change
in the future, and the API needs to be able to deal with them.

> I checked Ramiro's patch and I don't understand how it is related TBH.
> I don't understand Ramiro's patch at all TBH :)
> I assume Ramiro tries to remove memcpy from ffmpeg.c, but how it can
> be used outside ffmpeg.c?
> I'm quite tired already and it is to much to read.

You do not need to read the code, the question is about the API.

> Coming back to your solution, in my opinion it is not forth the
> effort to support transcoding. Reasons:
> - Transcoding is usually not real-time operation.
> - I guess transcoding to uncompressed form is rare case
> - Transcoding HD streams to uncompressed form is even more stupid
> and that's the case it would benefit the most (more data to be
> copied for no special reason)
> - I also believe it is a rare to do transcoding on mobile devices,
> embedded systems etc, where these 10% cpu really do matter.

What do you mean about "support transcoding"?

> But I don't want to be an ignoramus, faster transcoding is always
> better than slow one.
> 
> Unfortunately I don't know ffmpeg well at this level so cannot
> propose anything better than simple opinion.

I asked because I seem to remember you wrote a simple lavd-based player, and
that is exactly the kind of use this API is made for. The question is: what
would you consider the most practical API? The two obvious options are:

http://ffmpeg.org/pipermail/ffmpeg-devel/2014-January/153327.html
(just the doxy at the beginning of the file)

and a special encoder / encoder-like function that creates a special
AVPacket that you give to the muxer.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140126/42e4898b/attachment.asc>