* commit '3f4edf012593c73941caa0ef9b292da00225c3df':
dump_stream: print the timebase as is, do not reduce it
See: 75511c293a
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It makes more sense to print the timebase exactly as it is set. Also,
this avoids a divide by zero when av_dump_format() is called on a format
context before writing the header.
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>
As indicated in the function documentation, the header MUST be
checked prior to calling it because no consistency check is done
there.
CC:libav-stable@libav.org
It seems it is more secure to simply duplicate the computing routine from compute_pkt_fields to estimate_timings_from_pts.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '194be1f43ea391eb986732707435176e579265aa':
lavf: switch to AVStream.time_base as the hint for the muxer timebase
Conflicts:
doc/APIchanges
libavformat/filmstripenc.c
libavformat/movenc.c
libavformat/mxfenc.c
libavformat/oggenc.c
libavformat/swf.h
libavformat/version.h
tests/ref/lavf/mkv
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd754ed41727b1fcbab335b510248a9758a73320c':
riffenc: take an AVStream instead of an AVCodecContext
Conflicts:
libavformat/nutenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f792d3cbb8e8e35c54a9358a55dd596b7a40f228':
lavf: add the notimestamps flag to the muxers missing it
Conflicts:
libavformat/adtsenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cfbdd7ffbd9fe14d110fd1bb89bf52f0f7bde016':
rtpenc: base max_frames_per_packet on avg_frame_rate, not codec timebase
Merged-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).
It has not been properly maintained for years and there is little hope
of that changing in the future.
It appears simpler to write a new replacement from scratch than
unbreaking it.
* commit '711aa2a82727907f778fb8aa9a93aff2120170f2':
lavf: dump stream side data when probing
Conflicts:
libavformat/dump.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2dc265619a2fc9c6f9aff7ac2bcdbcb90e9610cb':
lavf: group dump functions together
Conflicts:
libavformat/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
