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

[Lukasz Marek]

On 26.01.2014 19:59, Nicolas George wrote:
> 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've been thinking about some kind of special device that could be feed 
with packets from 2 different streams (audio and video) and it would 
internally handle 2 specified devices. This is just an idea now, but you 
mention that. I'm not sure it would require any special treatment.

>> 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"?

To provide safe API that would allow transcoding without hacks/doing 
crazy things. I thought the discussion is about it, if not then ignore.

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

Yes, I did. From the developer point of view first solution is more 
convenient, but if the second one is just about calling one more 
function and there is nothing more to worry about then it is also OK.

The thing I would pay attention is to make easy switch for "old fashion" 
way and new way. For example user may switch audio device from device X 
to device Y and it should take as less as possible things to do, 
assuming one device supports new way and the other not. Not sure it is 
related to the second solution, not for first one I think.

-- 
Best Regards,
Lukasz Marek

Royale with Cheese.