From ranma+mplayer at tdiedrich.de Fri Jul 1 13:15:19 2011 From: ranma+mplayer at tdiedrich.de (Tobias Diedrich) Date: Fri, 1 Jul 2011 13:15:19 +0200 Subject: [MPlayer-dev-eng] [PATCH] Pass down error code from muxer_lavf av_write_header Message-ID: <20110701111519.GD10204@yumi.tdiedrich.de> The proper fix for the division by 0 when av_write_header failed is to pass down the error code and not try to write chunks with the muxer in a bad state. This changes the cont_write_header, muxer_flush and muxer_write_chunk prototypes to return an int (1 on success, 0 on failure) and adjusts all the calling sites. For mencoder I used a small wrapper that calls mencoder_exit if muxer_write_chunk fails, alternatively we could check the success at each call. TOOLS/vivodump.c | 5 ++++- help/help_mp-de.h | 2 +- help/help_mp-en.h | 2 +- help/help_mp-ja.h | 4 ++++ libmpcodecs/ve_lavc.c | 6 +++++- libmpcodecs/ve_libdv.c | 3 +-- libmpcodecs/ve_nuv.c | 6 +++--- libmpcodecs/ve_qtvideo.c | 6 +++++- libmpcodecs/ve_raw.c | 3 +-- libmpcodecs/ve_vfw.c | 3 +-- libmpcodecs/ve_x264.c | 3 ++- libmpcodecs/ve_xvid4.c | 13 ++++++------- libmpdemux/muxer.c | 29 ++++++++++++++++++++--------- libmpdemux/muxer.h | 6 +++--- libmpdemux/muxer_avi.c | 4 +++- libmpdemux/muxer_lavf.c | 6 ++++-- libmpdemux/muxer_mpeg.c | 4 ++-- libmpdemux/muxer_rawaudio.c | 4 ++-- libmpdemux/muxer_rawvideo.c | 4 ++-- mencoder.c | 18 +++++++++++++----- 20 files changed, 83 insertions(+), 48 deletions(-) -- Tobias PGP: http://8ef7ddba.uguu.de -------------- next part -------------- A non-text attachment was scrubbed... Name: muxer_check_errorcode.patch Type: text/x-diff Size: 19304 bytes Desc: not available URL: From diego at biurrun.de Sun Jul 3 13:15:40 2011 From: diego at biurrun.de (Diego Biurrun) Date: Sun, 03 Jul 2011 13:15:40 +0200 Subject: [MPlayer-dev-eng] [PATCH] Pass down error code from muxer_lavf av_write_header In-Reply-To: <20110701111519.GD10204@yumi.tdiedrich.de> References: <20110701111519.GD10204@yumi.tdiedrich.de> Message-ID: <20110703111540.GA9635@pool.informatik.RWTH-Aachen.DE> On Fri, Jul 01, 2011 at 01:15:19PM +0200, Tobias Diedrich wrote: > The proper fix for the division by 0 when av_write_header failed is > to pass down the error code and not try to write chunks with the > muxer in a bad state. > > This changes the cont_write_header, muxer_flush and > muxer_write_chunk prototypes to return an int (1 on success, 0 on > failure) and adjusts all the calling sites. > > For mencoder I used a small wrapper that calls mencoder_exit if > muxer_write_chunk fails, alternatively we could check the success > at each call. I like the patch overall, not sure if the wrapper is better than checking each call. Maybe Reimar has an opinion. > --- libmpcodecs/ve_qtvideo.c.orig 2011-07-01 12:50:40.050956000 +0200 > +++ libmpcodecs/ve_qtvideo.c 2011-07-01 13:03:09.300796000 +0200 > @@ -198,6 +198,7 @@ > int height = mpi->height; > int stride = width*2; > + int ret=0; > @@ -277,7 +278,10 @@ > printf("Ratio: %i:1\n",(stride*height)/compressedsize); > #endif > - muxer_write_chunk(mux_v, compressedsize , similarity?0:0x10, MP_NOPTS_VALUE, MP_NOPTS_VALUE); > + ret=muxer_write_chunk(mux_v, compressedsize , similarity?0:0x10, MP_NOPTS_VALUE, MP_NOPTS_VALUE); Please give the '=' some room to breathe. > --- mencoder.c.orig 2011-07-01 12:50:40.223889000 +0200 > +++ mencoder.c 2011-07-01 13:03:16.532250000 +0200 > @@ -286,6 +286,14 @@ > > + > +static void mencoder_write_chunk(muxer_stream_t *s, size_t len, unsigned int flags, double dts, double pts) nit: Please break this overly long line. Diego From ranma+mplayer at tdiedrich.de Mon Jul 4 20:43:10 2011 From: ranma+mplayer at tdiedrich.de (Tobias Diedrich) Date: Mon, 4 Jul 2011 20:43:10 +0200 Subject: [MPlayer-dev-eng] [PATCH] Pass down error code from muxer_lavf av_write_header In-Reply-To: <20110703111540.GA9635@pool.informatik.RWTH-Aachen.DE> References: <20110701111519.GD10204@yumi.tdiedrich.de> <20110703111540.GA9635@pool.informatik.RWTH-Aachen.DE> Message-ID: <20110704184310.GF19586@yumi.tdiedrich.de> Diego Biurrun wrote: > On Fri, Jul 01, 2011 at 01:15:19PM +0200, Tobias Diedrich wrote: > > The proper fix for the division by 0 when av_write_header failed is > > to pass down the error code and not try to write chunks with the > > muxer in a bad state. > > > > This changes the cont_write_header, muxer_flush and > > muxer_write_chunk prototypes to return an int (1 on success, 0 on > > failure) and adjusts all the calling sites. > > > > For mencoder I used a small wrapper that calls mencoder_exit if > > muxer_write_chunk fails, alternatively we could check the success > > at each call. > > I like the patch overall, not sure if the wrapper is better than > checking each call. Maybe Reimar has an opinion. > > > --- libmpcodecs/ve_qtvideo.c.orig 2011-07-01 12:50:40.050956000 +0200 > > +++ libmpcodecs/ve_qtvideo.c 2011-07-01 13:03:09.300796000 +0200 > > @@ -198,6 +198,7 @@ > > int height = mpi->height; > > int stride = width*2; > > + int ret=0; > > @@ -277,7 +278,10 @@ > > printf("Ratio: %i:1\n",(stride*height)/compressedsize); > > #endif > > - muxer_write_chunk(mux_v, compressedsize , similarity?0:0x10, MP_NOPTS_VALUE, MP_NOPTS_VALUE); > > + ret=muxer_write_chunk(mux_v, compressedsize , similarity?0:0x10, MP_NOPTS_VALUE, MP_NOPTS_VALUE); > > Please give the '=' some room to breathe. Done > > --- mencoder.c.orig 2011-07-01 12:50:40.223889000 +0200 > > +++ mencoder.c 2011-07-01 13:03:16.532250000 +0200 > > @@ -286,6 +286,14 @@ > > > > + > > +static void mencoder_write_chunk(muxer_stream_t *s, size_t len, unsigned int flags, double dts, double pts) > > nit: Please break this overly long line. Done, updated patch attached. -- Tobias PGP: http://8ef7ddba.uguu.de -------------- next part -------------- A non-text attachment was scrubbed... Name: muxer_check_errorcode.patch Type: text/x-diff Size: 19342 bytes Desc: not available URL: From sfsheldo at gmail.com Tue Jul 5 17:54:27 2011 From: sfsheldo at gmail.com (Stephen Sheldon) Date: Tue, 5 Jul 2011 15:54:27 +0000 (UTC) Subject: [MPlayer-dev-eng] [PATCH] gui/win32/dialogs.c Message-ID: The newly named function "gui" conflicts with the variable "gui" in gui/win32/dialogs.c. Here is the error: gui/win32/dialogs.c: In function 'SkinBrowserWndProc': gui/win32/dialogs.c:711:49: error: called object 'gui' is not a function make: *** [gui/win32/dialogs.o] Error 1 Here is a patch: Index: gui/win32/dialogs.c =================================================================== --- gui/win32/dialogs.c (revision 33822) +++ gui/win32/dialogs.c (working copy) @@ -662,7 +662,7 @@ { static HWND listbox; static char skinspath[MAX_PATH]; - gui_t* gui = (gui_t*) GetWindowLongPtr(hwnd, GWLP_USERDATA); + gui_t* mygui = (gui_t*) GetWindowLongPtr(hwnd, GWLP_USERDATA); switch (iMsg) { case WM_CREATE: @@ -718,9 +718,9 @@ strcat(skinspath, skinName); ShowWindow(hwnd, SW_HIDE); Shell_NotifyIcon(NIM_DELETE, &nid); - destroy_window(gui); - create_window(gui, skinspath); - create_subwindow(gui, skinspath); + destroy_window(mygui); + create_window(mygui, skinspath); + create_subwindow(mygui, skinspath); SendMessage(hwnd, WM_CLOSE, 0, 0); /* Avoid crashing when switching skin */ } } From ib at wupperonline.de Tue Jul 5 18:51:38 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo_Br=FCckl?=) Date: Tue, 05 Jul 2011 18:51:38 +0200 Subject: [MPlayer-dev-eng] [PATCH] gui/win32/dialogs.c In-Reply-To: Message-ID: <4e13411d.1fdfda4e.bm000@wupperonline.de> Stephen Sheldon wrote on Tue, 5 Jul 2011 15:54:27 +0000 (UTC): > The newly named function "gui" conflicts with the variable "gui" in > gui/win32/dialogs.c. Sorry. Fixed in svn r33823. Ingo From nm127 at freemail.hu Tue Jul 5 22:30:53 2011 From: nm127 at freemail.hu (=?UTF-8?B?TsOpbWV0aCBNw6FydG9u?=) Date: Tue, 05 Jul 2011 22:30:53 +0200 Subject: [MPlayer-dev-eng] demux_tv_fill_buffer() + V4L2 webcam removal detection? Message-ID: <4E13747D.9040407@freemail.hu> Hi, I'm faceing with the problem that mencoder seems to not detect when a V4L2 webcam is removed during encoding. I digged a little bit in the source code (SVN r33823) and found that the function demux_tv_fill_buffer() from stream/tv.c calls the grab_video_frame() to fetch a new video frame. In case of V4L2 the grab_video_frame() can be found in stream/tvi_v4l2.c file. That function will return zero if there was no frame available. The frames are captured from the V4L2 video device in the thread implemented in video_grabber() in stream/tvi_v4l2.c . This thread exits when there was some kind of unrecoverable error, for example when the VIDIOC_QBUF ioctl() returns -ENODEV. This signals that the device is no longer there. If this is for example an USB webcam then this is what happens when the device is unplugged. I have the following questions: - How will the stream/tvi_v4l2.c:grab_video_frame() function recognise that the video_grabber thread is stopped? - How will the stream/tv.c:demux_tv_fill_buffer() recognise that the video input stream is ended because the webcam was removed? According to the comment at demux_tv_fill_buffer() heading in this case the function shall return 0. Regards, M?rton N?meth From sfsheldo at gmail.com Fri Jul 8 04:26:56 2011 From: sfsheldo at gmail.com (Stephen Sheldon) Date: Fri, 8 Jul 2011 02:26:56 +0000 (UTC) Subject: [MPlayer-dev-eng] [PATCH] more implicit declarations of functions 1/3 Message-ID: Today I realized that when you configure with --enable-debug all the gcc WARNFLAGS are not set, and in particular you do not get "-Werror-implicit-function-declaration" errors, like this: gui/win32/dialogs.c: In function 'display_openfilewindow': gui/win32/dialogs.c:143:21: error: implicit declaration of function uiSetFileName' Several of these have crept into gui/win32. There are functions in interface.c called from dialogs.c and preferences.c, and there are problems with forward references in preferences.c. In an effort to try to keep things in the win32/gui directory, I created a new header file gui/win32/interface.h, which includes gui/interface.h and defines the functions called outside interface.c. The new header file is the first patch. The second patch changes the files in gui/win32 to include it. The third patch moves functions around in gui/win32/interface.c to avoid forward references. Here is the new header file. I don't know how to do with with an actual patch. /* * MPlayer GUI for Win32 * Copyright (C) 2003 Sascha Sommer * Copyright (C) 2006 Erik Augustson * Copyright (C) 2006 Gianluigi Tiesi * * This file is part of MPlayer. * * MPlayer is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * MPlayer is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License along * with MPlayer; if not, write to the Free Software Foundation, Inc., * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ #ifndef MPLAYER_GUI_WIN32_INTERFACE_H #define MPLAYER_GUI_WIN32_INTERFACE_H #include "gui/interface.h" void uiSetFileName (char *, char *, int); void gaddlist(char ***, const char *); #endif From sfsheldo at gmail.com Fri Jul 8 04:33:11 2011 From: sfsheldo at gmail.com (Stephen Sheldon) Date: Fri, 8 Jul 2011 02:33:11 +0000 (UTC) Subject: [MPlayer-dev-eng] =?utf-8?q?=5BPATCH=5D_more_implicit_declaration?= =?utf-8?q?s_of_functions=092/3?= References: Message-ID: This is the second patch to actually include the new header file: Index: gui/win32/preferences.c =================================================================== --- gui/win32/preferences.c (revision 33847) +++ gui/win32/preferences.c (working copy) @@ -32,7 +32,7 @@ #include "osdep/priority.h" #include "mixer.h" #include "gui/ui/gmplayer.h" -#include "gui/interface.h" +#include "gui/win32/interface.h" #include "gui.h" #include "mp_msg.h" #include "help_mp.h" Index: gui/win32/dialogs.c =================================================================== --- gui/win32/dialogs.c (revision 33847) +++ gui/win32/dialogs.c (working copy) @@ -24,7 +24,7 @@ #include #include #include "path.h" -#include "gui/interface.h" +#include "gui/win32/interface.h" #include "mp_msg.h" #include "help_mp.h" #include "mpcommon.h" Index: gui/win32/widgetrender.c =================================================================== --- gui/win32/widgetrender.c (revision 33847) +++ gui/win32/widgetrender.c (working copy) @@ -26,7 +26,7 @@ #include #include "gui/util/bitmap.h" -#include "gui/interface.h" +#include "gui/win32/interface.h" #include "gui.h" #define MAX_LABELSIZE 250 Index: gui/win32/gui.c =================================================================== --- gui/win32/gui.c (revision 33847) +++ gui/win32/gui.c (working copy) @@ -40,7 +40,7 @@ #include "stream/stream.h" #include "libvo/video_out.h" #include "libmpcodecs/vd.h" -#include "gui/interface.h" +#include "gui/win32/interface.h" #include "gui/ui/gmplayer.h" #include "gui.h" #include "dialogs.h" Index: gui/win32/wincfg.c =================================================================== --- gui/win32/wincfg.c (revision 33847) +++ gui/win32/wincfg.c (working copy) @@ -35,7 +35,7 @@ #include "osdep/priority.h" #include "mixer.h" #include "gui/ui/gmplayer.h" -#include "gui/interface.h" +#include "gui/win32/interface.h" #include "gui.h" /* params */ From sfsheldo at gmail.com Fri Jul 8 04:35:54 2011 From: sfsheldo at gmail.com (Stephen Sheldon) Date: Fri, 8 Jul 2011 02:35:54 +0000 (UTC) Subject: [MPlayer-dev-eng] =?utf-8?q?=5BPATCH=5D_more_implicit_declaration?= =?utf-8?q?s_of_functions=093/3?= References: Message-ID: In this patch I move functions around in gui/win32/interface.c to avoid forward references. Index: gui/win32/interface.c =================================================================== --- gui/win32/interface.c (revision 33847) +++ gui/win32/interface.c (working copy) @@ -30,7 +30,7 @@ #endif #include "path.h" -#include "gui/interface.h" +#include "gui/win32/interface.h" #include "m_option.h" #include "mixer.h" #include "mp_msg.h" @@ -156,6 +156,116 @@ (*list)[i + 1] = NULL; } +void uiPause( void ) +{ + if(!guiInfo.Playing) return; + + if(guiInfo.Playing == GUI_PLAY) + { + mp_cmd_t * cmd = calloc(1, sizeof(*cmd)); + cmd->id=MP_CMD_PAUSE; + cmd->name=strdup("pause"); + mp_input_queue_cmd(cmd); + } else guiInfo.Playing = GUI_PLAY; +} + +void uiPlay( void ) +{ + if((!guiInfo.Filename ) || (guiInfo.Filename[0] == 0)) + return; + + if(guiInfo.Playing > GUI_STOP) + { + uiPause(); + return; + } + guiInfo.NewPlay = 1; + gui(GUI_SET_STATE, (void *) GUI_PLAY); +} + +void uiNext(void) +{ + if(guiInfo.Playing == GUI_PAUSE) return; + switch(guiInfo.StreamType) + { +#ifdef CONFIG_DVDREAD + case STREAMTYPE_DVD: + if(guiInfo.DVD.current_chapter == (guiInfo.DVD.chapters - 1)) + return; + guiInfo.DVD.current_chapter++; + break; +#endif + default: + if(mygui->playlist->current == (mygui->playlist->trackcount - 1)) + return; + uiSetFileName(NULL, mygui->playlist->tracks[(mygui->playlist->current)++]->filename, + STREAMTYPE_STREAM); + break; + } + mygui->startplay(mygui); +} + +void uiPrev(void) +{ + if(guiInfo.Playing == GUI_PAUSE) return; + switch(guiInfo.StreamType) + { +#ifdef CONFIG_DVDREAD + case STREAMTYPE_DVD: + if(guiInfo.DVD.current_chapter == 1) + return; + guiInfo.DVD.current_chapter--; + break; +#endif + default: + if(mygui->playlist->current == 0) + return; + uiSetFileName(NULL, mygui->playlist->tracks[(mygui->playlist->current)--]->filename, + STREAMTYPE_STREAM); + break; + } + mygui->startplay(mygui); +} + +void uiSetFileName(char *dir, char *name, int type) +{ + if(!name) return; + if(!dir) + setdup(&guiInfo.Filename, name); + else + setddup(&guiInfo.Filename, dir, name); + + guiInfo.StreamType = type; + free(guiInfo.AudioFile); + guiInfo.AudioFile = NULL; + free(guiInfo.Subtitlename); + guiInfo.Subtitlename = NULL; +} + +void uiFullScreen( void ) +{ + if(!guiInfo.sh_video) return; + + if(sub_window) + { + if(!fullscreen && IsWindowVisible(mygui->subwindow) && !IsIconic(mygui->subwindow)) + GetWindowRect(mygui->subwindow, &old_rect); + + if(fullscreen) + { + fullscreen = 0; + style = WS_OVERLAPPEDWINDOW | WS_SIZEBOX; + } else { + fullscreen = 1; + style = WS_VISIBLE | WS_POPUP; + } + SetWindowLong(mygui->subwindow, GWL_STYLE, style); + update_subwindow(); + } + video_out->control(VOCTRL_FULLSCREEN, 0); + if(sub_window) ShowWindow(mygui->subwindow, SW_SHOW); +} + /* this function gets called by the gui to update mplayer */ static void guiSetEvent(int event) { @@ -326,116 +436,6 @@ } } -void uiPlay( void ) -{ - if((!guiInfo.Filename ) || (guiInfo.Filename[0] == 0)) - return; - - if(guiInfo.Playing > GUI_STOP) - { - uiPause(); - return; - } - guiInfo.NewPlay = 1; - gui(GUI_SET_STATE, (void *) GUI_PLAY); -} - -void uiPause( void ) -{ - if(!guiInfo.Playing) return; - - if(guiInfo.Playing == GUI_PLAY) - { - mp_cmd_t * cmd = calloc(1, sizeof(*cmd)); - cmd->id=MP_CMD_PAUSE; - cmd->name=strdup("pause"); - mp_input_queue_cmd(cmd); - } else guiInfo.Playing = GUI_PLAY; -} - -void uiNext(void) -{ - if(guiInfo.Playing == GUI_PAUSE) return; - switch(guiInfo.StreamType) - { -#ifdef CONFIG_DVDREAD - case STREAMTYPE_DVD: - if(guiInfo.DVD.current_chapter == (guiInfo.DVD.chapters - 1)) - return; - guiInfo.DVD.current_chapter++; - break; -#endif - default: - if(mygui->playlist->current == (mygui->playlist->trackcount - 1)) - return; - uiSetFileName(NULL, mygui->playlist->tracks[(mygui->playlist->current)++]->filename, - STREAMTYPE_STREAM); - break; - } - mygui->startplay(mygui); -} - -void uiPrev(void) -{ - if(guiInfo.Playing == GUI_PAUSE) return; - switch(guiInfo.StreamType) - { -#ifdef CONFIG_DVDREAD - case STREAMTYPE_DVD: - if(guiInfo.DVD.current_chapter == 1) - return; - guiInfo.DVD.current_chapter--; - break; -#endif - default: - if(mygui->playlist->current == 0) - return; - uiSetFileName(NULL, mygui->playlist->tracks[(mygui->playlist->current)--]->filename, - STREAMTYPE_STREAM); - break; - } - mygui->startplay(mygui); -} - -void uiSetFileName(char *dir, char *name, int type) -{ - if(!name) return; - if(!dir) - setdup(&guiInfo.Filename, name); - else - setddup(&guiInfo.Filename, dir, name); - - guiInfo.StreamType = type; - free(guiInfo.AudioFile); - guiInfo.AudioFile = NULL; - free(guiInfo.Subtitlename); - guiInfo.Subtitlename = NULL; -} - -void uiFullScreen( void ) -{ - if(!guiInfo.sh_video) return; - - if(sub_window) - { - if(!fullscreen && IsWindowVisible(mygui->subwindow) && !IsIconic(mygui->subwindow)) - GetWindowRect(mygui->subwindow, &old_rect); - - if(fullscreen) - { - fullscreen = 0; - style = WS_OVERLAPPEDWINDOW | WS_SIZEBOX; - } else { - fullscreen = 1; - style = WS_VISIBLE | WS_POPUP; - } - SetWindowLong(mygui->subwindow, GWL_STYLE, style); - update_subwindow(); - } - video_out->control(VOCTRL_FULLSCREEN, 0); - if(sub_window) ShowWindow(mygui->subwindow, SW_SHOW); -} - static unsigned __stdcall GuiThread(void* param) { MSG msg; From ib at wupperonline.de Fri Jul 8 09:46:57 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo_Br=FCckl?=) Date: Fri, 08 Jul 2011 09:46:57 +0200 Subject: [MPlayer-dev-eng] [PATCH] more implicit declarations of functions 1/3 In-Reply-To: Message-ID: <4e16d395.7c244f52.bm000@wupperonline.de> Stephen Sheldon wrote on Fri, 8 Jul 2011 02:26:56 +0000 (UTC): > Today I realized that when you configure with --enable-debug all the > gcc WARNFLAGS are not set, and in particular you do not get > "-Werror-implicit-function-declaration" errors, like this: > gui/win32/dialogs.c: In function 'display_openfilewindow': > gui/win32/dialogs.c:143:21: error: implicit declaration of function > uiSetFileName' > Several of these have crept into gui/win32. Thank you very much for your interest in the Win32 GUI. Although I'm able to compile it meanwhile with winegcc to check for the biggest mistakes, I haven't made further efforts, because I'm not using Windows. So I very much appreciate an active user. I'm interested in improving the Win32 GUI, but I don't think that a new gui/win32/interface.h is the right way. I'd rather take a completely different (aiming at a more drastic) approach I'd like to explain. The last days I've made efforts to clean up the interface between a GUI and MPlayer, so that it only contains stuff really needed between the both of them, and have moved all other, only GUI related stuff away. The long-term plan is to separate the GUI from MPlayer and to establish an extended master/slave mode between them, so the interface between them should be as small as possible and clearly defined (a goal which we are still far away from). The interface between MPlayer and a GUI is described in interface.h and there should be only one such file (realization takes place in interface.c). Just as there is a relationship between MPlayer and a GUI there is one between the GUIs (currently X11/GTK and Win32) as well. Both GUIs could and should use far more common code, but currently there is GUI related and window manager related code mixed, and the Win32 GUI even contains code identical to the X11/GTK GUI. (Most of the code you are moving in your third patch is identical to code already existing in the X11/GTK GUI.) As a result, X11/GTK code parts get fixed and improved, but Win32 parts often stay like they were. A cleaner approach than the current one would be: MPlayer <-> interface <-> GUI = common stuff + window manager related stuff where "window manger related stuff" is X11+GTK or Windows or something else. The only difference between the two GUIs then should be (a "small" amount of) window manger related stuff, and a GUI for a different platform could be created by only providing such new stuff. At some point I might start rebuilding the Win32 GUI that way. For now, please see svn r33849, which should fix the problems in this sense. Ingo From diego at biurrun.de Fri Jul 8 15:18:18 2011 From: diego at biurrun.de (Diego Biurrun) Date: Fri, 08 Jul 2011 15:18:18 +0200 Subject: [MPlayer-dev-eng] [PATCH] more implicit declarations of functions 1/3 In-Reply-To: References: Message-ID: <20110708131818.GA19969@pool.informatik.RWTH-Aachen.DE> On Fri, Jul 08, 2011 at 02:26:56AM +0000, Stephen Sheldon wrote: > > Several of these have crept into gui/win32. There are functions in > interface.c called from dialogs.c and preferences.c, and there are > problems with forward references in preferences.c. > In an effort to try to keep things in the win32/gui directory, > I created a new header file gui/win32/interface.h, which includes > gui/interface.h and defines the functions called outside interface.c. No, the function declarations should be in gui/interface.h if the symbols are exported from gui/interface.c. > The new header file is the first patch. The second patch changes the > files in gui/win32 to include it. This should be one patch. > Here is the new header file. I don't know how to do with with an actual > patch. svn add Diego From sfsheldo at gmail.com Fri Jul 8 16:30:48 2011 From: sfsheldo at gmail.com (Stephen Sheldon) Date: Fri, 8 Jul 2011 14:30:48 +0000 (UTC) Subject: [MPlayer-dev-eng] =?utf-8?q?=5BPATCH=5D_more_implicit_declaration?= =?utf-8?q?s_of=09functions_1/3?= References: <4e16d395.7c244f52.bm000@wupperonline.de> Message-ID: Ingo Br?ckl wupperonline.de> writes: > A cleaner approach than the current one would be: > > MPlayer <-> interface <-> GUI = common stuff + window manager related stuff > > where "window manger related stuff" is X11+GTK or Windows or something else. > > The only difference between the two GUIs then should be (a "small" amount of) > window manger related stuff, and a GUI for a different platform could be > created by only providing such new stuff. > At some point I might start rebuilding the Win32 GUI that way. > > For now, please see svn r33849, which should fix the problems in this sense. > > Ingo > Mplayer compiles without error without my patches, so thank you for that. Would you want patches to clean some of the duplicate code out of gui/win32? Right now the easiest one to do would be to get rid of the string stuff and use the gui/util/string.o object. Also the list stuff would be easy. Shall I direct my energies that way? From ib at wupperonline.de Fri Jul 8 17:06:00 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo_Br=FCckl?=) Date: Fri, 08 Jul 2011 17:06:00 +0200 Subject: [MPlayer-dev-eng] [PATCH] more implicit declarations of functions 1/3 In-Reply-To: Message-ID: <4e1720ab.71b22f20.bm000@wupperonline.de> Stephen Sheldon wrote on Fri, 8 Jul 2011 14:30:48 +0000 (UTC): > Would you want patches to clean some of the duplicate code out of > gui/win32? > Right now the easiest one to do would be to get rid of the string stuff > and use the gui/util/string.o object. Also the list stuff would be easy. > Shall I direct my energies that way? That would be great. The string and list stuff is very obviously duplicate, but there is other stuff like the ui functions which are either identical or only slightly different. I'd like them to be commonly used, too. (If there are differences we should figure out why and harmonize.) And then there is the skin(load), widget(render) and config stuff that doesn't need to exist twice. But let's take one step at a time... Ingo From sfsheldo at gmail.com Sun Jul 10 16:24:53 2011 From: sfsheldo at gmail.com (Stephen Sheldon) Date: Sun, 10 Jul 2011 14:24:53 +0000 (UTC) Subject: [MPlayer-dev-eng] [PATCH] remove some common code from gui/win32/interface.c Message-ID: This patch removes the duplicated code from from gui/win32/interface.c which is also in gui/util/list.c and gui/util/string.c. It moves the object files from the gtk section of the make file to the common section. Index: Makefile =================================================================== --- Makefile (revision 33866) +++ Makefile (working copy) @@ -517,7 +517,9 @@ SRCS_MPLAYER-$(GL_WIN32) += libvo/w32_common.c SRCS_MPLAYER-$(GL_X11) += libvo/x11_common.c SRCS_MPLAYER-$(MATRIXVIEW) += libvo/vo_matrixview.c libvo/matrixview.c -SRCS_MPLAYER-$(GUI) += gui/util/bitmap.c +SRCS_MPLAYER-$(GUI) += gui/util/bitmap.c \ + gui/util/list.c \ + gui/util/string.c SRCS_MPLAYER-$(GUI_GTK) += gui/app.c \ gui/cfg.c \ gui/interface.c \ @@ -541,8 +543,6 @@ gui/ui/sub.c \ gui/ui/widgets.c \ gui/util/cut.c \ - gui/util/list.c \ - gui/util/string.c \ gui/wm/ws.c \ gui/wm/wsxdnd.c \ Index: gui/win32/interface.c =================================================================== --- gui/win32/interface.c (revision 33866) +++ gui/win32/interface.c (working copy) @@ -94,72 +94,6 @@ return 0; } -char *gstrdup(const char *str) -{ - if (!str) return NULL; - return strdup(str); -} - -void setdup (char **old, const char *str) -{ - free(*old); - *old = gstrdup(str); -} - -void setddup (char **old, const char *dir, const char *name) -{ - free(*old); - *old = malloc(strlen(dir) + strlen(name) + 2); - if (*old) sprintf(*old, "%s/%s", dir, name); -} - -/** - * \brief this actually creates a new list containing only one element... - */ -void gaddlist( char ***list, const char *entry) -{ - int i; - - if (*list) - { - for (i=0; (*list)[i]; i++) free((*list)[i]); - free(*list); - } - - *list = malloc(2 * sizeof(char **)); - (*list)[0] = gstrdup(entry); - (*list)[1] = NULL; -} - -/** - * \brief this replaces a string starting with search by replace. - * If not found, replace is appended. - */ -void greplace(char ***list, const char *search, const char *replace) -{ - int i = 0; - int len = (search) ? strlen(search) : 0; - - if (*list) - { - for (i = 0; (*list)[i]; i++) - { - if (search && (!strncmp((*list)[i], search, len))) - { - free((*list)[i]); - (*list)[i] = gstrdup(replace); - return; - } - } - *list = realloc(*list, (i + 2) * sizeof(char *)); - } - else - *list = malloc(2 * sizeof(char *)); - - (*list)[i] = gstrdup(replace); - (*list)[i + 1] = NULL; -} - /* this function gets called by the gui to update mplayer */ static void guiSetEvent(int event) { From ib at wupperonline.de Sun Jul 10 17:50:01 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo_Br=FCckl?=) Date: Sun, 10 Jul 2011 17:50:01 +0200 Subject: [MPlayer-dev-eng] [PATCH] remove some common code from gui/win32/interface.c In-Reply-To: Message-ID: <4e19ca2a.73cb41eb.bm000@wupperonline.de> Stephen Sheldon wrote on Sun, 10 Jul 2011 14:24:53 +0000 (UTC): > This patch removes the duplicated code from from gui/win32/interface.c > which is also in gui/util/list.c and gui/util/string.c. It moves the > object files from the gtk section of the make file to the common section. Thanks. Applied in two steps. Step 1: string, step 2: list. Ingo From mociml at 163.com Mon Jul 11 06:13:27 2011 From: mociml at 163.com (mociml) Date: Mon, 11 Jul 2011 12:13:27 +0800 (CST) Subject: [MPlayer-dev-eng] mplayer stream cache adjustment mechanism Message-ID: <273e2fbf.6006.1311766558d.Coremail.mociml@163.com> hello everyone ,When playing online stream over http, we can set "-cache=4096 ,-cache-min=10",to indicate the first time cache fill percent before playing, but when time lapse ,maybe network is slow,so cache is empty or left little! mplayer play stream faster than fill cache,at this time mplayer stucked and continue playing stream , stucked ,play ,stucked , play !so the whole stream is hard to view smoothly!In my opinion,this time mplayer should pause and wait for cache filled enough to play smoothly! this is not a bug,but maybe hard to view for users ,so dos anyone has good idea to solve this ,or a point to debug info ? From sgreene at cs.binghamton.edu Mon Jul 11 21:50:50 2011 From: sgreene at cs.binghamton.edu (Steaphan Greene) Date: Mon, 11 Jul 2011 15:50:50 -0400 Subject: [MPlayer-dev-eng] [PATCH] Stereo3D Half-Width Side-By-Side Formats. In-Reply-To: <4E07344C.5030905@cs.binghamton.edu> References: <4E07344C.5030905@cs.binghamton.edu> Message-ID: <4E1B541A.1010104@cs.binghamton.edu> On 06/26/2011 09:29 AM, Steaphan Greene wrote: > The attached patch adds half-width side-by-side formats, for both input > and output, to the stereo3d plugin. This format is rather common, as a > halfway step for encoding 3D video files before it was standardized in > blu-ray 3D, and as a supported input format for many 3D displays. > > I tried to stick with the conventions already in use in this file for > format naming and code layout. Since there already is support for the > half-height above-below formats, this was pretty straight-forward. > > This patch also updates the man page (English only) with details on > these new input and output formats. My more critical patch has proven to be unexpectedly controversial. However, I believe this patch is perfectly innocuous, safe, and useful. So, if someone could commit this one at least, that would be appreciated. I've attached it again here, for clarity - and in case the signature I included with my original e-mail threw anyone off. I've updated it to be diffed off the current version of subversion (r33876) - though the original patch I sent still works fine as well. Thanks. -- Steaphan Greene Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: mplayer_stereo3d_half_width_side-by-side.patch Type: text/x-patch Size: 3415 bytes Desc: not available URL: From Reimar.Doeffinger at gmx.de Mon Jul 11 23:58:30 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Mon, 11 Jul 2011 23:58:30 +0200 Subject: [MPlayer-dev-eng] [PATCH] Stereo3D Half-Width Side-By-Side Formats. In-Reply-To: <4E1B541A.1010104@cs.binghamton.edu> References: <4E07344C.5030905@cs.binghamton.edu> <4E1B541A.1010104@cs.binghamton.edu> Message-ID: <20110711215830.GA2860@1und1.de> On Mon, Jul 11, 2011 at 03:50:50PM -0400, Steaphan Greene wrote: > On 06/26/2011 09:29 AM, Steaphan Greene wrote: > > The attached patch adds half-width side-by-side formats, for both input > > and output, to the stereo3d plugin. This format is rather common, as a > > halfway step for encoding 3D video files before it was standardized in > > blu-ray 3D, and as a supported input format for many 3D displays. > > > > I tried to stick with the conventions already in use in this file for > > format naming and code layout. Since there already is support for the > > half-height above-below formats, this was pretty straight-forward. > > > > This patch also updates the man page (English only) with details on > > these new input and output formats. > > My more critical patch has proven to be unexpectedly controversial. > However, I believe this patch is perfectly innocuous, safe, and useful. > So, if someone could commit this one at least, that would be appreciated. I simply wasn't aware of it (any more). Please be sure to remind, nowadays I basically never have time to go through my list archives to look for lost patches on my own. Applied. From Reimar.Doeffinger at gmx.de Tue Jul 12 00:02:18 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Tue, 12 Jul 2011 00:02:18 +0200 Subject: [MPlayer-dev-eng] [PATCH] Fix Pause/Break Key In-Reply-To: <20110612180724.GB16049@pool.informatik.RWTH-Aachen.DE> References: <4DF1AFA7.6070200@cs.binghamton.edu> <4DF24CA3.7020309@cs.binghamton.edu> <20110612180724.GB16049@pool.informatik.RWTH-Aachen.DE> Message-ID: <20110711220218.GB2860@1und1.de> On Sun, Jun 12, 2011 at 08:07:24PM +0200, Diego Biurrun wrote: > On Fri, Jun 10, 2011 at 12:56:03PM -0400, Steaphan Greene wrote: > > On 06/10/2011 04:32 AM, Carl Eugen Hoyos wrote: > > > Steaphan Greene cs.binghamton.edu> writes: > > > > > >> The (simple) attached patch fixes the pause/break key for X11 systems > > >> (in non-gui mode). This makes it able to be bound as KEY_PAUSE, as I > > >> believe was intended. > > > > > > Please consider sending uncompressed patches. > > > > Ok. The uncompressed version is attached. > > Looks good, I will apply after testing it. Hm, ping? From ib at wupperonline.de Tue Jul 12 00:09:43 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo_Br=FCckl?=) Date: Tue, 12 Jul 2011 00:09:43 +0200 Subject: [MPlayer-dev-eng] [PATCH] Fix Pause/Break Key In-Reply-To: <20110711220218.GB2860@1und1.de> Message-ID: <4e1b74a9.1d42a11f.bm000@wupperonline.de> Reimar D?ffinger wrote on Tue, 12 Jul 2011 00:02:18 +0200: > On Sun, Jun 12, 2011 at 08:07:24PM +0200, Diego Biurrun wrote: >> On Fri, Jun 10, 2011 at 12:56:03PM -0400, Steaphan Greene wrote: >> > On 06/10/2011 04:32 AM, Carl Eugen Hoyos wrote: >> > > Steaphan Greene cs.binghamton.edu> writes: >> > > >> > >> The (simple) attached patch fixes the pause/break key for X11 systems >> > >> (in non-gui mode). This makes it able to be bound as KEY_PAUSE, as I >> > >> believe was intended. >> > > >> > > Please consider sending uncompressed patches. >> > >> > Ok. The uncompressed version is attached. >> >> Looks good, I will apply after testing it. > Hm, ping? Got applied in r33609. Ingo From sgreene at cs.binghamton.edu Tue Jul 12 03:02:11 2011 From: sgreene at cs.binghamton.edu (Steaphan Greene) Date: Mon, 11 Jul 2011 21:02:11 -0400 Subject: [MPlayer-dev-eng] [PATCH] Stereo3D Half-Width Side-By-Side Formats. In-Reply-To: <20110711215830.GA2860@1und1.de> References: <4E07344C.5030905@cs.binghamton.edu> <4E1B541A.1010104@cs.binghamton.edu> <20110711215830.GA2860@1und1.de> Message-ID: <4E1B9D13.8090407@cs.binghamton.edu> On 07/11/2011 05:58 PM, Reimar D?ffinger wrote: > On Mon, Jul 11, 2011 at 03:50:50PM -0400, Steaphan Greene wrote: >> I believe this patch is perfectly innocuous, safe, and useful. >> So, if someone could commit this one at least, that would be appreciated. > > I simply wasn't aware of it (any more). Please be sure to remind, > nowadays I basically never have time to go through my list archives to > look for lost patches on my own. > Applied. Excellent, thanks - and thanks for the advise. I will post a follow-up about the other problem and suggested patch (the only remaining one I am waiting on now, after this) in a few minutes. -- Steaphan Greene Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt From sgreene at cs.binghamton.edu Tue Jul 12 03:17:44 2011 From: sgreene at cs.binghamton.edu (Steaphan Greene) Date: Mon, 11 Jul 2011 21:17:44 -0400 Subject: [MPlayer-dev-eng] [PATCH] Fix for mpeg2 A/V sync bug. In-Reply-To: <20110626184958.GA10462@1und1.de> References: <4E049191.4050607@cs.binghamton.edu> <20110626184958.GA10462@1und1.de> Message-ID: <4E1BA0B8.8040903@cs.binghamton.edu> On 06/26/2011 02:49 PM, Reimar D?ffinger wrote: > On Fri, Jun 24, 2011 at 09:30:57AM -0400, Steaphan Greene wrote: >> The attached patch fixes the bug with vob files (and, presumably other >> mpeg2 content) caused by the A/V sync code added with r32055/32056. I >> believe this solution should cause no other harm. >> >> Basically, it now just removes the last_pts data when one of these pts >> changes occurs in the mpeg2 stream. That way, the A/V resync code in >> question ignores this frame, and no longer breaks anything. > > But this is not code for non-uniform time-stamps really but it is > reordering. > And my suspicion is that your change only makes it so that non-B-frames > which MPlayer can detect break the other correction code you pointed out before. > If so you could just avoid the obfuscation and put the whole other code > under "if codec != MPEG-2" for exactly the same effect. I've attached an updated version of my band-aid for this bug based on current svn (r33877). I believe this is still correct, as, if I am understanding you correctly, this case is due to an out-of-order frame, which means that the time stored in last_pts really was not correct, as it did not actually store the pts of the truly-previous frame. ...I hope that explanation made sense to more people than just me. I have updated the comment to reflect this. Of course, I could still be wrong about exactly what's happening here. I am only confident from my traces that this fixes the problem I found, and only this problem, and causes no other harm. Without this patch, the current version of mplayer in SVN is not able to properly play most of my DVDs. So, unless a better solution is obvious, I'd request this patch be applied. Thanks. -- Steaphan Greene Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: mplayer_mpeg2_sync_failure_fix.svn33877.patch Type: text/x-patch Size: 575 bytes Desc: not available URL: From sgreene at cs.binghamton.edu Wed Jul 13 03:03:08 2011 From: sgreene at cs.binghamton.edu (Steaphan Greene) Date: Tue, 12 Jul 2011 21:03:08 -0400 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav Message-ID: <4E1CEECC.8010404@cs.binghamton.edu> Can anyone explain (or point me to an explanation of) the plan with the duplication between dvdnav:// and dvd:// in current mplayer? Basically, is this split/duplication intended to be permanent, or is this just the current state, awaiting improvement? As is, there are some things dvdnav: is better at (menus/navigation), and some things dvd: is better at (faster angle switching, smoother transitions). Is there any interest in merging these two, or, at least, obsoleting one by adding features to the other? I might be interested in trying the second choice myself. Either way, if I were to work on adding features to one or the other, which one should I add the features to, if it can not be added to both via common code? My eventual interest is in helping to complete blu-ray play/navigation support. But, of course, that is a long way off, so this seemed like a better place to start. In the meantime, I thought the ability to play multiple DVD angles at once might be neat (in fact, it is neat, and is possible via udp sync, but a bit cumbersome, and currently incompatible with most navigation). -- Steaphan Greene Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt From auerswal at unix-ag.uni-kl.de Wed Jul 13 09:18:06 2011 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Wed, 13 Jul 2011 09:18:06 +0200 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1CEECC.8010404@cs.binghamton.edu> References: <4E1CEECC.8010404@cs.binghamton.edu> Message-ID: <20110713071806.GA28856@sushi.unix-ag.uni-kl.de> Hi, On Tue, Jul 12, 2011 at 09:03:08PM -0400, Steaphan Greene wrote: > Can anyone explain (or point me to an explanation of) the plan with the > duplication between dvdnav:// and dvd:// in current mplayer? > > Basically, is this split/duplication intended to be permanent, or is > this just the current state, awaiting improvement? As is, there are > some things dvdnav: is better at (menus/navigation), and some things > dvd: is better at (faster angle switching, smoother transitions). > > Is there any interest in merging these two, or, at least, obsoleting one > by adding features to the other? I might be interested in trying the > second choice myself. FWIW I really like the dvd:// method of playing a DVD, because I usually just want to watch the movie without working my way through menus. So from a user's perspective I'd prefer this to be retained. But don't let this stop you from adding features to and/or improving the dvdnav:// method! Regards, Erik From sgreene at cs.binghamton.edu Wed Jul 13 09:44:24 2011 From: sgreene at cs.binghamton.edu (Steaphan Greene) Date: Wed, 13 Jul 2011 03:44:24 -0400 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <20110713071806.GA28856@sushi.unix-ag.uni-kl.de> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713071806.GA28856@sushi.unix-ag.uni-kl.de> Message-ID: <4E1D4CD8.80805@cs.binghamton.edu> On 07/13/2011 03:18 AM, Erik Auerswald wrote: > On Tue, Jul 12, 2011 at 09:03:08PM -0400, Steaphan Greene wrote: >> Can anyone explain (or point me to an explanation of) the plan with the >> duplication between dvdnav:// and dvd:// in current mplayer? >> >> Is there any interest in merging these two, or, at least, obsoleting one >> by adding features to the other? I might be interested in trying the >> second choice myself. > > FWIW I really like the dvd:// method of playing a DVD, because I usually > just want to watch the movie without working my way through menus. So > from a user's perspective I'd prefer this to be retained. Unless I am missing something, simply playing a track can be done with either quite well (eg. "dvd://3" and "dvdnav://3" basically act exactly the same until you hit menus, or try to change angles, etc...). I generally prefer the dvd:// method too, just for better performance, unless I need the menus to navigate more complex content (like getting at a disc's special features). -- Steaphan Greene Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt From alex at roalter.it Wed Jul 13 12:06:16 2011 From: alex at roalter.it (Alexander Roalter) Date: Wed, 13 Jul 2011 12:06:16 +0200 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1D4CD8.80805@cs.binghamton.edu> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713071806.GA28856@sushi.unix-ag.uni-kl.de> <4E1D4CD8.80805@cs.binghamton.edu> Message-ID: <4E1D6E18.80504@roalter.it> On 13.07.2011 09:44, Steaphan Greene wrote: > On 07/13/2011 03:18 AM, Erik Auerswald wrote: > I generally prefer the dvd:// method too, just for better performance, > unless I need the menus to navigate more complex content (like getting > at a disc's special features). > for that, dvd://1-99 would also suffice, so you can emulate a "Play All" feature. dvdnav has the advantage that it works with copy protected DVDs that use deliberately erroneous bad sectors placed in the normal stream. dvdnav navigates around them via the cell commands, and dvd doesn't, leaving some DVDs unplayable. Nowadays, I always use dvdnav instead of dvd, angle switching is something I never use, but currently on some chapter breaks dvdnav still gets a 'hickup' instead of playing smoothly through it. And I have a bunch of DVDs that won't play at all (only the dumped variant -dumpstream, in connection with dvdnav) will play when stored as a file (also b/c of copy protection, but apparently dvdnav has a problem handling these cell commands. I have also an issue with german Star Trek XI and Transformers II (both from Paramount), which also have some sort of copy protection, and here cell navigation and hickup at chapter break come together making it tiresome to watch. dumpstream on the other hand delivers a completely different result ?? I'd really like to see the dvdnav improved in that matter, i.e. - no hickup at chapter breaks, - playback of the remaining problematic DVDs - correct seeking: currently, with some DVDs seeking within a certain range always seeks to the same position: an example: Transformers 2 DVD: has 99 titles on the main feature disc, most of them are 'false' titles that play only a shortened version of the movie (some chapters missing, others playing in different order). Going through the menu (with -v and dvdnav), I see that title 9 is the correct title to play. It also has the correct length on -identify Now at chapter 4, roughly 14 minutes into the movie, comes a chapter break, that is not handled well: macroblock pixelation, audio hickup. When I seek to this position I land at 9 minutes and pressing forward 10 seconds I get to something like 9:40, but pressing forward again, I still get to 9:40. I can let the movie play beyond this position up until 12 minutes, pressing forward still gets me back to 9:40. So getting to the 14 minutes position is only doable when playing it out at normal speed, no seeking. And if I use dumpstream instead of normal playback, after chapter 4 doesn't come chapter 5, but again it jumps back to chapter 3. I can provide more info and a clearer analysis if needed. -- cheers, Alex From tempn at twmi.rr.com Wed Jul 13 13:45:03 2011 From: tempn at twmi.rr.com (compn) Date: Wed, 13 Jul 2011 07:45:03 -0400 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1CEECC.8010404@cs.binghamton.edu> References: <4E1CEECC.8010404@cs.binghamton.edu> Message-ID: <20110713074503.657a3af1.tempn@twmi.rr.com> On Tue, 12 Jul 2011 21:03:08 -0400, Steaphan Greene wrote: >Can anyone explain (or point me to an explanation of) the plan with the >duplication between dvdnav:// and dvd:// in current mplayer? might want to ask nico for his plans. >Basically, is this split/duplication intended to be permanent, or is >this just the current state, awaiting improvement? As is, there are >some things dvdnav: is better at (menus/navigation), and some things >dvd: is better at (faster angle switching, smoother transitions). i'm not sure if we have plans, due to people liking dvd:// but also needing dvdnav:// for menus. >Is there any interest in merging these two, or, at least, obsoleting one >by adding features to the other? I might be interested in trying the >second choice myself. > >Either way, if I were to work on adding features to one or the other, >which one should I add the features to, if it can not be added to both >via common code? maybe reimar knows this one. dvdnav is the newer of the two. companies are putting out bogus dvd discs and just dont care about having the certified 'dvd' logo anymore. these broken discs cause problems for mplayer and other dvd reading libraries. you will be fighting an uphill battle. at any rate, fixes/features to either of them would be appreciated. i think there is still an old feature request to play css encrypted vobs. >My eventual interest is in helping to complete blu-ray play/navigation >support. But, of course, that is a long way off, so this seemed like a >better place to start. there are some bluray components that would be useful in mplayer, like libaacs support, and the list of known player/disc keys. in the future we'll have to agree on java support for the bluray menus too. >In the meantime, I thought the ability to play multiple DVD angles at >once might be neat (in fact, it is neat, and is possible via udp sync, >but a bit cumbersome, and currently incompatible with most navigation). multiple video streams at once is very difficult in mplayer. i think only the videomixer patch has done it so far, and that needs multiple instances: http://onebithq.com/root/mplayer/videomixer -compn From auerswal at unix-ag.uni-kl.de Wed Jul 13 14:14:08 2011 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Wed, 13 Jul 2011 14:14:08 +0200 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1D6E18.80504@roalter.it> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713071806.GA28856@sushi.unix-ag.uni-kl.de> <4E1D4CD8.80805@cs.binghamton.edu> <4E1D6E18.80504@roalter.it> Message-ID: <20110713121408.GA4332@sushi.unix-ag.uni-kl.de> Hi, On Wed, Jul 13, 2011 at 12:06:16PM +0200, Alexander Roalter wrote: > On 13.07.2011 09:44, Steaphan Greene wrote: >> On 07/13/2011 03:18 AM, Erik Auerswald wrote: >> I generally prefer the dvd:// method too, just for better performance, >> unless I need the menus to navigate more complex content (like getting >> at a disc's special features). >> > for that, dvd://1-99 would also suffice, so you can emulate a "Play All" > feature. > > dvdnav has the advantage that it works with copy protected DVDs that use > deliberately erroneous bad sectors placed in the normal stream. dvdnav > navigates around them via the cell commands, and dvd doesn't, leaving > some DVDs unplayable. Many DVDs with bad sectors play with dvd:// if the correct track is given (e.g. dvd://3 for quite a lot of my DVDs). Often the movie track can be identified by looking for the longest track on the DVD (-identify). > I'd really like to see the dvdnav improved in that matter, i.e. > - no hickup at chapter breaks, > - playback of the remaining problematic DVDs > - correct seeking: currently, with some DVDs seeking within a certain > range always seeks to the same position: an example: All of my problematic DVDs can be played with VLC, therefore dvdnav:// improvements seem possible -- though I don't know enough to do this myself. Regards, Erik From auerswal at unix-ag.uni-kl.de Wed Jul 13 14:16:22 2011 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Wed, 13 Jul 2011 14:16:22 +0200 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1D4CD8.80805@cs.binghamton.edu> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713071806.GA28856@sushi.unix-ag.uni-kl.de> <4E1D4CD8.80805@cs.binghamton.edu> Message-ID: <20110713121622.GB4332@sushi.unix-ag.uni-kl.de> Hi, On Wed, Jul 13, 2011 at 03:44:24AM -0400, Steaphan Greene wrote: > On 07/13/2011 03:18 AM, Erik Auerswald wrote: >> On Tue, Jul 12, 2011 at 09:03:08PM -0400, Steaphan Greene wrote: >>> Can anyone explain (or point me to an explanation of) the plan with the >>> duplication between dvdnav:// and dvd:// in current mplayer? >>> >>> Is there any interest in merging these two, or, at least, obsoleting one >>> by adding features to the other? I might be interested in trying the >>> second choice myself. >> >> FWIW I really like the dvd:// method of playing a DVD, because I usually >> just want to watch the movie without working my way through menus. So >> from a user's perspective I'd prefer this to be retained. > > Unless I am missing something, simply playing a track can be done with > either quite well (eg. "dvd://3" and "dvdnav://3" basically act exactly > the same until you hit menus, or try to change angles, etc...). Thanks, I never tried this. IIRC dvdnav:// does not work with -cache, while dvd:// does (and I have a cache statement in my mplayer config file). Erik From nicola.sabbi at poste.it Wed Jul 13 14:51:30 2011 From: nicola.sabbi at poste.it (Nico Sabbi) Date: Wed, 13 Jul 2011 14:51:30 +0200 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1D6E18.80504@roalter.it> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713071806.GA28856@sushi.unix-ag.uni-kl.de> <4E1D4CD8.80805@cs.binghamton.edu> <4E1D6E18.80504@roalter.it> Message-ID: <4E1D94D2.7010309@poste.it> Alexander Roalter ha scritto: > > for that, dvd://1-99 would also suffice, so you can emulate a "Play > All" feature. > > dvdnav has the advantage that it works with copy protected DVDs that > use deliberately erroneous bad sectors placed in the normal stream. > dvdnav navigates around them via the cell commands, and dvd doesn't, > leaving some DVDs unplayable. > > Nowadays, I always use dvdnav instead of dvd, angle switching is > something I never use, but currently on some chapter breaks dvdnav > still gets a 'hickup' instead of playing smoothly through it. And I > have a bunch of DVDs that won't play at all (only the dumped variant > -dumpstream, in connection with dvdnav) will play when stored as a > file (also b/c of copy protection, but apparently dvdnav has a problem > handling these cell commands. > > I have also an issue with german Star Trek XI and Transformers II > (both from Paramount), which also have some sort of copy protection, > and here cell navigation and hickup at chapter break come together > making it tiresome to watch. dumpstream on the other hand delivers a > completely different result ?? really strange. If you can play smoothly the dump there's no reason why the stream shouldn't play. Maybe there's something that makes the VM spin round > > I'd really like to see the dvdnav improved in that matter, i.e. > - no hickup at chapter breaks, > - playback of the remaining problematic DVDs > - correct seeking: currently, with some DVDs seeking within a certain > range always seeks to the same position: an example: > > Transformers 2 DVD: has 99 titles on the main feature disc, most of > them are 'false' titles that play only a shortened version of the > movie (some chapters missing, others playing in different order). > Going through the menu (with -v and dvdnav), I see that title 9 is the > correct title to play. It also has the correct length on -identify > > Now at chapter 4, roughly 14 minutes into the movie, comes a chapter > break, that is not handled well: macroblock pixelation, audio hickup. > When I seek to this position I land at 9 minutes and pressing forward > 10 seconds I get to something like 9:40, but pressing forward again, I > still get to 9:40. I can let the movie play beyond this position up > until 12 minutes, pressing forward still gets me back to 9:40. So > getting to the 14 minutes position is only doable when playing it out > at normal speed, no seeking. > > And if I use dumpstream instead of normal playback, after chapter 4 > doesn't come chapter 5, but again it jumps back to chapter 3. I can > provide more info and a clearer analysis if needed. > > aha, this is more consistent. From nicola.sabbi at poste.it Wed Jul 13 14:58:02 2011 From: nicola.sabbi at poste.it (Nico Sabbi) Date: Wed, 13 Jul 2011 14:58:02 +0200 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <20110713074503.657a3af1.tempn@twmi.rr.com> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713074503.657a3af1.tempn@twmi.rr.com> Message-ID: <4E1D965A.1080300@poste.it> compn ha scritto: > On Tue, 12 Jul 2011 21:03:08 -0400, Steaphan Greene wrote: > >> Can anyone explain (or point me to an explanation of) the plan with the >> duplication between dvdnav:// and dvd:// in current mplayer? >> > might want to ask nico for his plans. > at the moment my plan is getting alive at the end of every day and diving in my bed:-) In any case there's no reason to remove anything. The two streams have complementary features and they go along perfectly well. I don't like the dvdnav mechanism, but I can hardly imagine a different one, on the other side the code in stream_dvd is "codus horribilis" but it's fast and as long as it works... don't touch it unless it's broken. dvdnav:// is simply the only way to play broken dvds or I wouldn't have committed the code years ago. From sgreene at cs.binghamton.edu Wed Jul 13 18:24:20 2011 From: sgreene at cs.binghamton.edu (Steaphan Greene) Date: Wed, 13 Jul 2011 12:24:20 -0400 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <20110713121622.GB4332@sushi.unix-ag.uni-kl.de> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713071806.GA28856@sushi.unix-ag.uni-kl.de> <4E1D4CD8.80805@cs.binghamton.edu> <20110713121622.GB4332@sushi.unix-ag.uni-kl.de> Message-ID: <4E1DC6B4.4080609@cs.binghamton.edu> On 07/13/2011 08:16 AM, Erik Auerswald wrote: > On Wed, Jul 13, 2011 at 03:44:24AM -0400, Steaphan Greene wrote: >> On 07/13/2011 03:18 AM, Erik Auerswald wrote: >>> FWIW I really like the dvd:// method of playing a DVD, because I usually >>> just want to watch the movie without working my way through menus. So >>> from a user's perspective I'd prefer this to be retained. >> >> Unless I am missing something, simply playing a track can be done with >> either quite well (eg. "dvd://3" and "dvdnav://3" basically act exactly >> the same until you hit menus, or try to change angles, etc...). > > Thanks, I never tried this. > > IIRC dvdnav:// does not work with -cache, while dvd:// does (and I have a > cache statement in my mplayer config file). That seems to still be the case (though I haven't seen a problem with it and caching, it still warns about it). I have this in my config: [protocol.dvdnav] profile-desc="profile for dvdnav:// streams" mouse-movements=yes nocache=yes #input=conf=input-dvdnav.conf ...which allows me to have cache for everything else (in [default]). That last commented-out line doesn't work (apparently, it won't reload the input config based on a new profile). This is one of the things I want to improve. I'd like to add standard skip/prev support which will seamlessly handle chapter navigation as well as multiple files (like xine does, for example). That way, I can use my remote with mplayer without needing a separate, special, config for dvds or bds (making the above, commented-out, line unnecessary). -- Steaphan Greene Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt From sgreene at cs.binghamton.edu Wed Jul 13 18:31:05 2011 From: sgreene at cs.binghamton.edu (Steaphan Greene) Date: Wed, 13 Jul 2011 12:31:05 -0400 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <20110713074503.657a3af1.tempn@twmi.rr.com> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713074503.657a3af1.tempn@twmi.rr.com> Message-ID: <4E1DC849.10902@cs.binghamton.edu> On 07/13/2011 07:45 AM, compn wrote: > On Tue, 12 Jul 2011 21:03:08 -0400, Steaphan Greene wrote: >> My eventual interest is in helping to complete blu-ray play/navigation >> support. But, of course, that is a long way off, so this seemed like a >> better place to start. > > there are some bluray components that would be useful in mplayer, like > libaacs support, and the list of known player/disc keys. in the future > we'll have to agree on java support for the bluray menus too. Unfortunately, I live in the U.S., where we apparently don't have the right to watch movies we purchase. Basically, I can't work on aacs, BD+, css, or key databases without risking getting into trouble. However, the java blu-ray menus are on my (long-rage) radar. >> In the meantime, I thought the ability to play multiple DVD angles at >> once might be neat (in fact, it is neat, and is possible via udp sync, >> but a bit cumbersome, and currently incompatible with most navigation). > > multiple video streams at once is very difficult in mplayer. i think > only the videomixer patch has done it so far, and that needs multiple > instances: http://onebithq.com/root/mplayer/videomixer This might be required for blu-ray 3D, depending on how ffmpeg decides to decode the dual streams (maybe it will just end up decoding them to one, side-by-side, stream). So, this might be worth hacking at anyway. -- Steaphan Greene Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt From sgreene at cs.binghamton.edu Wed Jul 13 18:36:47 2011 From: sgreene at cs.binghamton.edu (Steaphan Greene) Date: Wed, 13 Jul 2011 12:36:47 -0400 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1D965A.1080300@poste.it> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713074503.657a3af1.tempn@twmi.rr.com> <4E1D965A.1080300@poste.it> Message-ID: <4E1DC99F.4060909@cs.binghamton.edu> On 07/13/2011 08:58 AM, Nico Sabbi wrote: > at the moment my plan is getting alive at the end of every day and > diving in my bed:-) Mine too. I am just fortunate to have some personal project time from my job over the summers, and I chose to hack at mplayer this time. > In any case there's no reason to remove anything. The two streams have > complementary features and > they go along perfectly well. > I don't like the dvdnav mechanism, but I can hardly imagine a different > one, on the other side the > code in stream_dvd is "codus horribilis" but it's fast and as long as it > works... don't touch it unless > it's broken. > > dvdnav:// is simply the only way to play broken dvds or I wouldn't have > committed the code years ago. I see. Sounds like the consensus is that I should leave dvd:// as it is, and see if I can clean up the few things that don't work right (or as well) with dvdnav. I own significant DVD and BD collections, so I have plenty of testing materials to help debug things. -- Steaphan Greene Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt From matan at svgalib.org Thu Jul 14 00:27:15 2011 From: matan at svgalib.org (Matan Ziv-Av) Date: Thu, 14 Jul 2011 01:27:15 +0300 (IDT) Subject: [MPlayer-dev-eng] More aggresive index rebuild for AVI files Message-ID: Hello, the attached patch adds an option -fixidx, which works better than -forceidx for some damaged AVI files. This previous discussion is relevant: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-October/054571.html Two main differences between Reimar D?ffinger's patch and mine: The decision not to skip a putative chunk is based on id, rather than size. This patch introduces a new option, leaving the behaviour of forceidx unchanged. -- Matan Ziv-Av. matan at svgalib.org -------------- next part -------------- --- libmpdemux/aviheader.c.org 2011-07-13 16:33:59.000000000 +0300 +++ libmpdemux/aviheader.c 2011-07-14 01:15:20.000000000 +0300 @@ -74,7 +74,7 @@ // if(stream_eof(demuxer->stream)) break; // Imply -forceidx if -saveidx is specified - if (index_file_save) + if (index_file_save && (index_mode<2)) index_mode = 2; // if(id==mmioFOURCC('L','I','S','T')){ @@ -95,7 +95,7 @@ demuxer->movi_end=stream_tell(demuxer->stream)+len; mp_msg(MSGT_HEADER,MSGL_V,MSGTR_MPDEMUX_AVIHDR_FoundMovieAt,(int)demuxer->movi_start,(int)demuxer->movi_end); if(demuxer->stream->end_pos>demuxer->movi_end) demuxer->movi_end=demuxer->stream->end_pos; - if(index_mode==-2 || index_mode==2 || index_mode==0) + if(index_mode==-2 || index_mode==2 || index_mode==0 || index_mode==3) break; // reading from non-seekable source (stdin) or forced index or no index forced if(list_end>0) stream_seek(demuxer->stream,list_end); // skip movi list_end=0; @@ -704,6 +704,10 @@ #endif skip_chunk: skip=(len+1)&(~1UL); // total bytes in this chunk + if(index_mode==3 && + (((id&0xf0ffffff)!=0x30786469) && ((id&0xffff0000)!=0x62770000) && + ((id&0xfffff0f0)!=0x63643030) && ((id&0xfffff0f0)!=0x78743030))) + skip=0; stream_seek(demuxer->stream,8+demuxer->filepos+skip); } priv->idx_size=idx_pos; --- cfg-common.h.org 2011-07-14 01:12:59.000000000 +0300 +++ cfg-common.h 2011-07-14 01:12:36.000000000 +0300 @@ -424,6 +424,7 @@ {"noidx", &index_mode, CONF_TYPE_FLAG, 0, -1, 0, NULL}, {"idx", &index_mode, CONF_TYPE_FLAG, 0, -1, 1, NULL}, {"forceidx", &index_mode, CONF_TYPE_FLAG, 0, -1, 2, NULL}, + {"fixidx", &index_mode, CONF_TYPE_FLAG, 0, -1, 3, NULL}, {"saveidx", &index_file_save, CONF_TYPE_STRING, 0, 0, 0, NULL}, {"loadidx", &index_file_load, CONF_TYPE_STRING, 0, 0, 0, NULL}, From dalgoda+mplayer at gmail.com Thu Jul 14 02:37:48 2011 From: dalgoda+mplayer at gmail.com (Mike Castle) Date: Wed, 13 Jul 2011 17:37:48 -0700 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1D6E18.80504@roalter.it> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713071806.GA28856@sushi.unix-ag.uni-kl.de> <4E1D4CD8.80805@cs.binghamton.edu> <4E1D6E18.80504@roalter.it> Message-ID: I have seen a lot of Disney TV show DVDs that have even stranger characteristics. If you navigate to a track with either xine or mplayer dvdnav:// , the track will play. But if you go directly to the track, with any combination of xine /dev/dvd/N, mplayer dvd://N, mplayer dvdnav://N , it's all blocky and doesn't play at all. If I use libdvdnav's example program ``menus'' and use it to navigate to the track and dump it, it plays beautifully. I wonder if some of the issues you're seeing with the Paramount streams might be similar? mrc From s.doyon at videotron.ca Thu Jul 14 03:11:09 2011 From: s.doyon at videotron.ca (=?ISO-8859-15?Q?St=E9phane_Doyon?=) Date: Wed, 13 Jul 2011 21:11:09 -0400 (EDT) Subject: [MPlayer-dev-eng] [PATCH] Allow EDLs to work on audio files (fwd) Message-ID: Saw no response to this, resending. ---------- Forwarded message ---------- Date: Sat, 28 May 2011 19:30:27 -0400 (EDT) From: St?phane Doyon To: MPlayer-dev-eng at mplayerhq.hu Subject: [PATCH] Allow EDLs to work on audio files I had need to use an EDL on an audio file and was surprised to get this error: "Cannot use EDL without video, disabling." It wasn't obvious to me why there should be such a constraint. I took an admittedly quick look at the code, and found only the position was obtained from the video stream, and there seems no reason it can't use the audio position just as well. I made the simple change to use the audio position when there's no video, and it appears to work. Thanks -- St?phane Doyon http://pages.videotron.com/sdoyon/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mplayer-audio-edl.diff Type: text/x-diff Size: 2781 bytes Desc: URL: From nicola.sabbi at poste.it Thu Jul 14 12:25:43 2011 From: nicola.sabbi at poste.it (Nico Sabbi) Date: Thu, 14 Jul 2011 12:25:43 +0200 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1DC99F.4060909@cs.binghamton.edu> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713074503.657a3af1.tempn@twmi.rr.com> <4E1D965A.1080300@poste.it> <4E1DC99F.4060909@cs.binghamton.edu> Message-ID: <4E1EC427.1090906@poste.it> Steaphan Greene ha scritto: > >> In any case there's no reason to remove anything. The two streams have >> complementary features and >> they go along perfectly well. >> I don't like the dvdnav mechanism, but I can hardly imagine a different >> one, on the other side the >> code in stream_dvd is "codus horribilis" but it's fast and as long as it >> works... don't touch it unless >> it's broken. >> >> dvdnav:// is simply the only way to play broken dvds or I wouldn't have >> committed the code years ago. >> > I see. Sounds like the consensus is that I should leave dvd:// as it > is, and see if I can clean up the few things that don't work right (or > as well) with dvdnav. I own significant DVD and BD collections, so I > have plenty of testing materials to help debug things. > > well, if you volunteer I wish you good luck! You'll need a lot :) ... and much more patience. Since you have both the coding skills and a good amount of testing material you will surely improve the dvd playback mechanism. From josvanr at gmail.com Thu Jul 14 14:42:25 2011 From: josvanr at gmail.com (Jos van Riswick) Date: Thu, 14 Jul 2011 14:42:25 +0200 Subject: [MPlayer-dev-eng] color management patch Message-ID: Hi I am looking for color management support in mplayer and found 'the color management patch' on an mplayer wiki. The link doesn't work unfortunately. Is this patch still around or is it included in some mplayer git maybe? josvanr From sgreene at cs.binghamton.edu Thu Jul 14 19:30:48 2011 From: sgreene at cs.binghamton.edu (Steaphan Greene) Date: Thu, 14 Jul 2011 13:30:48 -0400 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1EC427.1090906@poste.it> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713074503.657a3af1.tempn@twmi.rr.com> <4E1D965A.1080300@poste.it> <4E1DC99F.4060909@cs.binghamton.edu> <4E1EC427.1090906@poste.it> Message-ID: <4E1F27C8.2010806@cs.binghamton.edu> On 07/14/2011 06:25 AM, Nico Sabbi wrote: > well, if you volunteer I wish you good luck! You'll need a lot :) ... > and much more patience. > Since you have both the coding skills and a good amount of testing > material you will surely > improve the dvd playback mechanism. I appreciate your vote of confidence. Hopefully, I'll at least partially succeed. I am highly motivated to make some progress here. I am annoyed that I must use 6 different media players to play my own content (because of various capabilities/advantages). I hope to give mplayer its missing features to reduce that number (hopefully, eventually, to just 1). At present, I think xine is the easiest target. Right now, I only use xine for its DVD menu support, and its more seamless file transitions. -- Steaphan Greene Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt From alex at roalter.it Thu Jul 14 23:26:32 2011 From: alex at roalter.it (Alexander Roalter) Date: Thu, 14 Jul 2011 23:26:32 +0200 Subject: [MPlayer-dev-eng] dvd -vs- dvdnav In-Reply-To: <4E1F27C8.2010806@cs.binghamton.edu> References: <4E1CEECC.8010404@cs.binghamton.edu> <20110713074503.657a3af1.tempn@twmi.rr.com> <4E1D965A.1080300@poste.it> <4E1DC99F.4060909@cs.binghamton.edu> <4E1EC427.1090906@poste.it> <4E1F27C8.2010806@cs.binghamton.edu> Message-ID: <4E1F5F08.2020904@roalter.it> On 07/14/2011 07:30 PM, Steaphan Greene wrote: > On 07/14/2011 06:25 AM, Nico Sabbi wrote: >> well, if you volunteer I wish you good luck! You'll need a lot :) ... >> and much more patience. >> Since you have both the coding skills and a good amount of testing >> material you will surely >> improve the dvd playback mechanism. > > I appreciate your vote of confidence. Hopefully, I'll at least > partially succeed. > > I am highly motivated to make some progress here. I am annoyed that I > must use 6 different media players to play my own content (because of > various capabilities/advantages). I hope to give mplayer its missing > features to reduce that number (hopefully, eventually, to just 1). > > At present, I think xine is the easiest target. Right now, I only use > xine for its DVD menu support, and its more seamless file transitions. > If you are looking into the DVDNAV stuff, there's something for you: http://www.roalter.it/dvd/downloads/producers_dvd.tar.gz It's the IFO files of the german "THE PRODUCERS" DVD (The Mel Brooks Movie from Sony). It uses ARccOS copy protection, but the playback from this title is somewhat strange. Title 1 is the main feature, and playing it delivers the correct sound (the one from the Columbia Logo), but the video is the last images of a deleted scene, then follow some black frames and then the Columbia Logo. All in all, there's around 10 seconds of Video delay, and roughly at 1 minute or more into the movie, video catches up with audio. If I seek with the arrow keys, the video always starts with the same frames from the initial deleted scene, and where at normal playback the Columbia Logo came, the scene jumped to appears. Jumping directly to a chapter (@ or !) instead works as expected. Maybe someone who has a parser for the cell navigation in the IFO files can shed some light on this issue. -- Cheers, Alex From xhx321 at gmail.com Mon Jul 18 10:11:59 2011 From: xhx321 at gmail.com (hengxing) Date: Mon, 18 Jul 2011 16:11:59 +0800 Subject: [MPlayer-dev-eng] How to catch the events in the MPLAYER? Message-ID: Hi, I'm a freshman in mplayer development. And I'm not familiar with the source code of the MPLAYER. Now, I hope the mplayer can catch some events, and then put these events to a pipe fifo on linux. The following are the events list: AUDDEC_EVT_NOT_KEEPING_UP : Audio decoder is unable to continue decoding at the current rate. AUDDEC_EVT_KEEPING_UP : Audio decoder has resumed being able to continue decoding at the current rate. AUDDEC_EVT_BUFFER_FULL : Audio decoder buffer is full AUDDEC_EVT_BUFFER_EMPTY : Audio decoder buffer is empty AUDDEC_EVT_BITRATE_CHANGE : Audio bitrate has changed AUDDEC_EVT_FREQUENCY_CHANGE: The audio sampling freq has changed AUDDEC_EVT_DATA_ERROR : Audio decoder error has occurred AUDDEC_EVT_PTS_EXPIRE : Audio pts expiration event. VIDDEC_EVT_NOT_KEEPING_UP : Video decoder is unable to maintain the selected decode rate VIDDEC_EVT_KEEPING_UP : Video decoder is again able to maintain the selected decode rate VIDDEC_EVT_BUFFER_FULL : Video decoder input buffer is full VIDDEC_EVT_BUFFER_EMPTY : Video decoder input buffer is empty VIDDEC_EVT_UNSUPPORTED_STREAM_TYPE : stream type is unsupported VIDDEC_EVT_IFRAME_DECODED : an IFRAME has been decoded VIDDEC_EVT_STREAM_INFO_CHANGE: Change in the stream characteristics VIDDEC_EVT_DATA_ERROR : stream data error How can I do this work? Thanks everyone for your reading Best Regards xhx321 From nicolas.george at normalesup.org Wed Jul 20 01:19:35 2011 From: nicolas.george at normalesup.org (Nicolas George) Date: Wed, 20 Jul 2011 01:19:35 +0200 Subject: [MPlayer-dev-eng] [PATCH] configure: set HAVE_LOCAL_ALIGNED_* for x86_64 Message-ID: <20110719231935.GA13649@-e> Hi. The attached patch does as the subject and the rest of the commit message say. It may be worth investigating why the fallback for LOCAL_ALIGNED_16 does not work, though. (And the router in front of my mail server has gone mad; I have taken temporary measures, I hope they will work; sorry if anything goes wrong.) Regards, -- Nicolas George -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-configure-set-HAVE_LOCAL_ALIGNED_-for-x86_64.patch Type: text/x-diff Size: 1025 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nicolas.george at normalesup.org Wed Jul 20 18:38:42 2011 From: nicolas.george at normalesup.org (Nicolas George) Date: Wed, 20 Jul 2011 18:38:42 +0200 Subject: [MPlayer-dev-eng] [PATCH] configure: set HAVE_LOCAL_ALIGNED_* for x86_64 In-Reply-To: <20110719231935.GA13649@-e> References: <20110719231935.GA13649@-e> Message-ID: <20110720163842.GA23585@phare.normalesup.org> Le duodi 2 thermidor, an CCXIX, Nicolas George a ?crit?: > It may be worth investigating why the fallback for LOCAL_ALIGNED_16 does not > work, though. I suppose this is the answer:o # dsputil: fix ff_check_alignment() # # The change to LOCAL_ALIGNED means the declared object must be an # array and the subsequent test should not use the & operator. # # Noticed by Uoti Urpala. # # Signed-off-by: Mans Rullgard But HAVE_LOCAL_ALIGNED_* should still be defined, IMHO. Objections? Regards, -- Nicolas George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From diego at biurrun.de Wed Jul 20 21:28:32 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 20 Jul 2011 21:28:32 +0200 Subject: [MPlayer-dev-eng] [PATCH] configure: set HAVE_LOCAL_ALIGNED_* for x86_64 In-Reply-To: <20110719231935.GA13649@-e> References: <20110719231935.GA13649@-e> Message-ID: <20110720192832.GA7080@pool.informatik.RWTH-Aachen.DE> On Wed, Jul 20, 2011 at 01:19:35AM +0200, Nicolas George wrote: > > The attached patch does as the subject and the rest of the commit message > say. Should be OK. Diego From nicolas.george at normalesup.org Wed Jul 20 23:24:27 2011 From: nicolas.george at normalesup.org (Nicolas George) Date: Wed, 20 Jul 2011 23:24:27 +0200 Subject: [MPlayer-dev-eng] [PATCH] configure: set HAVE_LOCAL_ALIGNED_* for x86_64 In-Reply-To: <20110720192832.GA7080@pool.informatik.RWTH-Aachen.DE> References: <20110719231935.GA13649@-e> <20110720192832.GA7080@pool.informatik.RWTH-Aachen.DE> Message-ID: <20110720212427.GA14878@phare.normalesup.org> Le duodi 2 thermidor, an CCXIX, Diego Biurrun a ?crit?: > Should be OK. Committed. Regards, -- Nicolas George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jarekczek at poczta.onet.pl Sat Jul 23 13:10:52 2011 From: jarekczek at poczta.onet.pl (Jarek Czekalski) Date: Sat, 23 Jul 2011 13:10:52 +0200 Subject: [MPlayer-dev-eng] solution of av desync on capturing with mencoder In-Reply-To: <4E061E48.9070407@poczta.onet.pl> References: <4DF47153.2020704@poczta.onet.pl> <4DF8FFF0.6090701@poczta.onet.pl> <20110617075933.GA6508@pool.informatik.RWTH-Aachen.DE> <4DFB7763.3080100@poczta.onet.pl> <20110618201640.GA10662@pool.informatik.RWTH-Aachen.DE> <4DFE134B.1020107@poczta.onet.pl> <4E061E48.9070407@poczta.onet.pl> Message-ID: <4E2AAC3C.5010100@poczta.onet.pl> Maybe you wanted to give me more time to test it in real daily usage. Then yes. I did it and it works. Time to commit now? W dniu 06/25/2011 07:43 PM, Jarek Czekalski pisze: > Shall I wait patiently or remind myself once a week or 2? > > W dniu 06/19/2011 05:18 PM, Jarek Czekalski pisze: >> W dniu 06/18/2011 10:16 PM, Diego Biurrun pisze: >>> On Fri, Jun 17, 2011 at 05:48:51PM +0200, Jarek Czekalski wrote: >>>> W dniu 06/17/2011 09:59 AM, Diego Biurrun pisze: >>>>> On Wed, Jun 15, 2011 at 08:54:40PM +0200, Jarek Czekalski wrote: >>>>>> --- DOCS/man/en/mplayer.1 (revision 33606) >>>>>> +++ DOCS/man/en/mplayer.1 (working copy) >>>>>> @@ -8105,6 +8105,11 @@ >>>>>> . >>>>>> .TP >>>>>> +.B \-noskipafter >>>>>> +Do not skip frames after 2 seconds. Useful when capturing from >>>>>> tv where >>>>>> +the first frames of video do not go even with audio. >>>>> New sentences must go on new lines in the man page. >>>>> >>>>> Useful when capturing from TV where the first video frames >>>>> are not in sync with audio. >>>>> >>>> Homework done. >>>> >>>> Changed also: >>>> do not go even with audio. -> do not go evenly with audio. >>> Except that this is not what I suggested. We do not commonly speak of >>> audio and video to "go even", they are "synchronized". >>> >>> Diego >>> _______________________________________________ >> Thanks for the language correction. Now it sounds much better: >> >> +Do not skip frames after 2 seconds. >> +Useful when capturing from tv where the first frames of video are not >> +synchronized with audio. >> >> Again I attach 2 patches, although only -noskipafter changed, and >> only in this very part. >> >> >> _______________________________________________ >> MPlayer-dev-eng mailing list >> MPlayer-dev-eng at mplayerhq.hu >> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng > > _______________________________________________ > MPlayer-dev-eng mailing list > MPlayer-dev-eng at mplayerhq.hu > https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng > From Reimar.Doeffinger at gmx.de Sun Jul 24 17:24:11 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 24 Jul 2011 17:24:11 +0200 Subject: [MPlayer-dev-eng] [PATCH] Allow EDLs to work on audio files (fwd) In-Reply-To: References: Message-ID: <20110724152411.GB26236@1und1.de> On Wed, Jul 13, 2011 at 09:11:09PM -0400, St?phane Doyon wrote: > Saw no response to this, resending. > > ---------- Forwarded message ---------- > Date: Sat, 28 May 2011 19:30:27 -0400 (EDT) > From: St?phane Doyon > To: MPlayer-dev-eng at mplayerhq.hu > Subject: [PATCH] Allow EDLs to work on audio files > > I had need to use an EDL on an audio file and was surprised to get this > error: > "Cannot use EDL without video, disabling." > > It wasn't obvious to me why there should be such a constraint. I > took an admittedly quick look at the code, and found only the > position was obtained from the video stream, and there seems no > reason it can't use the audio position just as well. I made the > simple change to use the audio position when there's no video, and > it appears to work. Seems ok to me, anyone with comments? From Reimar.Doeffinger at gmx.de Sun Jul 24 17:40:00 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 24 Jul 2011 17:40:00 +0200 Subject: [MPlayer-dev-eng] [PATCH] Fix for mpeg2 A/V sync bug. In-Reply-To: <4E1BA0B8.8040903@cs.binghamton.edu> References: <4E049191.4050607@cs.binghamton.edu> <20110626184958.GA10462@1und1.de> <4E1BA0B8.8040903@cs.binghamton.edu> Message-ID: <20110724154000.GC26236@1und1.de> On Mon, Jul 11, 2011 at 09:17:44PM -0400, Steaphan Greene wrote: > On 06/26/2011 02:49 PM, Reimar D?ffinger wrote: > > On Fri, Jun 24, 2011 at 09:30:57AM -0400, Steaphan Greene wrote: > >> The attached patch fixes the bug with vob files (and, presumably other > >> mpeg2 content) caused by the A/V sync code added with r32055/32056. I > >> believe this solution should cause no other harm. > >> > >> Basically, it now just removes the last_pts data when one of these pts > >> changes occurs in the mpeg2 stream. That way, the A/V resync code in > >> question ignores this frame, and no longer breaks anything. > > > > But this is not code for non-uniform time-stamps really but it is > > reordering. > > And my suspicion is that your change only makes it so that non-B-frames > > which MPlayer can detect break the other correction code you pointed out before. > > If so you could just avoid the obfuscation and put the whole other code > > under "if codec != MPEG-2" for exactly the same effect. > > I've attached an updated version of my band-aid for this bug based on > current svn (r33877). I believe this is still correct, as, if I am > understanding you correctly, this case is due to an out-of-order frame, > which means that the time stored in last_pts really was not correct, as > it did not actually store the pts of the truly-previous frame. > > ...I hope that explanation made sense to more people than just me. The B-frames are the out-of-order frames, which are the ones you _aren't_ touching. However the other frames are delayed whereas B-frames are not. There are files without B-frames, in which case the change would remove last_pts for _all_ frames. > I have updated the comment to reflect this. Of course, I could still be > wrong about exactly what's happening here. I am only confident from my > traces that this fixes the problem I found, and only this problem, and > causes no other harm. I think you mentioned a case for which the time-stamp correction code is necessary? I think that code is rather bad anyway: I never leads to good timing, it can only convert completely wrong timing into ok-timing as far as I understand and it should probably be restrained. > Without this patch, the current version of mplayer in SVN is not able to > properly play most of my DVDs. So, unless a better solution is obvious, > I'd request this patch be applied. I tested about 10 different DVDs and not a single one has the slightest issue. I do not have any NTSC DVDs though. Is there anyone else who can reproduce the issue? From diego at biurrun.de Wed Jul 27 17:35:08 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 27 Jul 2011 17:35:08 +0200 Subject: [MPlayer-dev-eng] [PATCH] build: drop BeOS support Message-ID: <1311780908-12016-1-git-send-email-diego@biurrun.de> BeOS is dead and support has been dropped from FFmpeg/Libav a long time ago. The support code that was added years ago adds considerable clutter while not providing any benefit, so it's better to drop it outright. Support for Haiku, the FOSS replacement of BeOS remains unaffected. --- Makefile | 1 - configure | 49 +++++-------------------------------------------- cpuinfo.c | 4 ---- mpbswap.h | 4 ---- osdep/shmem.c | 2 -- osdep/swab.c | 33 --------------------------------- osdep/timer-linux.c | 3 --- 7 files changed, 5 insertions(+), 91 deletions(-) delete mode 100644 osdep/swab.c diff --git a/Makefile b/Makefile index 581d001..3bc6595 100644 --- a/Makefile +++ b/Makefile @@ -182,7 +182,6 @@ SRCS_COMMON-$(NEED_MMAP) += osdep/mmap-os2.c SRCS_COMMON-$(NEED_SETENV) += osdep/setenv.c SRCS_COMMON-$(NEED_SHMEM) += osdep/shmem.c SRCS_COMMON-$(NEED_STRSEP) += osdep/strsep.c -SRCS_COMMON-$(NEED_SWAB) += osdep/swab.c SRCS_COMMON-$(NEED_VSSCANF) += osdep/vsscanf.c SRCS_COMMON-$(NETWORKING) += stream/stream_netstream.c \ stream/asf_mmst_streaming.c \ diff --git a/configure b/configure index a332996..cdaa83a 100755 --- a/configure +++ b/configure @@ -208,7 +208,6 @@ issystem() { } aix() { issystem "AIX"; } amigaos() { issystem "AmigaOS"; } -beos() { issystem "BEOS"; } bsdos() { issystem "BSD/OS"; } cygwin() { issystem "CYGWIN"; } darwin() { issystem "Darwin"; } @@ -1436,10 +1435,7 @@ if test -z "$_target" ; then # OS name system_name=$(uname -s 2>&1) case "$system_name" in - Linux|FreeBSD|NetBSD|OpenBSD|DragonFly|BSD/OS|Darwin|SunOS|QNX|GNU|BeOS|MorphOS|AIX|AmigaOS) - ;; - Haiku) - system_name=BeOS + Linux|FreeBSD|NetBSD|OpenBSD|DragonFly|BSD/OS|Darwin|SunOS|QNX|GNU|MorphOS|AIX|AmigaOS|Haiku) ;; IRIX*) system_name=IRIX @@ -1467,7 +1463,7 @@ if test -z "$_target" ; then # host's CPU/instruction set case "$(uname -m 2>&1)" in - x86_64|amd64|i[3-9]86*|x86|x86pc|k5|k6|k6_2|k6_3|k6-2|k6-3|pentium*|athlon*|i586_i686|i586-i686|BePC) host_arch=i386 ;; + x86_64|amd64|i[3-9]86*|x86|x86pc|k5|k6|k6_2|k6_3|k6-2|k6-3|pentium*|athlon*|i586_i686|i586-i686) host_arch=i386 ;; ia64) host_arch=ia64 ;; macppc|ppc|Power*) host_arch=ppc ;; ppc64) host_arch=ppc64 ;; @@ -2936,23 +2932,6 @@ fi ###################### -echocheck "-lposix" -if cflag_check -lposix ; then - extra_ldflags="$extra_ldflags -lposix" - echores "yes" -else - echores "no" -fi - -echocheck "-lm" -if cflag_check -lm ; then - extra_ldflags="$extra_ldflags -lm" - echores "yes" -else - echores "no" -fi - - echocheck "langinfo" if test "$_langinfo" = auto ; then _langinfo=no @@ -3106,14 +3085,13 @@ echores "$_nanosleep" echocheck "socklib" # for Solaris (socket stuff is in -lsocket, gethostbyname and friends in -lnsl): -# for BeOS (socket stuff is in -lsocket, gethostbyname and friends in -lbind): cat > $TMPC << EOF #include #include int main(void) { gethostbyname(0); socket(AF_INET, SOCK_STREAM, 0); return 0; } EOF _socklib=no -for _ld_tmp in "" "-lsocket -lbind" "-lsocket -ldnet" "-lsocket -lnsl" "-lnsl" "-lsocket" ; do +for _ld_tmp in "" "-lsocket -ldnet" "-lsocket -lnsl" "-lnsl" "-lsocket" ; do cc_check $_ld_tmp && _ld_sock="$_ld_tmp" && _socklib=yes && break done test $_socklib = yes && test $_winsock2_h = auto && _winsock2_h=no @@ -3813,19 +3791,6 @@ fi echores "$_vsscanf" -echocheck "swab()" -_swab=no -define_statement_check "_XOPEN_SOURCE 600" "unistd.h" 'int a, b; swab(&a, &b, 0)' || - statement_check "string.h" 'int a, b; swab(&a, &b, 0)' && _swab=yes -if test "$_swab" = yes ; then - def_swab='#define HAVE_SWAB 1' - need_swab=no -else - def_swab='#undef HAVE_SWAB' - need_swab=yes -fi -echores "$_swab" - echocheck "POSIX select()" cat > $TMPC << EOF #include @@ -5014,7 +4979,7 @@ EOF if cc_check $_inc_tmp $_ld_tmp >>"$TMPLOG" 2>&1 ; then _sdl=yes elif cc_check $_inc_tmp $_ld_tmp -lstdc++ >>"$TMPLOG" 2>&1 ; then - # HACK for BeOS/Haiku SDL + # HACK for Haiku SDL _ld_tmp="$_ld_tmp -lstdc++" _sdl=yes fi @@ -5816,8 +5781,6 @@ if test "$_libdvdcss_internal" = yes ; then extra_ldflags="$extra_ldflags -framework IOKit -framework Carbon" elif cygwin ; then cflags_libdvdcss="-DSYS_CYGWIN -DWIN32" - elif beos ; then - cflags_libdvdcss="-DSYS_BEOS" elif os2 ; then cflags_libdvdcss="-DSYS_OS2" fi @@ -7390,7 +7353,7 @@ echores "$_pvr" echocheck "ftp" -if test "$_ftp" = "auto" && test "$networking" = "yes" && ! beos ; then +if test "$_ftp" = "auto" && test "$networking" = "yes" ; then _ftp=yes fi if test "$_ftp" = yes ; then @@ -7858,7 +7821,6 @@ NEED_MMAP = $need_mmap NEED_SETENV = $need_setenv NEED_SHMEM = $need_shmem NEED_STRSEP = $need_strsep -NEED_SWAB = $need_swab NEED_VSSCANF = $need_vsscanf # features @@ -8215,7 +8177,6 @@ $def_setenv $def_setmode $def_shm $def_strsep -$def_swab $def_sysi86 $def_sysi86_iv $def_termcap diff --git a/cpuinfo.c b/cpuinfo.c index 5a39ddb..5da585d 100644 --- a/cpuinfo.c +++ b/cpuinfo.c @@ -32,10 +32,6 @@ #define sleep(t) Sleep(1000*t); #endif -#ifdef __BEOS__ -#define usleep(t) snooze(t) -#endif - #ifdef M_UNIX typedef long long int64_t; #define MISSING_USLEEP diff --git a/mpbswap.h b/mpbswap.h index 7ec7946..28f7337 100644 --- a/mpbswap.h +++ b/mpbswap.h @@ -31,8 +31,4 @@ #define be2me_16(v) av_be2ne16(v) #define be2me_32(v) av_be2ne32(v) -#ifndef HAVE_SWAB -void swab(const void *from, void *to, ssize_t n); -#endif - #endif /* MPLAYER_MPBSWAP_H */ diff --git a/osdep/shmem.c b/osdep/shmem.c index 712bc9f..395235d 100644 --- a/osdep/shmem.c +++ b/osdep/shmem.c @@ -33,8 +33,6 @@ #include #if HAVE_SYS_MMAN_H #include -#elif defined(__BEOS__) -#include #endif #include #include diff --git a/osdep/swab.c b/osdep/swab.c deleted file mode 100644 index f0bb796..0000000 --- a/osdep/swab.c +++ /dev/null @@ -1,33 +0,0 @@ -/* - * This file is part of MPlayer. - * - * MPlayer is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * MPlayer is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License along - * with MPlayer; if not, write to the Free Software Foundation, Inc., - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. - */ - -#include "config.h" - -/* system has no swab. emulate via bswap */ -#include "mpbswap.h" -#include - -void swab(const void *from, void *to, ssize_t n) { - const int16_t *in = (int16_t*)from; - int16_t *out = (int16_t*)to; - int i; - n /= 2; - for (i = 0 ; i < n; i++) { - out[i] = bswap_16(in[i]); - } -} diff --git a/osdep/timer-linux.c b/osdep/timer-linux.c index 4f61c0d..7d3a999 100644 --- a/osdep/timer-linux.c +++ b/osdep/timer-linux.c @@ -20,9 +20,6 @@ */ #include -#ifdef __BEOS__ -#define usleep(t) snooze(t) -#endif #include #include #include -- 1.7.2.5 From ikalvachev at gmail.com Thu Jul 28 23:52:47 2011 From: ikalvachev at gmail.com (Ivan Kalvachev) Date: Fri, 29 Jul 2011 00:52:47 +0300 Subject: [MPlayer-dev-eng] [PATCH] Fix for mpeg2 A/V sync bug. In-Reply-To: <20110724154000.GC26236@1und1.de> References: <4E049191.4050607@cs.binghamton.edu> <20110626184958.GA10462@1und1.de> <4E1BA0B8.8040903@cs.binghamton.edu> <20110724154000.GC26236@1und1.de> Message-ID: On 7/24/11, Reimar D?ffinger wrote: > On Mon, Jul 11, 2011 at 09:17:44PM -0400, Steaphan Greene wrote: >> On 06/26/2011 02:49 PM, Reimar D?ffinger wrote: >> > On Fri, Jun 24, 2011 at 09:30:57AM -0400, Steaphan Greene wrote: >> >> The attached patch fixes the bug with vob files (and, presumably other >> >> mpeg2 content) caused by the A/V sync code added with r32055/32056. I >> >> believe this solution should cause no other harm. >> >> >> >> Basically, it now just removes the last_pts data when one of these pts >> >> changes occurs in the mpeg2 stream. That way, the A/V resync code in >> >> question ignores this frame, and no longer breaks anything. >> > >> > But this is not code for non-uniform time-stamps really but it is >> > reordering. >> > And my suspicion is that your change only makes it so that non-B-frames >> > which MPlayer can detect break the other correction code you pointed out >> > before. >> > If so you could just avoid the obfuscation and put the whole other code >> > under "if codec != MPEG-2" for exactly the same effect. >> >> I've attached an updated version of my band-aid for this bug based on >> current svn (r33877). I believe this is still correct, as, if I am >> understanding you correctly, this case is due to an out-of-order frame, >> which means that the time stored in last_pts really was not correct, as >> it did not actually store the pts of the truly-previous frame. >> >> ...I hope that explanation made sense to more people than just me. > > The B-frames are the out-of-order frames, which are the ones you _aren't_ > touching. > However the other frames are delayed whereas B-frames are not. > There are files without B-frames, in which case the change would remove > last_pts for _all_ frames. > >> I have updated the comment to reflect this. Of course, I could still be >> wrong about exactly what's happening here. I am only confident from my >> traces that this fixes the problem I found, and only this problem, and >> causes no other harm. > > I think you mentioned a case for which the time-stamp correction code > is necessary? I think that code is rather bad anyway: I never leads > to good timing, it can only convert completely wrong timing into > ok-timing as far as I understand and it should probably be restrained. I'm also in favor of removing the ugly hack in mplayer.c . I think I tried to track down its introduction, at least in maillist and the case it "fixes" is double framerate of interlaced h264 .ts content. As the mail hinted, it is our demuxer that produces complete packets for single field (half frame), thus leading to double framerate. I may try to find name of the cited sample file (it is in our collection) if you can't find it on your own. Other than that, I've put some raw printf's in the correction code and I haven't yet found a file "in the wild" that triggers it. I did suspect it to cause A/V delay with immediatemode=0 on v4l2 capture, but didn't got any prove. >> Without this patch, the current version of mplayer in SVN is not able to >> properly play most of my DVDs. So, unless a better solution is obvious, >> I'd request this patch be applied. > > I tested about 10 different DVDs and not a single one has the slightest > issue. > I do not have any NTSC DVDs though. > Is there anyone else who can reproduce the issue? It must be soft-telecine. Most Film->PAL is done by stretching the audio as the ratio is smaller (24->25).