| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'a871ef0cc936612bdb0e643196be72efcf0c8986':
hwaccel: Rename priv_data_size to frame_priv_data_size
Conflicts:
libavcodec/avcodec.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
This describes more accurately what this field is for.
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* qatar/master:
mpegvideo: operate with pointers to AVFrames instead of whole structs
Conflicts:
libavcodec/h261dec.c
libavcodec/h263dec.c
libavcodec/intrax8.c
libavcodec/mpeg12enc.c
libavcodec/mpegvideo.c
libavcodec/mpegvideo.h
libavcodec/mpegvideo_enc.c
libavcodec/mpegvideo_motion.c
libavcodec/mpegvideo_xvmc.c
libavcodec/msmpeg4.c
libavcodec/ratecontrol.c
libavcodec/vaapi.c
libavcodec/vc1dec.c
libavcodec/vdpau_vc1.c
See: fc567ac49e17151f00f31b59030cd10f952612ef
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The most interesting parts are initialization in ff_MPV_common_init() and
uninitialization in ff_MPV_common_end().
ff_mpeg_unref_picture and ff_thread_release_buffer have additional NULL
checks for Picture.f, because these functions can be called on
uninitialized or partially initialized Pictures.
NULL pointer checks are added to ff_thread_release_buffer() stub function.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This gets rid of aliasing completely unrelated structs to Picture.
Fixes the remaining compilation warnings in the vdpau code.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '7948a51b5c3d08e1a1173442a7ff72b220def303':
vdpau: don't assume Picture and H264Picture are the same
Conflicts:
libavcodec/vdpau.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code passed H264Picture* and Picture*, and assumed the
hwaccel_picture_private field was in the same place in both
structs. Somehow this happened to work in Libav, but broke in
FFmpeg (and probably subtly breaks in Libav too).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit 'c2f7417eeb9cc31f75e71f7be2780f90f1628d7e':
vc1: move MpegEncContext.resync_marker into VC1Context.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| | |
The field still remains in MpegEncContext because it is used by the
mpeg4 decoder.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently the code passes some nonsense values as
references instead, causing corruption with NVidia's
and assertion failures with Mesa's implementation.
For non-corrupted input this mostly happens in
interlaced bitstreams, e.g.
http://samples.mplayerhq.hu/V-codecs/WMV9/interlaced/480i30__codec_WVC1__mode_2__framerate_29.970__type_2__preproc_17.wmv.
The != VDP_INVALID handle assert does not trigger
(and probably is quite nonsense) because the frames
are initialized to 0.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
|
|\ \
| |/
| |
| |
| |
| |
| | |
* commit '2852740e23f91d6775714d7cc29b9a73e1111ce0':
vdpau: store picture data in picture's rather than codec's context
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| | |
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '582963a8156522582e55466be4a59974a8d909a5':
vdpau: Fix VC-1 interlaced mode
Conflicts:
libavcodec/vdpau_vc1.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| | |
VDPAU expects the bitstream value (0, 2 or 3).
libavcodec uses an enum (0, 1 or 2).
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* qatar/master:
h264: deMpegEncContextize
Conflicts:
libavcodec/dxva2_h264.c
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
libavcodec/h264_loopfilter.c
libavcodec/h264_mb_template.c
libavcodec/h264_parser.c
libavcodec/h264_ps.c
libavcodec/h264_refs.c
libavcodec/h264_sei.c
libavcodec/svq3.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Most of the changes are just trivial are just trivial replacements of
fields from MpegEncContext with equivalent fields in H264Context.
Everything in h264* other than h264.c are those trivial changes.
The nontrivial parts are:
1) extracting a simplified version of the frame management code from
mpegvideo.c. We don't need last/next_picture anymore, since h264 uses
its own more complex system already and those were set only to appease
the mpegvideo parts.
2) some tables that need to be allocated/freed in appropriate places.
3) hwaccels -- mostly trivial replacements.
for dxva, the draw_horiz_band() call is moved from
ff_dxva2_common_end_frame() to per-codec end_frame() callbacks,
because it's now different for h264 and MpegEncContext-based
decoders.
4) svq3 -- it does not use h264 complex reference system, so I just
added some very simplistic frame management instead and dropped the
use of ff_h264_frame_start(). Because of this I also had to move some
initialization code to svq3.
Additional fixes for chroma format and bit depth changes by
Janne Grunau <janne-libav@jannau.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* commit '246da0b13551b1f80f067e4f258e5bd691f5ab33':
v4l2: avoid pointless indirection.
vdpau: Add VC-1 decoding via hwaccel infrastructure
vdpau: Add H.264 decoding via hwaccel infrastructure
Conflicts:
configure
libavcodec/Makefile
libavcodec/version.h
libavdevice/v4l2.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|