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).
James Almer
Ganesh Ajjanagadde
Hendrik Leppkes
Michael Niedermayer
Anton Khirnov
Agatha Hu
Luca Barbato
Paul B Mahol
Christophe Gisquet
Vicente Olivert Riera
wm4
Derek Buitenhuis
wang-bin
Vittorio Giovara