* commit '1d62ee38894afb696674db78cee8f8d89204a8fe':
movenc: Add a unit test for signaling of the track start times
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This way, it never starts with 0xFFF0, and never trips the
ADTS "Detection" code in movenc.c.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '3eeb7edfc2a1157b7b0e0ce21ac2cd44d55d405b':
movenc: Add a unit test for frag_discont with edit lists
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
All diferences in unit tests have been acounted for.
* commit '59e8ec0aa8ab174701d01a3bfe96fedd0b7fcead':
movenc: Add an API unit test for fragmenting options/calls
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
a set ost->frame_rate does not imply CFR in ffmpeg
The changed fate tests had all wrong packet durations
(like 1/1000 or 1/90000)
There might be more cases in which is_cfr could be set
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also support disabling them as they seem to cause problems to some
Users. They are also not allowed in IRT D-10 thus the default for
mxf_d10 is not to write them
This also decreases the filesize when no user comment are stored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Contrary to the normal fate tests that run via avconv, this tests
nontrivial call sequences that are only doable via the API
(mainly for different corner cases when using the muxer for
segmenting).
The test muxes fake packet data (with extradata that looks
enough like proper data to make the file be viewable with e.g.
boxdumper) and checks the hash of the produced files. The test also
verifies that fragments produced via different call sequences remain
identical (to avoid e.g. updating the output hashes and suddenly
having fragments that used to be identical suddenly diverging), for
fragments written with frag_discont and/or delay_moov.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '3efd71b4d0b4a73ccbbbdc092e6bbd54d92633f4':
avconv: set packet duration for CFR video streams
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The CMP variable seems to have been inherited from fate-api-seek which set it to null
the mxf reference needed a change due to c7e14a279f
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Trim unneeded leading components and trailing zeros.
Move the formating code in a separate function.
Use the function also to format the default value, it was currently
printed as plain integer, inconsistent to the way it is parsed.
Similar to testsrc, but using drawutils and therefore
supporting a lot of pixel formats instead of just rgb24.
This allows using it as input for other tests without
requiring a format conversion.
It is also slightly faster than testsrc for some reason.
Signed-off-by: Steven Robertson <steven@strobe.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For the 10-show-existing-frame, the source file indeed has a timestamp
of 3 (or 100/33) for the second visible frame, so the fix appears to
work correctly. For the other, only the timebase is fixed, but again
appears to be correct now.
This fixes a fate failure after bumping the minor version
Its unknown why this is not needed for the other aac tests,
more investigation needed but for now i dont want to leave
it broken while its investigated
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There were some errors in the calculation as well as an entire
unnecessary loop to find the gain coefficient. Merge the
two loops.
Thanks to @ubitux for the suggestions and testing.
The fate test command line is supposed to serve as an example. It's
nicer to explicitly state the profile rather than setting options
to force it for you.
GCC 3.4 miscompiles it on sunos. Date of release? The second of
August two thousand and five, anno Domini. That's ten years two
months and fourteen days ago. Three thousand seven hundred and
twenty seven days ago. One sixth of the average life expectancy
of a person living in a country with a human development index
of zero point eight hundred and eight, equality adjusted.
GCC 4.3 also miscompiles it, though not as bad.
The LTP encoding and the test is a bit slow currently, taking twice
the amount of time the other tests do, so in the future the
total time to encode might be cut down on that test.
