summaryrefslogtreecommitdiffstats
path: root/libmpcodecs
Commit message (Collapse)AuthorAgeFilesLines
* video, audio: use lavc decoders without codecs.conf entriesUoti Urpala2012-07-246-62/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for using libavcodec decoders that do not have entries in codecs.conf. This is currently only used with demux_lavf, and the codec selection is based on codec_id returned by libavformat. Also modify codec-related terminal output somewhat to make it use information from libavcodec and avoid excessively long default output. The new any-lavc-codec support is implemented with codecs.conf entries that invoke vd_ffmpeg/ad_ffmpeg without directly specifying any libavcodec codec name. In this mode, the decoders now instead select the libavcodec codec based on codec_id previously set by demux_lavf (if any). These new "generic" codecs.conf entries specify "status buggy", so that they're tried after any specific entries with higher-priority status. Add new directive "anyinput" to codecs.conf syntax. This means the entry will always match regardless of fourcc. This is used for the above new codecs.conf entries (so the driver always gets to decide whether to accept the input, and will fail init() if it can't find a suitable codec in libavcodec). Remove parsing support for the obsolete codecs.conf directive "cpuflags". This directive has not had any effect and has not been used in default codecs.conf since many years ago. Shorten codec-related terminal output. When using libavcodec decoders, show the libavcodec long_name field rather than codecs.conf "info" field as the name of the codec. Stop showing the codecs.conf entry name and "vfm/afm" name by default, as these are rarely needed; they're now in verbose output only. Show "VIDEO:" line at VO initialization rather than at demuxer open. This didn't really belong in demuxer code; the new location may show more accurate values (known after decoder has been opened) and works right if video track is changed after initial demuxer open. The vd.c changes (primarily done for terminal output changes) remove round-to-even behavior from code setting dimensions based on aspect ratio. I hope nothing depended on this; at least the even values were not consistently guaranteed anyway, as the rounding code did not run if the video file did not specify a nonzero aspect value.
* ad_mpg123: update libmpg123 API useThomas Orgis2012-05-071-167/+81
| | | | | | Improve ad_mpg123, including use of the more efficient framewise decoding with mpg123 version 1.14 or later (older versions are still supported).
* ad_ffmpeg: switch to avcodec_decode_audio4()Uoti Urpala2012-04-191-69/+112
| | | | | | | | | | | | | | | | | Switch libavcodec audio decoding from avcodec_decode_audio3() to avcodec_decode_audio4(). Instead of decoding directly to the output buffer, the data is now copied from the libavcodec output packet, adding an extra memory copy (optimizing this would require some interface changes). After libavcodec added avcodec_decode_audio4() earlier, it dropped support for splitting large audio packets into output chunks of size AVCODEC_MAX_AUDIO_FRAME_SIZE or less. This caused a regression with the previous API: audio files with huge packets could fail to decode, as libavcodec refused to write into the AVCODEC_MAX_AUDIO_FRAME_SIZE buffer provided by mplayer2. This occurrend mainly with some lossless audio formats. This commit restores support for those files; there are now no fixed limits on packet size.
* timeline: subs: keep subtitle tracks in source timeUoti Urpala2012-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Timeline handling converted the pts values from demuxed subtitles to timeline scale. Change the code to do most subtitle handling in original subtitle source pts, and instead convert current playback timeline pts to those units when deciding which subtitle to show. The main functionality changes are that now demuxed subtitles which overlap chapter boundaries are handled correctly (at least for libass subtitles), and external subtitles are assumed to use same pts scale as current source (this needs improvements later). Before, a video subtitle that had a duration continuing past the end of the chapter would continue to be shown for the original duration, even if the chapter ended and playback switched to a position in the source where the subtitle shouldn't exist. Now, the subtitle will correctly end. Before, external subtitle files were interpreted as specifying pts values in timeline scale. Now, they're interpreted as specifying pts values in source file time scale, for _every_ source file. This is probably more likely to be what the user wants for the "main" source file in case there is one, but almost certainly not quite right for multiple source files where the same subs could be shown over different scenes. If the user wants them to match some main source file, it's probably still better to have incorrect extra subs for video from some files than to have every subtitle appearing at the wrong time. The new code makes it easier to change the interpretation of the subtitle times, and some configurability should be added in the future.
* cosmetics: vf_vo.c: reformatUoti Urpala2012-03-251-102/+107
|
* cosmetics: misc minor cleanupsUoti Urpala2012-03-253-11/+1
| | | | | The deleted ZRM* things were only relevant to vo_zr, which was deleted earlier.
* windows support: unicode filenameswm42012-03-091-0/+2
| | | | | | | | | | | | | | | | | | | Windows uses a legacy codepage for char* / runtime functions accepting char *. Using UTF-8 as the codepage with setlocale() is explicitly forbidden. Work this around by overriding the MSVCRT functions with wrapper macros, that assume UTF-8 and use "proper" API calls like _wopen etc. to deal with unicode filenames. All code that uses standard functions that take or return filenames must now include osdep/io.h. stat() can't be overridden, because MinGW-w64 itself defines "stat" as a macro. Change code to use use mp_stat() instead. This is not perfectly clean, but still somewhat sane, and much better than littering the rest of the mplayer code with MinGW specific hacks. It's also a bit fragile, but that's actually little different from the previous situation. Also, MinGW is unlikely to ever include a nice way of dealing with this.
* cleanup: Silence compilation warnings on MinGW-w64wm42012-03-014-7/+6
| | | | | | | | | | | | | | | | | | | Some of the code, especially the dshow and windows codec loader parts, are extremely hacky and likely full of bugs. The goal is merely getting rid of warnings that could obscure more important warnings and actual bugs, instead of fixing actual problems. This reduces the number of warnings from over 500 to almost the same as when compiling on Linux. Note that many problems stem from using the ancient wine-derived windows headers. There are some differences to the "proper" windows header. Changing the code to compile with the proper headers would be too much trouble, and it still has to work on Unix. Some of the changes might actually break compilation on legacy MinGW, but we don't support that anymore. Always use MinGW-w64, even when compiling to 32 bit. Fixes some warnings in the win32 loader code on Linux too.
* configure, build: support compiling without libpostprocUoti Urpala2012-02-271-0/+2
| | | | | | libpostproc has been removed from Libav and the library now exists as a separate project. Because it's not essential, separate it from the Libav library check and allow compiling without it.
* vd_ffmpeg: fix flushing of buffered framesUoti Urpala2012-02-031-3/+0
| | | | | | | | | The vd_ffmpeg decode() function returned without doing anything if the input packet had size 0. This meant that flushing buffered frames at EOF did not work. Remove this test. Have the core code skip such packets coming from the file being played instead (Libav treats 0-sized packets as flush signals anyway, so better assume such packets do not represent real frames with any codec).
* vd_ffmpeg: adjust buffered frame count based on threads againUoti Urpala2012-02-031-0/+2
| | | | | | | | | Libav has changed back to not modifying avctx->has_b_frames based on the extra buffering caused by thread use. Add back the code to do the adjustment on the player side once again. The timing mode using the buffering info is no longer the default, so in most cases having this right or not won't matter for playback.
* build: switch to libavutil bswap.h and intreadwrite.hUoti Urpala2012-02-019-11/+19
| | | | | | | | | | | | Remove the private bswap and intreadwrite.h implementations and use libavutil headers instead. Originally these headers weren't publicly installed by libavutil at all. That already changed in 2010, but the pure C bswap version in installed headers was very inefficient. That was recently (2011-12) improved and now using the public bswap version probably shouldn't cause noticeable performance problems, at least if using a new enough compiler.
* Update Libav API usesUoti Urpala2012-02-014-44/+30
| | | | | | | | | | | | | | | | | | | Change various code to use the latest Libav API. The libavcodec error_recognition setting has been removed and replaced with different semantics. I removed the "--lavdopts=er=<value>" option accordingly, as I don't think it's widely enough used to be worth attempting to emulate the old option semantics using the new API. A new option with the new semantics can be added later if needed. Libav dropped APIs that were necessary with all Libav versions until quite recently (like setting avctx->age), and it would thus not be possible to keep compatibility with previous Libav versions without adding workarounds. The new APIs also had some bugs/limitations in the recent Libav release 0.8, and it would not work fully (at least some avcodec options would not be set correctly). Because of those issues, this commit makes no attempt to maintain compatibility with anything but the latest Libav git head. Hopefully the required fixes and improvements will be included in a following Libav point release.
* vd_ffmpeg: explicitly set thread count even if 1Uoti Urpala2012-01-171-2/+1
| | | | | | | | | | | Libav started automatically enabling threaded decoding a while ago. This is not safe, as it means callbacks can suddenly get called from other threads and outside calls to libavcodec. We need to know when threading will be used and disable thread-unsafe callbacks in those cases. Explicitly set thread count to 1 instead of leaving it at 0 (which triggers the autodetection) when we are not requesting more threads; this should make sure that autodetection on libavcodec side will not be used.
* ad_ffmpeg: pass packet side data from libavformatUoti Urpala2012-01-081-13/+26
| | | | | Pass avpacket->side_data when using a libavcodec audio decoder together with libavformat demuxer (this was already done for video).
* vf_fspp: make compile without Libav internalsUoti Urpala2012-01-022-9/+7
| | | | | Make vf_fspp compile without using internal Libav/FFmpeg files and compile it by default.
* Libav API updates (remove most deprecated-in-0.7 uses)Uoti Urpala2011-12-222-19/+3
| | | | | | | | Update various code using Libav libraries to remove use of API features that were deprecated at Libav release 0.7. I think this removes them all with the exception of URLContext functions still used in stream_ffmpeg.c (at least other uses that generated deprecation warnings with libraries from 0.7 are removed).
* configure, build: require at least Libav 0.7Uoti Urpala2011-12-222-8/+1
| | | | | | | | | | | | | | | | Require versions of the Libav libraries corresponding to Libav release 0.7. These are: libavutil 51.7.0 libavcodec 53.5.0 libavformat 53.2.0 libswscale 2.0.0 libpostproc 52.0.0 Also disable the fallback to simple header check if these libraries could not be found with pkg-config; now compiling without pkg-config support for these always requires explicitly setting --enable-libav and any needed compiler/linker flags. The simple check would have let compilation proceed even if a version mismatch was detected.
* vf_expand: always clear the added borderswm42011-12-191-93/+20
| | | | | | | | | | | | | | | | | | | | | | | | Using the "expand" filter makes the image area larger by adding borders to the video frame. These borders are supposed to be always black. The filter relied on the borders in its output buffer staying black without redrawing them for each frame. However, when using direct rendering, a video filter inserted after vf_expand can draw into these borders, for example the "unsharp" and "ass" filters. These changes incorrectly stayed visible in the the following video frames. Fix this by always clearing the borders in vf_expand. In some cases, this might be more work than necessary, but vf_expand has no way of detecting whether a subsequent filter draws into the borders or not, and this avoids fragile assumptions about the existing contents of the output buffer(s). This also deals with frame size changes when config() is called again. Before this commit, remains of the old video were visible if the new video frame size was smaller than before. Since we now always clear the borders, there's no more need for the complicated code that cleared only the regions that were covered by the OSD. Delete that.
* vf_dsize, vf_scale: fix behavior on multiple config() callswm42011-12-192-19/+26
| | | | | | When config() is called multiple times (e.g. aspect ratio changes while the same file is playing), the user settings are not honoured, because config() overwrites them. Don't do that.
* vf_dsize: cleanup identation (tabs to 4 spaces)wm42011-12-191-71/+71
|
* vo: reset EOSD change detection when VO is re-configuredwm42011-12-121-0/+3
| | | | | | | | | | | | | | | This fixes a crash with vo_gl when the switch_ratio slave command is used while a displaying an animated subtitle. switch_ratio will cause a config() call to vo_gl, which will reset all state, including the EOSD state. Next time the EOSD is rendered, its change detection will indicate that only subtitle positions have changed. The render code will attempt to access the EOSD data structures which have been deleted with config(). Fix this by forcing the change detection to indicate a full change if config() has been called. This only happens when doing switch_ratio with vo_gl, and the current subtitle is only changing positions, i.e. mp_eosd_images_t.changed == 1.
* configure, build: remove --disable-libav supportUoti Urpala2011-12-113-6/+2
| | | | | Remove support for building the player without libavcodec and libavformat. These libraries are now always required.
* Merge remote-tracking branch 'wm4/window_title'Uoti Urpala2011-12-072-4/+3
|\
| * libvo: remove title argument from struct vo_driver.configwm42011-12-062-4/+3
| | | | | | | | | | | | | | | | | | | | This affects only the "new" VO API. The config() title argument was barely used, and it's hardcoded to "MPlayer" in vf_vo.c. The X11 and the Cocoa GUI backends, which are the only ones properly supporting window titles, ignored this argument. Remove the title argument. Add the vo_get_window_title function. All GUI VOs are supposed to use it for the window title.
* | ad_ffmpeg: avoid avcodec_close() if avcodec_open() failedUoti Urpala2011-12-061-1/+1
| | | | | | | | | | | | Avoid calling avcodec_close() in uninit() if avcodec_open() failed. Calling avcodec_close() on a non-open codec context causes a crash with recent Libav versions.
* | core, vo: modify OSD redraw architecture, support EOSDUoti Urpala2011-12-067-20/+7
|/ | | | | | | | | | | | | | | | Previously the core sent VFCTRL_REDRAW_OSD to change OSD contents over the current frame. Change this to VFCTRL_REDRAW_FRAME followed by normal EOSD and OSD drawing calls, then vo_flip_page(). The new version supports changing EOSD contents for libass-rendered subtitles and simplifies the redraw support code needed per VO. vo_xv doesn't support EOSD changes because it relies on vf_ass to render EOSD contents earlier in the filter chain. vo_xv logic is additionally simplified because the previous commit removed the need to track the status of current and next images separately (now each frame is guaranteed to become "visible" soon after we receive it as "next", with no VO code running in the interval between).
* Merge branch 'screenshot' (early part)Uoti Urpala2011-11-253-148/+75
|\
| * video: use talloc for mp_image, abort if out of memorywm42011-11-251-14/+20
| | | | | | | | | | Make new_mp_image() allocate the struct with talloc and abort() if the av_malloc for image plane data fails.
| * core: add infrastructure to get screenshots from VOswm42011-11-252-134/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a VO command (VOCTRL_SCREENSHOT) which requests a screenshot directly from the VO. If VO support is available, screenshots will be taken instantly (no more 1 or 2 frames delay). Taking screenshots when hardware decoding is in use will also work (vdpau). Additionally, the screenshots will now use the same colorspace as the video display. Change the central MPContext to be allocated with talloc so that it can be used as a talloc parent context. This commit does not yet implement the functionality for any VO (added in subsequent commits). The old screenshot video filter is not needed anymore if VO support is present, and in that case will not be used even if it is present in the filter chain. If VO support is not available then the filter is used like before. Note that the filter still has some of the old problems, such as delaying the screenshot by at least 1 frame.
* | commands, vd_ffmpeg: fix switch_ratio slave commandUoti Urpala2011-11-144-34/+47
| | | | | | | | | | | | | | | | | | The implementation of the switch_ratio command was hacky and called mpcodecs_config_vo() to reconfigure the filter/VO chain from under an existing decoder. This call no longer worked properly with vd_ffmpeg after that started using mpcodec_config_vo2(). Add new video decoder control command VDCTRL_RESET_ASPECT and use this to tell vd_ffmpeg to reinitialize the output chain properly.
* | vd_ffmpeg: disable slice use that fails with size changesUoti Urpala2011-11-141-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When not using direct rendering, vd_ffmpeg created an mp_image struct before calling libavcodec decoder, so that possible slice support could be checked from the mpi_image and output would be ready for slice-drawing calls. However, this behavior is unsound with decoders that can change output size, as the parameters can change after the mp_image was created. Disable the code creating the mp_image at that point, which also disables use of slices in this case. Slices are disabled with threading anyway, so I think trying to add workarounds to support them is not a high priority. I think this code has always been buggy, but before common thread use it was rarely executed because the direct-rendering case was used instead.
* | cleanup: vf_scale.c, vf.c: replace numbers by flag macro namesUoti Urpala2011-11-142-13/+16
| |
* | cosmetics: vf.[ch]: reformatUoti Urpala2011-11-145-489/+586
|/ | | | Also a couple of smaller changes to other files.
* vd_ffmpeg.c: remove useless realvideo avctx->sub_id settingUoti Urpala2011-10-251-1/+0
| | | | Libavcodec has ignored the caller-set sub_id value since 2006.
* cosmetics: vd_ffmpeg.c: reformatUoti Urpala2011-10-221-348/+301
|
* audio/video: delete buggy "dynamic plugin" codeUoti Urpala2011-10-202-88/+0
| | | | | | | | | | | | Codec selection for audio and video decoding had a "dynamic plugin" feature that tried to load a shared library for any codec that had not been enabled at compilation (disabled by default, but could be enabled with --enable-dynamic-plugins configure switch; for unknown reasons some distro packages have enabled it). The implementation was buggy and could cause normal codec selection fallback to fail if the feature was enabled. I'm not aware of any real uses of such dynamic plugins and the feature seems questionable anyway (there are no ABI guarantees that would make it safe to use). Remove the buggy feature.
* video, options: implement better YUV->RGB conversion controlwm42011-10-166-2/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewrite control of the colorspace and input/output level parameters used in YUV-RGB conversions, replacing VO-specific suboptions with new common options and adding configuration support to more cases. Add new option --colormatrix which selects the colorspace the original video is assumed to have in YUV->RGB conversions. The default behavior changes from assuming BT.601 to colorspace autoselection between BT.601 and BT.709 using a simple heuristic based on video size. Add new options --colormatrix-input-range and --colormatrix-output-range which select input YUV and output RGB range. Disable the previously existing VO-specific colorspace and level conversion suboptions in vo_gl and vo_vdpau. Remove the "yuv_colorspace" property and replace it with one named "colormatrix" and semantics matching the new option. Add new properties matching the options for level conversion. Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv and vf_scale, and all can change it at runtime (previously only vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion matrix generation as vo_gl instead of libvdpau functionality; the main functional difference is that the "contrast" equalizer control behaves somewhat differently (it scales the Y component around 1/2 instead of around 0, so that contrast 0 makes the image gray rather than black). vo_xv does not support level conversion. vf_scale supports range setting for input, but always outputs full-range RGB. The value of the slave properties is the policy setting used for conversions. This means they can be set to any value regardless of whether the current VO supports that value or whether there currently even is any video. Possibly separate properties could be added to query the conversion actually used at the moment, if any. Because the colorspace and level settings are now set with a single VF/VO control call, the return value of that is no longer used to signal whether all the settings are actually supported. Instead code should set all the details it can support, and ignore the rest. The core will use GET_YUV_COLORSPACE to check which colorspace details have been set and which not. In other words, the return value for SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace conversion handling exists at all, and VOs have to take care to return the actual state with GET_YUV_COLORSPACE instead. To be changed in later commits: add missing option documentation.
* options: move libass-related options to structUoti Urpala2011-09-032-21/+26
|
* ad_ffmpeg: free resources on init failureUoti Urpala2011-08-211-4/+12
| | | | | | | | | | ad_ffmpeg init() function did not free resources if opening failed. Outside code (dec_audio.c) does not automatically call uninit() if init() returns failure, and the uninit function would have crashed in some cases had it been called (it did freed lavc_context->extradata, but lavc_context could have been NULL after early init failure). Add explicit calls to uninit() after failure and make uninit function safe to call at any point.
* ad_ffmpeg: handle timing for partially decoded packets betterUoti Urpala2011-08-211-7/+23
| | | | | | | | | | | | | | | | | | | | | | | At least the libavcodec WavPack decoder can return output for an audio frame in multiple parts and return 0 bytes input consumed for the initial parts. Timing info was not set correctly in this case: sh_audio->pts and pts_bytes were reset each time when decoding more from the packet, as if the packet had been new (ds_get_packet_pts() has a check to return MP_NOPTS_VALUE if the packet has already been partially read, but that didn't trigger since libavcodec returned exactly 0 bytes read so the demuxer-visible packet state didn't change). Add a field to keep track of whether a packet has already been decoded from, and don't reset timing info again if so. Adding the field requires adding a decoder context to store it (there wasn't one before). BTW the WavPack decoder behavior and avcodec_decode_audio3() documentation don't match - the documentation says the return value is "zero if no frame data was decompressed (used) from the input AVPacket", while the decoder DOES return some frame data which comes from the input packet.
* cosmetics: ad_ffmpeg.c: reformatUoti Urpala2011-08-211-131/+137
|
* core, demux, vd_ffmpeg: pass side data from demux_lavf to vd_ffmpegUoti Urpala2011-08-204-12/+27
| | | | | | | | | | | | Pass the libavformat packet side_data field from demux_lavf to vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and passing it is required for the playback of some paletted video codecs. The implementation works by giving vd_ffmpeg a copy of the struct demux_packet used to store the video packet (from which it can access the avpacket field). The definition of struct demux_packet is moved to new file demux_packet.h so that vd_ffmpeg.c can use it without including all of demuxer.h.
* vf_screenshot: better check for pixel format swscale supportharklu2011