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>
This is consistent with stdio and is what we want to do in all cases.
Fixes a bug in the voc muxer which didn't flush in write_trailer()
previously. This is the cause of the change in the test results.
After some internal talks it seems the code is similar to what is in FFmbc
by Baptiste Coudurier; Baptiste accepted to relicense the similiar chunks
from GPL to LGPL.
Some demuxers set a timecode in the format or streams metadata. The
muxers now make use of this metadata instead of a duplicated private
option.
This makes possible transparent copy of the timecode when transmuxing
and transcoding.
-timecode option for MPEG1/2 codec is also renamed to -gop_timecode. The
global ffmpeg -timecode option will set it anyway so no option change
visible for the user.
Support Main Profile at High 1440 Level in MXF container,
using essence coding label from SMPTE RDD 9, table 6.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>