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

libavformat/utils.c:2165:2: warning: label ‘fail’ defined but not used

704af3e29c broke publishing
of rtmp streams, at least publishing to Wowza servers.

This changes all invoke commands to use nb_invokes.

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

Inspired by a patch from Michael Root
Idea-by: Baptiste Coudurier
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

Its checked a few lines below too.
The only difference is that empty atoms with size=0 will now get parsed too.

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

was enough space to read the 32bit size.

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

The computed size doesn't contain the header size because it's already
skipped by incrementing total_size, but then it's skipped again in the
last line. The atom comes out 8 bytes short and the function
mov_read_chan() aborts the whole parsing process. I think the computed
size should be atom.size - total_size + 8.

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

This is just cosmetic as the if() is always true.

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

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

Reviewed-by: Baptiste Coudurier
Tested-with-QT: Baptiste Coudurier
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

malloc() is allowed to return NULL when zero is the argument. This
causes us to think malloc has failed and return AVERROR(ENOMEM). In
addition OS X malloc() returns an unfreeable non-NULL pointer for size
zero when alignment is greater than 16.

Fixes regressions caused by 30c3d976

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

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

Signed-off-by: David Goldwich <david.goldwich@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: David Goldwich <david.goldwich@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: David Goldwich <david.goldwich@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

instead of when the 2nd stream has been found.
This isnt ideal as we will likely still like before miss a data stream.

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

Fixes ticket #673.

Input: 01-Untitled-partial.oma
ZZUF params: zzuf[s=7157,r=0.001]

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

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