add xdecode for reuse Frame object

[magicbear]

add xdecode function for decoding to reuse Frame Object, prevent python GC using large of memory.

demo:

import av

in_container = av.open(file="test.flv", format='flv')

for packet in in_container.demux():
	if packet.stream.type == "video":
		for frame in packet.stream.codec_context.xdecode(packet):
			print(frame, frame.format)
	elif packet.stream.type == "audio":
		for frame in packet.stream.codec_context.xdecode(packet):
			print(frame, frame.format)

[magicbear]

this patch is for prevent python memory leak at long term usage, tested when using original decode method, after 100000 frames for 1080p uyvy422, will be using about 6g~10g memory, the python cannot automate to release the memory, after the patch, the memory is not remarkable growth.

[mikeboers]

What happens if you add a periodic gc.collect() instead?

Or... if you really want this explicit ability, a Frame.deref() method would be reasonable.

[magicbear]

What happens if you add a periodic gc.collect() instead?

Or... if you really want this explicit ability, a Frame.deref() method would be reasonable.

because of using for realtime signal processing, when using gc.collect, will cause the program make about 20~50ms latency, will cause drop frame. reuse the frame will be a better way to do this, and more closer the ffmpeg official usage example.

[mikeboers]

My immediate reaction is that I don't like making changes to enable real-time processing with demands that I feel are somewhat antithetical to Python in general. I know that I'm coming from a place of having already written PyAV and dealt with all the FFMpeg library, but it really wouldn't be that big of a deal for someone to make a module that just does a tight decode loop and doesn't expose anything except the final buffers as fast as possible.

But... if we can do it in a manner that doesn't put a burden (either real, or on the developers, or on the sensibilities of the API) then I'm not really against it.

So, I'm not keen on a new set of methods for this.

I'd be keen on a Frame.deref() or Frame.free() method, but that is still going to be creating a new Python Frame object. To be fair, this PR does not re-use Packet objects, and so you still have a the burden of having those objects.

[magicbear]

the memory and cpu usage between xdecode and unref/free for same code run after 1000 seconds.

[jlaine]

@magicbear could you give this PR a try please?

#516

Instead of changing the API this PR aims to make VideoFrame more gc-friendly so that memory can automatically be reclaimed.

[mikeboers]

Closing due to inactivity (not responding to jlaine above), conflicts with develop, and because I don't like how much duplicated code there is. If this remains a big deal we can look into passing a Frame into the decode methods to use.