[FFmpeg-devel] [RFC] avdevice/lavfi: output wrapped AVFrames

Timo Rothenpieler timo at rothenpieler.org
Sun Jul 3 16:40:51 EEST 2022


On 03.07.2022 15:19, Nicolas George wrote:
> Timo Rothenpieler (12022-06-29):
>> The lavfi avdevice as it is right now can't output "special frames"
>> like hardware frames.
>> This patch makes the lavfi avdevice output wrapped AVFrames instead
>> of copying the actual data, greatly simplifying it in the process.
> 
> Thanks for the patch. I am not familiar with the hardware frame
> infrastructure, but this patch makes the whole code much simpler, and
> assumedly more efficient to boot. That makes it worth it for that reason
> alone.

Make sure to take a look at the non-RFC version of this patch I sent.
It sadly is a bit more complex again, since wrapped avframes only work 
for video frames after all.
But copying audio data is not nearly as heavy weight as copying whole 
video frames.
Plus, there are no hardware-audio-frames.

> If it also allows to use hardware frames, even in a limited or fragile
> way, it is a bonus. I do not see how anybody could object.
> 
>> I am not at all sure if this has some unexpected consequences.
>> It works just fine with ffmpeg.c, but it might be an ABI break for
>> potential library consumers?
> 
> I think the case can be made for both positions: on one hand, an
> application should not assume a demuxer will output any kind of frame
> and should be ready for wrapped AVFrame; on the other hand, devices are
> special and somebody who uses a specific device on purpose may make
> assumptions on its behavior.
> 
> I think this case is fringe enough that we can accept the break, at
> least if the device only outputs normal frames by default, not hardware
> frames.

Yeah, I'm also leaning in that direction.
And full proper implementation won't care what kind of packets come out 
of it.
Plus I can't really think of any API consumer that'd possibly implement 
a lavfi.c based device and then also hardcodes the assumption what kind 
of packets it outputs.

So once the issue Michael discovered is ironed out, I'd be inclined to 
apply it, after some more testing.


More information about the ffmpeg-devel mailing list