http://blog.gmane.org/gmane.comp.video.mplayer.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.video.mplayer.devel/61634 <pre>Hi, this adds support for ralf codec (ffmpeg decoder only, not the binary dll) to our real demuxer. Tested with the two ralf sample that I have. I'll apply it in a few days if no comments (and if my svn account still works). Ciao, Roberto _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng&lt; at &gt;mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng</pre> Roberto Togni 2012-05-24T22:37:18 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61628 <pre>I found live555 checking is extended, but libliveMedia.a is forgotten. as a result, live555 will never get passed. this patch is going to fix this. Best Regards, Zongyao QU _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng&lt; at &gt;mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng</pre> Zongyao Qu 2012-05-22T14:16:03 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61622 <pre>I'm missing plaintext playlist parsing. Is this patch ok or should it be somehow restricted to the GUI (use_gui)? Ingo _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng&lt; at &gt;mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng</pre> Ingo Brückl 2012-05-21T22:24:34 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61621 <pre>Hello, below patch would compile MPlayer as PIE on x86 by default. On 32 bit, the cost would only be in a larger binary size and having to do relocations at startup, but no real cost at runtime. On 64 bit, there is almost no size or runtime overhead, mostly that in some cases PIC-relative addressing has to be used. I believe that none of the assembler code will be disabled by either. I have not made any changes to other architectures since I can't judge the impact. A side effect of the 64 bit case is that MPlayer will refuse to link against some static libraries (those not compiled with PIC and thus violating the ABI), one example (which only exists as static library) is LIVE555 as provided by Debian. Another point is that backtraces without debug info will probably be even less useful. Any comments? My belief is that there is negligible if any disadvantage for a sometimes significant win in security. Index: configure =================================================================== --- configure(revisio</pre> Reimar Döffinger 2012-05-21T20:54:15 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61607 <pre>I'm just about to update the completely outdated list of supported MIME types in mplayer.desktop for the GUI. There's probably only the list of extensions (libmpdemux/extension.c) and the list of demuxers in libmpdemux/ itself that might give me a clue about what MIME types are supported, isn't it? It would be nice if I had samples to test with. Is there a collection somewhere? Ingo </pre> Ingo Brückl 2012-05-18T08:41:22 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61596 <pre> Test for SCTP and remove it from the list of libavformat protocols in case the test did not succeed or the feature was explicitly disabled. Unconditionally trying to build it, as it was done before if you had a new enough libavformat version that contains that feature, is obviously not a good idea. This patch is closely based on a patch from Johan Andersson. --- configure | 25 ++++++++++++++++++++++++- 1 files changed, 24 insertions(+), 1 deletions(-) diff --git a/configure b/configure index 1afb4c1..9ad2692 100755 --- a/configure +++ b/configure &lt; at &gt;&lt; at &gt; -384,6 +384,7 &lt; at &gt;&lt; at &gt; Optional features: parsing [disabled] --enable-macosx-bundle enable Mac OS X bundle file locations [autodetect] --disable-inet6 disable IPv6 support [autodetect] + --disable-sctp disable SCTP support [autodetect] --disable-gethostbyname2 gethostbyname2 part of the C library [autodetect] --disable-ftp disable FTP support [enabled] --disable-vstream disable TiVo vs</pre> Alexander Strasser 2012-05-12T23:03:14 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61593 <pre>Hi! While testing on Cygwin I stumbled over 2 problems this patch series tries to solve. These patches apply to both the code base from the 1.1 release preview and current SVN. For the first patch I do not know if it is the best solution, but it was the first Idea that came to mind and it worked fine. I tested vo directx with and without hwaccel and the module worked fine here AFAICT. Please let me know what you think about it. Alexander Strasser (2): build: Fix vo directx compilation on Cygwin build: Update SDL test to check for new features configure | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) </pre> Alexander Strasser 2012-05-12T19:34:07 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61586 <pre>Where in the source code for mplayer do I find a place where I can insert my own code to analyze and modify the video frames before they are displayed? Specifically, I wish to add focus detection and indication. I know how to do focus detection in C, but I just can't find in the source code where (or what variables/buffers) I can analyze and modify each frame with my own code. Thank you very much, Jesse Gordon </pre> Jesse Gordon 2012-05-08T06:55:41 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61582 <pre>Hello, we decided it is time to do a release again. However there are two problems with that 1) We generally need a lot of testing to check that there are no too serious issues. 2) The usual people seem to have no time, FFmpeg has switched to git etc. so some knowledge on how to make the release tarball got lost. So I just made the first try of creating one from current trunk. I'd like as many people as possible to test compiling and running. I'd also like people to check that the right stuff is included (i.e. the HTML DOCS are there and work as expected, there are no .svn or .git directories etc.). I also have not decided on the formats, though I tend towards not making a .tar.gz available but only a .tar.bz2 and possibly .tar.xz. Opinions on that are welcome, too. And here's the tarball for you to test: http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.1_testing_only.tar.bz2 Thanks for your help, Reimar Döffinger </pre> Reimar Döffinger 2012-05-06T12:04:57 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61581 <pre>Hello, DOCS/tech/release-howto.txt mentions a release.sh script. Does that actually exist/does someone have a copy of it? I'm sure it would be quite outdated, but it wouldn't hurt to have it as a starting point to make it easier to avoid forgetting things. Reimar </pre> Reimar Döffinger 2012-05-06T11:15:02 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61575 <pre>Hi, This patch tries to improve (not completely fix) a v4l regression from svn r27057 which introduced per channel resetting of v4l2 normids when tuning channels. The relevant bug report can be found at http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1326. I tested on cx88 and bt878 based cards. Only the cx88 is affected. The problem is that cx88 based cards will reset the picture size to 320x240 when changing norms, squashing the picture to a quarter size in the top left corner when changing channels in mplayer. The cx8800 driver needs to reset the picture size due to a hardware filter recalculation requirement when changing norms. Others have also noticed this problem in the driver, but no comprehensive fix was found - see http://www.mail-archive.com/linux-media&lt; at &gt;vger.kernel.org/msg00157.html The fix proposed is to only change the norm if the new channel norm (eg. NTSC) differs from the current norm (eg. PAL-I), as specified in the user config file. This should at least work for most people most of the time</pre> Jon Doe 2012-05-01T08:16:22 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61574 <pre>Hi, Ivan noticed that, on some files, wild seeking can provoke hangup of the mpg123 decoder. I tracked that down to mpg123_getformat() triggering premature parsing of the next frame which may have not been provided yet. I fixed the offending code in mpg123 for the upcoming release and also prepared attached patch that prevents this from the mplayer side. As a bonus, it actually simplifies the code by avoiding unnecessary calls to mpg123_getformat() --- 12 lines less, yay! ;-) Please test (Ivan with the special trigger video) and apply. Alrighty then, Thomas _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng&lt; at &gt;mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng</pre> Thomas Orgis 2012-04-30T09:18:17 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61553 <pre>The "packet_t" structure is renamed with a prefix, because it is used a public header. --- sub/av_sub.c | 52 ++++++++++++++++++++++++++------ sub/spudec.c | 93 ++++++++++++++++++++++++++++++++++++++-------------------- sub/spudec.h | 8 +++++ 3 files changed, 111 insertions(+), 42 deletions(-) With Reimar's suggested changes, and the structure name change squashed in. diff --git a/sub/av_sub.c b/sub/av_sub.c index 505dacc..aa91531 100644 --- a/sub/av_sub.c +++ b/sub/av_sub.c &lt; at &gt;&lt; at &gt; -32,6 +32,47 &lt; at &gt;&lt; at &gt; void reset_avsub(struct sh_sub *sh) } } +static void avsub_to_spudec(AVSubtitleRect **rects, int num_rects, + double pts, double endpts) +{ + int i, xmin = INT_MAX, ymin = INT_MAX, xmax = 0, ymax = 0; + struct spu_packet_t *packet; + + if (num_rects == 1) { + spudec_set_paletted(vo_spudec, + rects[0]-&gt;pict.data[0], + rects[0]-&gt;pict.linesize[0], + rects[0]-&gt;pict.data[1], + </pre> Nicolas George 2012-04-22T17:51:03 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61544 <pre>--- sub/spudec.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sub/spudec.c b/sub/spudec.c index 787c3ad..0a0f7fa 100644 --- a/sub/spudec.c +++ b/sub/spudec.c &lt; at &gt;&lt; at &gt; -57,8 +57,8 &lt; at &gt;&lt; at &gt; int spu_aamode = 3; int spu_alignment = -1; float spu_gaussvar = 1.0; -typedef struct packet_t packet_t; -struct packet_t { +typedef struct spu_packet_t packet_t; +struct spu_packet_t { int is_decoded; unsigned char *packet; int data_len; </pre> Nicolas George 2012-04-22T16:32:15 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61543 <pre>Hello, this sure lacks a lot of things, and I am not volunteering to add them really. Main bikeshed issue is going to 1.1. The 1.0 rc has really become a too-long running joke. Yes, we could do 1.0 first, but I think it has become to confusing with years of RCs. It also avoids the "1.0 must be a big thing!" nonsense :-) Reimar _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng&lt; at &gt;mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng</pre> Reimar Döffinger 2012-04-22T16:07:42 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61531 <pre>Hi, I am using mplayer to play movie files from a http server (apache). If due to some error the connection drops and comes back soon, mplayer does not tries to reconnect and gets killed with a Broken frame error. Is there any fix to this problem. -- Mac </pre> Mac Smith 2012-04-20T14:15:37 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61529 <pre>Here is a patch will allow us to encode 7.1 audio AAC. 7.1 audio not being really popular, instead of creating a new re_order function, I'm using 2 functions for the re_ordering from L R Ls Rs C LFE Rls Rrs --&gt; C L R Ls Rs Rls Rrs LFE Index: libaf/reorder_ch.c =================================================================== --- libaf/reorder_ch.c (revision 34869) +++ libaf/reorder_ch.c (working copy) &lt; at &gt;&lt; at &gt; -785,6 +785,9 &lt; at &gt;&lt; at &gt; if (chnum==6) { REORDER_SELF_SWAP_5_STEP_1(src_8,tmp,samples,6,s0,s1,s2,s3,s4); } + else if (chnum==8) { + REORDER_SELF_SWAP_5_STEP_1(src_8,tmp,samples,8,s0,s1,s2,s3,s4); + } else { REORDER_SELF_SWAP_5_STEP_1(src_8,tmp,samples,5,s0,s1,s2,s3,s4); } &lt; at &gt;&lt; at &gt; -797,6 +800,9 &lt; at &gt;&lt; at &gt; if (chnum==6) { REORDER_SELF_SWAP_5_STEP_1(src_16,tmp,samples,6,s0,s1,s2,s3,s4); } + else if (chnum==8) { + REORDER_SELF_SWAP_5_STEP_1(src_16,tmp,samples,8,s0,s1,s2,s3,s4); + } else { REO</pre> Thierry Foucu 2012-04-18T18:29:03 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61527 <pre>Currently EDL relies on mpctx-&gt;sh_video-&gt;pts which (as noted earlier) can "reset" half way through a DVD, thus applying skips or mutes to any segment past that mark doesn't work. Patch to remedy this. -roger- https://github.com/rdp/mplayer-svn/commit/5ac533baf061a50809adbe6a3b0133b0e334ff8f diff --git a/mplayer.c b/mplayer.c index 3a5e38a..38f023c 100644 --- a/mplayer.c +++ b/mplayer.c &lt; at &gt;&lt; at &gt; -2608,7 +2608,8 &lt; at &gt;&lt; at &gt; static void edl_update(MPContext *mpctx) edl_records = NULL; return; } - + + double pts = demuxer_get_current_time(mpctx-&gt;demuxer); // This indicates that we need to reset next EDL record according // to new PTS due to seek or other condition if (edl_needs_reset) { &lt; at &gt;&lt; at &gt; -2619,19 +2620,19 &lt; at &gt;&lt; at &gt; static void edl_update(MPContext *mpctx) // Find next record, also skip immediately if we are already // inside any record while (next_edl_record) { - if (next_edl_record-&gt;start_sec &gt; mpctx-&gt;sh_video-&gt;pts) + if (next_edl_r</pre> Roger Pack 2012-04-18T16:39:08 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61524 <pre>Hi, here's a little patch to add support for xf86 forward and rewind keys. These are sent by my remote when I hold down the next/prev buttons for continuous skip/seek. Rafi _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng&lt; at &gt;mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng</pre> Rafi Rubin 2012-04-18T13:45:48 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61523 <pre>Could someone please make me the default assignee for component GUI, so that I'll receive notification on GUI bug reports? Ingo </pre> Ingo Brückl 2012-04-18T08:34:05 http://comments.gmane.org/gmane.comp.video.mplayer.devel/61513 <pre>*Hi all:* * * *Mplayer stutters seriously * on my machine while play rmvb of D1 size , the cpu arch of my machine is ARMV6, and run 600Mhz. my playback experience is audio always smooth but video seems be totally blocked , i found some other player ,like vlc, is able to keep video render first ,and audio stutter, i want to know how i can modify the av sync method to get this effect (audio sync to video) . following is my setting : "mplayer","-idle","-slave","-osdlevel","0","-vf","format=yv12","-noaspect","-nocorrect-pts","-quiet","-autosync","100","-mc","3.0","-framedrop". i have also tried "-nosound" instead of -autosync","100",but not any effect,audio decoded all the same. could somebody tell me how i can solve thie probem ? </pre> lean fu 2012-04-13T10:21:31 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.mplayer.devel