codec/decoder/audio: impl Iterator for Audio::decode

[trlim]

This is not for merge but for a discussion.

ffmpeg document says "Some decoders may support multiple frames in a single AVPacket" and this is true for APE/WMA Lossless audio streams I have.
(Maybe it can also be true for some "video" decoders)

But there seems to be no way to handle such case because current API doesn't return size of Packet bytes consumed.

This PR is to show what things to be done for this case by implementing an iterator.
For me, a major problem of this implementation is allocating frame::Audio on every iteration.

Want to hear your opinion or suggestion on how we can improve the API.

[trlim]

Another problem of this implementation is that as packet is borrowed as mutable by iterator, it cannot be borrowed immutable inside the loop.

[meh]

I think it would be better if the packet was borrowed immutably, and then copied over, then these two attributes modified in place in the internal packet.

[meh]

To avoid this, you could create and put the frame inside the AudioFrameIter itself, then you wouldn't need to create a new one on each iteration.

[trlim]

Used unsafe code to make internal copy of AVPacket. This is to avoid packet.clone() which seems to be expensive.

[meh]

Can't you just use clone_from?

[trlim]

Because av_copy_packet has some overhead which I think unnecessary but no problem to change it if you prefer.

[trlim]

A problem here is the wrapped frame can live longer than the original frame.

[trlim]

From more investigation, I concluded that allocating a new frame on every iteration is the most safe, simple and cheapest because AVFrame is designed to be heap allocated only and it is what av_frame_ref or av_frame_copy expect, so I'm reverting it.
I also replaced unsafe packet copy with clone_from.

[meh]

An option to avoid frame reallocations is to give an &mut audio::Frame created by the user to the iterator.

[trlim]

I tried this but couldn't make it work.

impl Audio {
    pub fn decode_iter<'a, 'b, 'c>(&'a mut self, packet: &'b Packet, frame: &'c mut frame::Audio)
	-> AudioFrameIter<'a, 'b, 'c> {
    ...
}

pub struct AudioFrameIter<'a, 'b, 'c> {
    frame: &'c mut frame::Audio,
    ...
}

impl<'a, 'b, 'c> Iterator for AudioFrameIter<'a, 'b, 'c> {
    type Item = Result<Option<&'c mut frame::Audio>, Error>;
    fn next(&mut self) -> Option<Self::Item> {
        ...
	error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements
	    Some(Ok(Some(self.frame)))
                    ^^^^^^^^^^^^^^^^
        ...
    }
}

I found a discussion on similar problem which I don't fully understand but only gives me a feeling I'm trying something Rust doesn't allow.
Am I trying the method you are telling?

[meh]

The Item shouldn't contain the frame, since the user already has it.

[trlim]

Ah yes, but then it will make the iterator less useful and I would prefer not to change current implementation in that case.
I think it might be helpful if we can have additional type which can carry a reference of frame in cheap and safe way.
Current implementation of Dictionary seems to do something similar by Ref and Mut.