mplayer (and all forks) use a single FourCC field to map codecs. This is
what sh_video->format and sh_audio->format is used for. Basically it's a
key into the codecs.conf table to find out what decoder to use. (There's
only one video codec and one major audio codec left - both libavcodec.
But we still have to deal with mapping coming from non-libavformat
demuxers.)
It seems this causes some video codecs to fail, such as WV1F in AVI [1].
demux_lavf generally throws away the codec_tag from libavformat if the
codec is MPEG-in-AVI. There are probably other cases like this. Add a
hack to enforce passing the correct codec tag when only ffmpeg demuxers
and decoders involved.
Note: the sample [1] needs to be flipped. With --demuxer=avi, this is
done correctly, because unlike demux_lavf, the demuxer uses the FourCC
directly for the sh_video->format tag, and finds the correct codecs.conf
entry (which contains the flip flag). We could just add a "whitelist" of
codec tags which can be passed through to sh_video->format, but I don't
want to do that just for such an obscure format as the sample at hand.
Note 2: when demux_lavf is used, the AVCodecContext could be passed
directly to vd_ffmpeg/ad_ffmpeg. The code to convert to/from the
internal mplayer stream headers is probably still needed, as there are
non-ffmpeg demuxers and audio decoders.
[1] http://samples.mplayerhq.hu/V-codecs/WV1F/AVI/title2.avi
Fix check for empty log file (n contains a start offset of 15).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35269 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Add missing ().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35270 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Conflicts:
libmpcodecs/vf_down3dright.c
Add comment to silence coverity (and it generally doesn't
hurt to make intentional fallthrough cases explicit).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35271 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Make uninit function handle vf->priv being NULL.
This happens in the case where memory allocation for it fails.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35272 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Remove useless variable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35273 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Conflicts:
libmpcodecs/vf_softpulldown.c
Make compiler give the ana_coeff array automatically the right size.
Makes adding more colour schemes easier.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35078 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Convert comments into designated initializers.
That is a simple way to ensure they always correspond
to what the compiler actually does.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35079 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Add another anaglyph color variant.
Patch by Bob [mpbob ezpi net].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35080 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Remove outdated code that instead of preventing now causes crashes.
The problem it was trying to catch (next filter not supporting slices)
was fixed already in r10141 (by implementing a fallback version
of vf_next_draw_slice).
This should fix Debian Bug#683907.
Example command-line:
mencoder big_buck_bunny_480p_stereo.avi -o a.mpg -vf crop=346:240:2:24 -oac copy -ovc lavc
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35061 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Conflicts:
libmpcodecs/vf_expand.c
This wasn't used anymore.
Remove the reference to IMGFMT_MJPEG in vf_dlopen as well. Thus format
is used as FourCC in the TV code (i.e. it's on the demuxer level, just
like raw formats), and never appears in the video filter chain. For
starters, vd_ffmpeg can never produce this format.
Fixes for palette allocation handling.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34304 b3059339-0415-0410-9bf9-f77b7e298cf2
This caused a crash with http://samples.ffmpeg.org/cdxl/fruit.cdxl if
direct rendering was used. (Which is rarely these days.)
With small changes: avoid av_freep() use, as this function is not sane.
FFmpeg and Libav are starting to return a growing number of planar samples
when decoding formats that save data like that.
In this first implementation planar formats are immediately converted to
packed formats. Fututre developments should move to use libavresample.
Original work by Nicolas George on mplayer(1).
Most of these have very limited actual use, or are even entirely
useless. They only serve to bloat the codebase and to make life harder.
Drowning users in tons of barely useful filters isn't exactly helpful
either. Some of these filters were redundant or marked as obsolete.
The dlopen and lua (to be added soon) video filters provide ways to add
custom filters.
Detailed listing for each filter with reasons (with contributions from
divVerent and lachs0r):
1bpp:
Replaced by "scale".
2xsai:
Pixel art scaling algorithm, useless with lossy video.
blackframe:
Not very useful. Apparently one use is combining it with scripts,
that pass the
bmovl:
Weirdly complex and insane (using FIFO commands), questionable use.
cropdetect:
Only sort-of useful when used with scripts, and then it will be
very fragile.
It's probably better to use the dlopen rectangle filter, or to
implement the common use-case in a better way.
decimate:
Not needed/useful with modern video codecs, is an
encoding-only filter.
denoise3d:
"hqdn3d" is better.
detc:
Some of the worse deteleciners.
dint:
Useless, actually crashes. (On an assert in vf.c that is disabled
by default in mplayer-svn.)
dvbscale:
Not even practical, and the same effect can be achieved through
other means.
eq:
Worse/older version of eq2.
field:
Limited use, available as dlopen filter.
fil:
Quoting the manpage:
This filter is very similar to the il filter but much faster,
the main disadvantage is that it does not always work.
Especially if combined with other filters it may produce
randomly messed up images, so be happy if it works but do not
complain if it does not for your combination of filters.
filmdint:
Kind of redundant with pullup, and slightly worse.
fixpts:
Never useful. (Most if not all filters have been fixed for PTS.)
framestep:
Questionable use. For things like creating thumbnails, ffmpeg or
--sstep should be used.
geq:
Limited use, will be redundant with the "lua" filter.
halfpack:
Useless, probably redundant with "scale".
harddup:
Useless.
hue:
Most VOs support this.
il:
Useless.
ivtc:
Another of the worse deteleciners.
kerndeint:
A bad deinterlacer.
lavc:
For DVB output devices. We removed that support.
lavcdeint:
A bad deinterlacer, was already deprecated.
Still available as --vf=pp=fd.
mcdeint:
A broken deinterlacer that uses lavc internals.
ow:
Very slow, barely any quality benefit over "hqdn3d".
palette:
Done by "scale".
perspective:
Files with incorrect perspective are extremely rare. About the
only real-world use for this is keystone correction, which is
usually done in hardware by the projector or by graphics
drivers/compositors.
pp7:
Another useless postprocessing filter with bad and complicated code.
Use libpostprocess with "pp" instead.
qp:
Useless.
remove-logo:
Redundant with delogo, which is better and more practical.
rgbtest:
Useless.
sab, smartblur, boxblur:
Blur filters, redundant to "unsharp".
softskip:
Does nothing.
spp, fspp, uspp:
Useless postprocessing filters. "spp" needs ffmpeg internals.
"fspp" is the optimized version of the "spp" filter (???), while
"uspp" is the slow version (????).
Use libpostprocess with "pp" instead.
telecine:
Evil and useless. Available as dlopen filter for testing
purposes.
test:
Useless.
tfields:
Useless, probably.
tile:
Questionable use. Available as dlopen filter.
tinterlace:
Evil and useless.
yuvcsp:
Probably useless.
yvu9:
Redundant with "scale".
Also remove the following left-over files: vd_null.c, vqf.h
Remove a pointless and broken check for avctx->codec->encode.
1) The check does not test for anything useful.
2) AVCodecContext.encode is a private field and is not supposed to be
accessed from outside of lavc.
2a) AVCodecContext.encode does not exist anymore in latest libavcodec,
so this block fails to build.
Otherwise it heavily violates the manpage's description, and describing
what it did before in the documentation is something too complicated to
describe in the English language.
This is done by requesting a buffer from the next filter in the chain, instead
of always allocating our own. This allows the next filter to e.g. ensure its
own preferred memory layout.
This is needed by demux_mpg (and possibly by demux_ts) for PCM playback.
The decoder does the mapping from MPEG headers to the actual PCM format,
and also unpacks sample data for 20/24 bit formats.
Support passing bitmap subtitles to VOs in full RGBA color, and
implement this for libavcodec-decoded subtitle formats on decoding
side and vo_vdpau on display side. Currently this is enabled for PGS
(blu-ray) and DVB subtitles.
VDPAU seems to have sampling issues similar to known GL ones when
drawing a sub-rectangle from a larger texture with scaling, where
adjacent pixels outside the specified source rectangle affect the
result. As the bitmap subtitles may be scaled, add padding support to
the bitmap packer code.
In principle, this could be used for colored DVD subtitles too.
However, the libavcodec DVD decoder lacks parts of the resolution and
palette handling that are present in spudec.c.
Conflicts:
libvo/vo_gl.c
sub/dec_sub.h
sub/sd_lavc.c
The rawaudio demuxer had a rather hard to use way to set the audio
format with the --rawaudio=format=value option. The user had to pass a
numeric value, which then was set as wFormatTag member in the
WAVEFORMATEX header.
Make it use the mplayer audio format (the same as --af=format=value).
Add a new internal pseudo audio codec tag, which is hopefully unused,
which makes ad_pcm use the value in wFormatTag as internal mplayer
audio format.
Playing non-PCM formats is disabled. (At least AC3 can be played
directly.)
No decoder actually used this value (except ad_acm, which was removed a
while ago), so this change shouldn't have any bad consequences.
ad_ffmpeg passes wf to libavcodec decoders, but only the extra data
portion.
This change is needed by the next commit.
This was removed in commit 6a26b4a665. Add it back, because it was
needed by demuxer_rawaudio and for PCM audio with demuxers other than
demux_lavf. (In practice, this broke rawaudio and PCM-in-Matroska only.)
Unlike with raw video, there is no single raw audio "decoder" in
libavcodec. Instead of trying to mess raw audio input into ad_ffmpeg
using a table to map audio formats to the respective libavcodec
decoders, it seems advantageous to simply add back ad_pcm.
This was needed by the now-removed mov demuxer for QuickTime video, or
to be more specific, the Sorenson 3 video codec. QuickTime can
(probably) still decoded by libavcodec, but this field is not needed
for this.
The reference in demux_mkv was apparently for decoding QuickTime in
Matroska, using binary QuickTime codecs (QTX stuff). It's possible that
this has been broken with the binary codecs removal (see commit
aebfbbf2bd), because it removed related code from demux_mkv. On the
other hand, the code section in question was enabled only if binary
win32 codecs were enabled. The win32 codec loader worked on 32 bit x86
only. This means QuickTime-in-Matroska was broken on all other
architectures, including 64 bit x86. Despite being possibly broken on a
major platform, nobody has complained about it yet, and since I couldn't
find a sample of such a mkv file, so don't bother with it.
vo_vdpau and vo_gl cache the last subtitle bitmaps uploaded to video
card in case they stay the same over multiple frames. Detecting
whether the bitmaps have changed and should be re-uploaded was
somewhat fragile. Change the VO API to provide a bitmap ID which can
be compared with what the VO has to determine whether a new upload of
the bitmaps is needed.
Conflicts:
libvo/vo_gl.c
Note: the changes for vo_gl.c were not merged. Instead, eosd_packer is
modified to use the new way of detecting EOSD changes. This takes care
of vo_gl, vo_gl3 and vo_direct3d, which all render EOSD. They don't
need to be updated in turn.
Remove subtitle selection code setting osd->ass_track directly and
vf_ass/vf_vo code rendering the track directly with libass. Instead,
do track selection and rendering with dec_sub.c functions.
Before, mpctx->set_of_ass_tracks[] contained bare libass tracks
generated from external subtitle files. For use with dec_sub.c, it now
contains struct sh_sub instances with decoder already initialized.
This commit breaks the sub_step command ('g' and 'y' keys) for
libass-rendered subtitles. It could be fixed, but it's so useless -
especially as with the existing implementation there's no practical
way to get subtitle delay back to normal after using it - that I
didn't bother.
Conflicts:
command.c
mp_core.h
mplayer.c
To draw libass subtitles, the code used ASS_Renderer objects created
in vf_vo (VO rendering) or vf_ass. They were destroyed and recreated
together with the video filter chain. Change the code to use a single
persistent renderer instance stored in the main osd_state struct.
Because libass seems to misbehave if fonts are changed while a
renderer exists (even if ass_set_fonts() is called on the renderer
afterwards), the renderer is recreated after adding embedded fonts.
The known benefits are simpler code and avoiding delays when switching
between timeline parts from different files (libass fontconfig
initialization, needed when creating a new renderer, can take a long
time in some cases; switching between files rebuilds the video filter
chain, and this required recreating the renderers). On the other hand,
I'm not sure whether this could cause inefficient bitmap caching in
libass; explicitly resetting the renderer in some cases could be
beneficial. The new code does not keep the distinction of separate
renderers for vsfilter munged aspect vs normal; this means that
changing subtitle tracks can lose cache for the previous track.
The new code always sets some libass parameters on each rendering
call, which were previously only set if they had potentially changed.
This should be harmless as libass itself has checks to see if the
values differ from previous ones.
Conflicts:
command.c
libmpcodecs/vf_ass.c
libmpcodecs/vf_vo.c
mplayer.c
sub/ass_mp.c
Remove the following #defines, which should never change in practice:
CONFIG_FAKE_MONO, OUTBURST, FAST_OSD, FAST_OSD_TABLE
The configure script hardcoded these to particular values in config.h.
They could only be changed by manually editing it. I don't think
anyone would want to.
X11_FULLSCREEN
This once did something, but became meaningless years ago and was now
always set to true if the files using it were compiled at all.
Conflicts:
configure
libvo/osd.c
libvo/vo_gl.c
Merged from mplayer2. The OSD defines were already removed in this fork.
af_format.h declares some symbols which are defined in format.c. The
fact that af_format.c is a completely unrelated file is rather
confusing. Having the header and implementation file use the same base
name is more uniform. (af_format.c is the audio conversion filter, while
af_format.h and format.c are about audio formats and their properties.)
Also fix all source files which include this file.
Remove the duplication of image format name lists from codec-cfg.c
and img_format.c. Remove the list of "long" image format names from
img_format.c.
One user visible change is that now mplayer won't print "long" format
names anymore: e.g. instead of "Planar 420P 10-bit little-endian",
the name "420p10le" is used. This is consistent with the names used
by the option parser, and also less noisy.
Partially based on mplayer2 commit f98e47574de15, with some differences.
The <libavutil/avutil.h> stopped including <libavutil/common.h>
recursively in recent ffmpeg/libav git revisions. As a result, some
files no longer got needed definitions, causing a build failure.
Modify #include lines in various files to fix build with the latest
versions of ffmpeg/libav headers.
If either of them is not defined, the old behavior is used:
- the colormatrix is guessed based on resolution.
- the color range is assumed to be tv aka limited range.
Change vd_ffmpeg such that if sh_video->format is a mplayer pixel
format, and there's no other codec information, try to play it as raw
video. (The case of no codec information happens if the "generic" ffmpeg
decoder is instantiated, which is tried last. This means clashes with
actual existing formats are less likely.)
demux_mng did not initialize all fields of the bih, which made vd_ffmpeg
do invalid memory accesses when trying to copy the extradata. Also, use
IMGFMT_RGB32 instead of creating the FourCC directly. (They should be
the same, but what if mplayer changes the IMGFMT_* values.)
This also fixes demux_rawvideo.
Probably all of these are supported by libavcodec. Missing things can
be added back.
Also remove qtpalette.h. It was used by demux_mov.c, and should have
been deleted with commit 1fde09db6f.
Remove the win32 loader - the win32 emulation layer, as well as the
code for using DirectShow/DMO/VFW codecs. Remove loading of xanim,
QuickTime, and RealMedia codecs.
The win32 emulation layer is based on a very old version of wine.
Apparently, wine code was copied and hacked until it was somehow able
to load a limited collection of binary codecs. It poked around in the
code segment of some known binary codecs to disable unsupported win32
API calls to make them work. Example from module.c:
for (i=0;i<5;i++) RVA(0x19e842)[i]=0x90; // make_new_region ?
for (i=0;i<28;i++) RVA(0x19e86d)[i]=0x90; // call__call_CreateCompatibleDC ?
for (i=0;i<5;i++) RVA(0x19e898)[i]=0x90; // jmp_to_call_loadbitmap ?
for (i=0;i<9;i++) RVA(0x19e8ac)[i]=0x90; // call__calls_OLE_shit ?
for (i=0;i<106;i++) RVA(0x261b10)[i]=0x90; // disable threads
Just to show how utterly insane this code is. You wouldn't want even
your worst enemy to have to maintain this. In fact, it seems nobody
made major changes to this code ever since it was committed.
Most formats can be decoded by libavcodecs these days, and the loader
couldn't be used on 64 bit platforms anyway. The same is (probably)
true for the other binary codecs.
General note about how support for win32 codecs could be added back:
It's not possible to replace the win32 loader code by using wine as
library, because modern wine can not be linked with native Linux
programs for certain reasons. It would be possible to to move DirectShow
video decoding into a separate process linked with wine, like the
CoreAVC-for-Linux patches do. There is also the mplayer-ww fork, which
uses the dshownative library to use DirectShow codecs on Windows.
The libavcodec Musepack SV8 decoder returned 2 bytes consumed for 1
byte input, which triggered a crash due to negative input packet size
later. Add a sanity check to prevent crashes with this type of minor
decoder overreads. Also add a check to parser consumed data.
It's not clear why this video filter supported OSD rendering.
The manpage says:
"Can be used for placing subtitles/OSD in the resulting black bands."
But every single VO already does this if vf_expand adds black borders.
This feature is 100% pointless.
This transition to a new VO API started over 4 years ago. It's time to
finally end it, and get rid of the horrible hacks.
Also removes some previously undetected dead code from spudec.c.
unsharp: actually process the frame we got.
Previously it would always process the last frame
allocated, but that might be a different one than the
one first returned.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34975 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Request a sufficiently large image for direct rendering.
Fixes broken video near the borders.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34979 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: ib
Request a sufficiently large image for direct rendering.
Due to alignment and similar, we might need a buffer
larger than the output of the ASS filter.
Fixes out of bound writes and/or broken video near the
borders.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34970 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
Remove unnecessary casts.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34827 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace malloc+memset by calloc.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34828 b3059339-0415-0410-9bf9-f77b7e298cf2
libmad: set i_bps only if it is not already set.
Since that value is only based on the very first MP3 frame,
it is very likely to be much less accurate than any existing
value from a demuxer.
Patch by Benoît Thébaudeau.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34829 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
wm4
reimar
Stefano Pigozzi
Anton Khirnov
Rudolf Polzer
Uoti Urpala
cantabile
mplayer-svn