If regularly parsing new chan atoms (as in rtpdec_qt), but the
chan atoms don't actually contain any channel layout, don't reset
the value that the caller has filled in (by guessing).
Signed-off-by: Martin Storsjö <martin@martin.st>
It is included for the open/read/write/close functions. On
MSVC, where this header does not exist, the same functions
are provided by io.h, which is already included.
On windows, these functions are provided by io.h. Make sure
io.h is included if it exists, regardless of the setmode
function.
Signed-off-by: Martin Storsjö <martin@martin.st>
Conflicts:
configure
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
unistd.h used to be required for gethostname. On windows, gethostname
is provided by winsock2.h. Now network.h includes both unistd.h and
winsock2.h if they exist.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes crashes when called from rtpdec_qt, where
AVFormatContext->pb is null, a crash present since 3bab7cd128.
Signed-off-by: Martin Storsjö <martin@martin.st>
Make internal small_strptime() function public, and use it in place of
strptime().
This allows to avoid a dependency on strptime() on systems which do not
support it.
In particular, fix trac ticket #992.
This fixes stream lookup in flv demuxer. When used with librtmp
protocol streams are sometimes added after head arrived. If the
first stream added in flv header reader is Audio stream then it
is messed with Video stream added later in the code patched.
The result is I have 2 Audio streams (first of them is said to have
a video codec like h264) instead of Audio/Video pair.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
After much discussion and back-and-forth, we reached the conclusion
that matroska uses convergence_duration for subtitle duration because
a 32bit value isn't large enough to store the duration if sub-micro-second
timebases are used. Matroska may not be the only one that supports these
timebases, but it's certainly the only one that ffmpeg attempts to support
in this way.
The long term solution that we seemed to reach was that if we encounter
a matroska file with a sub-micro-second timebase, we should internally
scale it up to at least micro-second, and then duration can be used
normally. This suggests that on the encode side, we should not allow
generation of files with sub-micro-second timebases, but that's a separate
issue.
That being a non-trivial change, and the subtitle interoperability breakage
being very real, I'm re-submitting this small change for consideration.
In this diff, we make sure that duration is populated by the matroska
demuxer, and that convergence_duration is respected in matroskaenc and
srtenc, but that duration is used otherwise. This ends up being a strict
improvement - pipelines that use convergence duration are unchanged, and
ones that are currently broken due to the duration mismatch will start
working - except for the ones with the extreme timebases, but those were
already broken.
Signed-off-by: Philip Langdale <philipl@overt.org>