headers
Tobias Diedrich | 1 Jul 2011 13:15
Picon

[PATCH] Pass down error code from muxer_lavf av_write_header

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 ++--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Diego Biurrun | 3 Jul 2011 13:15
Picon
Gravatar

Re: [PATCH] Pass down error code from muxer_lavf av_write_header

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
>  <at>  <at>  -198,6 +198,7  <at>  <at> 
>      int height = mpi->height;
>      int stride = width*2;
> +    int ret=0;
>  <at>  <at>  -277,7 +278,10  <at>  <at> 
>      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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tobias Diedrich | 4 Jul 2011 20:43
Picon

Re: [PATCH] Pass down error code from muxer_lavf av_write_header

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
> >  <at>  <at>  -198,6 +198,7  <at>  <at> 
> >      int height = mpi->height;
> >      int stride = width*2;
> > +    int ret=0;
> >  <at>  <at>  -277,7 +278,10  <at>  <at> 
> >      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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Sheldon | 5 Jul 2011 17:54
Picon

[PATCH] gui/win32/dialogs.c

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)
 <at>  <at>  -662,7 +662,7  <at>  <at> 
 {
     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:
 <at>  <at>  -718,9 +718,9  <at>  <at> 
                         strcat(skinspath, skinName);
                         ShowWindow(hwnd, SW_HIDE);
                         Shell_NotifyIcon(NIM_DELETE, &nid);
-                        destroy_window(gui);
-                        create_window(gui, skinspath);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ingo Brückl | 5 Jul 2011 18:51
Picon

Re: [PATCH] gui/win32/dialogs.c

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
Permalink | Reply | 0 comments |
headers
Németh Márton | 5 Jul 2011 22:30
Picon
Favicon

demux_tv_fill_buffer() + V4L2 webcam removal detection?

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
_______________________________________________
MPlayer-dev-eng mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Sheldon | 8 Jul 2011 04:26
Picon

[PATCH] more implicit declarations of functions 1/3

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 <saschasommer <at> freenet.de>
 * Copyright (C) 2006 Erik Augustson <erik_27can <at> yahoo.com>
 * Copyright (C) 2006 Gianluigi Tiesi <sherpya <at> netfarm.it>
 *
 * This file is part of MPlayer.
 *
(Continue reading)

Permalink | Reply | 6 comments |
headers
Stephen Sheldon | 8 Jul 2011 04:33
Picon

[PATCH] more implicit declarations of functions 2/3

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)
 <at>  <at>  -32,7 +32,7  <at>  <at> 
 #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)
 <at>  <at>  -24,7 +24,7  <at>  <at> 
 #include <windows.h>
 #include <commctrl.h>
 #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
===================================================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Sheldon | 8 Jul 2011 04:35
Picon

[PATCH] more implicit declarations of functions 3/3

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)
 <at>  <at>  -30,7 +30,7  <at>  <at> 
 #endif

 #include "path.h"
-#include "gui/interface.h"
+#include "gui/win32/interface.h"
 #include "m_option.h"
 #include "mixer.h"
 #include "mp_msg.h"
 <at>  <at>  -156,6 +156,116  <at>  <at> 
     (*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);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingo Brückl | 8 Jul 2011 09:46
Picon

Re: [PATCH] more implicit declarations of functions 1/3


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).
(Continue reading)

Permalink | Reply | 2 comments |

Gmane