It's been argued that the benefits of the current implementation far outweight
those of making the structs opaque.
This deprecation is not present in any release, so it can be safely removed.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This does not trigger any warnings but adds robustness.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The return code here should be checked.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The open syscall can obviously fail, and its return code needs to be
checked.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This should not trigger any warnings; but adds robustness.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
* commit '68e00ad66d13c57d9eb3a3862b44ab3fb030e19f':
w32pthreads: fix mingw build on x86 with -msse2 or higher
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '2d59159508c5c1830cc5da907a9454e229077320':
lavc: AV-prefix a few left out capabilities
Not applied, since this change breaks compilation and is not correct.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'e240a28b20680b326a39b0860fda37d7e459bfc0':
cmdutils: Add auto to threading capabilities report
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
When SSE2 or higher compiler optimizations are used, mingw uses
the _mm_mfence intrinsic for MemoryBarrier, however it doesn't include
the appropriate headers automatically.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Filters which support such changes should be excluded from these checks
Fixes Ticket4884
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When SSE2 or higher compiler optimizations are used, mingw uses
the _mm_mfence intrinsic for MemoryBarrier, however it doesn't include
the appropriate headers automatically.
This does not trigger any warnings, but adds robustness.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This will trigger a few warnings that need to be fixed.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The AVCodecContext.get_format callback is not only used for pixel format
negotiation with the API user, but also for hwaccel init. For the
latter, it's required that some codec parameters, in particular the
codec profile, are set when the callback is invoked.
This patch removes a get_format invocation where this is not guaranteed.
The codec parameters, including the profile, are really set further
below. (The same code path that sets the profile also calls get_format
properly too.)
This just happened to work by coincidence in most cases. For example, if
the API user just copied or reused the AVStream's AVCodecContext when
decoding, the profile would be set properly. But in some cases it
fails., such as with the sample WolfensteinTwitch.mp4 on the samples
server.
Remove the redundant get_format call. Apparently it serves no purpose
anymore, although it is possible that this was different at the time it
was added in commit ffd77f94a2.
This fixes hwaccel usage for API users which do not set the profile
when setting up the AVCodecContext (which is allowed).
Without EXT-X-MAP support we miss the first bytes of some streams.
These streams worked by luck before byte-ranged segment support was added in
da7759b357
Fixes ticket #4797.
Commit ad701326b4 ("avformat/hls: open playlists immediately when
AVDISCARD_ALL is dropped") inadvertently caused first_packet to never be
cleared, causing select_cur_seq_no() to not use the specific code for
live streams.
In practice this means that when the user selects a different audio
track during live stream (i.e. non-VOD) playback, there may be some
additional delay as the code might select an incorrect segment at first,
and we have to wait for video to catch audio (if too late segment was
selected) or to download more following audio segments (if too early
segment was selected).
Fix that by restoring the zeroing of first_packet.
