If the sdp is generated before the rtp muxer is initialized
(e.g. as when called from the rtsp muxer), this has to be done,
otherwise the rtp muxer doesn't know that the input really is
in mp4 format.

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Also remove redundant parentheses.

Signed-off-by: Martin Storsjö <martin@martin.st>

If an annex b bitstream is muxed into mov, the actual written
sample is reformatted to mp4 syntax before writing.

Currently, the RTP hints that copy data from the normal video
track, where the payload data might be offset compared to the
original sample that the RTP hinting used (when 3 byte
annex b startcodes have been converted into 4 byte mp4 format
startcodes).

Signed-off-by: Martin Storsjö <martin@martin.st>

It's not supposed to be set outside of lavc. Set r_frame_rate and
avg_frame_rate instead.

Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

It had become dead code when code was added to avoid
exporting audio and video codec id as metadata.
Untested due to lack of sample.

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

fixes Bug 119

It is a really bad idea to assign a video codec id
when we have set codec_type to audio and vice versa.

Fixes ticket #721.

Also fixes a memleak.

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

like SOX

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

original order is retained within the same tag or codec id to maintain the
muxing/demuxing priority.

This implements reading the tag in the demuxer and adds support for writing it
in the muxer. Some example channel layout tables for muxing are included for
ac3, aac, and alac, but they are not utilized yet.

Use Sound Sample Description Version 2 for all MOV files.
Updated FATE references accordingly.
Note that ADPCM is treated as compressed audio in version 2.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

No, ive no testcase, i just spoted these when looking ...

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This adds OPAtom support and proper seeking.
D-10 and non-seekable OP1a streams still use the old demuxing/seeking code.

This replaces the old essence_offset code

These values include KAGSize, HeaderByteCount and IndexByteCount.
The length of the pack itself is also stored, and KAGSize is sanity checked.
The FATE sample has KAGSize == 0, which is adjusted to 512.
Other bad KAGSizes are set to 1.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This isn't an error. It's also expected behavior for OPAtom files.

The information is relevant, but under normal circumstances
it raises far too many false alarms.

Signed-off-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This also zeroes new entries for good measure (used by future patches).

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Specifically, this means parsing as before until we run into essence.
At that point we seek to the footer and parse until EOF. After that we start
seeking backward to the previous partition and parse that until we run into
essence or the next partition. This procedure is repeated until we encounter
the last partition we parsed in the forward direction.

The end result of all this is that large essence containers aren't needlessly
parsed. This speeds up parsing large files a lot.

This fixes 0001GL.MXF.V1.mxf_opatom.mxf and 0001GL00.MXF.A1.mxf_opatom.mxf
getting two streams each due to both using the same SourcePackageID.

Reviewed-by: Baptiste Coudurier