Age | Commit message (Collapse) | Author |
|
ffmpeg: change due to revert of a backported commit
|
|
[DXVA] Fix h264 deconding with refs > 11 on recent Intel GPUs (SNB/IVB)
|
|
fix assert when playing certain wma files
|
|
Old Intel GPUs expect the reference frame index to the actual surface,
instead of the index into RefFrameList as specified by the spec.
This workaround should be set when using one of the "ClearVideo" decoder
devices.
|
|
The latest H.264 DXVA specification states that the index in this
structure should refer to a valid entry in the RefFrameList of the picture
parameter structure, and not to the actual surface index.
Fixes H.264 DXVA2 decoding on recent Intel GPUs (tested on Sandy and Ivy)
|
|
|
|
Fixes issue2.ts
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
This reverts commit 55562c856bbcca1b8e1ac1813209de7154570443.
|
|
This reverts commit 72b172ee52103a0f4345051e64a29ad6f5b04cc7.
|
|
|
|
ffmpeg backport: VC-1 DXVA2 improvements / Intel compat
|
|
|
|
Ensuring libbluray doesn't overwrite distro files on non-Darwin systems
|
|
platinum: add all currently applied patches
|
|
Embedded CxImage embeds a copy of libDCR, a fork of dcraw.c, which
contains several denial of service vulnerabilities as discovered by
Raphael Geissert. These seem to affect the CxImage-embedded libDCR as
well.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1438
----
Unspecified vulnerability in dcraw 0.8.x through 0.8.9, as used in
libraw, ufraw, shotwell, and other products, allows context-dependent
attackers to cause a denial of service via a crafted photo file that
triggers a (1) divide-by-zero, (2) infinite loop, or (3) NULL pointer
dereference.
----
Port the fix from libRaw [1] to CxImage copy of libDCR. The patch has
been submitted upstream.
[1]
https://github.com/LibRaw/LibRaw/commit/9ae25d8c3a6bfb40c582538193264f74c9b93bc0
|
|
libdvdnav runs dvdread-config to update CFLAGS and LDFLAGS with libdirs,...
|
|
|
|
|
|
Suggested by heleppkes on https://trac.ffmpeg.org/ticket/3133
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
|
|
|
|
|
|
ffmpeg: Correctly handle cookies that specify a sub-domain.
|
|
|
|
|
|
|
|
fixed: loading of images from urls which don't have an extension...
|
|
Fix two compilation errors.
|
|
|
|
version via our ppa for linux (all other platforms have the right version bundled) - for all non ppa conform distributions the upstream source has to be compiled and installed (if no package for the distribution is provided by the distributor)
|
|
|
|
could result in a buffer overflow.
|
|
ffmpeg removed reference_dts field in struct AVStream.
Related ffmpeg commit:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=2ba68dd044ca8fc591139c05563840f546a9c0c0
|
|
|
|
Upstream commit e10fccf62a36e09b54ad6ea3d5fa6638f298d5ae, for
http://trac.xbmc.org/ticket/13758.
AAC specification has 7.1(wide) as a default layout for 8-channel
streams (channel config 7). However, at least Nero AAC encoder encodes
non-wide 7.1 streams using the default channel config 7, mapping the
side channels of the original audio stream to the second
AAC_CHANNEL_FRONT pair in the AAC stream. Similarly, e.g. FAAD decodes
the second AAC_CHANNEL_FRONT pair as side channels, therefore decoding
the incorrect streams as if they were correct (and as the encoder
intended).
FFmpeg currently decodes such files by-the-spec, i.e. after decoding the
original front pair will be in AV_CH_FRONT_x_OF_CENTER and the original
side pair will be in AV_CH_FRONT_x.
As actual intended 7.1(wide) streams are very rare while misencoded 7.1
files actually exist in the wild, default to assuming a 7.1 layout was
intended unless in strict mode.
Fixes playback of e.g. 8_Channel_ID.m4a in samples.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
[CEC] bump to libCEC 2.1.4
|
|
changelog can be found here: https://github.com/Pulse-Eight/libcec/blob/release/ChangeLog
|
|
|
|
This disables NOHEADER after finding PMT for all programs to
avoid find_stream_info always exhausting probe size for mpegts.
This is very important for live streams since read speed
will be limited. rtsp, udp and any protocol streaming a live
mpegts will have dramatically faster startup time.
Note, lack of codec parameters for streams can still cause
the full probe size to be exhausted.
|
|
|
|
fixed bug where ffmpeg doesn't keep custom http headers when playing hls stream
|
|
|
|
|
|
|
|
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
each project
|
|
|
|
|
|
|
|
|