When only SPS or PPS is present in the stream, copy the missing one from
AVCC before insertion to the output stream.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If we setup AVIO interrupt callback and it will be returns 1 on socket
timeouts and we try to connect to non-existing streams on some servers
(like nginx-rtmp) we got FD leak.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2cd7c99498b1bcb450c328459cf85a686ce83456':
h264: reset ret to avoid propagating minor failures
See: 47048aa30b
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When AVFMT_FLAG_NOBUFFER is set, the packets are not added to the
AVFormatContext packet list, so they need to be freed when they are
no longer needed.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This also un-does the fate changes from a52f443714b5c2a40ed272d8445f4c39220a4b69,
leaving this fix without even small differences in the output, that is
a sample for which this makes a vissible difference is very welcome
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes CID1194380
There are no vissible differences in the changed fate samples. Only
a tiny number of pixels change by tiny amounts in the frames i checked
If someone has a file that shows a vissible difference, please post it.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The -hls_allow_cache parameter enables explicitly setting the
EXT-X-ALLOW-CACHE tag in the manifest file. That tag indicates
whether the client MAY or MUST NOT cache downloaded media
segments for later replay.
Valid values are 1 (=YES) or 0 (=NO) and the EXT-X-ALLOW-CACHE
will not show in the manifest for other values (or if
-hls_allow_cache is not used.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '551746680462538bb5ad7adf55fb1248190428ec':
configure: Provide a safe default for unknonw libcs
Conflicts:
configure
This is not merged as it does not work with musl here, while
our previous solution does.
See: 170e2fd7c3
Merged-by: Michael Niedermayer <michaelni@gmx.at>
After this the order from the original file is stored through readorder
when doing ffmpeg -i input.ass -c copy output.mkv.
And now that the ASS muxer honors the ReadOrder, extracting the ass back
(without transcoding) restores the original order.
This is more robust and should avoid false positives in coverity
That is if the type is ever mixed up, after this patch that would
just be a null pointer dereference instead of a random possibly
out of array access
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Jeffrey Wescott
Michael Niedermayer
Clément Bœsch
Benoit Fouet
Alexander Drozdov
Justin Ruggles
Luca Barbato
Timothy B. Terriberry
Reimar Döffinger
Joakim Roubert
Thilo Borgmann
lvqcl
Christophe Gisquet
Paul B Mahol