December 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] Add size based support for -endpos in MPlayer
by Clément Bœsch 11 Jun '11

11 Jun '11

A small patch to add size based support for -endpos in MPlayer. I tested it with random videos, audio only files and -loop option and it seems to work. Anything else I should test? However, I don't understand why mpctx->sh_audio is tested when mpctx->sh_video is NULL; is there a way to call the code around mplayer.c:L3698 without having neither mpctx->sh_video and mpctx->sh_audio? And then, does this mean mpctx->stream could be NULL? -- Clément B. Not sent from a jesusPhone.

2 12

[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] Add prefix to filename of files created by PNG video output
by Marco Aurélio Graciotto Silva 02 Feb '11

02 Feb '11

I was wondering if Mplayer couldn't add a prefix to the filename of the PNG created using PNG 'video' output. Thus, I created a small patch that allows the usage of a prefix for the PNG output filename. The new option is "outfile", which is used to define the 'png_outfile_prefix' variable. The default behaviour is the same as Mplayer currently has (default value for 'png_outfile_prefix' is an empty string), so backwards compatibility is kept. The patch was created against MPlayer svn #32707. Regards, Marco Aurélio

3 5

Git migration
by Clément Bœsch 22 Jan '11

22 Jan '11

Hello again, Since FFmpeg is migrating to Git, it was question of doing it also for MPlayer. Is there anyone opposed to this? Luca mentionned the MPlayer dev team in FFmpeg mailing list so I'd be happy to have opinions on this. Regards, -- Clément B. Not sent from a jesusPhone.

11 23

[PATCH] Correct translation of filename
by Ingo Brueckl 17 Jan '11

17 Jan '11

Currently, filenames like "Nice.Film.avi" get incorrectly translated to "Nice" instead of "Nice.Film".

4 7

[PATCH] Get rid of the "main" label
by Clément Bœsch 16 Jan '11

16 Jan '11

Hi, I'd like a feedback on this patch: there is still a "main" label in mplayer.c. This is patch to get rid of it. The code first check if there is a video context (is it the correct name for sh_video?). If there is, the video chain is reset. After that, if neither sh_video nor sh_audio are set, it goes to the next file. Then, two things are done, but only if there was a video context at first, so I just moved this in the "main" code where sh_video is checked. It seems no previous code depends on the spu state and the font load flag. Btw, mplayer.c really needs at least a reindent; the current state is quiet a mess… -- Clément B. Not sent from a jesusPhone.

2 7

[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 RESEND] Mac OS X: fix libao2 compilation on Mac OS X 10.4
by Aaro Koskinen 07 Jan '11

07 Jan '11

Hello, The patch below fixes mplayer compilation on Mac OS X 10.4 (it has been broken since r31713). Please apply - it should not change anything on newer Mac OS X versions. A. Index: libao2/ao_coreaudio.c =================================================================== --- libao2/ao_coreaudio.c (revision 32667) +++ libao2/ao_coreaudio.c (working copy) @@ -68,6 +68,23 @@ /* Prefix for all mp_msg() calls */ #define ao_msg(a, b, c...) mp_msg(a, b, "AO: [coreaudio] " c) +#if MAC_OS_X_VERSION_MAX_ALLOWED <= 1040 +/* + * AudioDeviceIOProcID does not exist in Mac OS X 10.4. We can emulate this + * by using AudioDeviceAddIOProc() and AudioDeviceRemoveIOProc(). + */ +#define AudioDeviceIOProcID AudioDeviceIOProc +#define AudioDeviceDestroyIOProcID AudioDeviceRemoveIOProc +static OSStatus AudioDeviceCreateIOProcID(AudioDeviceID dev, + AudioDeviceIOProc proc, + void *data, + AudioDeviceIOProcID *procid) +{ + *procid = proc; + return AudioDeviceAddIOProc(dev, proc, data); +} +#endif + typedef struct ao_coreaudio_s { AudioDeviceID i_selected_dev; /* Keeps DeviceID of the selected device. */

6 15

[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

New gmplayer options?
by Ingo Brückl 05 Jan '11

05 Jan '11

Hi, what about two new options for the gmplayer, namely load-and-play (start playing after file or playlist has been loaded) and play-and-quit (quit gui after all files have been played)? I'd like to have these and would code them. Ingo

6 16

hwswskin author reading here?
by Ingo Brueckl 05 Jan '11

05 Jan '11

Hi, I can't find a hint on hwsw.hu on how to contact the person in charge. I've added German umlaute to the font and would like to offer a second, slightly modified skin with the movie length displayed. Ingo

3 2

[PATCH] Fix compilation problem for arm920 types.
by Marek Belisko 05 Jan '11

05 Jan '11

Following patch fix compilation error: libmpeg2/motion_comp_arm_s.S:29: Error: selected processor does not support `pld [r1]' Signed-off-by: Marek Belisko <marek.belisko(a)open-nandra.com> --- libmpeg2/motion_comp_arm_s.S | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/libmpeg2/motion_comp_arm_s.S b/libmpeg2/motion_comp_arm_s.S index f6c3d7d..51abaea 100644 --- a/libmpeg2/motion_comp_arm_s.S +++ b/libmpeg2/motion_comp_arm_s.S @@ -18,6 +18,10 @@ @ along with mpeg2dec; if not, write to the Free Software @ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +#if !HAVE_PLD +.macro pld reg +.endm +#endif .text -- 1.7.1

2 1

running a program with a keystroke - passing playing filename to it
by Elias Gabriel Amaral da Silva 03 Jan '11

03 Jan '11

Hello, this is my first post. I want to run a program with a keystroke, and pass the playing filename to it (also the film length, current position..). I see that there is a run command. so putting run "mycommand" at input.conf works. But I don't see how to pass the current filename to it, or other data. Is it possible? (I have a playlist, so the current filename changes with > and <. If it were just one film, I could do something like FILE="$file" mplayer "$file" and mycommand would see FILE on its environment) I see that some commands (like osd_show_property_text) expand ${filename}. But run runs the command as a shell script, and inspecting run "env" I don't see a filename variable defined there. I think mplayer could define some variables for the execing proccess. Like MPLAYER_FILENAME, MPLAYER_POS.. I am about to implement it (unless there is another way to do what I want). Does this seem reasonable?

5 16

[PATCH] Factorize ROUND() redefinitions macro
by Clément Bœsch 03 Jan '11

03 Jan '11

Hi, ROUND() is redefined in a few places in the code, so here is a patch to factorize them in mpcommon.h. Is it the correct place to put it? I don't see any macro in it so… -- Clément B. Not sent from a jesusPhone.

2 3

[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

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

02 Jan '11

Is there anything completely wrong with this? Did I miss some formalities I should have strictly followed? Or did nobody find the time to look at this? -Michael

2 1

x264 dimensions not set / float point exception
by Joseph Miller 30 Dec '10

30 Dec '10

I keep getting floating point exceptions after doing the following. I have attached mencoder output. /opt/mplayer/bin/mencoder -oac mp3lame -srate 44100 -ovc x264 -vf harddup -of lavf -o integra-lavf.mp4 integra.mp4 /opt/mplayer/bin/mencoder -ovc copy -oac copy -nosound -of rawvideo integra-lavf.mp4 -o video.h264 /opt/mplayer/bin/mencoder -ovc copy -oac copy -of rawaudio integra-lavf.mp4 -o audio.mp3 MP4Box -fps 30 -new integra-mp4box.mp4 -add video.h264 -add audio.mp3 Then... /opt/mplayer/bin/mencoder -oac faac -ovc x264 -of lavf -o integra-reencode.mp4 integra-mp4box.mp4 /opt/mplayer/bin/mencoder -oac faac -ovc x264 -of lavf -o integra-reencode.mp4 integra-lavf.mp4 That last two give me Floating point exception. I have uploaded integra.mp4 and integra-lavf.mp4 and integra-mp4box.mp4 to the following location: http://www.calcmaster.net/downloads/fpx/ I have had this happen on MP4Box files and other .mp4 files. I'm not exactly sure what triggers it. I can get around this by encoding to .mp4 with mencoder and not using lavf, then reencoding that file using mencoder lavf. -Joseph

3 14

EVR Renderer
by Georgi Petrov 30 Dec '10

30 Dec '10

Hi, The Enhanced Video Renderer (EVR) turned out much more complicated than I imagined from what I've tried and saw as code. I may underestimated it a little bit, but I'm working on it. As my experimental code is very far from initial inclusion, I have a question. Can I submit the first patch to enable the "EVR infrastructure"? I refer to needed changes in configure, the new vo_evr.c and so on. Unfortunately VLC doesn't implement EVR at all. It just reads back from DXVA 2 and displays using other renderers. Right now the most complete implementation is in MPC-HC's source. I will write more information in the following days.

4 7

[PATCH] better detection of ASS comas number
by Aurelien Jacobs 29 Dec '10

29 Dec '10

Hi, Currently, when parsing an ASS file without using libass, MPlayer is wild-guessing the number of comas before the Text field of dialog events lines, just hopping that it is the most commonly used one without really checking. Attached patch adds some real auto-detection of the comas number by counting the number of comas in the "Format:" line of extradata. If no extradata is present or auto-detection don't work, it fallback on the previously used wild-guessing. Aurel

1 0

make x264 options more clear patch
by Joseph Miller 27 Dec '10

27 Dec '10

Dear list, I just found out that I should have been using crf instead of qp for x264 encoding and have been using the wrong options for the last 2 years. So that other people who are as dumb as I am don't make the same mistake, I propose the following patch to add make the man page more explicit. Please let me know if this is acceptable or if another approach should be made here. -Joseph

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] RFC: CrystalHD decoder support
by Philip Langdale 22 Dec '10

22 Dec '10

Hi all, For the past few weeks, I've been attempting to implement CrystalHD decoder support, first directly in ffmpeg and then in mplayer - and I'll touch on why that is in a moment. The current patch is largely functional with a few important caveats: * It doesn't work properly with the 70012 hardware. I did all my development against a 70015 and haven't really paid any attention to the 70012. It will run but it performs terribly for some reason. * Interlaced frames are not handled very well - it kinda works but av-sync is a mess. * Files with resolutions above 720p probably won't play properly due to not being able to get data in and out of the decoder fast enough. Broadcom state in the driver/lib source that you need separate input and output threads to keep it fed and I'm not sure how to reconcile that with the mplayer/ffmpeg API (I assume ffmpeg-mt could do this). However, the biggest issue is that the decoder breaks an assumption in mplayer about how many calls to decode can occur before a frame is returned. At the start up, the crystalhd might require 20 or more calls before it ever returns a frame, and without increasing the maximum number of buffered_pts, it will start discarding them, ensuring that av-sync goes out the window. So, I've bumped max buffered_pts to 128 in this patch - 64 was too low, but it might need to be even higher for 1080p content. I'm also not sure how QUERY_UNSEEN_FRAMES should be used. I don't know how many complete frames are in the decoder waiting to be decoded and mplayer seems to be comparing the result with buffered_pts which comes from the pts passed to each decode call, so I'm pretty confused. It also doesn't help with vd_ffmpeg adding 10 and then having it subtracted later. So I ended up returning 20 + the number of decode calls that haven't returned a frame since the last flush. It seems to work but it's hardly scientific. With that in place, progressive <= 720p content plays well - with a note that I have to force lavf to demux avi and wmv files correctly. The native demuxers dont' sync properly - i think because they also make assumptions about how long you have to wait for frames to come back. I'm not sure what's going on with interlacing. xbmc does line-doubling on each field and the gstreamer plugin doesn't handle it at all so I had to guess, and while I can construct a frame that de-interlacing filters are happy with, av-sync goes way out the window; NTSC content plays at not-quite half rate (if I force 59.94, it plays slightly too fast), etc. Now, why an mplayer plugin? I originally wrote this as an ffmpeg hwaccel on top of Gwenole's v2 patch with some additions to support accelerating decode_frame as opposed to decode_slice and it kinda worked but most of my h.264 streams would make the crystalhd grumpy (those play fine with the mplayer plugin). There's also no real benefit in terms of code sharing as the only place we need codec awareness is the sps/pps decoding and ffmpeg's h.264 codec doesn't build up a compatible struct anyway. I also had a problem where I just got solid grey output with x11/xv (but correct frames with vdpau). So, combining all that with wanting to debug the sync problems as directly as possible, I switched to an mplayer plugin and everything worked much better. Philosophically, I think it can be argued either way; you can consider libcrystalhd to be a library codec like theora or xvid and say it's a valid mplayer codec on that basis, or you can argue that it's an accelerator that should be usable from ffmpeg (although the advantages for a transcode job are going to be very marginal). At this point, I'm not seriously suggesting it's ready to go in - the interlaced handling needs to get sorted out and I think we need a more rigorous basis for how the av sync interactions are done; still I'm sure some people will be very happy to see mplayer finally using this hardware. --phil

5 9

Work on SDP and RTP support
by Clément Bœsch 22 Dec '10

22 Dec '10

Hi, At the moment, the FreeSDP library copy is only used in for the code in librtsp/rtsp_rtp.c. Since the freesdp code is a bit overkill, and unmaintained upstream, I thought of rewriting a small parser for the SDP protocol. So I just did it this week end, and it implements almost everything of RFC4566 in something like 400 lines (instead of the 10 times more with FreeSDP). Then I changed the freesdp calls in rtsp_rtp.c to the new sdp parser without any special issue. But the major issue now is to get a RTP stream working: I tried something like 10 streams on http://wiki.multimedia.cx/index.php?title=RTSP#RTSP_MOV.2FMP4 but none work. If I use the -rtsp-stream-over-tcp switch, it fallbacks to live555 module and then works. ffmpeg:// also works. But in both cases, it's a fallback to the RTP code failure. So a few questions: 1) Are you interested in a fix for the RTP code or you prefer to let it rot/drop it? 2) If you're ok with a fix, do you have a stream that currently works with it, or at least "should" 3) Are you ok with dropping FreeSDP over a simpler (already done) SDP implementation? Regards, -- Clément B. Not sent from a jesusPhone.

6 8

Re: [MPlayer-dev-eng] [PATCH] RFC: CrystalHD decoder support
by Philip Langdale 21 Dec '10

21 Dec '10

On 2010-12-20 8:34:29, Benjamin Zores wrote: > FYI, I had a BCM70012 which never worked out that well (in > gst-crystalhd). > I just bought a BCM70015 that does wonder. > So I'm starting considering it's the 70012 itself (or its firmware) > that is actually bugged. I actually got my 70012 to work well with gstbcmdec after one of the more significant updates to the driver/lib so I think it can be made to work, but certainly my current code is not treating it well. I would not be surprised to hear that the vlc patch has similar problems. > Haven't looked at the patch yet but I'll give it a try by tonight if > possible. > > FYI, VLC just added CrystalHD support very recently (or at least a > patch is 2-3 weeks old on mailing list), > if you need something else to compare with (other than gst). Thanks for the heads up, I took a look and it's conceptually the same; but it doesn't touch interlacing at all, and I suspect that if vlc actually uses output timestamps, things will go south fast on a 70015 as that fails to return them with the decoded frames (as mentioned in my reply to Reimar. I do intend to move this to an ffmpeg codec once I've dealt with the major problems and hopefully vlc can share that. --phil

1 0

[PATCH] Allow double quote to be defined in font file
by Ingo Brueckl 20 Dec '10

20 Dec '10

Hi, so far, it doesn't seem to be possible to define the double quote character in the font.fnt file. The patch enables this now. Ingo

4 9

[PATCH] RFC: CrystalHD decoder support
by Philip Langdale 20 Dec '10

20 Dec '10

Hi all, For the past few weeks, I've been attempting to implement CrystalHD decoder support, first directly in ffmpeg and then in mplayer - and I'll touch on why that is in a moment. The current patch is largely functional with a few important caveats: * It doesn't work properly with the 70012 hardware. I did all my development against a 70015 and haven't really paid any attention to the 70012. It will run but it performs terribly for some reason. * Interlaced frames are not handled very well - it kinda works but av-sync is a mess. * Files with resolutions above 720p probably won't play properly due to not being able to get data in and out of the decoder fast enough. Broadcom state in the driver/lib source that you need separate input and output threads to keep it fed and I'm not sure how to reconcile that with the mplayer/ffmpeg API (I assume ffmpeg-mt could do this). However, the biggest issue is that the decoder breaks an assumption in mplayer about how many calls to decode can occur before a frame is returned. At the start up, the crystalhd might require 20 or more calls before it ever returns a frame, and without increasing the maximum number of buffered_pts, it will start discarding them, ensuring that av-sync goes out the window. So, I've bumped max buffered_pts to 128 in this patch - 64 was too low, but it might need to be even higher for 1080p content. I'm also not sure how QUERY_UNSEEN_FRAMES should be used. I don't know how many complete frames are in the decoder waiting to be decoded and mplayer seems to be comparing the result with buffered_pts which comes from the pts passed to each decode call, so I'm pretty confused. It also doesn't help with vd_ffmpeg adding 10 and then having it subtracted later. So I ended up returning 20 + the number of decode calls that haven't returned a frame since the last flush. It seems to work but it's hardly scientific. With that in place, progressive <= 720p content plays well - with a note that I have to force lavf to demux avi and wmv files correctly. The native demuxers dont' sync properly - i think because they also make assumptions about how long you have to wait for frames to come back. I'm not sure what's going on with interlacing. xbmc does line-doubling on each field and the gstreamer plugin doesn't handle it at all so I had to guess, and while I can construct a frame that de-interlacing filters are happy with, av-sync goes way out the window; NTSC content plays at not-quite half rate (if I force 59.94, it plays slightly too fast), etc. Now, why an mplayer plugin? I originally wrote this as an ffmpeg hwaccel on top of Gwenole's v2 patch with some additions to support accelerating decode_frame as opposed to decode_slice and it kinda worked but most of my h.264 streams would make the crystalhd grumpy (those play fine with the mplayer plugin). There's also no real benefit in terms of code sharing as the only place we need codec awareness is the sps/pps decoding and ffmpeg's h.264 codec doesn't build up a compatible struct anyway. I also had a problem where I just got solid grey output with x11/xv (but correct frames with vdpau). So, combining all that with wanting to debug the sync problems as directly as possible, I switched to an mplayer plugin and everything worked much better. Philosophically, I think it can be argued either way; you can consider libcrystalhd to be a library codec like theora or xvid and say it's a valid mplayer codec on that basis, or you can argue that it's an accelerator that should be usable from ffmpeg (although the advantages for a transcode job are going to be very marginal). At this point, I'm not seriously suggesting it's ready to go in - the interlaced handling needs to get sorted out and I think we need a more rigorous basis for how the av sync interactions are done; still I'm sure some people will be very happy to see mplayer finally using this hardware. --phil -- --phil

1 0

[PATCH] Replace two malloc+memset with calloc
by Clément Bœsch 19 Dec '10

19 Dec '10

A trivial patch for two malloc+memset in stream module. Ok to apply? -- Clément B. Not sent from a jesusPhone.

2 3

[PATCH] Fix potential overflow in get_metadata
by Clément Bœsch 19 Dec '10

19 Dec '10

There is at least one potential heap overflow in mplayer.c:get_metadata: meta = malloc (8); sprintf (meta, "0x%08X", sh_video->format); So here is a patch to change the way "meta" is handled in this function. -- Clément B. Not sent from a jesusPhone.

2 3

[PATCH] Allow gmplayer the use of non-UTF-8 filename encoding
by Ingo Brueckl 19 Dec '10

19 Dec '10

Hi, so far, the gmplayer cannot handle non-UTF-8 filename encoding (but set to an arbitrary locale). The patch allows the (GLib) filename encoding to be in an arbitrary locale (given by gtk environment variable G_FILENAME_ENCODING), and the GUI dialogs will display and handle these filenames correctly. Ingo

2 2

[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

[PATCH] add support for HTTP 307 redirects
by chocolateboy 16 Dec '10

16 Dec '10

The attached patch adds support for HTTP 307 (Temporary Redirect) responses. Tested against: http://tinyurl.com/37qsk25 http://tinyurl.com/33nhh9j

3 2

[PATCH] Use BUFLENGTH for buf defined in draw_image
by Marco Aurélio Graciotto Silva 15 Dec '10

15 Dec '10

In libvo/vo_png.c, the variable 'buf', used to create the output PNG filename, has a constant size of 100. However, vo_png.c already defines and uses a constant, BUFLENGTH, for a similar purpose at config(). So, I changed draw_image() to use BUFLENGTH instead of 100 as its size. Regards, Marco

4 4

MPlayer creates a "fake" Apple
by İsmail Dönmez 13 Dec '10

13 Dec '10

Hi; This is the most amusing bug I've ever encountered. Attached is a snapshot of MPlayer running on Snow Leopard, using corevideo as video output. Notice that there are two Apple logos, one real (the one on the left) and one a cheap imitation (the one on the right). I am wondering how this is happening :-) Regards, ismail

1 0

Output filename prefix for PNG output
by Marco Aurélio Graciotto Silva 12 Dec '10

12 Dec '10

Dear MPlayer developers, I was wondering if Mplayer couldn't add a prefix to the filename of the PNG created using PNG 'video' output. I searched the mailing list and I could find just one post regarding this (http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-October/054281.html) but it was about writing everything to just one file (instead of several files). Thus, I created a small patch that allows the usage of a prefix for the PNG output filename. The new option is "outfile", which is used to define the 'png_outfile_prefix' variable. The default behaviour is the same as Mplayer currently has (default value for 'png_outfile_prefix' is an empty string), so backwards compatibility is kept. I also changed the BUFLENGTH value, so I could use the same value for the buffers at vo_png.c (they are all used for the same purpose, setting the name of the output path or filename). I also defined a saner value (255 as max path+file name) instead of the mixed 100 (as defined in 'draw_image' function) and 500 (as of 'config' function). Besides this, I also did minor indentation fixes. The patch was created against MPlayer svn #32678. Regards, Marco Aurelio

2 2

help me on mp4demux APIs
by anil v 11 Dec '10

11 Dec '10

Dear All, I am trying to extract the Audio / Video elementary streams from a sample C application using mplayer libraries ( ffmpeg/libmpdemux .. ). I could able to extract the AV streams using mplayer from command as below. #mplayer -dumpaudio -dumpvideo file.mp4. Is there any ffmpeg/any lib APIs can i access to demux the MP4 file from C application ? Please suggest me how can i acheive extration of AV elementary streams only from MP4 container file. Thanks in Advance. Thanks, Anil.V

1 0

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

Subtitles modules
by Clément Bœsch 04 Dec '10

04 Dec '10

Hi, subreader.c is huge file with lots of various, and I was planning to extract specific subtitles format functions into sub modules, just like libmpdemux, libmpcodecs, etc. So first step, I'd like to just put specific format functions into specific files: sub/st_jacosub.c sub/st_microdvd.c sub/st_sami.c sub/st_subrip.c ... This will be the first tricky thing since some formats have specific hacky global variable such as previous_sub_end. If I'm not wrong the second step would be to define some instance and info struct just like with at least init, read, postproc, dump and close function. The automatic type detection could be ported in the init function of each type. Does anyone has a grudge against this, or see a big obstacle? Regards, -- Clément B. Not sent from a jesusPhone.

4 9

[PATCH] Make use of mp_basename in a few places
by Clément Bœsch 04 Dec '10

04 Dec '10

Hi, Since mp_basename seems to work, I think it could be nice to use it all over the code instead of various hacky strrstr. Here is a patch to fix most of them. -- Clément B. Not sent from a jesusPhone.

2 2

[PATCH] Add support for login/password in http_proxy env variable
by Clément Bœsch 03 Dec '10

03 Dec '10

Hi, http_proxy:// syntax now well supports proxy authentication, but not in the env variable. So here is a patch to fix that. -- Clément B. Not sent from a jesusPhone.

2 9

[PATCH] Drop MPlayer base64_encode for av_base64_encode
by Clément Bœsch 03 Dec '10

03 Dec '10

Hi, Here is a patch to simplify the base64 computing in the stream module. Since libavutil provide a base64 encode, a factorization was possible, and code gets simplified. I tested the http authentication, but I couldn't for the rtsp one. If anyone has an idea of how the RTSP server can reply a 401, I'd like to hear about :) -- Clément B. Not sent from a jesusPhone.

2 3