When the dimensions are the entire frame ones, and the dispose operation
is to reset to background, or the new frame overwrites the new one, then
consider the frame as a key one.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '960aff379da46dcaff61504a57714d4d4e758e41':
lavf: Use wchar functions for filenames on windows for mkdir/rmdir/rename/unlink
Conflicts:
libavformat/os_support.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b9d08c77a44390b0848c06f20bc0e9e951ba6a3c':
lavf: Don't try to update files atomically with renames on windows
Conflicts:
libavformat/dashenc.c
libavformat/hdsenc.c
libavformat/internal.h
libavformat/smoothstreamingenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '40665d27e38e6a2f65037878202bd1a398c7683e':
flvdec: Document how the duration is retrieved at the end of the file
Conflicts:
libavformat/flvdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This makes sure that the internal utf8 path names are handled
properly - the normal file handling functions assume path names
are in the native codepage, which isn't utf8.
This assumes that the tools outside of lavf don't use the mkdir
definition. (The tools don't do the same reading of command line
parameters as wchar either - they probably won't handle all possible
unicode file parameters properly, but at least work more predictably
if no utf8/wchar conversion is involved.)
This is moved further down in os_support.h, since windows.h shouldn't
be included before winsock2.h, while io.h needs to be included before
the manual defines for lseek functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
On windows, rename(2) will fail if the target file exists. On
unix this trick is used to make sure that people reading the file
either will get the full previous file, or the full new version
of the file, but no intermediate version.
Signed-off-by: Martin Storsjö <martin@martin.st>
In order to support multiple IDAT of fdAT chunks following an fcTL one,
transmit all the chunks between two fcTL ones (or between fcTL and IEND
one).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'fe42f94ce1023f9c2f7e86404c60afcee5b078a9':
dashenc: Don't segment all video streams when one stream gets a keyframe
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This makes sure that segments actually start at a keyframe (and
makes sure we don't split segments twice in a row, with one segment
consisting of only a handful of packets), when one stream uses b-frames
while another one doesn't.
Signed-off-by: Martin Storsjö <martin@martin.st>
In current versions of ffmpeg, when streaming to an RTMP server, anytime a packet of type
RTMP_PT_NOTIFY is encountered, the packet is prepended with @setDataFrame before it gets sent
to the server. This is incorrect; only packets for onMetaData and |RtmpSampleAccess should
invoke @setDataFrame on the RTMP server. Specifically, the current bug manifests
itself when trying to stream onTextData or onCuePoint invocations.
This fix addresses that problem and ensures that the @setDataFrame is only prepended
for onMetaData and |RtmpSampleAccess.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f856d9c2f314c493c672dfb9c876da182525da3d':
dashenc: Don't require the stream bitrate to be known
Conflicts:
libavformat/dashenc.c
See: 5f8fcdd4481b3e740d76b09e10a80e3271ef47b5
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Don't write any bitrate attribute if it isn't known. As long as one
doesn't want automatic bitrate switching, playback can work just
fine even if it isn't set.
If strict standard compliance is requested, this is still considered
an error, since the attribute is mandatory according to the spec.
Based on a patch by Rodger Combs.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'fd9badd3cb3b60f5c54dcea35523e1ecca2f67a6':
xwma: Do not leak on failure path
Conflicts:
libavformat/xwma.c
See: 375a0c03a9a401a328a94b3d9f5338ab1524f7ef
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7fd10f66b722eccc2ada9128766d002f6d751f79':
hdsenc: Clear the previous codec tag when setting up the chained muxer
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f918b8a2933a65020cbe490ec637d5485c11a692':
hdsenc: Use the right filename in an error message
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The chained flv muxer wants one set of tags - normally this set
could be signaled via the AVOutputFormat codec_tag field (as
smoothstreamingenc and dashenc do). hdsenc doesn't signal it, since
the FLV codec tag arrays aren't exported from flvenc.c. This can
lead to the caller keeping an original codec tag from the originating
container here, which would then be a mismatch for the FLV muxer.
Since we don't really care about what codec tag the caller might
have set, just clear it and let the lavf muxer layer set the right
one for the chained FLV muxer later instead.
Signed-off-by: Martin Storsjö <martin@martin.st>
If a stream's bitrate is not set, this attempts to use its rc_max_rate;
if neither is set, it avoids writing a bandwidth attribute at all.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Regression since 745730c9c208c40f800d5d71ffa39aceab6ce044.
The dynamic buffer was not being used or freed.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
