November 2010 - MPlayer-dev-eng - lists.mplayerhq.hu

[PATCH] add support of compression algorithm 3 in mkv demuxer
by Alexander Beregalov 02 Jan '12

02 Jan '12

Specs from http://www.matroska.org/technical/specs/ : ContentCompAlgo The compression algorithm used. Algorithms that have been specified so far are: 0 - zlib, 1 - bzlib, 2 - lzo1x, 3 - Header Stripping. ContentCompSettings Settings that might be needed by the decompressor. For Header Stripping (ContentCompAlgo=3), the bytes that were removed from the beggining of each frames of the track. I have such file, it works for me. | + A track | + Track number: 2 | + Track UID: 2 | + Track type: audio | + Lacing flag: 1 | + Default flag: 1 | + Codec ID: A_AC3 | + Content encodings | + Content encoding | + Content compression | + Algorithm: 3 (header removal) | + Settings: length 2, data: 0x0b 0x77 See an attachment. Please comment.

7 21

DxVA in MPlayer
by Georgi Petrov 26 Jun '11

26 Jun '11

Hello, I'm Georgi Petrov and a year ago I developed the Direct 3D renderer. Now I'm interested in implementing DxVA support in MPlayer. Yesterday I started to investigate the amount of work and any difficulties I may have and I came up with the following questions: 1. Since DxVA 2 requires EVR renderer (the current Direct 3D one won't work), I suppose that the best way to start is implementing a working EVR renderer first. If so, are there anybody who is familiar at least a little with it? The only thing that bothers me is that EVR is supposed to be used in a DirectShow chain and MPlayer has nothing to do with DirectShow... In short - does anybody know is it feasible to develop the EVR renderer first and test it with the current (non-accelerated) internal MPlayer codecs? 2. Once the EVR custom presenter is ready, FFmpeg already has the needed infrastructure for offloading computations for H.264, VC-1, MPEG-2 and MPEG-4 ASP. Excuse me if I don't get it, but each one of these standards should have an "accelerated" implementation, which from MPlayer's point of view is a new codec. Then inside the codec there are places, where one can hook and transfer the decoding part to the DxVA/VA API/VDAPU at any given stage (IDCT, MO and so on). Is this right? I'm starting to look at the code right now, but a higher abstract point of view is welcome. 3. As far as I understand this approach is used by VA API and VDPAU. Can I reuse their infrastructure as well? On this page I see a VA API patches: http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/ Are they part of MPlayer already or not? 4. Can somebody, who has already worked on VA API/VDPAU implementations give me some clue? How much work is involved in getting the whole chain work? Are most of the puzzle pieces in place or I will have to dig deeper into understanding how H.264 / VC-1 and so on work on a pure codec level? 5. I am trying to figure out a realistic estimate about how much time and hard work this is about, so any help in this direction is welcome. Greeting, Georgi

9 46

[PATCH] Bind to seek to a given percent
by Clément Bœsch 05 May '11

05 May '11

Hi, It's the second time a person tells me he prefers GUI over classic MPlayer because the progress bar allows them to seek to a given position immediately. So I was wondering about making a default bind for this. It seems there is not current solution to bind a combination of keys, just like KEY_CTRL + '1', so I just binded F1 to F9 ('1' to '9' are for most of them already in use). I know this bind is not really good (especially for those using desktop managers) but I didn't find any better. What do you think of this? -- Clément B. Not sent from a jesusPhone.

3 8

[PATCH] -vf fixpts=use_timer
by Rudolf Polzer 22 Feb '11

22 Feb '11

Hello, I added an option to -vf fixpts that takes over the timer from mplayer/mencoder's "best known idea" of the current display time. It is mostly useless in mplayer as mplayer usually generates good pts anyway, but works there too for completeness. Its main intention is to support ASS subtitle baking in mencoder, even if the input video is variable frame rate. My mencoder profile for embedding subtitles is currently: [subtitles] vf-add=fixpts=use_timer,ass,expand=::::1,fixpts ass=yes embeddedfonts=yes It works by having mplayer/mencoder export their timer to a global variable, and having fixpts=use_timer read that back and use it as replacement pts. In case of mplayer, I simply could export sh_video->timer (did NOT use the usually more accurate sh_video->pts, as using that one is quite pointless as it is exactly what is sent as current timestamp anyway). The feature therefore is mainly a debugging help in mplayer. In case of mencoder, sh_video->timer was not available, and sh_video->pts was not monotonous (and thus bad for e.g. subtitle rendering), so I got no better idea than using the audio timer instead. As I noticed the audio timer is broken (positive infinity) for some input video files (e.g. those which use vorbis as audio codec), I had to port over mplayer's audio PTS generation (which is, if possible, no longer based on constant bitrate input data sizes, but on output data sizes of the audio codec, which also works for VBR audio like vorbis). This also solves almost all failcases of mencoder that I have that previously needed -mc 0 to encode properly, as apparently this very issue also caused AV sync to fail in mencoder. To do this port, I also had to delete the written-only (grep did not find any other access to it anywhere) delay_corrected variable. I hope that is okay. If desired, I can split up the changes into separate diffs, however the fixpts=use_timer feature depends on the mencoder.c audio timer fix, or rather, causes huge breakage (infinite pts values) on many input video files when added to the filter chain. Or you can instead download them separately on github: http://github.com/divVerent/mplayer/commits/divVerent/fix_audio_pts http://github.com/divVerent/mplayer/commits/divVerent/fixpts_get_audio_pts http://github.com/divVerent/mplayer/commits/divVerent/integration/fixpts (integration branch of both + current svn) I attached my patch to svn r31721 (= git master on git.mplayerhq.hu), and hope for a review. Best regards, Rudolf Polzer

4 17

[PATCH] Subtitles directories
by Clément Bœsch 08 Jan '11

08 Jan '11

Hi, Not a lot grudge seemed to come up when I proposed the first draft of the subtitles directories, so here is a full working one, with documentation. A few notes about this patch: - It needs the basename patch to work (that should be commited soon, just waiting for a OK.) - I tried not to trash the existing code but I needed some refactorization, so the diff is not quiet clear on the sub_filenames modification (renamed in get_sub_list and set static). - A reindent of get_sub_list will be commited after this one is accepted. - mp_dirname is also part of the patch for a refactorization issue. - It was suggested that -subpaths (or similar) could be more appropriated. What do you think? I hope the man page is clear enough about the feature. If not enough for you developers, get_full_sub_list is quiet explanatory by itself about the new subtitles tracking behaviour. Please review :) -- Clément B. Not sent from a jesusPhone.

3 32

[PATCH] Fix for broken GUI support in current SVN head mplayer version
by Dirk Porezag 05 Jan '11

05 Jan '11

xmga video-out support is broken in the current SVN release in GUI (gmplayer) mode. Playing a video will crash since "vo_window" is not set up properly before using. Also, moving the window across the screen also doesn't work. The patch fixes both issues, changes are rather trivial but I'm happy to discuss them if needed. There still is an issue with extensive flickering in full-screen mode that is neither addressed nor caused by this patch - I didn't have time yet to look into this. Thanks & keep up the good work on my favorite video player, Dirk

2 1

[PATCH] configure: make v4l work with older kernels again
by Michael Lampe 02 Jan '11

02 Jan '11

Including 'linux/videodev*.h' alone results in "error: field 'timestamp' has incomplete type" with kernel 2.6.18-194.17.1.el5. It worked with earlier mplayer versions and to resurrect this, I propose the following patch. -Michael

2 1

internal libfaad2 forked copy
by Diego Biurrun 23 Dec '10

23 Dec '10

Janne just committed LATM support to FFmpeg. AFAIK that fixes the main shortcoming of FFmpeg's AAC decoder compared to libfaad2. IOW, the time for us to remove the internal libfaad2 copy from MPlayer appears to have come. libfaad2 is still faster than ffaac in fixed-point mode on my K6-III, which has a slow FPU, but I'm not aware of any other major issues. Anything I'm missing? Otherwise libfaad2 shall go the way of the dodo. Diego

8 34

[PATCH] proper version info for git.mplayerhq.hu
by Rudolf Polzer 17 Dec '10

17 Dec '10

I attached a small patch that, if mplayer is compiled from mplayer.git, uses the git commit hash instead of UNKNOWN as version info. The format will be: git-<commithash>-<gccversion> if mplayer is built from "master", and git-<closest commithash on master>-<commithash>-<gccversion> if mplayer is built from another branch. In my case, at the moment it prints: MPlayer git-15dfe0a-ceba2bd-4.4.1 (C) 2000-2010 MPlayer Team It changes nothing if run from a svn repository. Best regards, Rudolf Polzer

5 17

MPlayer linking takes forever on MinGW
by Georgi Petrov 06 Dec '10

06 Dec '10

Hi, Fresh msys/mingw (GCC 4.5.0), just installed. Fresh SVN revision of MPlayer, just downloaded. YASM added. Everything compiles fine, but the linking takes forever and never finishes. I tried waiting 2 hours on a very, very fast system. 2% CPU usage by ld.exe, 100MB/s writing to mplayer.exe and... nothing. I tried on my old msys/mingw 100% working configuration first (GCC 3.x.x) and the result was the same. I attach config.log, gzipped. Any ideas? I'm trying for 6 hours and I have no success so far.

7 30