Otherwise, during error conditions, the caller will be left with
dangling pointers to a destructed packet => boom.
BUG=242786
TEST=ffmpeg_regression_tests
Commit slightly simplified by commiter
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b3ea76624ad1baab0b6bcc13f3f856be2f958110':
vf_aspect: use the name 's' for the pointer to the private context
Remove commented-out debug #define cruft
Conflicts:
libavcodec/4xm.c
libavcodec/dvdsubdec.c
libavcodec/ituh263dec.c
libavcodec/mpeg12.c
libavfilter/avfilter.c
libavfilter/vf_aspect.c
libavfilter/vf_fieldorder.c
libavformat/rtmpproto.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* cigaes/master:
lavf/matroskaenc: return an error for unsupported types.
lavf/concatdec: remove invalid check for AVSEEK_FLAG_BACKWARD.
lavf: filter out AVSEEK_FLAG_BACKWARD in new API.
lavf: call the new seek API from the old.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
If the demuxer implements read_seek2() and not read_seek(),
call avformat_seek_file() from av_seek_frame().
Allow to properly seek in formats that only implement the
new API from applications that use the old one.
Tested with mplayer and a concat script.
When a file appears to start with a id3 tag and appears to
also be something else, then try to increase the probe buffer
size if its below its limit.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
To avoid allocating ridiculous amounts of memory for corrupted files,
read the input in chunks limited to filesize or an arbitrary large
amount when that is not known (chosen to be 50M).
As far as I can tell the code should not change behaviour
depending on locale in any of these places.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Fix trac ticket #2300 because the duration of the segments
was computed using the timestamp of the last packet plus its
duration using the 1/90000 default time base instead of using
the chained muxer time base.
* qatar/master:
lavf: Add a fate test for the noproxy pattern matching
lavf: Handle the environment variable no_proxy more properly
Conflicts:
libavformat/Makefile
libavformat/internal.h
libavformat/tls.c
libavformat/utils.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 4a8fc1d83b.
The commit caused null pointer derefernces when using udp://
after i fixed that it caused ffmpeg to get stuck and remapped
arguments like ?ttl=255 -> ?ttl%3d255
I dont want to leave this broken thus temporary revert so we all
have some time to look at this without half the network protocols
being broken in the meantime
The handling of the environment variable no_proxy, present since
one of the initial commits (de6d9b6404), is inconsistent with
how many other applications and libraries interpret this
variable. Its bare presence does not indicate that the use of
proxies should be skipped, but it is some sort of pattern for
hosts that does not need using a proxy (e.g. for a local network).
As investigated by Rudolf Polzer, different libraries handle this
in different ways, some supporting IP address masks, some supporting
arbitrary globbing using *, some just checking that the pattern matches
the end of the hostname without regard for whether it actually is
the right domain or a domain that ends in the same string.
This simple logic should be pretty similar to the logic used by
lynx and curl.
Signed-off-by: Martin Storsjö <martin@martin.st>
Michael Niedermayer
Anton Khirnov
Dale Curtis
Diego Biurrun
Nicolas George
Paul B Mahol
Carl Eugen Hoyos
Reimar Döffinger
Senthilnathan M
Martin Storsjö