In the structure of MPContext, there are four fields: sh_audio, sh_video; d_audio, d_video. what are differences during sh_* and d_*? 2008-12-04 kedahanzi
Hi All! I update my OSD timestamp patch. Parameters: -osdtime [b|t[r|c|l]]_<format string> (eg.: "bl_%Y-%m-%d\tCam1\t%H:%M:%S") Align: _ : bottom-left (default) b_ : bottom-left t_ : top-left bl_ : bottom-left bc_ : bottom-center br_ : bottom-right tl_ : top-left tc_ : top-center tr_ : top-right Format string: \\ : '\' \_ : ' ' (space) \t : switch horizontal align: left -> center -> right -> left ... \r : switch vertical align: top -> bottom -> top ... (restore vertical align) \n : New line (restore vertical align) %Y : Year (4 digit) %m : Month (decimal number) %d : Day (decimal number) %H : Hour (24h) %S : Minutes %M : Second(Continue reading)
Reset attributes back to normal so that subsequent commands or shell prompt doesn't occasionally inherit them. Just typing `mplayer -v -msgcolor' may result in all subsequent lines colored in green because of vo: x11 uninit called but X11 not initialized.. was the last line from mplayer.
Index: mp_msg.c
===================================================================
--- mp_msg.c (revision 28082)
+++ mp_msg.c (working copy)
@@ -104,6 +104,12 @@
fprintf(stream, "\033[%d;3%dm", c >> 3, c & 7);
}
+static void reset_msg_color(FILE* stream)
+{
+ if (mp_msg_color)
+ fprintf(stream, "\033[0m");
+}
+
static void print_msg_module(FILE* stream, int mod)
{
static const char *module_text[MSGT_MAX] = {
@@ -221,5 +227,6 @@
(Continue reading)On Wed, Dec 3, 2008 at 1:44 PM, Reimar Döffinger <Reimar.Doeffinger <at> stud.uni-karlsruhe.de> wrote: > On Fri, Nov 28, 2008 at 11:15:12PM +0000, Jim Hauxwell wrote: >> OSD is a big patch and has required many goes from me to get the >> formatting correct etc. I think it would be better to have a small >> patch to enhance the OSD later. > > Well, if the vo_direct3d maintainer agrees with that I don't really have > a problem with it. I absolutely agree that the patch should be included!!! I prefer to see the code and try to find problems/improve it myself and discuss it with Jim, who has the know-how. > But there is one issue I just noticed that can't really be ignored > because I can not guarantee that it is not exploitable: > For a source video aspect < 1 the calc_height variable can be larger > than the OSD texture size, allowing to write beyond the bounds of the > texture memory buffer. > Jim, can you fix it and submit the patch again? _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng <at> mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
On Wed, Dec 03, 2008 at 01:09:52PM +0200, Georgi Petrov wrote: > I hope that Jim gets the OSD working good soon, so I > can begin testing his code as well. Well, I won't commit it as long as you haven't looked at it and tested it, and I think he does not want to work on it before the current version has been committed...
Currently _def_pthread_cache never gets emitted in config.h (patch below). Otherwise it seems to be working fine on darwin/Mac OS X. No cache thread related crashes or deadlocks yet. It _seems_ sane enough to enable if pthreads are enabled (just remove the outer if/fi block in configure), but I'll let you guys make the call on that one. I just changed to "if cygwin || darwin" for testing here. -DrD-
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng <at> mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Sorry - this check_events (fixed with the latest patch from Reimar) left from my experiments with the current problem I posted about.
Hi, I have this particular problem. Using MPUI 1.3 (haven't changed since 2006) and Direct3D vo, when I first open a movie, the MPUI initializes the window size to 145/105 pixels and my driver fails, because in doesn't accept odd dimensions values. This is not important. I would start displaying it if it was 146/106 for example. The important thing is that I never receive a resize event to the real movie's dimensions afterward (MPlayer continues to supply frames). When using vo_gl almost the same thing happens - the dimensions are exactly 145/105, BUT before the video begins, vo_gl receives a resize event to the real dimensions. I use the same w32_common code, but I don't receive this event. I'm trying to understand what triggers the resize event in vo_gl and not in my driver, but I'm unable to determine it. Reimar - do you have something in mind? I'll continue my investigation though.
On Tue, 2 Dec 2008 02:51:17 +0100 (CET), Carl Eugen Hoyos wrote: >Hi! > >Attached patch allows playback of files produced with >ffmpeg -i input.file -acodec mp2 output.mov >(See issue737) >Index: etc/codecs.conf >=================================================================== >--- etc/codecs.conf (Revision 27960) >+++ etc/codecs.conf (Arbeitskopie) >@@ -3165,6 +3165,7 @@ > format 0x50 ; layer-1 && layer-2 > format 0x55 ; layer-3 > format 0x5500736d ; "ms\0\x55" older mp3 fcc (MOV files) >+ format 0x5000736D it doesnt bother me, but the file is indeed broken. mov muxer should have the correct tags if mp2 audio can be put in it. be sure to put a comment like the above one for mp3. format 0x5000736D ; "ms\0\x50 older mp2 fcc (MOV files) -compn
On Mon, 2008-12-01 at 15:46 -0700, Kevin DeKorte wrote: > Georgi Petrov wrote: > > I getting mad. I'm sure I fixed whitespace before the opening braces > > as well, but it somehow slipped... I attach the updated patch. > > Isn't there a way to automatically do this using indent rules? Seems > like a lot of conversation over whitespace happens with patches. You can use automatic indent once, but it's not an answer for continuous maintenance. It doesn't always get everything right and you need to fix some things by hand; if you'd run it after every change you'd constantly need to fix the same problems again.
> Isn't there a way to automatically do this using indent rules? Seems
> like a lot of conversation over whitespace happens with patches.
Good point.
About those indentations - I'll switch to a different merger. This one
does a terrible job and 2/3 of the mistakes come from it.
BTW - I removed the whitespace before "(" intentionally. That's the
coding style, right?
>random indention
Not quite. Just trying to stay within this outdated as hell 80 columns
madness...
Reimer, please apply it. I attach a patch with those issues fixed.
Index: libvo/vo_direct3d.c
===================================================================
--- libvo/vo_direct3d.c (revision 28056)
+++ libvo/vo_direct3d.c (working copy)
@@ -168,12 +168,12 @@
priv->is_clear_needed = 1;
}
-/** @brief Destroy D3D Context related to the current window.
+/** @brief Destroy D3D Offscreen and Backbuffer surfaces.
*/
(Continue reading)
RSS Feed50416 |
|---|
