We can't keep the cc decoder serialized with video decoder.
If the decoding delay between packetizer and video decoder is bigger
than caching (for example when using multi threaded decoder), we will
be too late for the next picture display while we wait for the right
rendering time for the CC.

Close #9049

Fix needed after b71c85b3
Encoders should use i_visible_width / i_visible_height

Refs #9147

Pointed by BtbN on IRC

Fix #9342

Implements INFO LIST chunk.
See OpenDML spec.

Current RIFF header builder was working with static sizes and
was unable to handle extra metadata.

This will also save more than 9.5KB on most files.

Close #9275 #9328
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Suggestion from funman

This should be more resilient to updates.

Fixes #9217

Close #9329

copy/paste...

This patch should fix this sample:
http://samples.ffmpeg.org/A-codecs/g726-test1.wavSigned-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The broadcom omx implementation has a vendor extension to fetch pixel aspect
information from the decoder. Use this to pass proper aspect information with
the pictures.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

Handle changes of aspect ratio through the Control handler.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

Makes version 1.14 happy.

There is no use to CPU memory edges when decoding in hardware (arguably
libavcodec should be "enhanced" to not add them in that case).
This unbreaks VDPAU.

Some browsers, such as Firefox, are very picky about WebM streams needing to
start with a keyframe. To be able to handle this correctly when streaming,
the avformat mux needs to mark keyframe-containing blocks (or clusters, in
Matroska terminology) as such even after they have been muxed. The next patch
in the series will make httpd actually care about this flag.

Unfortunately, as avformat does not actually propagate this status, we need
to use some heuristics to figure out which blocks contain keyframes. The natural
thing to do would be to say that when we write a keyframe, the block that comes
back has to be a keyframe block, but the WebM/Matroska muxer thwarts this by
having its own internal buffering of clusters, flushing the _previous_ cluster
when we send it a keyframe. Thus, we need to explicitly send a flush (a NULL
packet) before the one that comes back when we mux a keyframe.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The previous value, 32 kB, causes formats like WebM to overflow
and split the blocks, which has negative consequences for streaming.
We're unlikely to have a memory crunch in this area, so increase it
to something generous.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>