See ffmpeg doc:
https://www.ffmpeg.org/doxygen/2.7/group__lavu__sampmanip.html#ga4db4c77f928d32c7d8854732f50b8c04

See ffmpeg doc:
https://www.ffmpeg.org/doxygen/3.0/group__lavc__picture.html#ga40412936f5777964c0c80b1742ec58ef

Will be used when calling refFrame.

Symmetry with refFrame.

To keep symmetry with allocateAVFrame private method.

* Same behavior as before.
* But this call is explicitly mention in the documentation.

* The way to reference other frame in ffmpeg/libav is tricky. For
example, if src is not reference counted, new buffers are allocated and
the data is copied. And this case leads us to memory leaks in our
program!
* See the code:
https://www.ffmpeg.org/doxygen/2.6/frame_8c_source.html#l00278
* Because we do not reference a lot of frames in our code, to avoid an
overhead of complexity this commit removes these methods.
* Instead, we copy the data.

* According to the doc, for each new stream added, the user should call
avcodec_close and avformat_free_context.
* See the doc:
https://www.ffmpeg.org/doxygen/3.0/group__lavf__core.html#gadcb0fd3e507d9b58fe78f61f8ad39827

* This is a common case, without filters added.
* This avoid a copy of the data of each encoded frame.

Because we are using ffmpeg/libav functions, we should use ffmpeg/libav
structures too.

* A data buffer is not allocated by default in the constructor.
* Frame is now an abstract class: easier to call allocateData and
freeData methods.
* Depending on the case, we could manipulate frame with data allocated
elsewhere. For example, an empty frame is given to a decoder, which is
responsible to allocate and free the data buffers.

* Remove protected method inherited from ITransform.
* Add the same series of test for the video and the audio transform.

In that case, the data buffer of the generated data should be allocated
manually.

* Solution: keep the original description when the frame was created,
and use it to reallocate it when needed.
* No need to check and reallocate data in the generators.

Because the common case is to allocate the data at the same time as the
frame itself, this commit adds a default parameter to the constructor of
Video/Audio frames.

This info can be found from elsewhere, and the method is not so used.

… space

…pace

* IFrame is an abstract class.
* To keep the naming convention of the project, rename it to IFrame.

* Less code to maintain.
* Rename assign methods to assignBuffer and assignValue (to avoid
 implicite C++ cast and so calling the wrong method).

* The data buffer of the frame should be freed before allocate a new
buffer.
* The new buffer should be allocated using malloc instead of free, since
ffmpeg/libav uses free to deallocate the data. The valgrind error was:
"Mismatched free() / delete / delete []".

…wrap stream

In a demultiplexing case, the buffer should be allocated by us, but only
once (not in the decodeNextFrame method)!

The number of channels and the channel layout is already correctly set
by the StreamTranscoder.

In this case, the buffer of decoded data should be manually allocated,
and freed when it is the decoder's turn.

* If the buffer of filtered data is too small: reallocate it.
* If the buffer of transformed data is too small: reallocate it.

…channel

…size

No real impact in the process, because we only check that "decodedSize"
is not equal to 0. But it is more accurate :)

…fers

…iplexing

In case of audio demultiplexing, we allocate the data buffer, so we
should not reallocate it when we switch to a generator.