[FFmpeg-devel] [PATCH 2/5] ffmpeg: use the write_uncoded_frame() API.
george at nsup.org
Sun Jan 26 19:59:00 CET 2014
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
> 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:
(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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel