summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mplayer: remove Linux RTC supportwm42012-07-304-112/+14
| | | | | | | This used /dev/rtc for timing. /dev/rtc root only by default, and I have a hard time believing that the standard OS functions are not good enough. (Even if not, support for POSIX high resolution timers should be added instead, see clock_gettime() and others.)
* configure, mp_msg.h: get rid of MP_DEBUGwm42012-07-302-14/+1
| | | | | | | | | | The function mp_dbg() was silent if MP_DEBUG was not defined. MP_DEBUG was defined only if configure was invoked with --enable-debug. Remove it and make mp_dbg an alias to mp_msg. This has the advantage tha --enable-debug changes less. (It only adds -g now and disables stripping the binary on installation.) Using log levels is the better way to silence annoying debug messages.
* sub: remove unrar_execwm42012-07-306-490/+0
| | | | | This removes the ability to open compressed bitmap subtitles from rar files. The code makes me afraid, and I never needed this feature.
* mplayer: remove crash handler stuffwm42012-07-304-266/+0
| | | | | | | | | | | | | | | | | | | | mplayer tries to catch all signals by default, and displays a "nice" crash message if a signal is caught. This is mostly useless for diagnosing problems, and it's extremely fragile. It's likely to cause more harm than it possibly solves. Also remove the current_module variable, which was supposed to give a hint which submodule was being run. This was far from accurate or useful. mplayer also caught SIG_CHILD, and tried to wait for any children. This potentially gets rid of zombies, but I'm not sure which ones. The only places that fork(), cache2.c and unrar_exec.c, seem to wait for their child processes properly. Just get rid of it. Note that we don't even catch SIGTERM. Maybe this will have to be added back in order to re-enable screensavers and such when the user terminates mplayer with ^C on the terminal.
* vf_scale: don't pass CPU flags anymorewm42012-07-305-18/+6
| | | | | | libav detects them automatically. Also fix a bunch of other VFs, which use the get_sws_cpuflags() function defined by vf_scale.c.
* Rip out 3DNOW supportwm42012-07-3013-270/+6
| | | | | | | | Ancient AMD specific enhancement to the MMX instruction set. Officually discontinued by AMD. Note that support for this was already disabled in the previous commit. This commit removes the actual code.
* Remove compile time/runtime CPU detection, and drop some platformswm42012-07-3022-1615/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer had three ways of enabling CPU specific assembler routines: a) Enable them at compile time; crash if the CPU can't handle it. b) Enable them at compile time, but let the configure script detect your CPU. Your binary will only crash if you try to run it on a different system that has less features than yours. This was the default, I think. c) Runtime detection. The implementation of b) and c) suck. a) is not really feasible (it sucks for users). Remove all code related to this, and use libav's CPU detection instead. Now the configure script will always enable CPU specific features, and disable them at runtime if libav reports them not as available. One implication is that now the compiler is always expected to handle SSE (etc.) inline assembly at runtime, unless it's explicitly disabled. Only checks for x86 CPU specific features are kept, the rest is either unused or barely used. Get rid of all the dump -mpcu, -march etc. flags. Trust the compiler to select decent settings. Get rid of support for the following operating systems: - BSD/OS (some ancient BSD fork) - QNX (don't care) - BeOS (dead, Haiku support is still welcome) - AIX (don't care) - HP-UX (don't care) - OS/2 (dead, actual support has been removed a while ago) Remove the configure code for detecting the endianness. Instead, use the standard header <endian.h>, which can be used if _GNU_SOURCE or _BSD_SOURCE is defined. (Maybe these changes should have been in a separate commit.) Since this is a quite violent code removal orgy, and I'm testing only on x86 32 bit Linux, expect regressions.
* fastmemcpy.h: remove code duplicationwm42012-07-301-28/+2
| | | | | | | Remove the mem2agpcpy_pic function, which is obviously duplicated from the other function in this file. Untested, as this is only used by the directx and directfb2 VOs.
* libvo: remove custom assembler memcpy implementations (aka fastmemcpy)wm42012-07-305-713/+6
| | | | | | | | | | | | | | aclib[_template].c contained inline assembler versions of memcpy using MMX/SSE/3dnow etc. instructions. It's possible that this gave quite a speed a decade ago, but it's unlikely to have any use on modern systems. Also, libc implementations already have their own optimizations for the native memcpy function. I did not verify my assumptions eith benchmarks, so I could be wrong. Also note that some platforms have extremely crappy libc implementations, and it's well possible that these might suffer from a major performance loss (hello Windows). Unfortunately, I do not care.
* configure: remove pointless checks for yasm etc.wm42012-07-292-166/+7
| | | | | | | | | | mplayer doesn't use yasm, as or ranlib. They were only needed to build with internal libav, which is gone. Also, get rid of nm. nm was used to find out how external symbols are mangled. Replace this by a platform check in mangle.h. As far as I know, sane systems don't mangle symbols. Windows prefixes them with an underscore ("_symbol"). I don't know about OSX.
* Change version stringwm42012-07-293-5/+4
| | | | | | | | | | | | | | Change the "main" name from "mplayer2" to "mplayer". Note that upstream mplayer2 uses "MPlayer2", and mplayer uses "MPlayer", so it's unambiguous. The version.sh script used to put the latest tag into the version script. The intention was to add a new tag on each release, but this hasn't been done in over a year, making the tag absolutely pointless. Remove it. Now "git-SHORTHASH" is used. Remove the string "MPlayer & mplayer2 teams" after the copyright date, because that sounded silly.
* ad_faad: include neaacdec.h instead of faad.hwm42012-07-282-2/+2
| | | | | The faad.h header printed a warning that this header is outdated. The header neaacdec.h is probably the proper header, so use that.
* bstr: rename bstr() function to bstr0(), and typedef bstr to struct bstrwm42012-07-2825-95/+91
| | | | | Replace all uses of bstr() with bstr0(). Also remove the ridiculous C++ workaround.
* configure: disable win32 emulation by defaultwm42012-07-281-2/+2
| | | | | | | | | | | | | | The win32 emulation code can be used to load Windows binary codecs. Unfortunately, this code is extremely whacky and unmaintained. It consists of an ancient copy of wine, that was hacked to death and back. It does super-whacky stuff like patching the loaded codecs at fixed memory offsets to make them work. Not removing yet, because it still has some limited use, and some of the code is needed to load codecs when running natively on Windows. (Actually, I only care because mplayer can get video input from the webcam of that-one-latop under Windows, which I find far too neat to just kill all the code.)
* osd: osd_font.h -> osd_font.pfbwm42012-07-284-546/+7
| | | | | | osd_font.pfb is an actual font file extracted from osd_font.h. file2string.py is used to turn it back into a header during the build process.
* TOOLS/fil2string.py: fix for use with binary fileswm42012-07-281-1/+1
| | | | | | | | | | The script was written to be able to deal with binary files, but it had a bug corrupting some data: e.g. a byte sequence 0x1 0x37 was printed as "\17" (0x1 = escaped as "\1", and 0x37 = kept as literal "7"), which would be interpreted as single character 0xF. Always pad octal literals to length 3, which makes the escape sequences unambiguous.
* osd: remove freetype font rendering codewm42012-07-2814-2827/+58
| | | | | | | | | | | | The previous commit made libass the default OSD renderer. This commit removes the disabled freetype renderer completely. The commits were done separately to make rolling back easier, because using libass for OSD rendering is a risky choice. Also remove freetype/fontconfig/fribidi code. This is all done by libass now. If mplayer is compiled without libass, no OSD is displayed.
* osd: use libass for OSD renderingwm42012-07-2823-1110/+1508
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OSD will now be rendered with libass. The old rendering code, which used freetype/fontconfig and did text layout manually, is disabled. To re-enable the old code, use the --disable-libass-osd configure switch. Some switches do nothing with the new code enabled, such as -subalign, -sub-bg-alpha, -sub-bg-color, and many more. (The reason is mostly that the code for rendering unstyled subtitles with libass doesn't make any attempts to support them. Some of them could be supported in theory.) Teletext rendering is not implemented in the new OSD rendering code. I don't have any teletext sources for testing, and since teletext is being phased out world-wide, the need for this is questionable. Note that rendering is extremely inefficient, mostly because the libass output is blended with the extremely strange mplayer OSD format. This could be improved at a later point. Remove most OSD rendering from vo_aa.c, because that was extremely hacky, can't be made work with osd_libass, and didn't work anyway in my tests. Internally, some cleanup is done. Subtitle and OSD related variable declarations were literally all over the place. Move them to sub.h and sub.c, which were hoarding most of these declarations already. Make the player core in mplayer.c free of concerns like bitmap font loading. The old OSD rendering code has been moved to osd_ft.c. The font_load.c and font_load_ft.c are only needed and compiled if the old OSD rendering code is configured.
* Add support for playing video from streaming sites with libquviwm42012-07-284-2/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This enables playing URLs from libquvi supported streaming sites directly, e.g. "mplayer http://www.youtube.com/watch?v=...." Anything opened with mplayer is checked with libquvi. If it looks like a URL of a supported streaming site, libquvi is used to extract the media URL, which is then passed to the lower level mplayer code instead of the HTML URL. Hopefully the libquvi URL checker works well enough that it doesn't cause any problems with normal URLs, files, or whatever else mplayer's stream layer accepts. Add the --libquvi-format option. the option value is directly passed to libquvi as requested format. The only values that seem to work for any streaming site seem to be "best" (best quality) and "default" (lowest quality). The mplayer option defaults to "best" (overriding libquvi's default). Outstanding issues: - Does libquvi checking every opened file really not cause problems? Should there be a runtime option to disable libquvi use? (Probably not an issue.) - Should we check/set the supported protocol? By default libquvi has support for all protocols enabled. In the worst case, it might return an URL using a protocol not supported by mplayer, even though it could extract URLs with other protocols too. (Probably not an issue.) - Somehow export metadata (like media title) to the mplayer frontend?
* commands: add show_tracks_osd command to display audio and subtitle tracks ↵wm42012-07-284-0/+87
| | | | | | | | | on OSD The command lists the audio and subtitle tracks in the current file on the OSD. It also marks the currently active streams. Video streams are not shown, as files with more than one video stream are exceedingly rare.
* commands: add show_chapters_osd command to display chapters on OSDwm42012-07-284-0/+48
| | | | | | | | The command lists the chapters in the current file on the OSD. It also marks the current chapter. This is actually a cheap replacement for the chapter select libmenu functionality.
* osd: enable line breaking for OSD textwm42012-07-281-31/+67
| | | | | | | | OSD text wider than the window will be broken to fit the width. The line breaking algorithm is naive and intended as temporary, until the OSD render code is possibly replaced by "something better". Newline characters are also considered.
* core: change format of time properties to match the OSD time formatwm42012-07-281-11/+11
| | | | | | | Time property values converted to strings via M_PROPERTY_PRINT resulted in a string different to what the OSD displays (if the OSD level is >= 2). Change it to match the OSD.
* libvo, libao: remove useless video and audio output driverswm42012-07-2851-20674/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of these have only limited use, and some of these have no use at all. Remove them. They make maintainance harder and nobody needs them. It's possible that many of the removed drivers were very useful a dozen of years ago, but now it's 2012. Note that some of these could be added back, in case they were more useful than I thought. But right now, they are just a burden. Reason for removal for each module: vo_3dfx, vo_dfbmga, vo_dxr3, vo_ivtv, vo_mga, vo_s3fb, vo_tdfxfb, vo_xmga, vo_tdfx_vid: All of these are for very specific and outdated hardware. Some of them require non-standard kernel drivers or do direct HW access. vo_dga: the most crappy and ancient way to get fast output on X. vo_aa: there's vo_caca for the same purpose. vo_ggi: this never lived, and is entirely useless. vo_mpegpes: for DVB cards, I can't test this and it's crappy. vo_fbdev, vo_fbdev2: there's vo_directfb2 vo_bl: what is this even? But it's neither important, nor alive. vo_svga, vo_vesa: you want to use this? You can't be serious. vo_wii: I can't test this, and who the hell uses this? vo_xvr100: some Sun thing. vo_xover: only useful in connection with xvr100. ao_nas: still alive, but I doubt it has any meaning today. ao_sun: Sun. ao_win32: use ao_dsound or ao_portaudio instead. ao_ivtv: removed along vo_ivtv. Also get rid of anything SDL related. SDL 1.x is total crap for video output, and will be replaced with SDL 2.x soon (perhaps), so if you want to use SDL, write output drivers for SDL 2.x. Additionally, I accidentally damaged Sun support, which made me completely remove Sun/Solaris support. Nobody cares about this anyway. Some left overs from previous commits removing modules were cleaned up.
* Makefile: remove unused rule for mplayer-nomain.owm42012-07-281-3/+0
|
* Makefile: move dependency rules for autogenerated fileswm42012-07-281-7/+5
| | | | | | | | | | | Explicit dependency rules are needed when a source file depends on an autogenerated file. Move these rules to the same place in the Makefile as the rules for creating the generated files. Also, change the rules to declare the direct dependency, not a transitive one (e.g. codecs.conf.h is needed by codec-cfg.c, not codec-cfg.o). In practice, this shouldn't change anything, but it's cleaner.
* Remove QTX testswm42012-07-283-215/+2
| | | | Whatever.
* Makefile: clean upwm42012-07-281-29/+2
| | | | There were some targets left for stuff removed in previous commits.
* Rename DOCS/tech/ to DOCS/OUTATED-tech/wm42012-07-2823-5/+1
| | | | | | | | | | While DOCS/tech/ contains lots of documentation about mplayer's internals, most of it seems outdated, and hasn't been touched in many years. On the other hand, there still might be useful things in there, but it's hard to tell which parts. Instead of deleting all it, rename the directory to "warn" potential developers that the documentation is completely outdated.
* Remove DOCS/xmlwm42012-07-2819-3757/+0
| | | | | | This contained _some_ documentation, but it was all old, crappy, barely maintained. Even if it was maintained, uau hasn't merged back changes for years.
* TOOLS: remove useless crapwm42012-07-2831-5245/+0
| | | | | | | | | | | | | | | | | | | | Most of the scripts in TOOLS seem entirely useless. Remove them. There were about 3 types of scripts: - apparent developer tools (like file format dumpers, benchmarks) => I doubt any mplayer developer still alive even uses these - helpers for encoding or ripping stuff => mencoder is gone, at least from this version of mplayer - helpers meant for users (launching mplayer in weird ways, etc.) => just no, it will cause you more pain than gain So no, there is nothing useful. Under the scripts not deleted, these are needed for building mplayer: file2string.py matroska.py vdpau_functions.py These might have _some_ use (but still questionable): binary_codecs.sh checktree.sh
* Remove TOOLS/realcodecswm42012-07-2810-3903/+0
| | | | | | | I have no idea what these are about, but it's probably useless outdated crap. According to TOOLS/README, they are wrappers around some Real binary codecs. They were added in 2003, and never touched again (except for cosmetic changes).
* Remove ancient kernel device driverswm42012-07-2815-8277/+0
| | | | | | These were device driver kernel modules for certain prehistoric graphic cards. The source code indicates these are written against early 2.4 kernels.
* build: remove bin_to_header.py and use TOOLS/file2string.py insteadwm42012-07-283-46/+5
| | | | | | TOOLS/file2string.py was recently added upstream, so bin_to_header.py is not needed anymore. Also fix vo_gl3.c, since file2string.py works slightly different from my script.
* Merge remote-tracking branch 'origin/master'wm42012-07-28159-217652/+753
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .gitignore bstr.c cfg-mplayer.h defaultopts.c libvo/video_out.c The conflict in bstr.c is due to uau adding a bstr_getline function in commit 2ba8b91a97e7e8. This function already existed in this branch. While uau's function is obviously derived from mine, it's incompatible. His function preserves line breaks, while mine strips them. Add a bstr_strip_linebreaks function, fix all other uses of bstr_getline, and pick uau's implementation. In .gitignore, change vo_gl3_shaders.h to use an absolute path additional to resolving the merge conflict.
| * vo_sharedbuffer: remove from autoprobe listStefano Pigozzi2012-07-271-3/+3
| | | | | | | | | | | | This video output is headless and only intended to work with GUIs explicitly asking for it. This makes it useless to have it in the autoprobe list.
| * vo_corevideo, vo_sharedbuffer: put private state in vo->privStefano Pigozzi2012-07-272-81/+77
| | | | | | | | | | | | | | These VOs were already using a struct for all private data but the struct variable itself was static. Change them to store the address in vo->priv. Also change them to use the new automatic private data allocation and option parsing mechanism.
| * demux_rawdv.c: fix change missing from recent 8079f4ff821Uoti Urpala2012-07-271-1/+0
| | | | | | | | | | | | | | | | | | | | | | Like vd_vfw.c fixed earlier, demux_rawdv.c was also missing a change needed for the "flags"->"keyframe" demux packet field rename. This broke compilation with libdv enabled. Hopefully there aren't more cases. It's hard to reliably check for references in files that aren't compiled in the local tree if they use different base variable names, as the "flags" name itself is used for many unrelated things.
| * vo_vdpau: disable refresh-aware frame timing when compositedUoti Urpala2012-07-273-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under a compositing window manager the current VDPAU implementation behaves differently than without it. Frame flip timing info becomes incorrect (I guess it only reflects when the frame was sent to the compositor, not when it was actually shown), and there is no limitation to at most one frame switch per refresh like without compositing. Detect whether a compositing window manager is active and disable refresh-aware frame timing and dropping in this case, similarly to what fps=-1 would do. This behavior can be controlled with the new suboption "composite-detect". Disabling the refresh-aware logic makes timing somewhat less accurate. Because the video switch rate limit isn't there, the lack of frame dropping on player side does not impose a hard limit on video FPS, but does reduce performance somewhat as redundant frames are drawn in memory. The existence of a compositing window manager does not guarantee that the current window is actually composited, so the current check is not foolproof. In particular, some WMs have support for a "unredirect fullscreen windows" option. Support for such things could be improved.
| * options: support "no-foo" syntax for flag suboptionsUoti Urpala2012-07-271-6/+23
| | | | | | | | | | | | | | Allow using "no-foo" as an alternative to "foo=no" for flag suboptions, similarly to what top-level flag options already support. This means things like "--lavdopts=no-fast" or "--vo=vdpau:no-chroma-deint" are now supported.
| * demux_lavf: use lavf for RealMedia (.rm) files by defaultUoti Urpala2012-07-261-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | RealMedia was listed as a format for which the internal demuxer (demux_real) was preferred over lavf. The original reason for this (lavf failing to give any timing information for some video frames) has been fixed in libavformat since. Make demux_lavf the preferred demuxer for RealMedia. The libavformat demuxer does still have issues. COOK audio initially misbehaves after a seek (inconsistent timestamps, audio remaining from the before-seek position). However, the internal demuxer seemed to be _consistently_ out of sync with a test file. I haven't done thorough testing, but the internal demuxer does not seem less buggy.
| * vd_vfw.c: fix part missing from previous commitUoti Urpala2012-07-261-2/+3
| | | | | | | | | | | | vd_vfw.c was missing a change to rename field used from 'flags' to 'keyframe'. This broke compilation with 32-bit Windows codec support enabled.
| * demux, vd_ffmpeg: fix demux keyframe flag, set AV_PKT_FLAG_KEYUoti Urpala2012-07-2520-82/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was some confusion about the "flags" field in demuxer packets. Demuxers set it to either 1 or 0x10 to indicate a keyframe (and the field was not used to indicate anything else). This didn't cause visible problems because nothing read the value. Replace the "flags" field with a boolean "keyframe" field. Set AV_PKT_FLAG_KEY based on this field in packets fed to libavcodec video decoders (looks like PNG and ZeroCodec are the only ones which depend on values from demuxer; previously this was hardcoded to true for PNG). Make demux_mf set the keyframe field in every packet. This matters for PNG files now that the demuxer flag is forwarded to libavcodec. Fix logic setting the field in demux_mkv. It had probably not been updated when adding SimpleBlock support. This probably makes no difference for any current practical use.
| * video, audio: use lavc decoders without codecs.conf entriesUoti Urpala2012-07-2413-202/+175
| | | | | |