This is the maximum rate possible based on the frame size limit of MXF D-10
Previous version reviewed by tim nicholson <nichot20@yahoo.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Previous version Reviewed-by: tim nicholson <nichot20@yahoo.com>
Previous version Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Previously unset, and some software mishandles files if it is absent
Signed-off-by: Tim Nicholson <tim.nicholson@bbc.co.uk>
Reviewed-by: tomas.hardin@codemill.se
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes a crash, when trying to mux h264 into mxf_opatom.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Previous version reviewed-by: tomas.hardin@codemill.se
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Reviewed-by: tomas.hardin@codemill.se
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
To keep h264 parsing simple and fast, I used the framesize for selecting the right Panasonic codec label. The framesize is fixed for Panasonic AVC Intra.
This patch only supports AVCI50/100. But in all flavours, i.e. with no SPS/PPS in header.
Reviewed-by: tomas.hardin@codemill.se
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
gmtime isn't thread safe in general. In msvcrt (which lacks gmtime_r),
the buffer used by gmtime is thread specific though.
One call to localtime is left in avconv_opt.c, where thread safety
shouldn't matter (instead of making avconv depend on the libavutil
internal header).
Signed-off-by: Martin Storsjö <martin@martin.st>
None of these are likely unless the user is writing a file with two billion
streams or a duration of around two months.
CC: libav-stable@libav.org
Bug-Id: CID 700568 / CID 700569 / CID 700570 /
CID 700571 / CID 700572 / CID 700573
Approved-by: Tomas Härdin <tomas.hardin@codemill.se>
Approved-by: tim nicholson <nichot20@yahoo.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There are interoperability issues with D-10 related to the channelcount property in the generic sound essence descriptor.
On one side, SMPTE 386M requires channel count to be 4 or 8, other values being prohibited.
The most widespread value is 8, which seems straightforward as it is the actual size of the allocated structure/disk space.
At the end, it appears that some vendors or workflows do require this descriptor to be 8, and otherwise just "fail".
On the other side, at least AVID and ffmpeg do write/set the channel count to the exact number of channels really "used",
usually 2 or 4, or any other value. And on the decoding side, ffmpeg (for example) make use of the channel count for probing
and only expose this limited number of audio streams
(which make sense but has strong impact on ffmpeg command line usage, output, and downstream workflow).
At the end, I find it pretty usefull to simply give ffmpeg the ability to force/set the channel count to any value the user wants.
(there are turnaround using complex filters, pans, amerge etc., but it is quite boring and requires the command line to be adapted to the input file properties)
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Previously, AVStream.codec.time_base was used for that purpose, which
was quite confusing for the callers. This change also opens the path for
removing AVStream.codec.
The change in the lavf-mkv test is due to the native timebase (1/1000)
being used instead of the default one (1/90000), so the packets are now
sent to the crc muxer in the same order in which they are demuxed
(previously some of them got reordered because of inexact timestamp
conversion).
Use it instead of checking CODEC_FLAG_BITEXACT in the first stream's
codec context.
Using codec options inside lavf is fragile and can easily break when the
muxing codec context is not the encoding context.
None of these are likely unless the user is writing a file with two billion
streams or a duration of around two months.
This fixes CIDs 700568, 700569, 700570, 700571, 700572 and 700573.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The field is intended to overflow and have only its low 16bits stored.
This commit avoids the implicit truncation and clarifies that its
intended and not a bug
S326m section 7.6 ("Continuity count"):
> The continuity count word consists of 2 bytes allow-
> ing a number to be created by a modulo 65536
> counter (bits C15 to C0 in figure 7). The continuity
> count shall increment by 1 for each newly transmit-
> ted content package with the same SDTI source and
> destination addresses. The continuity count may
> be used to detect whether the content package
> sequence has been broken by an operation such as
> a routing switch.
Approved-by: Tjoppen
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Michael Niedermayer
Hendrik Leppkes
Michael Niedermayer
Carl Eugen Hoyos
Vittorio Giovara
Mark Reid
Tim Nicholson
Andreas Cadhalpun
Robert Krüger
Diego Biurrun
wm4
Thomas Mundt
Martin Storsjö
Tomas Härdin
Benoit Fouet
Gaullier Nicolas
Anton Khirnov
Alexandra Khirnova
Paul B Mahol