From doc4holliday at gmail.com  Sun Jan  1 03:28:53 2012
From: doc4holliday at gmail.com (Doc Holliday)
Date: Sun, 1 Jan 2012 02:28:53 +0000 (UTC)
Subject: [MPlayer-dev-eng] [RFC] Playing growing file
References: <04FAF4E5-1B46-484B-B913-D228627BD8B4@gmail.com>
Message-ID: <loom.20120101T031710-685@post.gmane.org>

Vlad Seryakov <vseryakov <at> gmail.com> writes:

> Hi,
> 
> This is just some crazy idea i am thinking about while trying to figure out
how to play MPEG TS recordings with
> mplayer. Really this is not full timeshift solution and never be, player is
just a player but supporting
> growing file may be very useful.
> I decided to try with adding one function to stream_file.c which will handle 
> pipe://
>  urls and just use different fill_buffer function which indefinitely reads
from file but process events to
> avoid hangs.
> Just wondetng what other think about this solution.
> 
> Thanks

Hi Vlad,
I've run into a slight problem with your file. Specifically, while playing a
test mkv file, mplayer would just freeze. I realized that in some cases demux
might try to search all the way to the end of the file (eg in order to determine
its length), which will cause it to freeze.

So I took liberty in adding a few lines and making it into an actual patch
(attached). I also changed the prefix from pipe:// to grow://. Hope you don't
mind ;)

-Doc

==

>From 846db1c1c9ceeecf5dd253302bd1dc69bc333d0c Mon Sep 17 00:00:00 2001
From: Doc Holliday <doc4holliday at gmail.com>
Date: Fri, 30 Dec 2011 21:14:08 -0500
Subject: [PATCH] Wait for data

When file is opened as grow://file.ext, mplayer will
continue waiting for new data even after it reaches EOF.
---
 mplayer.c            |    7 ++++++
 stream/stream.h      |    1 +
 stream/stream_file.c |   53 +++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 60 insertions(+), 1 deletions(-)

diff --git a/mplayer.c b/mplayer.c
index 53139dd..ef60bbc 100644
--- a/mplayer.c
+++ b/mplayer.c
@@ -3292,8 +3292,15 @@ if(stream_cache_size>0){
 //============ Open DEMUXERS --- DETECT file type =======================
 current_module="demux_open";
 
+// HACK temporarily disable STREAM_GROW, as some demuxers like to seek
+// all the way to the end to find out length of the stream
+int grow = mpctx->stream->flags & STREAM_GROW;
+mpctx->stream->flags &= ~STREAM_GROW;
+
 mpctx->demuxer=demux_open(mpctx->stream,mpctx->file_format,audio_id,video_id,dvdsub_id,filename);
 
+mpctx->stream->flags |= grow;
+
 // HACK to get MOV Reference Files working
 
 if (mpctx->demuxer && mpctx->demuxer->type==DEMUXER_TYPE_PLAYLIST)
diff --git a/stream/stream.h b/stream/stream.h
index 184d569..500577e 100644
--- a/stream/stream.h
+++ b/stream/stream.h
@@ -75,6 +75,7 @@
     separation between stream an demuxer and thus is not
     actually a stream cache can not be used */
 #define STREAM_NON_CACHEABLE 8
+#define STREAM_GROW 16
 
 //////////// Open return code
 #define STREAM_REDIRECTED -2
diff --git a/stream/stream_file.c b/stream/stream_file.c
index 9af6013..6192bbf 100644
--- a/stream/stream_file.c
+++ b/stream/stream_file.c
@@ -23,6 +23,9 @@
 #include <sys/stat.h>
 #include <fcntl.h>
 #include <unistd.h>
+#if HAVE_SETMODE
+#include <io.h>
+#endif
 
 #include "mp_msg.h"
 #include "stream.h"
@@ -30,6 +33,10 @@
 #include "m_option.h"
 #include "m_struct.h"
 
+#include "input/input.h"
+#include "libmpdemux/demuxer.h"
+#include <errno.h>
+
 static struct stream_priv_s {
   char* filename;
   char *filename2;
@@ -109,6 +116,45 @@ static int control(stream_t *s, int cmd, void *arg) {
   return STREAM_UNSUPPORTED;
 }
 
+static int grow_fill_buffer(stream_t *s, char* buffer, int max_len)
+{
+  int nread = 0, nodata = 0;
+
+again:
+  nread = read(s->fd, buffer, max_len);
+  if (nread < 0) {
+    if (errno == EINTR) goto again;
+    s->eof = 1;
+    return -1;
+  }
+
+  struct stat st;
+  s->end_pos = fstat(s->fd, &st) ? s->end_pos : st.st_size;
+
+  if (nread == 0)
+    if (s->flags & STREAM_GROW) {
+      mp_cmd_t *cmd = mp_input_get_cmd(0, 0, 1);
+      switch (cmd ? cmd->id : 0) {
+      case MP_CMD_QUIT:
+      case MP_CMD_STOP:
+        s->eof = 1;
+        return -1;
+      }
+      nodata++;
+  
+      // Report periodically but keep spinning
+      if (nodata % 1000 == 0) {
+        mp_msg(MSGT_STREAM,MSGL_ERR, "[ts] nodata=%d, file=%s, len=%d,
pos=%lld, size=%lld\n", nodata, s->url, max_len, s->pos, s->end_pos);
+      }
+      usleep(5000);
+      goto again;
+    }
+    else nread = -1;
+
+  return nread;
+}
+
+
 static int open_f(stream_t *stream,int mode, void* opts, int* file_format) {
   int f;
   mode_t m = 0;
@@ -198,6 +244,11 @@ static int open_f(stream_t *stream,int mode, void* opts,
int* file_format) {
   stream->control = control;
   stream->read_chunk = 64*1024;
 
+  if (!stream->url || strncmp(stream->url, "grow://", 7) == 0) {
+    stream->fill_buffer = grow_fill_buffer;
+    stream->flags|=STREAM_GROW;
+  }
+
   m_struct_free(&stream_opts,opts);
   return STREAM_OK;
 }
@@ -208,7 +259,7 @@ const stream_info_t stream_info_file = {
   "Albeu",
   "based on the code from ??? (probably Arpi)",
   open_f,
-  { "file", "", NULL },
+  { "file", "grow", "", NULL },
   &stream_opts,
   1 // Urls are an option string
 };
-- 
1.7.8.1




From siretart at tauware.de  Mon Jan  2 00:22:41 2012
From: siretart at tauware.de (Reinhard Tartler)
Date: Mon, 02 Jan 2012 00:22:41 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
Message-ID: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>

Hi,

In order to build mplayer against Libav, a couple of minor patches are
necessary. I've developed them in the course of maintaining the daily
builds at https://launchpad.net/~motumedia/+archive/mplayer-daily/, but
as compatibility with Libav is a requirement for the distro mplayer
package in debian, I feel they should better go to svn properly.

So here we go:

--- mplayer-1.0~svn34481.orig/fmt-conversion.c
+++ mplayer-1.0~svn34481/fmt-conversion.c
@@ -24,6 +24,11 @@
 #include "libaf/af_format.h"
 #include "fmt-conversion.h"
 
+// libav.org's libavutil is missing this
+#ifndef PIX_FMT_GBR24P
+#define PIX_FMT_GBR24P PIX_FMT_GBRP
+#endif
+
 static const struct {
     int fmt;
     enum PixelFormat pix_fmt;
@@ -57,7 +62,9 @@
     {IMGFMT_RGB8,    PIX_FMT_BGR8},
     {IMGFMT_RGB4,    PIX_FMT_BGR4},
     {IMGFMT_BGR8,    PIX_FMT_PAL8},
+#ifdef PIX_FMT_0RGB32
     {IMGFMT_BGR32,   PIX_FMT_0RGB32},
+#endif
 #if LIBAVUTIL_VERSION_INT >= AV_VERSION_INT(51, 20, 1)
     {IMGFMT_GBR24P,  PIX_FMT_GBR24P},
 #endif

I think these hunks should be rather safe. Instead of using
PIX_FMT_GBR24P, we could also use PIX_FMT_GBRP directly, as this #define
was copied FFmpeg's libavcodec.

--- mplayer-1.0~svn34481.orig/libmpdemux/mp_taglists.c
+++ mplayer-1.0~svn34481/libmpdemux/mp_taglists.c
@@ -43,7 +43,9 @@
     { CODEC_ID_COOK,              MKTAG('c', 'o', 'o', 'k')},
     { CODEC_ID_DSICINAUDIO,       MKTAG('D', 'C', 'I', 'A')},
     { CODEC_ID_EAC3,              MKTAG('E', 'A', 'C', '3')},
+#ifdef CODEC_ID_FFWAVESYNTH
     { CODEC_ID_FFWAVESYNTH,       MKTAG('F', 'F', 'W', 'S')},
+#endif
     { CODEC_ID_G723_1,            MKTAG('7', '2', '3', '1')},
     { CODEC_ID_INTERPLAY_DPCM,    MKTAG('I', 'N', 'P', 'A')},
     { CODEC_ID_MLP,               MKTAG('M', 'L', 'P', ' ')},
@@ -85,7 +87,9 @@
     { CODEC_ID_DVVIDEO,           MKTAG('d', 'v', 's', 'd')},
     { CODEC_ID_EAC3,              MKTAG('E', 'A', 'C', '3')},
     { CODEC_ID_ESCAPE124,         MKTAG('E', '1', '2', '4')},
+#ifdef CODEC_ID_ESCAPE130
     { CODEC_ID_ESCAPE130,         MKTAG('E', '1', '3', '0')},
+#endif
     { CODEC_ID_FLV1,              MKTAG('F', 'L', 'V', '1')},
     { CODEC_ID_G729,              MKTAG('G', '7', '2', '9')},
     { CODEC_ID_H264,              MKTAG('H', '2', '6', '4')},

These codec id's do not exist in Libav's libavcodec.

Actually, there used to be a couple of more patches in the daily builds,
but I think they are no longer necessary. In case I'm wrong, I'll sent
another email with those included. The patches above, however, are
definitly necessary.

Please tell me which of the above changes are acceptable and what
additional work the other ones require to become acceptable.

Happy new year,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

From ikalvachev at gmail.com  Mon Jan  2 14:03:28 2012
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Mon, 2 Jan 2012 15:03:28 +0200
Subject: [MPlayer-dev-eng] [PATCH] add support of compression algorithm
 3 in mkv demuxer
In-Reply-To: <a4423d670805061524x738327ebg1ae575351479cef@mail.gmail.com>
References: <a4423d670805061524x738327ebg1ae575351479cef@mail.gmail.com>
Message-ID: <CABA=pqd=mexkXPEJyO0xW-hU6kvjNREKXtSvwujV9O6DnUEnOA@mail.gmail.com>

On 5/7/08, Alexander Beregalov <a.beregalov at gmail.com> wrote:
> Specs from http://www.matroska.org/technical/specs/ :
> ContentCompAlgo         The compression algorithm used. Algorithms that have
> been specified so far are: 0 - zlib, 1 - bzlib, 2 - lzo1x, 3 - Header
> Stripping.
> ContentCompSettings    Settings that might be needed by the
> decompressor. For Header Stripping (ContentCompAlgo=3), the bytes that
> were removed from the beggining of each frames of the track.
>
> I have such file, it works for me.
>
> | + A track
> |  + Track number: 2
> |  + Track UID: 2
> |  + Track type: audio
> |  + Lacing flag: 1
> |  + Default flag: 1
> |  + Codec ID: A_AC3
> |  + Content encodings
> |   + Content encoding
> |    + Content compression
> |     + Algorithm: 3 (header removal)
> |     + Settings: length 2, data: 0x0b 0x77
>
> See an attachment.
> Please comment.

After almost 4 years:
Patch committed (r34486).

There may be better ways to make this faster, but I guess that's how
it is done in the libavformat demuxer. Making it work for now is good
enough.

(And yes, a user having problem with osd text subtitles and
libavformat mkv demuxer,  provided me with sample that needs this
patch.).

From Reimar.Doeffinger at gmx.de  Mon Jan  2 17:29:01 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Mon, 2 Jan 2012 17:29:01 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
Message-ID: <9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>

On 2 Jan 2012, at 00:22, Reinhard Tartler <siretart at tauware.de> wrote:
> In order to build mplayer against Libav, a couple of minor patches are
> necessary. I've developed them in the course of maintaining the daily
> builds at https://launchpad.net/~motumedia/+archive/mplayer-daily/, but
> as compatibility with Libav is a requirement for the distro mplayer
> package in debian, I feel they should better go to svn properly.
> 
> So here we go:
> 
> --- mplayer-1.0~svn34481.orig/fmt-conversion.c
> +++ mplayer-1.0~svn34481/fmt-conversion.c
> @@ -24,6 +24,11 @@
> #include "libaf/af_format.h"
> #include "fmt-conversion.h"
> 
> +// libav.org's libavutil is missing this
> +#ifndef PIX_FMT_GBR24P
> +#define PIX_FMT_GBR24P PIX_FMT_GBRP
> +#endif
> +
> static const struct {
>     int fmt;
>     enum PixelFormat pix_fmt;
> @@ -57,7 +62,9 @@
>     {IMGFMT_RGB8,    PIX_FMT_BGR8},
>     {IMGFMT_RGB4,    PIX_FMT_BGR4},
>     {IMGFMT_BGR8,    PIX_FMT_PAL8},
> +#ifdef PIX_FMT_0RGB32
>     {IMGFMT_BGR32,   PIX_FMT_0RGB32},
> +#endif
> #if LIBAVUTIL_VERSION_INT >= AV_VERSION_INT(51, 20, 1)
>     {IMGFMT_GBR24P,  PIX_FMT_GBR24P},
> #endif
> 
> I think these hunks should be rather safe. Instead of using
> PIX_FMT_GBR24P, we could also use PIX_FMT_GBRP directly, as this #define
> was copied FFmpeg's libavcodec.
> 
> --- mplayer-1.0~svn34481.orig/libmpdemux/mp_taglists.c
> +++ mplayer-1.0~svn34481/libmpdemux/mp_taglists.c
> @@ -43,7 +43,9 @@
>     { CODEC_ID_COOK,              MKTAG('c', 'o', 'o', 'k')},
>     { CODEC_ID_DSICINAUDIO,       MKTAG('D', 'C', 'I', 'A')},
>     { CODEC_ID_EAC3,              MKTAG('E', 'A', 'C', '3')},
> +#ifdef CODEC_ID_FFWAVESYNTH
>     { CODEC_ID_FFWAVESYNTH,       MKTAG('F', 'F', 'W', 'S')},
> +#endif
>     { CODEC_ID_G723_1,            MKTAG('7', '2', '3', '1')},
>     { CODEC_ID_INTERPLAY_DPCM,    MKTAG('I', 'N', 'P', 'A')},
>     { CODEC_ID_MLP,               MKTAG('M', 'L', 'P', ' ')},
> @@ -85,7 +87,9 @@
>     { CODEC_ID_DVVIDEO,           MKTAG('d', 'v', 's', 'd')},
>     { CODEC_ID_EAC3,              MKTAG('E', 'A', 'C', '3')},
>     { CODEC_ID_ESCAPE124,         MKTAG('E', '1', '2', '4')},
> +#ifdef CODEC_ID_ESCAPE130
>     { CODEC_ID_ESCAPE130,         MKTAG('E', '1', '3', '0')},
> +#endif
>     { CODEC_ID_FLV1,              MKTAG('F', 'L', 'V', '1')},
>     { CODEC_ID_G729,              MKTAG('G', '7', '2', '9')},
>     { CODEC_ID_H264,              MKTAG('H', '2', '6', '4')},
> 
> These codec id's do not exist in Libav's libavcodec.
> 
> Actually, there used to be a couple of more patches in the daily builds,
> but I think they are no longer necessary. In case I'm wrong, I'll sent
> another email with those included. The patches above, however, are
> definitly necessary.
> 
> Please tell me which of the above changes are acceptable and what
> additional work the other ones require to become acceptable.

I'll have to check up on it, but I don't think any of these can work, those are not defines but enums only to my knowledge, so the whole ifndef stuff shouldn't work one bit.

From siretart at tauware.de  Mon Jan  2 17:35:08 2012
From: siretart at tauware.de (Reinhard Tartler)
Date: Mon, 02 Jan 2012 17:35:08 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de> ("Reimar
	=?utf-8?Q?D=C3=B6ffinger=22's?= message of "Mon, 2 Jan 2012 17:29:01
	+0100")
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
Message-ID: <87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>

On Mo, Jan 02, 2012 at 17:29:01 (CET), Reimar D?ffinger wrote:

> On 2 Jan 2012, at 00:22, Reinhard Tartler <siretart at tauware.de> wrote:
>> In order to build mplayer against Libav, a couple of minor patches are
>> necessary. I've developed them in the course of maintaining the daily
>> builds at https://launchpad.net/~motumedia/+archive/mplayer-daily/, but
>> as compatibility with Libav is a requirement for the distro mplayer
>> package in debian, I feel they should better go to svn properly.
>> 
>> So here we go:
>> 
>> --- mplayer-1.0~svn34481.orig/fmt-conversion.c
>> +++ mplayer-1.0~svn34481/fmt-conversion.c
>> @@ -24,6 +24,11 @@
>> #include "libaf/af_format.h"
>> #include "fmt-conversion.h"
>> 
>> +// libav.org's libavutil is missing this
>> +#ifndef PIX_FMT_GBR24P
>> +#define PIX_FMT_GBR24P PIX_FMT_GBRP
>> +#endif
>> +
>> static const struct {
>>     int fmt;
>>     enum PixelFormat pix_fmt;
>> @@ -57,7 +62,9 @@
>>     {IMGFMT_RGB8,    PIX_FMT_BGR8},
>>     {IMGFMT_RGB4,    PIX_FMT_BGR4},
>>     {IMGFMT_BGR8,    PIX_FMT_PAL8},
>> +#ifdef PIX_FMT_0RGB32
>>     {IMGFMT_BGR32,   PIX_FMT_0RGB32},
>> +#endif
>> #if LIBAVUTIL_VERSION_INT >= AV_VERSION_INT(51, 20, 1)
>>     {IMGFMT_GBR24P,  PIX_FMT_GBR24P},
>> #endif
>> 
>> I think these hunks should be rather safe. Instead of using
>> PIX_FMT_GBR24P, we could also use PIX_FMT_GBRP directly, as this #define
>> was copied FFmpeg's libavcodec.
>> 
>> --- mplayer-1.0~svn34481.orig/libmpdemux/mp_taglists.c
>> +++ mplayer-1.0~svn34481/libmpdemux/mp_taglists.c
>> @@ -43,7 +43,9 @@
>>     { CODEC_ID_COOK,              MKTAG('c', 'o', 'o', 'k')},
>>     { CODEC_ID_DSICINAUDIO,       MKTAG('D', 'C', 'I', 'A')},
>>     { CODEC_ID_EAC3,              MKTAG('E', 'A', 'C', '3')},
>> +#ifdef CODEC_ID_FFWAVESYNTH
>>     { CODEC_ID_FFWAVESYNTH,       MKTAG('F', 'F', 'W', 'S')},
>> +#endif
>>     { CODEC_ID_G723_1,            MKTAG('7', '2', '3', '1')},
>>     { CODEC_ID_INTERPLAY_DPCM,    MKTAG('I', 'N', 'P', 'A')},
>>     { CODEC_ID_MLP,               MKTAG('M', 'L', 'P', ' ')},
>> @@ -85,7 +87,9 @@
>>     { CODEC_ID_DVVIDEO,           MKTAG('d', 'v', 's', 'd')},
>>     { CODEC_ID_EAC3,              MKTAG('E', 'A', 'C', '3')},
>>     { CODEC_ID_ESCAPE124,         MKTAG('E', '1', '2', '4')},
>> +#ifdef CODEC_ID_ESCAPE130
>>     { CODEC_ID_ESCAPE130,         MKTAG('E', '1', '3', '0')},
>> +#endif
>>     { CODEC_ID_FLV1,              MKTAG('F', 'L', 'V', '1')},
>>     { CODEC_ID_G729,              MKTAG('G', '7', '2', '9')},
>>     { CODEC_ID_H264,              MKTAG('H', '2', '6', '4')},
>> 
>> These codec id's do not exist in Libav's libavcodec.
>> 
>> Actually, there used to be a couple of more patches in the daily builds,
>> but I think they are no longer necessary. In case I'm wrong, I'll sent
>> another email with those included. The patches above, however, are
>> definitly necessary.
>> 
>> Please tell me which of the above changes are acceptable and what
>> additional work the other ones require to become acceptable.
>
> I'll have to check up on it, but I don't think any of these can work,
> those are not defines but enums only to my knowledge, so the whole
> ifndef stuff shouldn't work one bit.

Yeah, sorry, Uoti pointed this out to me on IRC as well.

While I still guess the PIX_FMT #definery should still work, the
CODEC_ID enums require some other solution. Can you think about a better
way than to hack up configure to see if ffwavesync and escpae130 are
available?

Cheers,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

From nicolas.george at normalesup.org  Mon Jan  2 17:42:39 2012
From: nicolas.george at normalesup.org (Nicolas George)
Date: Mon, 2 Jan 2012 17:42:39 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
Message-ID: <20120102164239.GA12755@phare.normalesup.org>

Le tridi 13 niv?se, an CCXX, Reinhard Tartler a ?crit?:
> While I still guess the PIX_FMT #definery should still work, the
> CODEC_ID enums require some other solution. Can you think about a better
> way than to hack up configure to see if ffwavesync and escpae130 are
> available?

For FFWAVESYNC, that is easy: the CODEC_ID comes with the decoder, so you
have the CONFIG_FFWAVESYNTH_DECODER macro.

But for the long run, we will not escape addressing the point of the API/ABI
compatibility between ffmpeg and libav. Unfortunately, most of the leaders
of libav seem to not care about it at all, and if I had to take a guess, I
may say that some of them enjoy the prospect of breaking compatibility.

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: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120102/baafce82/attachment.asc>

From Dan.Oscarsson at tieto.com  Mon Jan  2 17:59:19 2012
From: Dan.Oscarsson at tieto.com (Dan Oscarsson)
Date: Mon, 02 Jan 2012 17:59:19 +0100
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
Message-ID: <1325523559.20740.15.camel@luna.malmo.kicore.net>

Hi

Attached is a new version of my threaded cache code.

This version does not have a sleep or timed wait in the cache thread.
configure need more work, I expect some of you know better then me how
you want it.

   Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cache-thread.diff
Type: text/x-patch
Size: 3367 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120102/22844432/attachment.bin>

From siretart at tauware.de  Mon Jan  2 18:04:53 2012
From: siretart at tauware.de (Reinhard Tartler)
Date: Mon, 02 Jan 2012 18:04:53 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <20120102164239.GA12755@phare.normalesup.org> (Nicolas George's
	message of "Mon, 2 Jan 2012 17:42:39 +0100")
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
Message-ID: <8762guhw7e.fsf@faui43f.informatik.uni-erlangen.de>

On Mo, Jan 02, 2012 at 17:42:39 (CET), Nicolas George wrote:

> Le tridi 13 niv?se, an CCXX, Reinhard Tartler a ?crit?:
>> While I still guess the PIX_FMT #definery should still work, the
>> CODEC_ID enums require some other solution. Can you think about a better
>> way than to hack up configure to see if ffwavesync and escpae130 are
>> available?
>
> For FFWAVESYNC, that is easy: the CODEC_ID comes with the decoder, so you
> have the CONFIG_FFWAVESYNTH_DECODER macro.

That's a good idea. I'll update the patch like this then.

> But for the long run, we will not escape addressing the point of the API/ABI
> compatibility between ffmpeg and libav. Unfortunately, most of the leaders
> of libav seem to not care about it at all, and if I had to take a guess, I
> may say that some of them enjoy the prospect of breaking compatibility.

There are no "leaders" in libav.

But be assured, I am active in libav and I do care about mplayer
compatibility, otherwise I wouldn't submit such patches to mplayer.

As for escape130, I've just submitted the decoder to libav. If it gets
accepted, then I think we've found an acceptable solution.

Cheers,
Reinhard.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

From siretart at tauware.de  Mon Jan  2 18:08:20 2012
From: siretart at tauware.de (Reinhard Tartler)
Date: Mon, 02 Jan 2012 18:08:20 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <20120102164239.GA12755@phare.normalesup.org> (Nicolas George's
	message of "Mon, 2 Jan 2012 17:42:39 +0100")
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
Message-ID: <871urihw1n.fsf@faui43f.informatik.uni-erlangen.de>

On Mo, Jan 02, 2012 at 17:42:39 (CET), Nicolas George wrote:

> Le tridi 13 niv?se, an CCXX, Reinhard Tartler a ?crit?:
>> While I still guess the PIX_FMT #definery should still work, the
>> CODEC_ID enums require some other solution. Can you think about a better
>> way than to hack up configure to see if ffwavesync and escpae130 are
>> available?
>
> For FFWAVESYNC, that is easy: the CODEC_ID comes with the decoder, so you
> have the CONFIG_FFWAVESYNTH_DECODER macro.

Unfortunately, the macro CONFIG_FFWAVESYNTH_DECODER does not show up in
mplayer's config.h.

Maybe I misunderstood you, could you please clarify?

Cheers,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

From siretart at tauware.de  Mon Jan  2 18:13:55 2012
From: siretart at tauware.de (Reinhard Tartler)
Date: Mon, 02 Jan 2012 18:13:55 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <871urihw1n.fsf@faui43f.informatik.uni-erlangen.de> (Reinhard
	Tartler's message of "Mon, 02 Jan 2012 18:08:20 +0100")
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
	<871urihw1n.fsf@faui43f.informatik.uni-erlangen.de>
Message-ID: <87wr9agh7w.fsf@faui43f.informatik.uni-erlangen.de>

On Mo, Jan 02, 2012 at 18:08:20 (CET), Reinhard Tartler wrote:

> On Mo, Jan 02, 2012 at 17:42:39 (CET), Nicolas George wrote:
>
>> Le tridi 13 niv?se, an CCXX, Reinhard Tartler a ?crit?:
>>> While I still guess the PIX_FMT #definery should still work, the
>>> CODEC_ID enums require some other solution. Can you think about a better
>>> way than to hack up configure to see if ffwavesync and escpae130 are
>>> available?
>>
>> For FFWAVESYNC, that is easy: the CODEC_ID comes with the decoder, so you
>> have the CONFIG_FFWAVESYNTH_DECODER macro.
>
> Unfortunately, the macro CONFIG_FFWAVESYNTH_DECODER does not show up in
> mplayer's config.h.

My bad, it does show up. I looked in a wrong, outdated, mplayer
checkout.

Sorry for the confusion.

Cheers,
Reinhard
-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

From nicolas.george at normalesup.org  Mon Jan  2 18:15:34 2012
From: nicolas.george at normalesup.org (Nicolas George)
Date: Mon, 2 Jan 2012 18:15:34 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <8762guhw7e.fsf@faui43f.informatik.uni-erlangen.de>
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
	<8762guhw7e.fsf@faui43f.informatik.uni-erlangen.de>
Message-ID: <20120102171534.GA17856@phare.normalesup.org>

Le tridi 13 niv?se, an CCXX, Reinhard Tartler a ?crit?:
> There are no "leaders" in libav.
> 
> But be assured, I am active in libav and I do care about mplayer
> compatibility, otherwise I wouldn't submit such patches to mplayer.

I see you do, but I am afraid you are quite isolated. But maybe it is an
unfounded impression from me.

> As for escape130, I've just submitted the decoder to libav. If it gets
> accepted, then I think we've found an acceptable solution.

I saw your patch, but I had not yet time to comment. I fear it will not
work. You insert the CODEC_ID in the middle of the list, so you change the
value of all subsequent ids. That should only happen with major bumps.

But even if you append it at the end, during his nightly merges Michael will
define CODEC_ID_ESCAPE130_BIS or something to ensure binary compatibility
with both previous ffmpeg and next libav. And finally, someone will insert
CODEC_ID_ESCAPE130_BIS into the fourcc table of MPlayer for some reason.

The best course of action for the future would probably be to get
CODEC_ID_ESCAPE130 accepted with the same value as in ffmpeg.

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: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120102/9baf79fb/attachment.asc>

From nicolas.george at normalesup.org  Mon Jan  2 18:18:57 2012
From: nicolas.george at normalesup.org (Nicolas George)
Date: Mon, 2 Jan 2012 18:18:57 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <871urihw1n.fsf@faui43f.informatik.uni-erlangen.de>
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
	<871urihw1n.fsf@faui43f.informatik.uni-erlangen.de>
Message-ID: <20120102171857.GB17856@phare.normalesup.org>

Le tridi 13 niv?se, an CCXX, Reinhard Tartler a ?crit?:
> Unfortunately, the macro CONFIG_FFWAVESYNTH_DECODER does not show up in
> mplayer's config.h.

In mine it does. I am not familiar with the subtleties of the build system,
but I guess it depends on what version of ffmpeg/libavcodec/allcodecs.c is
present in the build tree.

I suppose you need to check whether the macro is defined or not, and not
whether its boolean value is true or false.

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: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120102/09caefc7/attachment.asc>

From siretart at tauware.de  Mon Jan  2 18:33:44 2012
From: siretart at tauware.de (Reinhard Tartler)
Date: Mon, 02 Jan 2012 18:33:44 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <20120102171534.GA17856@phare.normalesup.org> (Nicolas George's
	message of "Mon, 2 Jan 2012 18:15:34 +0100")
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
	<8762guhw7e.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102171534.GA17856@phare.normalesup.org>
Message-ID: <87sjjyggav.fsf@faui43f.informatik.uni-erlangen.de>

On Mo, Jan 02, 2012 at 18:15:34 (CET), Nicolas George wrote:

> Le tridi 13 niv?se, an CCXX, Reinhard Tartler a ?crit?:
>> There are no "leaders" in libav.
>> 
>> But be assured, I am active in libav and I do care about mplayer
>> compatibility, otherwise I wouldn't submit such patches to mplayer.
>
> I see you do, but I am afraid you are quite isolated. But maybe it is an
> unfounded impression from me.

Let's assume your impression unfounded for now.

>
>> As for escape130, I've just submitted the decoder to libav. If it gets
>> accepted, then I think we've found an acceptable solution.
>
> I saw your patch, but I had not yet time to comment. I fear it will not
> work. You insert the CODEC_ID in the middle of the list, so you change the
> value of all subsequent ids. That should only happen with major bumps.

I see. Will update the patch then.

As for the ffmpeg/libav politics, let's please leave them aside for now
and focus on the following patch:


--- fmt-conversion.c	(revision 34482)
+++ fmt-conversion.c	(working copy)
@@ -24,6 +24,11 @@
 #include "libaf/af_format.h"
 #include "fmt-conversion.h"
 
+// libav.org's libavutil is missing this
+#ifndef PIX_FMT_GBR24P
+#define PIX_FMT_GBR24P PIX_FMT_GBRP
+#endif
+
 static const struct {
     int fmt;
     enum PixelFormat pix_fmt;
@@ -57,7 +62,9 @@
     {IMGFMT_RGB8,    PIX_FMT_BGR8},
     {IMGFMT_RGB4,    PIX_FMT_BGR4},
     {IMGFMT_BGR8,    PIX_FMT_PAL8},
+#ifdef PIX_FMT_0RGB32
     {IMGFMT_BGR32,   PIX_FMT_0RGB32},
+#endif
 #if LIBAVUTIL_VERSION_INT >= AV_VERSION_INT(51, 20, 1)
     {IMGFMT_GBR24P,  PIX_FMT_GBR24P},
 #endif

--- libmpdemux/mp_taglists.c	(revision 34482)
+++ libmpdemux/mp_taglists.c	(working copy)
@@ -43,7 +43,9 @@
     { CODEC_ID_COOK,              MKTAG('c', 'o', 'o', 'k')},
     { CODEC_ID_DSICINAUDIO,       MKTAG('D', 'C', 'I', 'A')},
     { CODEC_ID_EAC3,              MKTAG('E', 'A', 'C', '3')},
+#ifdef CONFIG_FFWAVESYNTH_DECODER
     { CODEC_ID_FFWAVESYNTH,       MKTAG('F', 'F', 'W', 'S')},
+#endif
     { CODEC_ID_G723_1,            MKTAG('7', '2', '3', '1')},
     { CODEC_ID_INTERPLAY_DPCM,    MKTAG('I', 'N', 'P', 'A')},
     { CODEC_ID_MLP,               MKTAG('M', 'L', 'P', ' ')},
@@ -85,7 +87,9 @@
     { CODEC_ID_DVVIDEO,           MKTAG('d', 'v', 's', 'd')},
     { CODEC_ID_EAC3,              MKTAG('E', 'A', 'C', '3')},
     { CODEC_ID_ESCAPE124,         MKTAG('E', '1', '2', '4')},
+#ifdef CONFIG_ESCAPE130_DECODER
     { CODEC_ID_ESCAPE130,         MKTAG('E', '1', '3', '0')},
+#endif
     { CODEC_ID_FLV1,              MKTAG('F', 'L', 'V', '1')},
     { CODEC_ID_G729,              MKTAG('G', '7', '2', '9')},
     { CODEC_ID_H264,              MKTAG('H', '2', '6', '4')},

In my tests, this allows compilation against libav. Moreover, this
version does allow mplayer to playback escape130 files when compiled
against FFmpeg.



-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

From nicolas.george at normalesup.org  Mon Jan  2 19:34:32 2012
From: nicolas.george at normalesup.org (Nicolas George)
Date: Mon, 2 Jan 2012 19:34:32 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <87sjjyggav.fsf@faui43f.informatik.uni-erlangen.de>
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
	<8762guhw7e.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102171534.GA17856@phare.normalesup.org>
	<87sjjyggav.fsf@faui43f.informatik.uni-erlangen.de>
Message-ID: <20120102183432.GA30422@phare.normalesup.org>

Le tridi 13 niv?se, an CCXX, Reinhard Tartler a ?crit?:
> As for the ffmpeg/libav politics, let's please leave them aside for now
> and focus on the following patch:

Yes, of course.

> In my tests, this allows compilation against libav. Moreover, this
> version does allow mplayer to playback escape130 files when compiled
> against FFmpeg.

It will not allow a mplayer built against a libav tree and dynamically
linked to lavc to start playing escape130 if lavc.so is replaced by one
coming from ffmpeg, but I believe we can live with that for now.

If Reimar is fine with the ifdeffery -- I know he does not like it as a
general principle -- this patch seems ok.

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: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120102/8fa0b532/attachment.asc>

From nicolas.george at normalesup.org  Mon Jan  2 21:31:33 2012
From: nicolas.george at normalesup.org (Nicolas George)
Date: Mon,  2 Jan 2012 21:31:33 +0100
Subject: [MPlayer-dev-eng] [PATCH] taglists: try to convert codec_id to tag.
Message-ID: <1325536293-5143-1-git-send-email-nicolas.george@normalesup.org>

FFmpeg has recently started to use fourccs as codec_id values. This patch
tries, if everything else has failed, to detect them (by checking that all
four bytes are likely ASCII characters) and use them.

It allows to remove FFWAVESYNTH from the hardcoded list.
Other may possibly also be removed.
---


I tried to remove CODEC_ID_ESCAPE130 too, but it seems that the test:
// mp4a tag is used for all mp4 files no matter what they actually contain
is producing a bad result. As I do not really understand what it does, I
leave it alone for now.

Regards,

-- 
  Nicolas George


 libmpdemux/mp_taglists.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/libmpdemux/mp_taglists.c b/libmpdemux/mp_taglists.c
index a7a1c7b..7381432 100644
--- a/libmpdemux/mp_taglists.c
+++ b/libmpdemux/mp_taglists.c
@@ -43,7 +43,6 @@ static const struct AVCodecTag mp_wav_tags[] = {
     { CODEC_ID_COOK,              MKTAG('c', 'o', 'o', 'k')},
     { CODEC_ID_DSICINAUDIO,       MKTAG('D', 'C', 'I', 'A')},
     { CODEC_ID_EAC3,              MKTAG('E', 'A', 'C', '3')},
-    { CODEC_ID_FFWAVESYNTH,       MKTAG('F', 'F', 'W', 'S')},
     { CODEC_ID_G723_1,            MKTAG('7', '2', '3', '1')},
     { CODEC_ID_INTERPLAY_DPCM,    MKTAG('I', 'N', 'P', 'A')},
     { CODEC_ID_MLP,               MKTAG('M', 'L', 'P', ' ')},
@@ -169,6 +168,25 @@ enum CodecID mp_tag2codec_id(uint32_t tag, int audio)
     return av_codec_get_id(avi_format->codec_tag, tag);
 }
 
+/**
+ * Detect codec_ids that are likely to be the result of MKBETAG.
+ */
+static uint32_t fourcc_codec_id_to_tag(uint32_t id)
+{
+    int i, c;
+    uint32_t r = 0;
+
+    for (i = 0; i < 4; i++) {
+        c = id & 0xFF;
+        if (!(c == ' ' || (c >= '0' && c <= '9') || (c >= 'A' && c <= 'Z') ||
+              (c >= 'a' && c <= 'z')))
+            return 0;
+        id >>= 8;
+        r = (r << 8) | c;
+    }
+    return r;
+}
+
 uint32_t mp_codec_id2tag(enum CodecID codec_id, uint32_t old_tag, int audio)
 {
     AVOutputFormat *avi_format;
@@ -194,5 +212,8 @@ uint32_t mp_codec_id2tag(enum CodecID codec_id, uint32_t old_tag, int audio)
         mp_msg(MSGT_DEMUXER, MSGL_FATAL, "MPlayer cannot work properly without AVI muxer in libavformat!\n");
         return 0;
     }
-    return av_codec_get_tag(avi_format->codec_tag, codec_id);
+    tag = av_codec_get_tag(avi_format->codec_tag, codec_id);
+    if (tag)
+        return tag;
+    return fourcc_codec_id_to_tag(codec_id);
 }
-- 
1.7.2.5


From andrej at rep.kiev.ua  Mon Jan  2 22:59:59 2012
From: andrej at rep.kiev.ua (Andrej N. Gritsenko)
Date: Mon, 2 Jan 2012 23:59:59 +0200
Subject: [MPlayer-dev-eng] threaded cache, round 2
In-Reply-To: <1325523559.20740.15.camel@luna.malmo.kicore.net>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
Message-ID: <20120102215959.GA18417@rep.kiev.ua>

    Hello!

Dan Oscarsson has written:
>Attached is a new version of my threaded cache code.

>This version does not have a sleep or timed wait in the cache thread.
>configure need more work, I expect some of you know better then me how
>you want it.

[.......]
>+#ifdef PTHREAD_CACHE
>+    if (!((cache_vars_t *)s->cache_data)->do_work) {
>+        pthread_mutex_lock(&((cache_vars_t *)s->cache_data)->go_ahead_mutex);
>+           ((cache_vars_t *)s->cache_data)->do_work = 1;
>+        pthread_mutex_unlock(&((cache_vars_t *)s->cache_data)->go_ahead_mutex);
>+        pthread_cond_signal(&((cache_vars_t *)s->cache_data)->go_ahead);
>+    } else {
>+        // when cache_do_control loops on the cpu, sometimes system is slow
>+        // to wake up threads. A quick sleep helps
>+        usec_sleep(1);
>+    }
>+#endif
>+
[.......]

    Is it change on do_work possible only in one thread? If not then you
should lock mutex before conditional based on its value. And as soon it's
set to 1 in one thread and to 0 in another (assuming from you code) that
means your code contains race condition, i.e. mutex locking is really not
functional so you have to fix that everywhere.

    With best wishes.
    Andriy.

From vyslnqaaxytp at dyxyl.com  Mon Jan  2 23:06:35 2012
From: vyslnqaaxytp at dyxyl.com (Martin Simmons)
Date: Mon,  2 Jan 2012 22:06:35 +0000 (GMT)
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
In-Reply-To: <1325523559.20740.15.camel@luna.malmo.kicore.net> (message from
	Dan Oscarsson on Mon, 02 Jan 2012 17:59:19 +0100)
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
Message-ID: <20120102220635.2329D1F02C9@localhost.localdomain>

>>>>> On Mon, 02 Jan 2012 17:59:19 +0100, Dan Oscarsson said:
> 
> +#ifdef PTHREAD_CACHE
> +    if (!((cache_vars_t *)s->cache_data)->do_work) {
> +        pthread_mutex_lock(&((cache_vars_t *)s->cache_data)->go_ahead_mutex);
> +           ((cache_vars_t *)s->cache_data)->do_work = 1;
> +        pthread_mutex_unlock(&((cache_vars_t *)s->cache_data)->go_ahead_mutex);
> +        pthread_cond_signal(&((cache_vars_t *)s->cache_data)->go_ahead);

The last two lines are in the wrong order -- to avoid race conditions, you
must signal while holding the lock.


> +#ifdef PTHREAD_CACHE
> +    if (!s->do_work) {
> +        pthread_mutex_lock(&s->go_ahead_mutex);
> +           s->do_work = 1;
> +        pthread_mutex_unlock(&s->go_ahead_mutex);
> +        pthread_cond_signal(&s->go_ahead);

Ditto.


> +#ifdef PTHREAD_CACHE
> +            if (!s->do_work) {
> +                pthread_mutex_lock(&s->go_ahead_mutex);
> +                    while (!s->do_work) pthread_cond_wait(&s->go_ahead, &s->go_ahead_mutex);
> +                pthread_mutex_unlock(&s->go_ahead_mutex);
> +            }
> +            s->do_work = 0;

Set s->do_work to 0 while holding the lock inside the if, also to avoid race
conditions.

__Martin

From Reimar.Doeffinger at gmx.de  Tue Jan  3 02:04:23 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Tue, 3 Jan 2012 02:04:23 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <20120102183432.GA30422@phare.normalesup.org>
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
	<8762guhw7e.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102171534.GA17856@phare.normalesup.org>
	<87sjjyggav.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102183432.GA30422@phare.normalesup.org>
Message-ID: <3F2AAC9E-A333-4B53-9630-A5EF7015738E@gmx.de>

On 2 Jan 2012, at 19:34, Nicolas George <nicolas.george at normalesup.org> wrote:
> Le tridi 13 niv?se, an CCXX, Reinhard Tartler a ?crit :
>> As for the ffmpeg/libav politics, let's please leave them aside for now
>> and focus on the following patch:
> 
> Yes, of course.
> 
>> In my tests, this allows compilation against libav. Moreover, this
>> version does allow mplayer to playback escape130 files when compiled
>> against FFmpeg.
> 
> It will not allow a mplayer built against a libav tree and dynamically
> linked to lavc to start playing escape130 if lavc.so is replaced by one
> coming from ffmpeg, but I believe we can live with that for now.
> 
> If Reimar is fine with the ifdeffery -- I know he does not like it as a
> general principle -- this patch seems ok.

I do not like it, yes. I can accept it, but that is only if it's not completely broken.
The current suggestions are, the decoder config defines are not part of the public API and won't work when compiling against external FFmpeg.
You can just distinguish between FFmpeg and libav by checking whether the micro version is < 100 (there might be some other method preferred libav-side).
Of course this means that these codecs will not be supported with libav even if support for them is added there.
As said before I am not willing to make an effort to support libav myself (ok, not much of an effort, I guess I am too nice to make no effort at all), so I'd request for someone else to keep an eye out for that (or come up with a better solution).
One possible solution might be to make the mapping codec name <-> tag and then use a find codec by id etc.
However this has a few issues, too. For example we will want some/most mappings to work even when lavc was compiled without support for that codec.
Also in the past against my objections the name was not considered part of the ABI, so this might break any time even without a major bump.
Thuse so far my best idea is a hard-codec check for FFmpeg vs. libav, crappy as it is.

From Dan.Oscarsson at tieto.com  Tue Jan  3 09:47:38 2012
From: Dan.Oscarsson at tieto.com (Dan Oscarsson)
Date: Tue, 03 Jan 2012 09:47:38 +0100
Subject: [MPlayer-dev-eng] threaded cache, round 2
In-Reply-To: <20120102215959.GA18417@rep.kiev.ua>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
	<20120102215959.GA18417@rep.kiev.ua>
Message-ID: <1325580458.4662.3.camel@luna.malmo.kicore.net>

m?n 2012-01-02 klockan 23:59 +0200 skrev Andrej N. Gritsenko:
> [.......]
> >+#ifdef PTHREAD_CACHE
> >+    if (!((cache_vars_t *)s->cache_data)->do_work) {
> >+        pthread_mutex_lock(&((cache_vars_t *)s->cache_data)->go_ahead_mutex);
> >+           ((cache_vars_t *)s->cache_data)->do_work = 1;
> >+        pthread_mutex_unlock(&((cache_vars_t *)s->cache_data)->go_ahead_mutex);
> >+        pthread_cond_signal(&((cache_vars_t *)s->cache_data)->go_ahead);
> >+    } else {
> >+        // when cache_do_control loops on the cpu, sometimes system is slow
> >+        // to wake up threads. A quick sleep helps
> >+        usec_sleep(1);
> >+    }
> >+#endif
> >+
> [.......]
> 
>     Is it change on do_work possible only in one thread? If not then you
> should lock mutex before conditional based on its value. And as soon it's
> set to 1 in one thread and to 0 in another (assuming from you code) that
> means your code contains race condition, i.e. mutex locking is really not
> functional so you have to fix that everywhere.

Main thread sets do_work to 1 to tell cache that main thread have read
data from cache or a command is available to be processed. And main
thread does this after it has read data from cache or set up command. I
do not think there can be a race condition.

   Dan


From Dan.Oscarsson at tieto.com  Tue Jan  3 09:58:04 2012
From: Dan.Oscarsson at tieto.com (Dan Oscarsson)
Date: Tue, 03 Jan 2012 09:58:04 +0100
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
In-Reply-To: <20120102220635.2329D1F02C9@localhost.localdomain>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
	<20120102220635.2329D1F02C9@localhost.localdomain>
Message-ID: <1325581084.4662.13.camel@luna.malmo.kicore.net>

m?n 2012-01-02 klockan 22:06 +0000 skrev Martin Simmons:
> >>>>> On Mon, 02 Jan 2012 17:59:19 +0100, Dan Oscarsson said:
> > 
> > +#ifdef PTHREAD_CACHE
> > +    if (!((cache_vars_t *)s->cache_data)->do_work) {
> > +        pthread_mutex_lock(&((cache_vars_t *)s->cache_data)->go_ahead_mutex);
> > +           ((cache_vars_t *)s->cache_data)->do_work = 1;
> > +        pthread_mutex_unlock(&((cache_vars_t *)s->cache_data)->go_ahead_mutex);
> > +        pthread_cond_signal(&((cache_vars_t *)s->cache_data)->go_ahead);
> 
> The last two lines are in the wrong order -- to avoid race conditions, you
> must signal while holding the lock.

No, not from my analysis. If cache thread detects that do_work is 1
before the signal is sent, it does not matter. Either the cache thread
detects that do_work is 1 and starts to work, or it locks the mutex
before do_work is set to 1, and waits for signal instead.

> 
> 
> > +#ifdef PTHREAD_CACHE
> > +    if (!s->do_work) {
> > +        pthread_mutex_lock(&s->go_ahead_mutex);
> > +           s->do_work = 1;
> > +        pthread_mutex_unlock(&s->go_ahead_mutex);
> > +        pthread_cond_signal(&s->go_ahead);
> 
> Ditto.
> 
> 
> > +#ifdef PTHREAD_CACHE
> > +            if (!s->do_work) {
> > +                pthread_mutex_lock(&s->go_ahead_mutex);
> > +                    while (!s->do_work) pthread_cond_wait(&s->go_ahead, &s->go_ahead_mutex);
> > +                pthread_mutex_unlock(&s->go_ahead_mutex);
> > +            }
> > +            s->do_work = 0;
> 
> Set s->do_work to 0 while holding the lock inside the if, also to avoid race
> conditions.

Quite often it is so, but not in this case (unless my analysis is
wrong). When cache thread sets do_work to 0 above, it is going to do
some work (reading data and command processing), so it does not matter
if do_work is set to 1 by main thread and that is erased by this setting
to zero.

I moved pthread_cond_signal and the setting of do_work = 0 outside the
mutex lock to reduce time spent inside the lock as I it looks like the
cannot be a race condition in this case.
We can move them back in even if nobody can show a case where it gets
wrong, just to be sure.

   Dan


From diego at biurrun.de  Tue Jan  3 14:40:48 2012
From: diego at biurrun.de (Diego Biurrun)
Date: Tue,  3 Jan 2012 14:40:48 +0100
Subject: [MPlayer-dev-eng] =?utf-8?q?=5BPATCH=5D_Remove_warning_when_tryin?=
	=?utf-8?q?g_to_invoke_long-gone_alsa9_and_alsa1x_ao_drivers=2E?=
Message-ID: <1325598048-3157-1-git-send-email-diego@biurrun.de>

These drivers have been replaced years ago, it's time to drop the hint.
---
 help/help_mp-bg.h    |    3 ---
 help/help_mp-cs.h    |    1 -
 help/help_mp-de.h    |    3 ---
 help/help_mp-en.h    |    1 -
 help/help_mp-es.h    |    1 -
 help/help_mp-fr.h    |    3 ---
 help/help_mp-hu.h    |    1 -
 help/help_mp-it.h    |    1 -
 help/help_mp-nl.h    |    3 ---
 help/help_mp-pl.h    |    3 ---
 help/help_mp-ru.h    |    1 -
 help/help_mp-sv.h    |    3 ---
 help/help_mp-tr.h    |    3 ---
 help/help_mp-zh_CN.h |    1 -
 help/help_mp-zh_TW.h |    3 ---
 libao2/audio_out.c   |    4 ----
 16 files changed, 0 insertions(+), 35 deletions(-)

diff --git a/help/help_mp-bg.h b/help/help_mp-bg.h
index ee71580..aafb272 100644
--- a/help/help_mp-bg.h
+++ b/help/help_mp-bg.h
@@ -856,9 +856,6 @@ static const char help_text[]=
 
 // libao2
 
-// audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out: ???????? alsa9 ? alsa1x ?? ??????????, ??????????? -ao alsa .\n"
-
 // ao_oss.c
 #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup: ?? ???? ?? ?????? ?????????? ???????? %s: %s\n"
 #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup:\n?????????? ?? ????????? ????? ???? ????? '%s', ???????? ?? ??????????? ??.\n"
diff --git a/help/help_mp-cs.h b/help/help_mp-cs.h
index 837d75e..7fbd5fb 100644
--- a/help/help_mp-cs.h
+++ b/help/help_mp-cs.h
@@ -1105,7 +1105,6 @@ static const char help_text[]=
 // ======================= audio output drivers ========================
 
 // audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out: moduly alsa9 a alsa1x byly odstran?ny, m?sto nich pou?ijte -ao alsa.\n"
 #define MSGTR_AO_NoSuchDriver "Takov? audio rozhran? nen? '%.*s'\n"
 #define MSGTR_AO_FailedInit "Selhala inicializace audio rozhran? '%s'\n"
 
diff --git a/help/help_mp-de.h b/help/help_mp-de.h
index f0cfdd8..2149172 100644
--- a/help/help_mp-de.h
+++ b/help/help_mp-de.h
@@ -1120,9 +1120,6 @@ static const char help_text[]=
 // ======================= Audioausgabetreiber ========================
 
 // audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed \
-"audio_out: Die Module alsa9 und alsa1x wurden entfernt, benutze stattdessen \n" \
-"-ao alsa.\n"
 #define MSGTR_AO_NoSuchDriver "Kein Audiotreiber '%.*s'\n"
 #define MSGTR_AO_FailedInit "Konnte Audiotreiber '%s' nicht initialisieren\n"
 
diff --git a/help/help_mp-en.h b/help/help_mp-en.h
index 8cac0ec..30dcf80 100644
--- a/help/help_mp-en.h
+++ b/help/help_mp-en.h
@@ -1166,7 +1166,6 @@ static const char help_text[]=
 // ======================= audio output drivers ========================
 
 // audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out: alsa9 and alsa1x modules were removed, use -ao alsa instead.\n"
 #define MSGTR_AO_NoSuchDriver "No such audio driver '%.*s'\n"
 #define MSGTR_AO_FailedInit "Failed to initialize audio driver '%s'\n"
 
diff --git a/help/help_mp-es.h b/help/help_mp-es.h
index 61cadf5..c6a1c07 100644
--- a/help/help_mp-es.h
+++ b/help/help_mp-es.h
@@ -1119,7 +1119,6 @@ static const char help_text[]=
 // ======================= audio output drivers ========================
 
 // audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out: los m?dulos alsa9 y alsa1x fueron eliminados, usa -ao alsa.\n"
 #define MSGTR_AO_NoSuchDriver "No existe ese controlador de audio '%.*s'\n"
 #define MSGTR_AO_FailedInit "Fallo al inicializar controlador de audio '%s'\n"
 
diff --git a/help/help_mp-fr.h b/help/help_mp-fr.h
index d6e384a..b329f2b 100644
--- a/help/help_mp-fr.h
+++ b/help/help_mp-fr.h
@@ -1029,9 +1029,6 @@ static const char help_text[]=
 
 // libao2
 
-// audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out : modules alsa9 et alsa1x enlev?s, utiliser plut?t -ao alsa.\n"
-
 // ao_oss.c
 #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup : Impossible d'ouvrir mixeur %s : %s\n"
 #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup : Mixeur de carte audio n'a pas canal '%s' utilise default.\n"
diff --git a/help/help_mp-hu.h b/help/help_mp-hu.h
index c3cfaff..3bb9558 100644
--- a/help/help_mp-hu.h
+++ b/help/help_mp-hu.h
@@ -1118,7 +1118,6 @@ static const char help_text[]=
 // ======================= audio output drivers ========================
 
 // audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out: alsa9 ?s alsa1x modulok t?r?lve lettek, haszn?ld a -ao alsa kapcsol?t helyett?k.\n"
 #define MSGTR_AO_NoSuchDriver "Nincs ilyen audi? vez?rl?: '%.*s'\n"
 #define MSGTR_AO_FailedInit "A(z) '%s' audi? vez?rl? inicializ?l?sa nem siker?lt\n"
 
diff --git a/help/help_mp-it.h b/help/help_mp-it.h
index 70d1490..dc4e175 100644
--- a/help/help_mp-it.h
+++ b/help/help_mp-it.h
@@ -1113,7 +1113,6 @@ static const char help_text[]=
 // ======================= audio output drivers ========================
 
 // audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out: i moduli alsa9/alsa1x sono stati rimossi, ora usa -ao alsa.\n"
 #define MSGTR_AO_NoSuchDriver "driver audio '%.*s' non trovato\n"
 #define MSGTR_AO_FailedInit "Inizializzazione del driver audio '%s' non riuscita\n"
 
diff --git a/help/help_mp-nl.h b/help/help_mp-nl.h
index 099d63a..d736316 100644
--- a/help/help_mp-nl.h
+++ b/help/help_mp-nl.h
@@ -791,9 +791,6 @@ static const char help_text[]=
 
 // libao2
 
-// audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out: de alsa9 en alsa1x modules werden verwijderd, gebruik -ao alsa.\n"
-
 // ao_oss.c
 #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup: Kan het mixer apparaat %s niet openen : %s\n"
 #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup: De mixer van de geluidskaart heeft geen kanaal dat de standaard '%s' gebruikt.\n"
diff --git a/help/help_mp-pl.h b/help/help_mp-pl.h
index cd95fe1..51ac23b 100644
--- a/help/help_mp-pl.h
+++ b/help/help_mp-pl.h
@@ -995,9 +995,6 @@ static const char help_text[]=
 
 // libao2
 
-// audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out: modu?y alsa9 i alsa1x zosta?y usuni?te, u?yj w zamian -ao alsa.\n"
-
 // ao_oss.c
 #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup: Nie mog? otworzy? mixera %s: %s\n"
 #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup: Mixer karty d?wi?kowej nie ma kana?u '%s', u?ywam domy?lnego.\n"
diff --git a/help/help_mp-ru.h b/help/help_mp-ru.h
index ada9bc9..489efa3 100644
--- a/help/help_mp-ru.h
+++ b/help/help_mp-ru.h
@@ -1106,7 +1106,6 @@ static const char help_text[]=
 // ======================= audio output drivers ========================
 
 // audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "??????????: ?????? alsa9 ? alsa1x ???? ???????, ??????????? -ao alsa ??????.\n"
 #define MSGTR_AO_NoSuchDriver "??????????? ????? ??????? '%.*s'\n"
 #define MSGTR_AO_FailedInit "?? ???? ???????????????? ????? ??????? '%s'\n"
 
diff --git a/help/help_mp-sv.h b/help/help_mp-sv.h
index 4b2a241..76bc227 100644
--- a/help/help_mp-sv.h
+++ b/help/help_mp-sv.h
@@ -810,9 +810,6 @@ static const char help_text[]=
 
 // libao2
 
-// audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "audio_out: alsa9- samt alsa1xmodulerna har blivit borttagna, anv?nd -ao ist?llet.\n"
-
 // ao_oss.c
 #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup: Kan inte ?ppna mixernehet %s: %s\n"
 #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup: Audiokortsmixer har inte kanal '%s' anv?nder standard.\n"
diff --git a/help/help_mp-tr.h b/help/help_mp-tr.h
index d2abd7c..180a953 100644
--- a/help/help_mp-tr.h
+++ b/help/help_mp-tr.h
@@ -1043,9 +1043,6 @@ static const char help_text[]=
 
 // libao2
 
-// audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "ses_??k???: alsa9 ve alsa1x mod?lleri silindi, yerine -ao se?ene?ini kullan?n?z.\n"
-
 // ao_oss.c
 #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] ses_kurulumu: %s kar??t?r?c? ayg?t? a??lam?yor: %s\n"
 #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] ses_kurulumu: Ses kart? kar??t?r?c?s? '%s' kanal?na sahip de?il, varsay?lan kullan?l?yor.\n"
diff --git a/help/help_mp-zh_CN.h b/help/help_mp-zh_CN.h
index 79f68e9..88ce157 100644
--- a/help/help_mp-zh_CN.h
+++ b/help/help_mp-zh_CN.h
@@ -1166,7 +1166,6 @@ static const char help_text[]=
 // ======================= audio output drivers ========================
 
 // audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "?????alsa9 ? alsa1x ????????? -ao alsa ???\n"
 #define MSGTR_AO_NoSuchDriver "???????%.*s?\n"
 #define MSGTR_AO_FailedInit "??????????%s?\n"
 
diff --git a/help/help_mp-zh_TW.h b/help/help_mp-zh_TW.h
index 913b9aa..af1fd0b 100644
--- a/help/help_mp-zh_TW.h
+++ b/help/help_mp-zh_TW.h
@@ -1014,9 +1014,6 @@ static const char help_text[]=
 
 // libao2
 
-// audio_out.c
-#define MSGTR_AO_ALSA9_1x_Removed "????: alsa9 ? alsa1x ??????, ?? -ao alsa ???\n"
-
 // ao_oss.c
 #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] ????: ????????? %s: %s\n"
 #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] ????: ???????'%s', ???????\n"
diff --git a/libao2/audio_out.c b/libao2/audio_out.c
index c0840a4..56b0b77 100644
--- a/libao2/audio_out.c
+++ b/libao2/audio_out.c
@@ -141,10 +141,6 @@ const ao_functions_t* init_best_audio_out(char** ao_list,int use_plugin,int rate
       while(ao_list[0][0]){
         char* ao=ao_list[0];
         int ao_len;
-        if (strncmp(ao, "alsa9", 5) == 0 || strncmp(ao, "alsa1x", 6) == 0) {
-            mp_msg(MSGT_AO, MSGL_FATAL, MSGTR_AO_ALSA9_1x_Removed);
-            exit_player(EXIT_NONE);
-        }
         free(ao_subdevice);
         ao_subdevice = NULL;
         ao_subdevice=strchr(ao,':');
-- 
1.7.2.5


From ib at wupperonline.de  Tue Jan  3 16:31:20 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 03 Jan 2012 16:31:20 +0100
Subject: [MPlayer-dev-eng] [PATCH] win32 gui open disk for audio cd
In-Reply-To: <4EFC9E4A.6010000@gmail.com>
Message-ID: <4f032736.59e39a16.bm000@wupperonline.de>

Stephen Sheldon wrote on Thu, 29 Dec 2011 09:07:22 -0800:

> Here is the the error in the first test:

> /usr/local/lib/libcdio.a(win32.o): In function `_cdio_mciSendCommand':
> /home/sheldon/src/libcdio-0.83/lib/driver/MSWindows/win32.c:201:
> undefined reference to `_mciSendCommandA at 16'

I finally succeeded in building (an older version, i.e. v0.77) libcdio with
Cygwin and got the same error, but only with mencoder.exe while mplayer.exe
was built. As mentioned earlier, the libcdio packages didn't run with my
Windows 98SE and so didn't this build, but crashed. But building from source
now had the advantage that I could trace down the crashing instruction in
libcdio. I found calls like verify_read_command(), but didn't feel like
further investigating.

Well, to make a long story short, the number of tracks (which is the only
information that is needed for this patch) was already determined in libcdio
prior to the crash, so I could comment the crashing calls and still call
cdda_tracks() which enabled me to check the patch, so I can confirm now it
works.

Ingo

From ib at wupperonline.de  Tue Jan  3 17:22:38 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 03 Jan 2012 17:22:38 +0100
Subject: [MPlayer-dev-eng] [PATCH] stream_cdda.c bugs and such
In-Reply-To: <4ef873bd.5c53b8cf.bm000@wupperonline.de>
Message-ID: <4f032b99.5d069785.bm000@wupperonline.de>

I wrote on Mon, 26 Dec 2011 13:50:34 +0100:

> Reimar D?ffinger wrote on Fri, 23 Dec 2011 17:48:53 +0100:

>> On Tue, Dec 20, 2011 at 06:54:07PM +0100, Ingo Br?ckl wrote:
>>> #3: -1 is never a valid track

>> No, but -1 means "error". Your patch breaks the error case (e.g. broken
>> TOC) by always returning 0 then.

> Oh, I see, but no use is made of the error. The return value is instantly
> used for calculation. Shouldn't there be a check and a STREAM_ERROR then?

>   Index: stream/stream_cdda.c
>   ===================================================================
>   --- stream/stream_cdda.c      (revision 34466)
>   +++ stream/stream_cdda.c      (working copy)
>   @@ -247,6 +247,7 @@
>        {
>          int start_track = get_track_by_sector(p, p->start_sector);
>          int end_track = get_track_by_sector(p, p->end_sector);
>   +      if (start_track == -1 || end_track == -1) return STREAM_ERROR;
>          *(unsigned int *)arg = end_track + 1 - start_track;
>          return STREAM_OK;
>        }
>   @@ -256,6 +257,7 @@
>          unsigned int track = *(unsigned int *)arg;
>          int start_track = get_track_by_sector(p, p->start_sector);
>          int end_track = get_track_by_sector(p, p->end_sector);
>   +      if (start_track == -1 || end_track == -1) return STREAM_ERROR;
>          int seek_sector;
>          track += start_track;
>          if (track > end_track) {
>   @@ -273,6 +275,7 @@
>        {
>          int start_track = get_track_by_sector(p, p->start_sector);
>          int cur_track = get_track_by_sector(p, p->sector);
>   +      if (start_track == -1 || cur_track == -1) return STREAM_ERROR;
>          *(unsigned int *)arg = cur_track - start_track;
>          return STREAM_OK;
>        }

Ping?

Ingo

From Reimar.Doeffinger at gmx.de  Tue Jan  3 19:32:01 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Tue, 3 Jan 2012 19:32:01 +0100
Subject: [MPlayer-dev-eng] [PATCH] stream_cdda.c bugs and such
In-Reply-To: <4f032b99.5d069785.bm000@wupperonline.de>
References: <4f032b99.5d069785.bm000@wupperonline.de>
Message-ID: <AC9A2472-A90A-457C-A9E0-455DD14B9718@gmx.de>


On 3 Jan 2012, at 17:22, Ingo Br?ckl <ib at wupperonline.de> wrote:
> I wrote on Mon, 26 Dec 2011 13:50:34 +0100:
> 
>> Reimar D?ffinger wrote on Fri, 23 Dec 2011 17:48:53 +0100:
> 
>>> On Tue, Dec 20, 2011 at 06:54:07PM +0100, Ingo Br?ckl wrote:
>>>> #3: -1 is never a valid track
> 
>>> No, but -1 means "error". Your patch breaks the error case (e.g. broken
>>> TOC) by always returning 0 then.
> 
>> Oh, I see, but no use is made of the error. The return value is instantly
>> used for calculation. Shouldn't there be a check and a STREAM_ERROR then?
> 
>>  Index: stream/stream_cdda.c
>>  ===================================================================
>>  --- stream/stream_cdda.c      (revision 34466)
>>  +++ stream/stream_cdda.c      (working copy)
>>  @@ -247,6 +247,7 @@
>>       {
>>         int start_track = get_track_by_sector(p, p->start_sector);
>>         int end_track = get_track_by_sector(p, p->end_sector);
>>  +      if (start_track == -1 || end_track == -1) return STREAM_ERROR;
>>         *(unsigned int *)arg = end_track + 1 - start_track;
>>         return STREAM_OK;
>>       }
>>  @@ -256,6 +257,7 @@
>>         unsigned int track = *(unsigned int *)arg;
>>         int start_track = get_track_by_sector(p, p->start_sector);
>>         int end_track = get_track_by_sector(p, p->end_sector);
>>  +      if (start_track == -1 || end_track == -1) return STREAM_ERROR;
>>         int seek_sector;
>>         track += start_track;
>>         if (track > end_track) {
>>  @@ -273,6 +275,7 @@
>>       {
>>         int start_track = get_track_by_sector(p, p->start_sector);
>>         int cur_track = get_track_by_sector(p, p->sector);
>>  +      if (start_track == -1 || cur_track == -1) return STREAM_ERROR;
>>         *(unsigned int *)arg = cur_track - start_track;
>>         return STREAM_OK;
>>       }
> 
> Ping?

Except for the second patch mixing code and declarations it should be ok.
I don't know if anything will handle the error correctly though.

From ib at wupperonline.de  Wed Jan  4 00:15:13 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 04 Jan 2012 00:15:13 +0100
Subject: [MPlayer-dev-eng] Should #include <X11/extensions/XShm.h> be
	conditional?
Message-ID: <4f03936b.7f9f236a.bm000@wupperonline.de>

While currently checking the #ifdefs in the GUI code and whether they are
necessary, I came across #include <X11/extensions/XShm.h>. As an extension,
it doesn't necessarily have to be present, does it?

As far as I can see, there is no check or CONFIG definition for XShm in the
configure script.

Should there be a condition for this include (and the function calls)?

(Yeah, I know, this isn't exactly the direction I'm heading for...)

Ingo

From vseryakov at gmail.com  Wed Jan  4 02:47:07 2012
From: vseryakov at gmail.com (Vlad Seryakov)
Date: Tue, 3 Jan 2012 20:47:07 -0500
Subject: [MPlayer-dev-eng] [RFC] Playing growing file
Message-ID: <E46AD4AE-01CC-41F8-80C3-21AACFEFA007@gmail.com>

>> Vlad Seryakov <vseryakov <at> gmail.com> writes:
>> Hi,
>> This is just some crazy idea i am thinking about while trying to figure out
>> how to play MPEG TS recordings with
>> mplayer. Really this is not full timeshift solution and never be, player is
>> just a player but supporting
>> growing file may be very useful.
>> 
>> I decided to try with adding one function to stream_file.c which will handle 
>> pipe:// urls and just use different fill_buffer function which indefinitely reads
>> from file but process events to avoid hangs.
>> 
>> Just wondering what other think about this solution.
>> Thanks
>> 

> Hi Vlad,
> I've run into a slight problem with your file. Specifically, while playing a
> test mkv file, mplayer would just freeze. I realized that in some cases demux
> might try to search all the way to the end of the file (eg in order to determine
> its length), which will cause it to freeze.
> 
> So I took liberty in adding a few lines and making it into an actual patch
> (attached). I also changed the prefix from 
> pipe:// to grow://.
>  Hope you don't
> mind ;)
> 
> -Doc

Hello Doc,

No problem, i never thought it will make it but wanted to get opinion if it is possible. Actually, i wanted to use it with MPEG TS files only, recording from DVB tuner, never thought about playing other file formats. I've added some timeouts so it will exit if no data after some interval but never sent it. Without maintaining proper length it may work in very narrow cases and may never be usable generically. For example, in my case i do not care about duration, i have guide info and know how long any particular program will run for, but without it, duration is necessary and this may require updating all demuxers to detect new file length but for some formats even that may not work well

Thanks





From wdraxinger.maillist at draxit.de  Wed Jan  4 09:53:39 2012
From: wdraxinger.maillist at draxit.de (Wolfgang Draxinger)
Date: Wed, 4 Jan 2012 09:53:39 +0100
Subject: [MPlayer-dev-eng] Should #include <X11/extensions/XShm.h> be
 conditional?
In-Reply-To: <4f03936b.7f9f236a.bm000@wupperonline.de>
References: <4f03936b.7f9f236a.bm000@wupperonline.de>
Message-ID: <20120104095339.191a5983@narfi.yggdrasil.draxit.de>

On Wed, 04 Jan 2012 00:15:13 +0100
Ingo Br?ckl <ib at wupperonline.de> wrote:

> While currently checking the #ifdefs in the GUI code and whether they
> are necessary, I came across #include <X11/extensions/XShm.h>. As an
> extension, it doesn't necessarily have to be present, does it?
> 
> As far as I can see, there is no check or CONFIG definition for XShm
> in the configure script.
> 
> Should there be a condition for this include (and the function calls)?

IMHO no. Although it's entitled a "extension", XShm can be considered
"core" these days, just like XFixes or XInput. And you probably don't
want to run mplayer on a system that doesn't support them. I think it's
a safe assumption to consider XShm and XInput present if X11 is
detected.


Wolfgang

From diego at biurrun.de  Wed Jan  4 12:08:52 2012
From: diego at biurrun.de (Diego Biurrun)
Date: Wed, 04 Jan 2012 12:08:52 +0100
Subject: [MPlayer-dev-eng] [PATCH] Port codebase to Theora 1.0 API
In-Reply-To: <CACy97_9vcHP=ToX6nAZY6q5TsFYC3URgMhUzsJzHQ+i4SLmkZw@mail.gmail.com>
References: <CACy97_850K23hdZQQTrjwhrXK75a9U0zbrq1TN8KCcmm4jTuNA@mail.gmail.com>
	<20111216170821.GA2908@pool.informatik.rwth-aachen.de>
	<CACy97_-PwoUia=KRkZdmpYmAr6bGp+4j5Jp=zEUX4b5bBZCwYg@mail.gmail.com>
	<20111220110530.GA4393@pool.informatik.rwth-aachen.de>
	<CACy97_9vcHP=ToX6nAZY6q5TsFYC3URgMhUzsJzHQ+i4SLmkZw@mail.gmail.com>
Message-ID: <20120104110852.GA12621@pool.informatik.rwth-aachen.de>

On Tue, Dec 20, 2011 at 01:20:41PM +0100, Giorgio Vazzana wrote:
> 2011/12/20 Diego Biurrun <diego at biurrun.de>:
> > On Fri, Dec 16, 2011 at 09:02:41PM +0100, Giorgio Vazzana wrote:
> >> 2011/12/16 Diego Biurrun <diego at biurrun.de>:
> >> >> - ?memset(&op, 0, sizeof(op));
> >> >> - ?r = theora_decode_header(&inf, &tc, &op);
> >> >> - ?r = theora_decode_init(&st, &inf);
> >> >> - ?t = theora_granule_time(&st, op.granulepos);
> >> >> - ?r = theora_decode_packetin(&st, &op);
> >> >> - ?r = theora_decode_YUVout(&st, &yuv);
> >> >> - ?theora_clear(&st);
> >> >> -
> >> >> - ?return 0;
> >> >> + ?r = th_decode_headerin(&ti, &tc, &tsi, &op);
> >> >> + ?tctx = th_decode_alloc(&ti, tsi);
> >> >> + ?th_setup_free(tsi);
> >> >> + ?t = th_granule_time(tctx, op.granulepos);
> >> >> + ?r = th_decode_packetin(tctx, &op, NULL);
> >> >> + ?r = th_decode_ycbcr_out(tctx, ycbcrbuf);
> >> >> + ?th_decode_free(tctx);
> >> >
> >> > .. I wonder why the Theora check has to be so complicated to begin
> >> > with when 90% of the other codec library checks can be accomplished
> >> > with a simple function invocation.
> >>
> >> Yes, to be honest I wondered why the configure script had such a
> >> complicate check in the first place too, but I didn't want to make too
> >> many changes in one patch.
> >> Anyway, in my opinion it's not necessary to include all that code,
> >> this can be simplified a lot: we just need to include the header, call
> >> a decode initialization function, and make sure that compiling and
> >> linking go well. See then new patch attached.
> >
> > I think we can simplify it even further.
> >
> >> --- configure (revision 34447)
> >> +++ configure (working copy)
> >> @@ -6234,53 +6234,35 @@
> >> ?if test "$_theora" = auto ; then
> >> ? ?_theora=no
> >> ? ? ?cat > $TMPC << EOF
> >> +#include <theora/theoradec.h>
> >> ?int main(void) {
> >> + ?th_info ti;
> >> + ?th_setup_info *tsi = NULL;
> >> + ?th_dec_ctx *tctx;
> >> + ?th_info_init(&ti);
> >> + ?tctx = th_decode_alloc(&ti, tsi);
> >> + ?th_setup_free(tsi);
> >> ? ?return 0;
> >> ?}
> >> ?EOF
> >
> > Do we need such a complex check? ?Isn't just calling
> >
> > ?th_info_init(NULL);
> >
> > enough?
> 
> It should work: I have tested it here, and I don't see any reason why
> it would fail. After all FFmpeg uses a similar check for the encoder.
> I have reduced it to one line, let me know if this is acceptable.

I simplified the Theora check in configure separately.  I have applied
your patch locally, will push later after testing.

Diego

From diego at biurrun.de  Thu Jan  5 00:12:26 2012
From: diego at biurrun.de (Diego Biurrun)
Date: Thu, 05 Jan 2012 00:12:26 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <20120102164239.GA12755@phare.normalesup.org>
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
Message-ID: <20120104231226.GA17458@pool.informatik.rwth-aachen.de>

On Mon, Jan 02, 2012 at 05:42:39PM +0100, Nicolas George wrote:
> 
> But for the long run, we will not escape addressing the point of the API/ABI
> compatibility between ffmpeg and libav.

> Unfortunately, most of the leaders of libav

You are confused, there is no such thing.

> seem to not care about it at all, and if I had to take a guess, I may
> say that some of them enjoy the prospect of breaking compatibility.

Your impression does not appear to take into account two Libav people
working on MPlayer.

That said, for compatibility between FFmpeg and Libav the onus is on the
downstream project, FFmpeg, to keep compatibility with its upstream as
it adds extra features.

It's not at all clear to me what you want Libav to do wrt API/ABI
compatibility.  Could you elaborate?

Diego

From nicolas.george at normalesup.org  Thu Jan  5 00:16:54 2012
From: nicolas.george at normalesup.org (Nicolas George)
Date: Thu, 5 Jan 2012 00:16:54 +0100
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <20120104231226.GA17458@pool.informatik.rwth-aachen.de>
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
	<20120104231226.GA17458@pool.informatik.rwth-aachen.de>
Message-ID: <20120104231654.GA10128@phare.normalesup.org>

Le sextidi 16 niv?se, an CCXX, Diego Biurrun a ?crit?:
> That said, for compatibility between FFmpeg and Libav the onus is on the
> downstream project, FFmpeg, to keep compatibility with its upstream as
> it adds extra features.

You may consider libav to be the upstream of ffmpeg, but that is not
universal.

> It's not at all clear to me what you want Libav to do wrt API/ABI
> compatibility.  Could you elaborate?

Adding codec ids to the enum to keep in sync would have been a good start.

But here is not the place to restart the flame.

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: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120105/9451e555/attachment.asc>

From ikalvachev at gmail.com  Thu Jan  5 01:08:24 2012
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Thu, 5 Jan 2012 02:08:24 +0200
Subject: [MPlayer-dev-eng] Should #include <X11/extensions/XShm.h> be
	conditional?
In-Reply-To: <4f03936b.7f9f236a.bm000@wupperonline.de>
References: <4f03936b.7f9f236a.bm000@wupperonline.de>
Message-ID: <CABA=pqcYGSwursxrpqbgxGkxWOW8PzN9YOpH31meT0FaExvwZg@mail.gmail.com>

On 1/4/12, Ingo Br?ckl <ib at wupperonline.de> wrote:
> While currently checking the #ifdefs in the GUI code and whether they are
> necessary, I came across #include <X11/extensions/XShm.h>. As an extension,
> it doesn't necessarily have to be present, does it?
>
> As far as I can see, there is no check or CONFIG definition for XShm in the
> configure script.
>
> Should there be a condition for this include (and the function calls)?
>
> (Yeah, I know, this isn't exactly the direction I'm heading for...)

There is "HAVE_SHM".

From ib at wupperonline.de  Thu Jan  5 09:32:10 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 05 Jan 2012 09:32:10 +0100
Subject: [MPlayer-dev-eng] Should #include <X11/extensions/XShm.h> be
	conditional?
In-Reply-To: <CABA=pqcYGSwursxrpqbgxGkxWOW8PzN9YOpH31meT0FaExvwZg@mail.gmail.com>
Message-ID: <4f056386.56c87ca3.bm000@wupperonline.de>

Ivan Kalvachev wrote on Thu, 5 Jan 2012 02:08:24 +0200:

> On 1/4/12, Ingo Br?ckl <ib at wupperonline.de> wrote:
>> While currently checking the #ifdefs in the GUI code and whether they are
>> necessary, I came across #include <X11/extensions/XShm.h>. As an extension,
>> it doesn't necessarily have to be present, does it?
>>
>> As far as I can see, there is no check or CONFIG definition for XShm in the
>> configure script.
>>
>> Should there be a condition for this include (and the function calls)?
>>
>> (Yeah, I know, this isn't exactly the direction I'm heading for...)

> There is "HAVE_SHM".

I'm not well versed in shared memory. Is HAVE_SHM (sys/shm.h) a prerequisite
for XShm? (Well, seems it is, because that's checked for in vo_x11, vo_xv and
vo_xvmc...)

So, if I've got it right, when building with HAVE_SHM then I can do a
XShmQueryExtension() and I'll end up either with or without shared memory at
runtime between client and server. When building without HAVE_SHM then I
cannot do a XShmQueryExtension() call and I'll end up without shared memory,
right?

Ingo

From Reimar.Doeffinger at gmx.de  Thu Jan  5 14:01:07 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Thu, 5 Jan 2012 14:01:07 +0100
Subject: [MPlayer-dev-eng] [PATCH] cleanup faterun.sh,
	do not use / if FATE_SAMPLES is not set
Message-ID: <20120105130107.GA372@1und1.de>

Hello,
currently fatetest behaves badly if FATE_SAMPLES is not set.
And the script contains code duplication and bad variables names like
"i".
Attached patch IMO is much better.
-------------- next part --------------
Index: Makefile
===================================================================
--- Makefile	(revision 34508)
+++ Makefile	(working copy)
@@ -996,6 +996,7 @@
     qt-surge-suite/% real/ra% sipr/% truespeech/% vorbis/%         \
     vqf/% w64/% wmapro/% wmavoice/%                                \
 
+ifdef FATE_SAMPLES
 ALLSAMPLES_FULLPATH = $(wildcard $(FATE_SAMPLES)/*/*.*)
 ALLSAMPLES          = $(patsubst $(FATE_SAMPLES)/%,%,$(ALLSAMPLES_FULLPATH))
 SAMPLES := $(filter-out $(BROKEN_SAMPLES),$(ALLSAMPLES))
@@ -1006,6 +1007,7 @@
 
 tests/res/%.md5: mplayer$(EXESUF) $(FATE_SAMPLES)/%
 	@tests/faterun.sh $*
+endif
 
 
 
Index: tests/faterun.sh
===================================================================
--- tests/faterun.sh	(revision 34508)
+++ tests/faterun.sh	(working copy)
@@ -1,15 +1,20 @@
 #!/bin/sh
-i=$1
-echo "running $i"
-mkdir -p tests/res/$(dirname $i)
-touch tests/res/$i.md5
-./mplayer -noconfig all -lavdopts threads=4:bitexact -really-quiet -noconsolecontrols -nosound -benchmark -vo md5sum:outfile=tests/res/$i.md5 $FATE_SAMPLES/$i
-ref_file=tests/ref/$i.md5
+if [ -z "$FATE_SAMPLES" ] ; then
+  echo "FATE_SAMPLES is not set!"
+  exit 1
+fi
+sample=$1
+md5out=tests/res/$sample.md5
+ref_file=tests/ref/$sample.md5
+echo "running $sample"
+mkdir -p $(dirname $md5out)
+touch $md5out
+./mplayer -noconfig all -lavdopts threads=4:bitexact -really-quiet -noconsolecontrols -nosound -benchmark -vo md5sum:outfile=$md5out $FATE_SAMPLES/$sample
 if ! [ -e $ref_file ] ; then
   touch tests/ref/empty.md5
   ref_file=tests/ref/empty.md5
 fi
-if ! diff -uw $ref_file tests/res/$i.md5 ; then
-  mv tests/res/$i.md5 tests/res/$i.md5.bad
+if ! diff -uw $ref_file $md5out ; then
+  mv $md5out $md5out.bad
   exit 1
 fi

From mywing81 at gmail.com  Thu Jan  5 16:24:52 2012
From: mywing81 at gmail.com (Giorgio Vazzana)
Date: Thu, 5 Jan 2012 16:24:52 +0100
Subject: [MPlayer-dev-eng] [PATCH] Port codebase to Theora 1.0 API
In-Reply-To: <20120104110852.GA12621@pool.informatik.rwth-aachen.de>
References: <CACy97_850K23hdZQQTrjwhrXK75a9U0zbrq1TN8KCcmm4jTuNA@mail.gmail.com>
	<20111216170821.GA2908@pool.informatik.rwth-aachen.de>
	<CACy97_-PwoUia=KRkZdmpYmAr6bGp+4j5Jp=zEUX4b5bBZCwYg@mail.gmail.com>
	<20111220110530.GA4393@pool.informatik.rwth-aachen.de>
	<CACy97_9vcHP=ToX6nAZY6q5TsFYC3URgMhUzsJzHQ+i4SLmkZw@mail.gmail.com>
	<20120104110852.GA12621@pool.informatik.rwth-aachen.de>
Message-ID: <CACy97_9K22__p0FgosNiL8kZ=w0QzU+JaM9S1W6-6mDOrrsMqg@mail.gmail.com>

2012/1/4 Diego Biurrun <diego at biurrun.de>:
> I simplified the Theora check in configure separately. ?I have applied
> your patch locally, will push later after testing.

Diego, thanks for applying this patch. There is a small problem in
configure though, we need to check for th_info_init() and not
theora_info_init(), otherwise the check will fail.  See attached
patch.

At this point, I only have one more patch about Theora decoder, I will
post it later.

Giorgio Vazzana
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004_theora_configure.diff
Type: text/x-patch
Size: 923 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120105/5d484c25/attachment.bin>

From mywing81 at gmail.com  Thu Jan  5 16:28:33 2012
From: mywing81 at gmail.com (Giorgio Vazzana)
Date: Thu, 5 Jan 2012 16:28:33 +0100
Subject: [MPlayer-dev-eng] [PATCH] demux_ogg: Use double instead of
 float for pts.
In-Reply-To: <20111215192939.GC3100@1und1.de>
References: <CACy97_8Ew5NMHaKxTqHfGR=e0wbB6f-z-gqPfX8BMFJp_dhkrw@mail.gmail.com>
	<20111215192939.GC3100@1und1.de>
Message-ID: <CACy97_8EoS_zKSKNke8s2V5_2PQV+PAo9cN9N9Bb6pc6-MjpYQ@mail.gmail.com>

2011/12/15 Reimar D?ffinger <Reimar.Doeffinger at gmx.de>:
> On Thu, Dec 15, 2011 at 07:43:01PM +0100, Giorgio Vazzana wrote:
>> The attached patch #2 should solve the problem:
>
> Seems good, we should always have used double.

Ping.

From doc4holliday at gmail.com  Thu Jan  5 16:37:53 2012
From: doc4holliday at gmail.com (Doc Holliday)
Date: Thu, 05 Jan 2012 10:37:53 -0500
Subject: [MPlayer-dev-eng] [RFC] Playing growing file
In-Reply-To: <E46AD4AE-01CC-41F8-80C3-21AACFEFA007@gmail.com>
References: <E46AD4AE-01CC-41F8-80C3-21AACFEFA007@gmail.com>
Message-ID: <4F05C3D1.9080605@gmail.com>

On 01/03/2012 08:47 PM, Vlad Seryakov wrote:
>>> Vlad Seryakov<vseryakov<at>  gmail.com>  writes:
>>> Hi,
>>> This is just some crazy idea i am thinking about while trying to figure out
>>> how to play MPEG TS recordings with
>>> mplayer. Really this is not full timeshift solution and never be, player is
>>> just a player but supporting
>>> growing file may be very useful.
>>>
>>> I decided to try with adding one function to stream_file.c which will handle
>>> pipe:// urls and just use different fill_buffer function which indefinitely reads
>>> from file but process events to avoid hangs.
>>>
>>> Just wondering what other think about this solution.
>>> Thanks
>>>
>
>> Hi Vlad,
>> I've run into a slight problem with your file. Specifically, while playing a
>> test mkv file, mplayer would just freeze. I realized that in some cases demux
>> might try to search all the way to the end of the file (eg in order to determine
>> its length), which will cause it to freeze.
>>
>> So I took liberty in adding a few lines and making it into an actual patch
>> (attached). I also changed the prefix from
>> pipe:// to grow://.
>>   Hope you don't
>> mind ;)
>>
>> -Doc
>
> Hello Doc,
>
> No problem, i never thought it will make it but wanted to get opinion if it is possible. Actually, i wanted to use it with MPEG TS files only, recording from DVB tuner, never thought about playing other file formats. I've added some timeouts so it will exit if no data after some interval but never sent it. Without maintaining proper length it may work in very narrow cases and may never be usable generically. For example, in my case i do not care about duration, i have guide info and know how long any particular program will run for, but without it, duration is necessary and this may require updating all demuxers to detect new file length but for some formats even that may not work well
>
> Thanks

Hi Vlad, Incidentally, I am also playing back MPEG TS (or maybe PS, not 
sure) files recorded by HVR-1950, but for testing I grabbed an .mkv, 
which is where I discovered the problem.
You are correct about the length, although mplayer seems to be happily 
playing MPEG files as long as new data keeps coming.
Unfortunately, in my particular case I do need to know the current 
length of the file. And for that I have to resort to a special form of 
hackery, which is made possible by your mod and is described in my other 
post. :)
Anyway, thanks for your patch.
-D

From Reimar.Doeffinger at gmx.de  Thu Jan  5 16:42:14 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Thu, 5 Jan 2012 16:42:14 +0100
Subject: [MPlayer-dev-eng] [PATCH] Port codebase to Theora 1.0 API
In-Reply-To: <CACy97_9K22__p0FgosNiL8kZ=w0QzU+JaM9S1W6-6mDOrrsMqg@mail.gmail.com>
References: <CACy97_850K23hdZQQTrjwhrXK75a9U0zbrq1TN8KCcmm4jTuNA@mail.gmail.com>
	<20111216170821.GA2908@pool.informatik.rwth-aachen.de>
	<CACy97_-PwoUia=KRkZdmpYmAr6bGp+4j5Jp=zEUX4b5bBZCwYg@mail.gmail.com>
	<20111220110530.GA4393@pool.informatik.rwth-aachen.de>
	<CACy97_9vcHP=ToX6nAZY6q5TsFYC3URgMhUzsJzHQ+i4SLmkZw@mail.gmail.com>
	<20120104110852.GA12621@pool.informatik.rwth-aachen.de>
	<CACy97_9K22__p0FgosNiL8kZ=w0QzU+JaM9S1W6-6mDOrrsMqg@mail.gmail.com>
Message-ID: <20120105154214.GA6136@1und1.de>

On Thu, Jan 05, 2012 at 04:24:52PM +0100, Giorgio Vazzana wrote:
> 2012/1/4 Diego Biurrun <diego at biurrun.de>:
> > I simplified the Theora check in configure separately. ?I have applied
> > your patch locally, will push later after testing.
> 
> Diego, thanks for applying this patch. There is a small problem in
> configure though, we need to check for th_info_init() and not
> theora_info_init(), otherwise the check will fail.  See attached
> patch.

Committed.

From doc4holliday at gmail.com  Thu Jan  5 16:46:36 2012
From: doc4holliday at gmail.com (Doc Holliday)
Date: Thu, 05 Jan 2012 10:46:36 -0500
Subject: [MPlayer-dev-eng] Playing growing MPEG files
In-Reply-To: <20111229162337.GA3533@1und1.de>
References: <4EF8D5C0.1050007@gmail.com> <20111229162337.GA3533@1und1.de>
Message-ID: <4F05C5DC.7040706@gmail.com>

On 12/29/2011 11:23 AM, Reimar D?ffinger wrote:
> On Mon, Dec 26, 2011 at 03:14:56PM -0500, Doc Holliday wrote:
>> I have a small Qt-based GUI that runs on top of mplayer in -slave mode
>> and allows users to navigate to different positions in the file by means
>> of a slider (QSlider). The user drags and drops the slider handle and
>> the mplayer jumps to the appropriate position in the file and continues
>> playing from there.
>>
>> This all works great until they start playing a growing file, which
>> happens regularly and which I am trying to figure out solution for.
>>
>> Playing growing files with mplayer seems to generally work. However,
>> time length of the file is set in demux_mpg_open and is not updated
>> after that. So the new part of the file, which has been recorded after
>> the file was open is not accessible through the slider. Currently, the
>> user has to stop playing the file and start playing it again.
>>
>> My idear was to do the following:
>>
>> 1. Regularly call demux_get_time_length (eg in from print_status)
>>
>> 2. Which in turn calls demux_mpg_control(DEMUXER_CTRL_GET_TIME_LENGTH)
>>
>> 3. Inside demux_mpg_control I:
>>       a. Call stream_control(STREAM_CTRL_GET_SIZE)
>>       b. Update demuxer->stream->end_pos and demuxer->movi_end
>>       c. Save current stream position
>>       d. Call read_first_mpeg_pts_at_position( demuxer->movi_end -
>> TIMESTAMP_PROBE_LEN )
>>       e. Update final_pts and first_to_final_pts_len
>>       f. Restore current stream position
>>
>> Unfortunately, the above does not seem to work, as I end up with corrupt
>> screen and the file not playing. My guess is that there are some
>> internal structures/buffers that get messed up and interrupt the "flow"
>> through the file.
>>
>> I am wondering if the above is a workable approach and it's just a
>> matter of preserving a few other variables prior to calling
>> read_first_mpeg_pts_at_position or if there is another better or more
>> proper way of doing this.
>
> You can't use read_first_mpeg_pts_at_position because it flushes
> all buffered data.
> At least as importantly, your approach of seeking back and forth
> all the time will give abysmal performance e.g. over http, from
> a CD/DVD and in general anything networked with high latency.
> Even when playing from disk the cache flushes the seeks cause would
> be bad.
> What to do depends on what you need. The duration for MPG files is
> between "inaccurate" and "nonsense" anyway, so one option is to
> just make guesses based on the size.
> Or you could start a second MPlayer just with -identify to get the
> new time guess (note however that just because a file has the same name
> does not necessarily mean it is the same file as the one you are playing
> - someone might have deleted that for example).
> You could possibly add a command to update the duration of a file,
> though that would require a lot more changes than what you attempted,
> particularly for MPG.

Thanks Reimar. I found it out the hard way. :)

There is a small patch, written by Vlad, which will make mplayer wait 
for new data to arrive.

What I will do is fire up 2 mplayers at the same time and run one of 
them with -vo null -ao null, put it at the end of the file and set speed 
to 4X. This way it will constantly keep bumping into the last frame of 
the file and sit there waiting for fresh data. I will parse its output 
and use it to figure out the length.

The other mplayer will run normally.

-Doc

From Reimar.Doeffinger at gmx.de  Thu Jan  5 16:52:08 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Thu, 5 Jan 2012 16:52:08 +0100
Subject: [MPlayer-dev-eng] [PATCH] demux_ogg: Use double instead of
 float for pts.
In-Reply-To: <CACy97_8EoS_zKSKNke8s2V5_2PQV+PAo9cN9N9Bb6pc6-MjpYQ@mail.gmail.com>
References: <CACy97_8Ew5NMHaKxTqHfGR=e0wbB6f-z-gqPfX8BMFJp_dhkrw@mail.gmail.com>
	<20111215192939.GC3100@1und1.de>
	<CACy97_8EoS_zKSKNke8s2V5_2PQV+PAo9cN9N9Bb6pc6-MjpYQ@mail.gmail.com>
Message-ID: <20120105155208.GA6761@1und1.de>

On Thu, Jan 05, 2012 at 04:28:33PM +0100, Giorgio Vazzana wrote:
> 2011/12/15 Reimar D?ffinger <Reimar.Doeffinger at gmx.de>:
> > On Thu, Dec 15, 2011 at 07:43:01PM +0100, Giorgio Vazzana wrote:
> >> The attached patch #2 should solve the problem:
> >
> > Seems good, we should always have used double.
> 
> Ping.

I committed and changed a few more places.

From vseryakov at gmail.com  Thu Jan  5 20:09:36 2012
From: vseryakov at gmail.com (Vlad Seryakov)
Date: Thu, 5 Jan 2012 14:09:36 -0500
Subject: [MPlayer-dev-eng] [RFC] Playing growing file
Message-ID: <B88B5B95-FAD9-4AB1-B503-AE1D247F78CC@gmail.com>

>> No problem, i never thought it will make it but wanted to get opinion if it is possible. Actually, i wanted to use it with MPEG TS files only, recording from DVB tuner, never thought about playing other file formats. I've added some timeouts so it will exit if no data after some interval but never sent it. Without maintaining proper length it may work in very narrow cases and may never be usable generically. For example, in my case i do not care about duration, i have guide info and know how long any particular program will run for, but without it, duration is necessary and this may require updating all demuxers to detect new file length but for some formats even that may not work well
>> 
> Hi Vlad, Incidentally, I am also playing back MPEG TS (or maybe PS, not 
> sure) files recorded by HVR-1950, but for testing I grabbed an .mkv, 
> which is where I discovered the problem.
> You are correct about the length, although mplayer seems to be happily 
> playing MPEG files as long as new data keeps coming.
> Unfortunately, in my particular case I do need to know the current 
> length of the file. And for that I have to resort to a special form of 
> hackery, which is made possible by your mod and is described in my other 
> post. :)
> Anyway, thanks for your patch.
> -D

Alternatively, because grow: stream updates stream->end_pos constantly, one easy change in ts_parse before returning packet length would be to update demuxer->movi_end, this way demuxer_get_time_length would use it every time and return actual file length.
Just add 
demuxer->movi_end = demuxer->stream->end_pos; 
in demux_ts.c before line 3081. This will not hurt if playing regular files but will work for growing files, i think.
Let me know if this will work.

Thanks

From onemda at gmail.com  Thu Jan  5 20:44:16 2012
From: onemda at gmail.com (Paul B Mahol)
Date: Thu,  5 Jan 2012 19:44:16 +0000
Subject: [MPlayer-dev-eng] [PATCH] Support for Avid Meridian Uncompressed
	via FFmpeg.
Message-ID: <1325792656-2103-1-git-send-email-onemda@gmail.com>

---
 etc/codecs.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/etc/codecs.conf b/etc/codecs.conf
index af70541..4eea6ca 100644
--- a/etc/codecs.conf
+++ b/etc/codecs.conf
@@ -3937,7 +3937,7 @@ videocodec ffrawuyvy
   fourcc uyv1,UYV1
   fourcc 2Vu1,2vu1,2VU1
   fourcc 2Vuy,2vuy,2VUY
-  fourcc AV1x,AVup
+  fourcc AV1x,AVup,AVUI
   fourcc VDTZ,auv2
   driver ffmpeg
   dll rawvideo
-- 
1.7.7


From cehoyos at ag.or.at  Thu Jan  5 21:19:16 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Thu, 5 Jan 2012 20:19:16 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH] Support for Avid Meridian
	Uncompressed via FFmpeg.
References: <1325792656-2103-1-git-send-email-onemda@gmail.com>
Message-ID: <loom.20120105T211851-547@post.gmane.org>

Paul B Mahol <onemda <at> gmail.com> writes:

> +++ b/etc/codecs.conf
> @@ -3937,7 +3937,7 @@ videocodec ffrawuyvy
>    fourcc uyv1,UYV1
>    fourcc 2Vu1,2vu1,2VU1
>    fourcc 2Vuy,2vuy,2VUY
> -  fourcc AV1x,AVup
> +  fourcc AV1x,AVup,AVUI

Patch applied.

Thank you, Carl Eugen


From emmanuel.anne at gmail.com  Fri Jan  6 09:02:20 2012
From: emmanuel.anne at gmail.com (Emmanuel Anne)
Date: Fri, 6 Jan 2012 09:02:20 +0100
Subject: [MPlayer-dev-eng] bmovl bug : regression
Message-ID: <CAL+ye25OBGfYzNgnhMOim7VA1Xe+xiZE0gWA=AY+OYYdUz7WUw@mail.gmail.com>

Hi, I just noticed a very bad bug with bmovl in the current svn version
(and since at least a few weeks).
It's related to the fps, some files make it badly crash, but it's hard to
tell which ones. Anyway some files have a bad fps in their header, mplayer
identifies them with something like 1000 fps, but plays them correctly
anyway at 25 or 30 fps in normal conditions. When passing -vf
bmovl=1:0:fifo for example, then it tries to play the file with the bad fps
from the number. If it's 1000 fps, then you get a crash.

I even got a crash from a normal 23.97 fps file, so I don't know where this
one comes from.
The bug didn't happen in the debian package labeled svn20111213 so it must
be quite recent.
But even with this version, with one of of these videos I get the message
"pts after filters MISSING" and it's played way too fast.
The only filter here was bmovl, and without it the video is played
correctly.
Quite a strange bug, I didn't know bmovl could affect fps ?

On a side note I noticed mplayer can't seem to be able to display subtitles
embeded in a h264/aac video file, but I guess it's a known problem ? It
detects the subtitle, even displays its language when using the j key, but
there is no way to make it to display it.

I can post some video pieces if you want...

From mywing81 at gmail.com  Fri Jan  6 11:52:07 2012
From: mywing81 at gmail.com (Giorgio Vazzana)
Date: Fri, 6 Jan 2012 11:52:07 +0100
Subject: [MPlayer-dev-eng] [PATCH] demux_ogg: Use double instead of
 float for pts.
In-Reply-To: <20120105155208.GA6761@1und1.de>
References: <CACy97_8Ew5NMHaKxTqHfGR=e0wbB6f-z-gqPfX8BMFJp_dhkrw@mail.gmail.com>
	<20111215192939.GC3100@1und1.de>
	<CACy97_8EoS_zKSKNke8s2V5_2PQV+PAo9cN9N9Bb6pc6-MjpYQ@mail.gmail.com>
	<20120105155208.GA6761@1und1.de>
Message-ID: <CACy97_9=0CiC2=y-QYxjZp+inh=kDrjnSS+zzNG6p7ExtQJa0A@mail.gmail.com>

2012/1/5 Reimar D?ffinger <Reimar.Doeffinger at gmx.de>:
> On Thu, Jan 05, 2012 at 04:28:33PM +0100, Giorgio Vazzana wrote:
>> 2011/12/15 Reimar D?ffinger <Reimar.Doeffinger at gmx.de>:
>> > On Thu, Dec 15, 2011 at 07:43:01PM +0100, Giorgio Vazzana wrote:
>> >> The attached patch #2 should solve the problem:
>> >
>> > Seems good, we should always have used double.
>>
>> Ping.
>
> I committed and changed a few more places.

Thanks.

From mywing81 at gmail.com  Fri Jan  6 11:52:30 2012
From: mywing81 at gmail.com (Giorgio Vazzana)
Date: Fri, 6 Jan 2012 11:52:30 +0100
Subject: [MPlayer-dev-eng] [PATCH] Port codebase to Theora 1.0 API
In-Reply-To: <20120105154214.GA6136@1und1.de>
References: <CACy97_850K23hdZQQTrjwhrXK75a9U0zbrq1TN8KCcmm4jTuNA@mail.gmail.com>
	<20111216170821.GA2908@pool.informatik.rwth-aachen.de>
	<CACy97_-PwoUia=KRkZdmpYmAr6bGp+4j5Jp=zEUX4b5bBZCwYg@mail.gmail.com>
	<20111220110530.GA4393@pool.informatik.rwth-aachen.de>
	<CACy97_9vcHP=ToX6nAZY6q5TsFYC3URgMhUzsJzHQ+i4SLmkZw@mail.gmail.com>
	<20120104110852.GA12621@pool.informatik.rwth-aachen.de>
	<CACy97_9K22__p0FgosNiL8kZ=w0QzU+JaM9S1W6-6mDOrrsMqg@mail.gmail.com>
	<20120105154214.GA6136@1und1.de>
Message-ID: <CACy97_-6Vzjr0KMZAR26Thv4A9shktb_3WQzdesk9kX7Lp1n5Q@mail.gmail.com>

2012/1/5 Reimar D?ffinger <Reimar.Doeffinger at gmx.de>:
> On Thu, Jan 05, 2012 at 04:24:52PM +0100, Giorgio Vazzana wrote:
>> 2012/1/4 Diego Biurrun <diego at biurrun.de>:
>> > I simplified the Theora check in configure separately. ?I have applied
>> > your patch locally, will push later after testing.
>>
>> Diego, thanks for applying this patch. There is a small problem in
>> configure though, we need to check for th_info_init() and not
>> theora_info_init(), otherwise the check will fail. ?See attached
>> patch.
>
> Committed.

Thank you.

From diego at biurrun.de  Fri Jan  6 15:46:38 2012
From: diego at biurrun.de (Diego Biurrun)
Date: Fri, 06 Jan 2012 15:46:38 +0100
Subject: [MPlayer-dev-eng] [PATCH] cleanup faterun.sh,
 do not use / if FATE_SAMPLES is not set
In-Reply-To: <20120105130107.GA372@1und1.de>
References: <20120105130107.GA372@1und1.de>
Message-ID: <20120106144638.GA32660@pool.informatik.rwth-aachen.de>

On Thu, Jan 05, 2012 at 02:01:07PM +0100, Reimar D?ffinger wrote:
> Hello,
> currently fatetest behaves badly if FATE_SAMPLES is not set.
> And the script contains code duplication and bad variables names like
> "i".
> Attached patch IMO is much better.

> --- Makefile	(revision 34508)
> +++ Makefile	(working copy)
> @@ -996,6 +996,7 @@
>  
> +ifdef FATE_SAMPLES
>  ALLSAMPLES_FULLPATH = $(wildcard $(FATE_SAMPLES)/*/*.*)
>  ALLSAMPLES          = $(patsubst $(FATE_SAMPLES)/%,%,$(ALLSAMPLES_FULLPATH))
>  SAMPLES := $(filter-out $(BROKEN_SAMPLES),$(ALLSAMPLES))
> @@ -1006,6 +1007,7 @@
>  
>  tests/res/%.md5: mplayer$(EXESUF) $(FATE_SAMPLES)/%
>  	@tests/faterun.sh $*
> +endif

This is pointless - the declarations are harmless unless you really run
fatetest, which should now give an error message.

> --- tests/faterun.sh	(revision 34508)
> +++ tests/faterun.sh	(working copy)
> @@ -1,15 +1,20 @@
>  #!/bin/sh
> -i=$1
> -echo "running $i"
> -mkdir -p tests/res/$(dirname $i)
> -touch tests/res/$i.md5
> -./mplayer -noconfig all -lavdopts threads=4:bitexact -really-quiet -noconsolecontrols -nosound -benchmark -vo md5sum:outfile=tests/res/$i.md5 $FATE_SAMPLES/$i
> -ref_file=tests/ref/$i.md5
> +if [ -z "$FATE_SAMPLES" ] ; then
> +  echo "FATE_SAMPLES is not set!"
> +  exit 1
> +fi
> +sample=$1
> +md5out=tests/res/$sample.md5
> +ref_file=tests/ref/$sample.md5
> +echo "running $sample"

"testing" might be better than "running" here.

The file could use a bit of whitespace to look less crammed, but overall
this is a clear improvement.

Diego

From eclipse7 at gmx.net  Fri Jan  6 17:04:43 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Fri, 6 Jan 2012 17:04:43 +0100
Subject: [MPlayer-dev-eng] [PATCH] cleanup faterun.sh,
 do not use / if FATE_SAMPLES is not set
In-Reply-To: <20120105130107.GA372@1und1.de>
References: <20120105130107.GA372@1und1.de>
Message-ID: <20120106160442.GA2262@akuma>

Hello Reimar!

Reimar D?ffinger wrote:
[...]
> Index: tests/faterun.sh
> ===================================================================
> --- tests/faterun.sh	(revision 34508)
> +++ tests/faterun.sh	(working copy)
> @@ -1,15 +1,20 @@
>  #!/bin/sh
> -i=$1
> -echo "running $i"
> -mkdir -p tests/res/$(dirname $i)
> -touch tests/res/$i.md5
> -./mplayer -noconfig all -lavdopts threads=4:bitexact -really-quiet -noconsolecontrols -nosound -benchmark -vo md5sum:outfile=tests/res/$i.md5 $FATE_SAMPLES/$i
> -ref_file=tests/ref/$i.md5
> +if [ -z "$FATE_SAMPLES" ] ; then

  I personally prefer using test instead of [ but that is not important.

> +  echo "FATE_SAMPLES is not set!"
> +  exit 1
> +fi
> +sample=$1

  The parameter $1 should be quoted with double quotes. Also see below.
Actually in this case it doesn't seem to be really needed.
 
> +md5out=tests/res/$sample.md5
> +ref_file=tests/ref/$sample.md5

  These too.

> +echo "running $sample"
> +mkdir -p $(dirname $md5out)

If I am not mistaken:
mkdir -p "$(dirname "$md5out")"

> +touch $md5out
> +./mplayer -noconfig all -lavdopts threads=4:bitexact -really-quiet -noconsolecontrols -nosound -benchmark -vo md5sum:outfile=$md5out $FATE_SAMPLES/$sample
>  if ! [ -e $ref_file ] ; then
>    touch tests/ref/empty.md5
>    ref_file=tests/ref/empty.md5
>  fi
> -if ! diff -uw $ref_file tests/res/$i.md5 ; then
> -  mv tests/res/$i.md5 tests/res/$i.md5.bad
> +if ! diff -uw $ref_file $md5out ; then
> +  mv $md5out $md5out.bad

  Here these variables should be in double quotes: ref_file and md5out,
FATE_SAMPLES, samples too. Ideally the vo md5sum outfile parameter
should contain an additional layer of quoting for the sub option parser.
Though that would need a bit more logic to work with all possible inputs.

  The importance of getting the quoting right here can be argued, but
I would rather like to see it done right. Not sure if the quoting stuff
can be security relevant in certain circumstances.
 
>    exit 1

  I would terminate with exit status 2 to differentiate between
usage error and other errors.

>  fi

  Well about the quoting remarks, consider to ignore them for now.
For the usual way this is invoked it should not be relevant as the
names should not contain whitespace that would lead to splitting.
The whitespace couldn't be easily properly handled in make and this
script usually gets invoked only from make.


  Alexander

From Reimar.Doeffinger at gmx.de  Fri Jan  6 18:06:44 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Fri, 6 Jan 2012 18:06:44 +0100
Subject: [MPlayer-dev-eng] [PATCH] cleanup faterun.sh,
	do not use / if FATE_SAMPLES is not set
In-Reply-To: <20120106144638.GA32660@pool.informatik.rwth-aachen.de>
References: <20120105130107.GA372@1und1.de>
	<20120106144638.GA32660@pool.informatik.rwth-aachen.de>
Message-ID: <54B8016E-809C-45F4-9021-66DB82F364F2@gmx.de>


On 6 Jan 2012, at 15:46, Diego Biurrun <diego at biurrun.de> wrote:
> On Thu, Jan 05, 2012 at 02:01:07PM +0100, Reimar D?ffinger wrote:
>> Hello,
>> currently fatetest behaves badly if FATE_SAMPLES is not set.
>> And the script contains code duplication and bad variables names like
>> "i".
>> Attached patch IMO is much better.
> 
>> --- Makefile    (revision 34508)
>> +++ Makefile    (working copy)
>> @@ -996,6 +996,7 @@
>> 
>> +ifdef FATE_SAMPLES
>> ALLSAMPLES_FULLPATH = $(wildcard $(FATE_SAMPLES)/*/*.*)
>> ALLSAMPLES          = $(patsubst $(FATE_SAMPLES)/%,%,$(ALLSAMPLES_FULLPATH))
>> SAMPLES := $(filter-out $(BROKEN_SAMPLES),$(ALLSAMPLES))
>> @@ -1006,6 +1007,7 @@
>> 
>> tests/res/%.md5: mplayer$(EXESUF) $(FATE_SAMPLES)/%
>>    @tests/faterun.sh $*
>> +endif
> 
> This is pointless - the declarations are harmless unless you really run
> fatetest, which should now give an error message.

I am afraid it is not harmless.
wildcard ends up scanning / in that case which for some users contains so many files that make seems to hang.
And no, not just when running fatetest.

From nicola.sabbi at poste.it  Sun Jan  8 08:52:42 2012
From: nicola.sabbi at poste.it (Nico Sabbi)
Date: Sun, 08 Jan 2012 08:52:42 +0100
Subject: [MPlayer-dev-eng] Broken vf_lavc and dvb-out playback. Possibly
	wrong pts asignment
Message-ID: <4F094B4A.8010500@poste.it>

DVB out is totally broken unless you can use MPEG12 pass-through.
Re-encoding on the fly with vf_lavc floods the screen with

A:   0.9 V:-9223372036854775808.0 A-V:  0.000 ct:  0.104   0/  0 12% 
39%  2.0% 0 0
pts after filters MISSING

and doesn't show anything on the display. This functionality must have 
been broken for years.

In put_image() the pts is discarded, in its place MP_NOPTS_VALUE is 
propagated to the next
filter, that -as far as I remember- is wrong.

Please, consider the next patch. It's working  correctly.
AH, btw I think I forgot my passwod :-) so if it's the case apply it.

Index: libmpcodecs/vf_lavc.c
===================================================================
--- libmpcodecs/vf_lavc.c    (revisione 34526)
+++ libmpcodecs/vf_lavc.c    (copia locale)
@@ -115,7 +115,7 @@

      dmpi->planes[0]=(unsigned char*)&vf->priv->pes;

-    return vf_next_put_image(vf,dmpi, MP_NOPTS_VALUE);
+    return vf_next_put_image(vf,dmpi, pts);
  }

  //===========================================================================//


From Reimar.Doeffinger at gmx.de  Sun Jan  8 10:33:44 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 8 Jan 2012 10:33:44 +0100
Subject: [MPlayer-dev-eng] [PATCH] cleanup faterun.sh,
 do not use / if FATE_SAMPLES is not set
In-Reply-To: <20120105130107.GA372@1und1.de>
References: <20120105130107.GA372@1und1.de>
Message-ID: <20120108093344.GA2950@1und1.de>

On Thu, Jan 05, 2012 at 02:01:07PM +0100, Reimar D?ffinger wrote:
> Hello,
> currently fatetest behaves badly if FATE_SAMPLES is not set.
> And the script contains code duplication and bad variables names like
> "i".
> Attached patch IMO is much better.

I committed both, the first because I suspect it will fix the many
issues people reported lately.
I did some further changes to the second one taking your comments into
account.

From nicolas.george at normalesup.org  Sun Jan  8 17:09:58 2012
From: nicolas.george at normalesup.org (Nicolas George)
Date: Sun, 8 Jan 2012 17:09:58 +0100
Subject: [MPlayer-dev-eng] bmovl bug : regression
In-Reply-To: <CAL+ye25OBGfYzNgnhMOim7VA1Xe+xiZE0gWA=AY+OYYdUz7WUw@mail.gmail.com>
References: <CAL+ye25OBGfYzNgnhMOim7VA1Xe+xiZE0gWA=AY+OYYdUz7WUw@mail.gmail.com>
Message-ID: <20120108160958.GA16370@phare.normalesup.org>

Le septidi 17 niv?se, an CCXX, Emmanuel Anne a ?crit?:
> Hi, I just noticed a very bad bug with bmovl in the current svn version
> (and since at least a few weeks).
> It's related to the fps, some files make it badly crash, but it's hard to
> tell which ones. Anyway some files have a bad fps in their header, mplayer
> identifies them with something like 1000 fps, but plays them correctly
> anyway at 25 or 30 fps in normal conditions. When passing -vf
> bmovl=1:0:fifo for example, then it tries to play the file with the bad fps
> from the number. If it's 1000 fps, then you get a crash.

Please provide a small sample file and a precise command line that exhibit
the problem.

> On a side note I noticed mplayer can't seem to be able to display subtitles
> embeded in a h264/aac video file, but I guess it's a known problem ? It
> detects the subtitle, even displays its language when using the j key, but
> there is no way to make it to display it.

Again, please point us to a sample file, or at least copy-paste the whole
output of mplayer.

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: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120108/fed4fe1d/attachment.asc>

From emmanuel.anne at gmail.com  Sun Jan  8 22:56:44 2012
From: emmanuel.anne at gmail.com (Emmanuel Anne)
Date: Sun, 8 Jan 2012 22:56:44 +0100
Subject: [MPlayer-dev-eng] bmovl bug : regression
In-Reply-To: <20120108160958.GA16370@phare.normalesup.org>
References: <CAL+ye25OBGfYzNgnhMOim7VA1Xe+xiZE0gWA=AY+OYYdUz7WUw@mail.gmail.com>
	<20120108160958.GA16370@phare.normalesup.org>
Message-ID: <CAL+ye27NRitq2SeGHsXc5FthHHLjtrHawyuyF05QTT6o_XZs9Q@mail.gmail.com>

2012/1/8 Nicolas George <nicolas.george at normalesup.org>

> Le septidi 17 niv?se, an CCXX, Emmanuel Anne a ?crit :
> > Hi, I just noticed a very bad bug with bmovl in the current svn version
> > (and since at least a few weeks).
> > It's related to the fps, some files make it badly crash, but it's hard to
> > tell which ones. Anyway some files have a bad fps in their header,
> mplayer
> > identifies them with something like 1000 fps, but plays them correctly
> > anyway at 25 or 30 fps in normal conditions. When passing -vf
> > bmovl=1:0:fifo for example, then it tries to play the file with the bad
> fps
> > from the number. If it's 1000 fps, then you get a crash.
>
> Please provide a small sample file and a precise command line that exhibit
> the problem.
>

Ok, that's test.avi, very short only 10 frames inside.
Play it normally -> no problem.
Just add -vf bmovl=1:0:fifo (the fifo file doesn't even need to exist) ->
crash.
http://dl.free.fr/rjWWbBWcp
This one plays fine with the old mplayer.
1 file should be enough here. If you need the one which produces a bad
playing speed with bmovl enabled, just ask.

>
> > On a side note I noticed mplayer can't seem to be able to display
> subtitles
> > embeded in a h264/aac video file, but I guess it's a known problem ? It
> > detects the subtitle, even displays its language when using the j key,
> but
> > there is no way to make it to display it.
>
> Again, please point us to a sample file, or at least copy-paste the whole
> output of mplayer.
>

Well this one might be very hard. I thought vlc could play it, but actually
it can't neither. It detects 1 more subtitle track though (the teletext
one), but when you try to display any of these subtittles it just says it
can't handle this.
Anyway I have uploaded 2 versions : mp4/aac here :
http://dl.free.fr/mik7J66rL
and mpeg2/m2v here : http://dl.free.fr/iEAtPiYRb
Both in mpeg transport container. Dumped using mplayer -dumpstream, I hope
it dumped everything correctly...

I made the files very small (only 2 Mb), just ask if you need something
bigger here.

Thanks to take the time to have a look !

>
> Regards,
>
> --
>  Nicolas George
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk8Jv9YACgkQsGPZlzblTJMixgCbBms8WYJItmxGJw0pnDnbqb+D
> rdoAoMyI74ZS5KSrm69RFLINTsxPf3Je
> =ZAcZ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>

From ib at wupperonline.de  Mon Jan  9 13:18:19 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 09 Jan 2012 13:18:19 +0100
Subject: [MPlayer-dev-eng] [PATCH] Define extern sub_cp unconditionally
Message-ID: <4f0adfad.368777f8.bm000@wupperonline.de>

I'm not quite sure how declaration and definition of a global variable only
needed for particular CONFIGs are supposed to be done, but I could remove
some #ifdefs in the GUI code if unconditionally declared extern sub_cp would
be defined unconditionally as well.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subreader.patch
Type: text/x-diff
Size: 394 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120109/5a7e8b27/attachment.bin>

From diego at biurrun.de  Mon Jan  9 16:05:28 2012
From: diego at biurrun.de (Diego Biurrun)
Date: Mon, 09 Jan 2012 16:05:28 +0100
Subject: [MPlayer-dev-eng] [PATCH] Remove warning when trying to invoke
 long-gone alsa9 and alsa1x ao drivers.
In-Reply-To: <1325598048-3157-1-git-send-email-diego@biurrun.de>
References: <1325598048-3157-1-git-send-email-diego@biurrun.de>
Message-ID: <20120109150528.GB25905@pool.informatik.rwth-aachen.de>

On Tue, Jan 03, 2012 at 02:40:48PM +0100, Diego Biurrun wrote:
> These drivers have been replaced years ago, it's time to drop the hint.
> ---
>  help/help_mp-bg.h    |    3 ---
>  help/help_mp-cs.h    |    1 -
>  help/help_mp-de.h    |    3 ---
>  help/help_mp-en.h    |    1 -
>  help/help_mp-es.h    |    1 -
>  help/help_mp-fr.h    |    3 ---
>  help/help_mp-hu.h    |    1 -
>  help/help_mp-it.h    |    1 -
>  help/help_mp-nl.h    |    3 ---
>  help/help_mp-pl.h    |    3 ---
>  help/help_mp-ru.h    |    1 -
>  help/help_mp-sv.h    |    3 ---
>  help/help_mp-tr.h    |    3 ---
>  help/help_mp-zh_CN.h |    1 -
>  help/help_mp-zh_TW.h |    3 ---
>  libao2/audio_out.c   |    4 ----
>  16 files changed, 0 insertions(+), 35 deletions(-)

No objections?  Will push in a few days then.

Diego

From artem.prof at mail.ru  Mon Jan  9 16:43:21 2012
From: artem.prof at mail.ru (=?UTF-8?B?0JDRgNGC0LXQvCDQlNGA0LDRh9C60L7Qsg==?=)
Date: Mon, 09 Jan 2012 19:43:21 +0400
Subject: [MPlayer-dev-eng] =?utf-8?q?Help=2C_please?=
Message-ID: <E1RkHNZ-0005nh-00.artem-prof-mail-ru@f86.mail.ru>

Hello!

I have a problem with VDPAU decoding, I don't know how to get video&audiostream from h264 videos! I have seen lots of infos about it ( ffmpeg docs, mplayer + vdpau code, etc ) but there is no effects! I have h264 video file, installed nvidia driver, libs, etc and mplayer. VDPAU works perfectly within mplayer -vo vdpau -vc ffh264vdpau some_file. I need to send video file to vdpau and get decoding streams for out it to display by SDL.

Help, please!

----------------
? ?????????, ??????? ?????
artem.prof(at)mail.ru

From Reimar.Doeffinger at gmx.de  Mon Jan  9 20:57:40 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 9 Jan 2012 20:57:40 +0100
Subject: [MPlayer-dev-eng] [PATCH] Remove warning when trying to invoke
 long-gone alsa9 and alsa1x ao drivers.
In-Reply-To: <20120109150528.GB25905@pool.informatik.rwth-aachen.de>
References: <1325598048-3157-1-git-send-email-diego@biurrun.de>
	<20120109150528.GB25905@pool.informatik.rwth-aachen.de>
Message-ID: <20120109195740.GB2647@1und1.de>

On Mon, Jan 09, 2012 at 04:05:28PM +0100, Diego Biurrun wrote:
> On Tue, Jan 03, 2012 at 02:40:48PM +0100, Diego Biurrun wrote:
> > These drivers have been replaced years ago, it's time to drop the hint.
> > ---
> >  help/help_mp-bg.h    |    3 ---
> >  help/help_mp-cs.h    |    1 -
> >  help/help_mp-de.h    |    3 ---
> >  help/help_mp-en.h    |    1 -
> >  help/help_mp-es.h    |    1 -
> >  help/help_mp-fr.h    |    3 ---
> >  help/help_mp-hu.h    |    1 -
> >  help/help_mp-it.h    |    1 -
> >  help/help_mp-nl.h    |    3 ---
> >  help/help_mp-pl.h    |    3 ---
> >  help/help_mp-ru.h    |    1 -
> >  help/help_mp-sv.h    |    3 ---
> >  help/help_mp-tr.h    |    3 ---
> >  help/help_mp-zh_CN.h |    1 -
> >  help/help_mp-zh_TW.h |    3 ---
> >  libao2/audio_out.c   |    4 ----
> >  16 files changed, 0 insertions(+), 35 deletions(-)
> 
> No objections?  Will push in a few days then.

No, go ahead whenever you want.

From cehoyos at ag.or.at  Mon Jan  9 22:46:09 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Mon, 9 Jan 2012 21:46:09 +0000 (UTC)
Subject: [MPlayer-dev-eng] Help, please
References: <E1RkHNZ-0005nh-00.artem-prof-mail-ru@f86.mail.ru>
Message-ID: <loom.20120109T224456-547@post.gmane.org>

????? ??????? <artem.prof <at> mail.ru> writes:

> I have a problem with VDPAU decoding,

Please see (and use) http://www.nvnews.net/vbulletin/forumdisplay.php?f=14

Carl Eugen


From ib at wupperonline.de  Tue Jan 10 10:41:02 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 10 Jan 2012 10:41:02 +0100
Subject: [MPlayer-dev-eng] GUI Icon
In-Reply-To: <4de6638e.44f9a4ca.bm000@wupperonline.de>
Message-ID: <4f0c0ed4.1f56cb9a.bm000@wupperonline.de>

I wrote on Wed, 01 Jun 2011 18:00:30 +0200:

> [...] On Bugzilla (http://bugzilla.mplayerhq.hu/show_bug.cgi?id=710) there
> is an offer for a GUI icon set that is quite nice.

> If there is no general objection in using these icons for the GUI, I could
> try to contact the creator, Andreas Nilsson, and ask for a full set of
> these icons and a licence information to include both to the MPlayer
> repository.

It took quite a while, but finally I received the set of icons under GPL.

Currently, the icons (as well as mplayer.desktop) are in the etc directory of
the repository. We now have multiple icons with the same name in different
sizes. Should they go in a subdirectory of etc/ or should I move all icons
and mplayer.desktop into a new subdirectory under gui/ (where I maybe could
move pixmaps/ as well)?

Ingo

From tempn at twmi.rr.com  Wed Jan 11 07:03:31 2012
From: tempn at twmi.rr.com (compn)
Date: Wed, 11 Jan 2012 01:03:31 -0500
Subject: [MPlayer-dev-eng] Allow compilation with Libav
In-Reply-To: <8762guhw7e.fsf@faui43f.informatik.uni-erlangen.de>
References: <87ehvjnh32.fsf@faui43f.informatik.uni-erlangen.de>
	<9BFA68F9-8758-4EE8-8939-13EC70746F7A@gmx.de>
	<87hb0ehxkz.fsf@faui43f.informatik.uni-erlangen.de>
	<20120102164239.GA12755@phare.normalesup.org>
	<8762guhw7e.fsf@faui43f.informatik.uni-erlangen.de>
Message-ID: <20120111010331.2c4e1777.tempn@twmi.rr.com>

On Mon, 02 Jan 2012 18:04:53 +0100, Reinhard Tartler wrote:
>But be assured, I am active in libav and I do care about mplayer
>compatibility, otherwise I wouldn't submit such patches to mplayer.

would be better if libav and ffmpeg were compatable api. this would
also fix any other projects currently having problems as well...

-compn

From nicola.sabbi at poste.it  Wed Jan 11 12:10:36 2012
From: nicola.sabbi at poste.it (Nico Sabbi)
Date: Wed, 11 Jan 2012 12:10:36 +0100
Subject: [MPlayer-dev-eng] [PATCH]Broken vf_lavc and dvb-out playback.
 Possibly wrong pts asignment
In-Reply-To: <4F094B4A.8010500@poste.it>
References: <4F094B4A.8010500@poste.it>
Message-ID: <4F0D6E2C.1090200@poste.it>

Nico Sabbi ha scritto:
> DVB out is totally broken unless you can use MPEG12 pass-through.
> Re-encoding on the fly with vf_lavc floods the screen with
>
> A:   0.9 V:-9223372036854775808.0 A-V:  0.000 ct:  0.104   0/  0 12% 
> 39%  2.0% 0 0
> pts after filters MISSING
>
> and doesn't show anything on the display. This functionality must have 
> been broken for years.
>
> In put_image() the pts is discarded, in its place MP_NOPTS_VALUE is 
> propagated to the next
> filter, that -as far as I remember- is wrong.
>
> Please, consider the next patch. It's working  correctly.
> AH, btw I think I forgot my passwod :-) so if it's the case apply it.
>
> Index: libmpcodecs/vf_lavc.c
> ===================================================================
> --- libmpcodecs/vf_lavc.c    (revisione 34526)
> +++ libmpcodecs/vf_lavc.c    (copia locale)
> @@ -115,7 +115,7 @@
>
>      dmpi->planes[0]=(unsigned char*)&vf->priv->pes;
>
> -    return vf_next_put_image(vf,dmpi, MP_NOPTS_VALUE);
> +    return vf_next_put_image(vf,dmpi, pts);
>  }
>
>  //===========================================================================// 
>
>

ping. Reimar, ok to commit?

From komh78 at gmail.com  Wed Jan 11 13:15:35 2012
From: komh78 at gmail.com (KO Myung-Hun)
Date: Wed, 11 Jan 2012 21:15:35 +0900
Subject: [MPlayer-dev-eng] [PATCH] Enable os2threads supports on OS/2
Message-ID: <4F0D7D67.1000703@chollian.net>

Hi/2.

This patch enables os2threads support on OS/2.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.0.14
Under OS/2 Warp 4 for Korean with FixPak #15
On Intel Core2Duo T5500 1.66GHz with 2GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: os2threads.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120111/856f5cd2/attachment.ksh>

From mywing81 at gmail.com  Wed Jan 11 13:35:52 2012
From: mywing81 at gmail.com (Giorgio Vazzana)
Date: Wed, 11 Jan 2012 13:35:52 +0100
Subject: [MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out() for
 packets representing a dropped (0-byte) frame.
Message-ID: <CACy97__g7yMHSJggs8KqnGF7kHKg=KHTxaVABYU6AEfpiAhH5w@mail.gmail.com>

Hello,

this is the last patch I wanted to submit. The subject pretty much
says it all: in case of 0-byte packets we don't need to call
th_decode_ycbcr_out() to decode the frame because we have a duplicated
frame, and so we can use the last frame.

Note: currently we are returning NULL in decode() if (!data || !len)
so basically we are discarding duplicated frames. When/if the
demuxer(s) will get fixed, we can delete that 'if' and things will
work properly at the decoder end.

After this patch, the file needs a reindent, I don't know if there is
an automated program/script that can do it. If not let me know and
I'll do it by hand, after all it's a small file. Regards,

Giorgio Vazzana
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-theora.diff
Type: text/x-patch
Size: 1764 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120111/86c4ec15/attachment.bin>

From Reimar.Doeffinger at gmx.de  Wed Jan 11 19:40:11 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 11 Jan 2012 19:40:11 +0100
Subject: [MPlayer-dev-eng] Broken vf_lavc and dvb-out playback. Possibly
 wrong pts asignment
In-Reply-To: <4F094B4A.8010500@poste.it>
References: <4F094B4A.8010500@poste.it>
Message-ID: <20120111184011.GC2120@1und1.de>

On Sun, Jan 08, 2012 at 08:52:42AM +0100, Nico Sabbi wrote:
> DVB out is totally broken unless you can use MPEG12 pass-through.
> Re-encoding on the fly with vf_lavc floods the screen with
> 
> A:   0.9 V:-9223372036854775808.0 A-V:  0.000 ct:  0.104   0/  0 12%
> 39%  2.0% 0 0
> pts after filters MISSING
> 
> and doesn't show anything on the display. This functionality must
> have been broken for years.

This should only happen for some input formats.
-nocorrect-pts should for example avoid it.

> In put_image() the pts is discarded, in its place MP_NOPTS_VALUE is
> propagated to the next
> filter, that -as far as I remember- is wrong.

Since we are encoding I-only, passing on the pts is probably correct.
However this really shouldn't cause things to fail completely,
MPlayer is supposed to fall back to fps-based timing for example.
But unless someone with the right hardware has time to debug further
that will probably remain a mystery.

> AH, btw I think I forgot my passwod :-) so if it's the case apply it.

Remembered it again or do you need me to apply?
Or we can solve the password problem if you see a chance of needing
it more often again :-)

From nicola.sabbi at poste.it  Thu Jan 12 14:38:23 2012
From: nicola.sabbi at poste.it (Nico Sabbi)
Date: Thu, 12 Jan 2012 14:38:23 +0100
Subject: [MPlayer-dev-eng] Broken vf_lavc and dvb-out playback. Possibly
 wrong pts asignment
In-Reply-To: <20120111184011.GC2120@1und1.de>
References: <4F094B4A.8010500@poste.it> <20120111184011.GC2120@1und1.de>
Message-ID: <4F0EE24F.1010906@poste.it>

Reimar D?ffinger ha scritto:
>
> This should only happen for some input formats.
> -nocorrect-pts should for example avoid it.

indeed it does
>
> Since we are encoding I-only, passing on the pts is probably correct. 
> However this really shouldn't cause things to fail completely, MPlayer 
> is supposed to fall back to fps-based timing for example. But unless 
> someone with the right hardware has time to debug further that will 
> probably remain a mystery.

not the right moment for me, maybe in the future I'll debug it.

>
>> AH, btw I think I forgot my passwod :-) so if it's the case apply it.
> Remembered it again or do you need me to apply?
> Or we can solve the password problem if you see a chance of needing
> it more often again :-)
>

password remembered and patch committed:-). I don't remember how many 
years have passed.


From ib at wupperonline.de  Thu Jan 12 19:25:23 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 12 Jan 2012 19:25:23 +0100
Subject: [MPlayer-dev-eng] Should #include <X11/extensions/XShm.h> be
	conditional?
In-Reply-To: <20120104095339.191a5983@narfi.yggdrasil.draxit.de>
Message-ID: <4f0f25a4.5d35a25b.bm000@wupperonline.de>

Wolfgang Draxinger wrote on Wed, 4 Jan 2012 09:53:39 +0100:

> XShm can be considered "core" these days, just like XFixes or XInput. And
> you probably don't want to run mplayer on a system that doesn't support
> them.

Just to see what happens I compiled mplayer with #undef HAVE_SHM and it
wasn't that much of a difference.

Anyway, there is proper XShm handling now.

Ingo

From ib at wupperonline.de  Fri Jan 13 02:33:45 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Fri, 13 Jan 2012 02:33:45 +0100
Subject: [MPlayer-dev-eng] [PATCH] Makefile,
	debian rules and rpm spec for new GUI icons
Message-ID: <4f100131.10bcdfeb.bm000@wupperonline.de>

I've decided to put the new icons as mplayer16x16.png, mplayer22x22.png, ...
into etc/ and changed Makefile and the rules for Debian and RPM.

Any objections?

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.patch
Type: text/x-diff
Size: 5977 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120113/078e0930/attachment.bin>

From ib at wupperonline.de  Fri Jan 13 02:33:45 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Fri, 13 Jan 2012 02:33:45 +0100
Subject: [MPlayer-dev-eng] [PATCH] Makefile,
	debian rules and rpm spec for new GUI icons
Message-ID: <4f100131.10bcdfeb.bm000@wupperonline.de>

I've decided to put the new icons as mplayer16x16.png, mplayer22x22.png, ...
into etc/ and changed Makefile and the rules for Debian and RPM.

Any objections?

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.patch
Type: text/x-diff
Size: 5977 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120113/078e0930/attachment-0001.bin>

From siretart at tauware.de  Fri Jan 13 16:16:00 2012
From: siretart at tauware.de (Reinhard Tartler)
Date: Fri, 13 Jan 2012 16:16:00 +0100
Subject: [MPlayer-dev-eng] [PATCH] Makefile,
	debian rules and rpm spec for new GUI icons
In-Reply-To: <4f100131.10bcdfeb.bm000@wupperonline.de> ("Ingo =?utf-8?Q?Br?=
	=?utf-8?Q?=C3=BCckl=22's?=
	message of "Fri, 13 Jan 2012 02:33:45 +0100")
References: <4f100131.10bcdfeb.bm000@wupperonline.de>
Message-ID: <87ipkfab0v.fsf@faui43f.informatik.uni-erlangen.de>

On Fr, Jan 13, 2012 at 02:33:45 (CET), Ingo Br?ckl wrote:

> I've decided to put the new icons as mplayer16x16.png, mplayer22x22.png, ...
> into etc/ and changed Makefile and the rules for Debian and RPM.
>
> Any objections?

Thank you for taking care of the installation rules in
debian/rules. They have immediate effect on the packages that get built
here (currently about twice a week):

https://launchpad.net/~motumedia/+archive/mplayer-daily/+packages



-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

From emmanuel.anne at gmail.com  Fri Jan 13 17:18:29 2012
From: emmanuel.anne at gmail.com (Emmanuel Anne)
Date: Fri, 13 Jan 2012 17:18:29 +0100
Subject: [MPlayer-dev-eng] patch for bmovl
Message-ID: <CAL+ye249Kd6g6EB7SMChQ69=qMrjxAWQoc=aBX_MiwQa0ZiQhQ@mail.gmail.com>

Ok, here is finally a patch for the problem I posted 1 week ago.
Finally it's not related to fps, but rather to the size of the video : if
the video buffer is aligned its size changes while the bmovl buffer
doesn't, which produces a nice crash. Fixed by passing the right flag to
vf_get_image

Then if you play a video with a broken size (like 540x396), the application
communicating via bmovl will send a buffer for a 540 pixels wide buffer and
it will be totally distorted because the actual width here is 544 for
alignement reasons. So this patch now makes the difference between the
width of the source bitmap and the one of the destination bitmap instead of
assuming they are always identical.

So far all the videos I could test pass without problem (tested on 2
computers !).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_mplayer_bmovl
Type: application/octet-stream
Size: 4015 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120113/bda7ba0d/attachment.obj>

From benoit.thebaudeau at advansee.com  Fri Jan 13 21:47:24 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Fri, 13 Jan 2012 21:47:24 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.
In-Reply-To: <a983683f-2189-4049-802d-ed48e20589aa@zose-store-12>
Message-ID: <3f188a10-3df7-4932-96e4-07101ae8152f@zose-store-12>

Hi all,

ID3v2.4 tags may have a footer, and they may be appended to MP3 files, before
ID3v1 tags. Skip these like other ID3 tags.

Signed-off-by: "Beno?t Th?baudeau" <benoit.thebaudeau at advansee.com>

Best regards,
Beno?t Th?baudeau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1-demux-audio-skip-id3v2.4.patch
Type: text/x-patch
Size: 1576 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120113/2324528d/attachment-0001.bin>

From benoit.thebaudeau at advansee.com  Fri Jan 13 21:47:36 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Fri, 13 Jan 2012 21:47:36 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] Fix wrong runtime and average bitrate for
	VBR MP3.
In-Reply-To: <37158bf8-c961-4212-90fd-42fb88ed6c23@zose-store-12>
Message-ID: <5d363081-00a7-4bab-acde-24438f20f623@zose-store-12>

Hi all,

According to http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm, the MP3
frame size depends only on the MP3 Layer, while according to
http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx#XINGHeader, the
size of the Layer III side information depends only on the MPEG version, so spf
can not be used by mp3_vbr_frames() to determine the Layer III side information
size. Fix this by using lsf instead.

Moreover, spf was not filled by mp_get_mp3_header() for NULL freq, which was an
issue for mp3_vbr_frames(). This is also fixed.

Signed-off-by: "Beno?t Th?baudeau" <benoit.thebaudeau at advansee.com>

Best regards,
Beno?t Th?baudeau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2-fix-mp3-vbr.patch
Type: text/x-patch
Size: 7177 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120113/bb7f083e/attachment.bin>

From benoit.thebaudeau at advansee.com  Fri Jan 13 21:47:45 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Fri, 13 Jan 2012 21:47:45 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] Fix wrong runtime and average bitrate for
	VBR MP3 if using libmad.
In-Reply-To: <27529d85-7af3-4083-8b53-67b79bf1be33@zose-store-12>
Message-ID: <218cd79e-b2cf-4903-ad18-1b919baf3c4f@zose-store-12>

Hi all,

The libmad codec interface writes i_bps without taking the VBR case into
account. This is fixed by not overwriting i_bps if it has already been computed
successfully by the audio demuxer.

Signed-off-by: "Beno?t Th?baudeau" <benoit.thebaudeau at advansee.com>

Best regards,
Beno?t Th?baudeau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3-fix-libmad-bitrate.patch
Type: text/x-patch
Size: 557 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120113/77a52d06/attachment.bin>

From komh78 at gmail.com  Sat Jan 14 04:29:31 2012
From: komh78 at gmail.com (KO Myung-Hun)
Date: Sat, 14 Jan 2012 12:29:31 +0900
Subject: [MPlayer-dev-eng] [PATCH] Enable os2threads supports on OS/2
In-Reply-To: <4F0D7D67.1000703@chollian.net>
References: <4F0D7D67.1000703@chollian.net>
Message-ID: <4F10F69B.5070400@chollian.net>



KO Myung-Hun wrote:
> Hi/2.
> 
> This patch enables os2threads support on OS/2.
> 
> 
> 
> os2threads.diff
> 
> 
> Index: configure
> ===================================================================
> --- configure	(revision 34540)
> +++ configure	(working copy)
> @@ -389,6 +389,7 @@
>    --disable-vstream      disable TiVo vstream client support [autodetect]
>    --disable-pthreads     disable Posix threads support [autodetect]
>    --disable-w32threads   disable Win32 threads support [autodetect]
> +  --disable-os2threads   disable OS/2 threads support [autodetect]
>    --enable-ass-internal  enable internal SSA/ASS subtitle support [autodetect]
>    --disable-ass          disable SSA/ASS subtitle support [autodetect]
>    --enable-rpath         enable runtime linker path for extra libs [disabled]
> @@ -858,6 +859,7 @@
>  _vstream=auto
>  _pthreads=auto
>  _w32threads=auto
> +_os2threads=auto
>  _ass=auto
>  ass_internal=auto
>  _rpath=no
> @@ -1351,6 +1353,8 @@
>    --disable-pthreads)   _pthreads=no    ;;
>    --enable-w32threads)  _w32threads=yes ;;
>    --disable-w32threads) _w32threads=no  ;;
> +  --enable-os2threads)  _os2threads=yes ;;
> +  --disable-os2threads) _os2threads=no  ;;
>    --enable-ass)         _ass=yes        ;;
>    --disable-ass)        _ass=no         ;;
>    --enable-ass-internal)  ass_internal=yes ;;
> @@ -3560,6 +3564,7 @@
>  def_threads='#define HAVE_THREADS 0'
>  def_pthreads='#define HAVE_PTHREADS 0'
>  def_w32threads='#define HAVE_W32THREADS 0'
> +def_os2threads='#define HAVE_OS2THREADS 0'
> 
>  echocheck "pthread"
>  if linux ; then
> @@ -3615,6 +3620,18 @@
>  test "$_w32threads" = yes && def_threads='#define HAVE_THREADS 1' && def_w32threads='#define HAVE_W32THREADS 1'
>  echores "$_w32threads"
> 
> +echocheck "os2threads"
> +if test "$_pthreads" = yes ; then
> +  res_comment="using pthread instead"
> +  _os2threads=no
> +fi
> +if test "$_os2threads" = auto ; then
> +  _os2threads=no
> +  os2 && _os2threads=yes
> +fi
> +test "$_os2threads" = yes && def_threads='#define HAVE_THREADS 1' && def_os2threads='#define HAVE_OS2THREADS 1'
> +echores "$_os2threads"
> +
>  echocheck "rpath"
>  if test "$_rpath" = yes ; then
>    for I in $(echo $extra_ldflags | sed 's/-L//g') ; do
> @@ -8200,6 +8217,7 @@
>  CONFIG_ZLIB     = $_zlib
> 
>  HAVE_GNU_AS     = $gnu_as
> +HAVE_OS2THREADS = $_os2threads
>  HAVE_PTHREADS   = $_pthreads
>  HAVE_SHM        = $_shm
>  HAVE_W32THREADS = $_w32threads
> @@ -8635,6 +8653,7 @@
>  $def_mkstemp
>  $def_mmap
>  $def_network
> +$def_os2threads
>  $def_pic
>  $def_poll_h
>  $def_posix_memalign
> @@ -8677,7 +8696,6 @@
>  #define HAVE_LDBRX 0
>  #define HAVE_LOCALTIME_R 0
>  #define HAVE_MAPVIEWOFFILE 0
> -#define HAVE_OS2THREADS 0
>  #define HAVE_PPC4XX 0
>  #define HAVE_STRERROR_R 0
>  #define HAVE_STRPTIME 0
> 
> 

No objections ?

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.0.14
Under OS/2 Warp 4 for Korean with FixPak #15
On Intel Core2Duo T5500 1.66GHz with 2GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr


From tempn at twmi.rr.com  Sat Jan 14 04:55:36 2012
From: tempn at twmi.rr.com (compn)
Date: Fri, 13 Jan 2012 22:55:36 -0500
Subject: [MPlayer-dev-eng] [PATCH] Enable os2threads supports on OS/2
In-Reply-To: <4F10F69B.5070400@chollian.net>
References: <4F0D7D67.1000703@chollian.net>
	<4F10F69B.5070400@chollian.net>
Message-ID: <20120113225536.ba166742.tempn@twmi.rr.com>

On Sat, 14 Jan 2012 12:29:31 +0900, KO Myung-Hun wrote:
>No objections ?

none from me :P

-compn

From cehoyos at ag.or.at  Sat Jan 14 13:47:30 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Sat, 14 Jan 2012 13:47:30 +0100
Subject: [MPlayer-dev-eng] [PATCH]Support 64bit tiff via opengl
Message-ID: <201201141347.31011.cehoyos@ag.or.at>

Hi!

I don't know what side-effects the "|64" has.

Please comment, Carl Eugen
-------------- next part --------------
Index: libmpcodecs/mp_image.c
===================================================================
--- libmpcodecs/mp_image.c	(revision 34561)
+++ libmpcodecs/mp_image.c	(working copy)
@@ -107,7 +107,9 @@
     }
     mpi->num_planes=1;
     if (IMGFMT_IS_RGB(out_fmt)) {
+        if (out_fmt == IMGFMT_RGBA64LE || out_fmt == IMGFMT_RGBA64BE) {
+            mpi->bpp = 64;
-        if (IMGFMT_RGB_DEPTH(out_fmt) < 8 && !(out_fmt&128))
+        } else if (IMGFMT_RGB_DEPTH(out_fmt) < 8 && !(out_fmt&128))
             mpi->bpp = IMGFMT_RGB_DEPTH(out_fmt);
         else
             mpi->bpp=(IMGFMT_RGB_DEPTH(out_fmt)+7)&(~7);
Index: libmpcodecs/img_format.c
===================================================================
--- libmpcodecs/img_format.c	(revision 34561)
+++ libmpcodecs/img_format.c	(working copy)
@@ -37,6 +37,8 @@
 //  case IMGFMT_RGB32:   return "RGB 32-bit";
     case IMGFMT_RGB48LE: return "RGB 48-bit LE";
     case IMGFMT_RGB48BE: return "RGB 48-bit BE";
+    case IMGFMT_RGBA64LE:return "RGB 64-bit LE";
+    case IMGFMT_RGBA64BE:return "RGB 64-bit BE";
     case IMGFMT_BGR1:    return "BGR 1-bit";
     case IMGFMT_BGR4:    return "BGR 4-bit";
     case IMGFMT_BG4B:    return "BGR 4-bit per byte";
Index: libmpcodecs/img_format.h
===================================================================
--- libmpcodecs/img_format.h	(revision 34561)
+++ libmpcodecs/img_format.h	(working copy)
@@ -36,6 +36,8 @@
 #define IMGFMT_RGB32 (IMGFMT_RGB|32)
 #define IMGFMT_RGB48LE (IMGFMT_RGB|48)
 #define IMGFMT_RGB48BE (IMGFMT_RGB|48|128)
+#define IMGFMT_RGBA64LE (IMGFMT_RGB|64)
+#define IMGFMT_RGBA64BE (IMGFMT_RGB|64|128)
 
 #define IMGFMT_BGR_MASK 0xFFFFFF00
 #define IMGFMT_BGR (('B'<<24)|('G'<<16)|('R'<<8))
@@ -56,6 +58,7 @@
 #define IMGFMT_BGRA    (IMGFMT_RGB32|64)
 #define IMGFMT_ARGB    IMGFMT_BGR32
 #define IMGFMT_RGBA    (IMGFMT_BGR32|64)
+#define IMGFMT_RGBA64NE IMGFMT_RGBA64BE
 #define IMGFMT_RGB48NE IMGFMT_RGB48BE
 #define IMGFMT_RGB12BE IMGFMT_RGB12
 #define IMGFMT_RGB12LE (IMGFMT_RGB12|64)
@@ -74,6 +77,7 @@
 #define IMGFMT_BGRA IMGFMT_BGR32
 #define IMGFMT_ARGB (IMGFMT_RGB32|64)
 #define IMGFMT_RGBA IMGFMT_RGB32
+#define IMGFMT_RGBA64NE IMGFMT_RGBA64LE
 #define IMGFMT_RGB48NE IMGFMT_RGB48LE
 #define IMGFMT_RGB12BE (IMGFMT_RGB12|64)
 #define IMGFMT_RGB12LE IMGFMT_RGB12
Index: fmt-conversion.c
===================================================================
--- fmt-conversion.c	(revision 34561)
+++ fmt-conversion.c	(working copy)
@@ -43,6 +43,8 @@
     {IMGFMT_RGB1,    PIX_FMT_MONOBLACK},
     {IMGFMT_RG4B,    PIX_FMT_BGR4_BYTE},
     {IMGFMT_BG4B,    PIX_FMT_RGB4_BYTE},
+    {IMGFMT_RGBA64LE,PIX_FMT_RGBA64LE},
+    {IMGFMT_RGBA64BE,PIX_FMT_RGBA64BE},
     {IMGFMT_RGB48LE, PIX_FMT_RGB48LE},
     {IMGFMT_RGB48BE, PIX_FMT_RGB48BE},
     {IMGFMT_ABGR,    PIX_FMT_ABGR},
Index: codec-cfg.c
===================================================================
--- codec-cfg.c	(revision 34561)
+++ codec-cfg.c	(working copy)
@@ -198,6 +198,8 @@
     {"UYVY",        IMGFMT_UYVY},
     {"YVYU",        IMGFMT_YVYU},
 
+    {"RGBA64LE",     IMGFMT_RGBA64LE},
+    {"RGBA64BE",     IMGFMT_RGBA64BE},
     {"RGB48LE",     IMGFMT_RGB48LE},
     {"RGB48BE",     IMGFMT_RGB48BE},
     {"RGB4",        IMGFMT_RGB4},
Index: m_option.c
===================================================================
--- m_option.c	(revision 34561)
+++ m_option.c	(working copy)
@@ -1126,6 +1126,8 @@
   {"bgr4", IMGFMT_BGR4},
   {"bg4b", IMGFMT_BG4B},
   {"bgr1", IMGFMT_BGR1},
+  {"rgba64be", IMGFMT_RGBA64BE},
+  {"rgba64le", IMGFMT_RGBA64LE},
   {"rgb48be", IMGFMT_RGB48BE},
   {"rgb48le", IMGFMT_RGB48LE},
   {"rgb48ne", IMGFMT_RGB48NE},
Index: libvo/gl_common.c
===================================================================
--- libvo/gl_common.c	(revision 34561)
+++ libvo/gl_common.c	(working copy)
@@ -272,6 +272,8 @@
   *bpp = IMGFMT_IS_BGR(fmt)?IMGFMT_BGR_DEPTH(fmt):IMGFMT_RGB_DEPTH(fmt);
   *gl_texfmt = 3;
   switch (fmt) {
+    case IMGFMT_RGBA64NE:
+      *gl_texfmt = 4;
     case IMGFMT_RGB48NE:
       *gl_format = GL_RGB;
       *gl_type = GL_UNSIGNED_SHORT;
Index: etc/codecs.conf
===================================================================
--- etc/codecs.conf	(revision 34561)
+++ etc/codecs.conf	(working copy)
@@ -578,7 +578,7 @@
   fourcc "tiff" ; for TIFF-encoded QuickTime files
   driver ffmpeg
   dll tiff
-  out BGR32,BGR24,BGR8,Y800,RGB32,RGB24,RGB8
+  out BGR32,BGR24,BGR8,Y800,RGBA64LE,RGB32,RGB24,RGB8
 
 videocodec ffpcx
   info "FFmpeg PCX"

From Reimar.Doeffinger at gmx.de  Sat Jan 14 14:23:55 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 14 Jan 2012 14:23:55 +0100
Subject: [MPlayer-dev-eng] [PATCH]Support 64bit tiff via opengl
In-Reply-To: <201201141347.31011.cehoyos@ag.or.at>
References: <201201141347.31011.cehoyos@ag.or.at>
Message-ID: <20120114132355.GA5781@1und1.de>

On Sat, Jan 14, 2012 at 01:47:30PM +0100, Carl Eugen Hoyos wrote:
> Index: libmpcodecs/mp_image.c
> ===================================================================
> --- libmpcodecs/mp_image.c	(revision 34561)
> +++ libmpcodecs/mp_image.c	(working copy)
> @@ -107,7 +107,9 @@
>      }
>      mpi->num_planes=1;
>      if (IMGFMT_IS_RGB(out_fmt)) {
> +        if (out_fmt == IMGFMT_RGBA64LE || out_fmt == IMGFMT_RGBA64BE) {
> +            mpi->bpp = 64;
> -        if (IMGFMT_RGB_DEPTH(out_fmt) < 8 && !(out_fmt&128))
> +        } else if (IMGFMT_RGB_DEPTH(out_fmt) < 8 && !(out_fmt&128))

If you want that, move the BE signalling to | 128 for all formats and
change IMGFMT_RGB_DEPTH to use & 0x7F

> +    {"RGBA64LE",     IMGFMT_RGBA64LE},
> +    {"RGBA64BE",     IMGFMT_RGBA64BE},
>      {"RGB48LE",     IMGFMT_RGB48LE},

Indentation is off.

> +  {"rgba64be", IMGFMT_RGBA64BE},
> +  {"rgba64le", IMGFMT_RGBA64LE},

If you call it RGBA that would imply a variant without
"A". There is not really any encoding left for that then though?

From cehoyos at ag.or.at  Sat Jan 14 15:14:01 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Sat, 14 Jan 2012 14:14:01 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH]Support 64bit tiff via opengl
References: <201201141347.31011.cehoyos@ag.or.at>
	<20120114132355.GA5781@1und1.de>
Message-ID: <loom.20120114T150952-622@post.gmane.org>

Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:

> On Sat, Jan 14, 2012 at 01:47:30PM +0100, Carl Eugen Hoyos wrote:
> > Index: libmpcodecs/mp_image.c
> > ===================================================================
> > --- libmpcodecs/mp_image.c	(revision 34561)
> > +++ libmpcodecs/mp_image.c	(working copy)
> > @@ -107,7 +107,9 @@
> >      }
> >      mpi->num_planes=1;
> >      if (IMGFMT_IS_RGB(out_fmt)) {
> > +        if (out_fmt == IMGFMT_RGBA64LE || out_fmt == IMGFMT_RGBA64BE) {
> > +            mpi->bpp = 64;
> > -        if (IMGFMT_RGB_DEPTH(out_fmt) < 8 && !(out_fmt&128))
> > +        } else if (IMGFMT_RGB_DEPTH(out_fmt) < 8 && !(out_fmt&128))
> 
> If you want that, move the BE signalling to | 128 for all formats and
> change IMGFMT_RGB_DEPTH to use & 0x7F

I think I do not understand: "|64" is used to signal "non-native-endian" iiuc,
BE is already signalled with "|128" for all formats, or am I wrong?

Since I don't know where "non-native-endian" is used, I cannot change it...

> > +    {"RGBA64LE",     IMGFMT_RGBA64LE},
> > +    {"RGBA64BE",     IMGFMT_RGBA64BE},
> >      {"RGB48LE",     IMGFMT_RGB48LE},
> 
> Indentation is off.

Fixed locally.

> > +  {"rgba64be", IMGFMT_RGBA64BE},
> > +  {"rgba64le", IMGFMT_RGBA64LE},
> 
> If you call it RGBA that would imply a variant without
> "A". There is not really any encoding left for that then though?

Changed to:
+  {"rgb64be", IMGFMT_RGBA64BE},
+  {"rgb64le", IMGFMT_RGBA64LE},
Is that what you meant?

Carl Eugen



From Reimar.Doeffinger at gmx.de  Sat Jan 14 16:28:43 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 14 Jan 2012 16:28:43 +0100
Subject: [MPlayer-dev-eng] [PATCH]Support 64bit tiff via opengl
In-Reply-To: <loom.20120114T150952-622@post.gmane.org>
References: <201201141347.31011.cehoyos@ag.or.at>
	<20120114132355.GA5781@1und1.de>
	<loom.20120114T150952-622@post.gmane.org>
Message-ID: <20120114152843.GA2882@1und1.de>

On Sat, Jan 14, 2012 at 02:14:01PM +0000, Carl Eugen Hoyos wrote:
> Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:
> 
> > On Sat, Jan 14, 2012 at 01:47:30PM +0100, Carl Eugen Hoyos wrote:
> > > Index: libmpcodecs/mp_image.c
> > > ===================================================================
> > > --- libmpcodecs/mp_image.c	(revision 34561)
> > > +++ libmpcodecs/mp_image.c	(working copy)
> > > @@ -107,7 +107,9 @@
> > >      }
> > >      mpi->num_planes=1;
> > >      if (IMGFMT_IS_RGB(out_fmt)) {
> > > +        if (out_fmt == IMGFMT_RGBA64LE || out_fmt == IMGFMT_RGBA64BE) {
> > > +            mpi->bpp = 64;
> > > -        if (IMGFMT_RGB_DEPTH(out_fmt) < 8 && !(out_fmt&128))
> > > +        } else if (IMGFMT_RGB_DEPTH(out_fmt) < 8 && !(out_fmt&128))
> > 
> > If you want that, move the BE signalling to | 128 for all formats and
> > change IMGFMT_RGB_DEPTH to use & 0x7F
> 
> I think I do not understand: "|64" is used to signal "non-native-endian" iiuc,

For RGB yes.

> BE is already signalled with "|128" for all formats, or am I wrong?

No, only for RGB48, all others use either | 64 (though to indicate
swapped endianness, not big-endian to be specific) or a reordered tag.

> 
> Since I don't know where "non-native-endian" is used, I cannot change it...

Hm, at least in vo_x11.c, but it's used wrongly anyway, only works
for RGB32 that way.

From Reimar.Doeffinger at gmx.de  Sat Jan 14 16:58:46 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 14 Jan 2012 16:58:46 +0100
Subject: [MPlayer-dev-eng] New stereo output mode for OpenGL video driver
In-Reply-To: <20111224193529.6ad095df@narfi.yggdrasil.draxit.de>
References: <20111218235354.23ce78b2@narfi.yggdrasil.draxit.de>
	<20111223222505.GB3054@1und1.de> <20111223223702.GA3217@1und1.de>
	<20111224154833.2d3aa86e@narfi.yggdrasil.draxit.de>
	<20111224151047.GA1860@1und1.de>
	<20111224193529.6ad095df@narfi.yggdrasil.draxit.de>
Message-ID: <20120114155846.GA3162@1und1.de>

On Sat, Dec 24, 2011 at 07:35:29PM +0100, Wolfgang Draxinger wrote:
> My revised patch follows:

Sorry for the delay, it is fine in principle.
Would you also update the man page?

> +static GLubyte const stipple_none[] = {

I don't see why that one would be necessary.
I also thought if it wouldn't be nicer to generate
these on stack at runtime, they make the binary slightly larger like
this.

> + *  - at window move events the origin of the window interior origin
> + *    in screen coordinates must be determined and that taken into
> + *    account choosing the stipple pattern.

Missing when/for before "choosing" I think.

> + *  - a nice have to feature was retrieving the EDID of the display
> + *
> + * A further nice-to-have feature was a anti-ghost implementation

"was" should be "would be" I think.

> +      mpglPolygonStipple(stipple_none);

As mentioned above that should not be necessary, why did you add it?
Disabling the feature should suffice I think.

From eclipse7 at gmx.net  Sat Jan 14 20:59:07 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 14 Jan 2012 20:59:07 +0100
Subject: [MPlayer-dev-eng] [PATCH] Enable os2threads supports on OS/2
In-Reply-To: <20120113225536.ba166742.tempn@twmi.rr.com>
References: <4F0D7D67.1000703@chollian.net> <4F10F69B.5070400@chollian.net>
	<20120113225536.ba166742.tempn@twmi.rr.com>
Message-ID: <20120114195907.GA2847@akuma>

Hello!

compn wrote:
> On Sat, 14 Jan 2012 12:29:31 +0900, KO Myung-Hun wrote:
> >No objections ?
> 
> none from me :P

  No objections from me neither.

  Your changes definitely look correct to me and I assume you tested
at least on OS/2.

  I tested myself on Linux and can confirm the results are as expected
and analogous to Win32 threads. Build is also successful.

  Though you still might give Diego a little time to comment. IIRC he
might want you to drop the leading underscore in the _os2threads variable
because he does not like that variable naming style. Not sure though,
so please wait for his comment before changing anything.

  Alexander

From cehoyos at ag.or.at  Sat Jan 14 23:25:38 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Sat, 14 Jan 2012 22:25:38 +0000 (UTC)
Subject: [MPlayer-dev-eng]
	=?utf-8?q?=5BPATCH=5D_Do_not_call_to_th=5Fdecod?=
	=?utf-8?q?e=5Fycbcr=5Fout=28=29_for_packets_representing_a_dropped?=
	=?utf-8?q?_=280-byte=29_frame=2E?=
References: <CACy97@mail.gmail.com>
Message-ID: <loom.20120114T232342-563@post.gmane.org>

Giorgio Vazzana <mywing81 <at> gmail.com> writes:

> this is the last patch I wanted to submit. The subject pretty much
> says it all: in case of 0-byte packets we don't need to call
> th_decode_ycbcr_out() to decode the frame because we have a duplicated
> frame, and so we can use the last frame.

Is this related in any way to the problem mentioned here?
http://thread.gmane.org/gmane.comp.video.mplayer.devel/59554/focus=59565

> Note: currently we are returning NULL in decode() if (!data || !len)
> so basically we are discarding duplicated frames. When/if the
> demuxer(s) will get fixed, we can delete that 'if' and things will
> work properly at the decoder end.
> 
> After this patch, the file needs a reindent, I don't know if there is
> an automated program/script that can do it. If not let me know and
> I'll do it by hand, after all it's a small file. Regards,

Don't worry, whoever applies can do that, or ask for a patch later.

Carl Eugen


From anssi.hannula at iki.fi  Sun Jan 15 11:39:14 2012
From: anssi.hannula at iki.fi (Anssi Hannula)
Date: Sun, 15 Jan 2012 12:39:14 +0200
Subject: [MPlayer-dev-eng] FLV seeking regression when cache enabled
	(bisected)
Message-ID: <4F12ACD2.4080308@iki.fi>

Hi!

I noticed that seeking no longer properly worked for me in FLV files,
resulting in random demuxing or decoding errors and playback being
stopped (most of the time).

Automatic bisection pointed to r34461 by Reimar as the culprit:
>>>>>
Flush cache and sync stream position/eof after seeking STREAM_CTRLs.

This avoid some strange differences in behaviour between -cache and
-nocache.
<<<<<

After seeing the commit msg I dropped the use of cache, and seeking
seems to work fine again. Alternatively, reverting the above commit
makes seeking work fine again (even with cache).

Example error:
> Starting playback...
> Unsupported PixelFormat 61
> Unsupported PixelFormat 53
> Unsupported PixelFormat 81
> Movie-Aspect is 1.77:1 - prescaling to correct movie aspect.
> VO: [xv] 638x360 => 638x360 Planar YV12  [zoom]
> A:   2.2 V:   2.2 A-V: -0.000 ct:  0.042   0/  0  8%  1%  0.3% 0 0 84% 
-- here I hit right key to seek forward
> [flv @ 0xd3b220]Unsupported video codec (c)
> [flv @ 0xd3b220]negative cts, previous timestamps might be wrong
> [flv @ 0xd3b220]negative cts, previous timestamps might be wrong
> Truncating packet of size 6936416 to 380526
> A:  13.4 V:  13.4 A-V:  0.023 ct:  0.006   0/  0 ??% ??% ??,?% 0 0 0% 
> [h264 @ 0xdb5960]error while decoding MB 30 10, bytestream (-3)
> [h264 @ 0xdb5960]concealing 539 DC, 539 AC, 539 MV errors
> A:  13.4 V:  13.4 A-V: -0.019 ct:  0.004   0/  0 ??% ??% ??,?% 0 0 0% 
> [h264 @ 0xdb5960]AVC: nal size 344331781
> [h264 @ 0xdb5960]no frame!
> Error while decoding frame!
> [h264 @ 0xdb5960]AVC: nal size 835711728
> [h264 @ 0xdb5960]no frame!
> Error while decoding frame!
> A:  13.4 V:  13.4 A-V: -0.019 ct:  0.003   0/  0 ??% ??% ??,?% 0 0 0% 
> 
> 
> Exiting... (End of file)

Another example:

> Starting playback...
> Unsupported PixelFormat 61
> Unsupported PixelFormat 53
> Unsupported PixelFormat 81
> Movie-Aspect is 1.77:1 - prescaling to correct movie aspect.
> VO: [xv] 638x360 => 638x360 Planar YV12  [zoom]
> A:  11.3 V:  11.4 A-V: -0.090 ct: -0.005   0/  0 ??% ??% ??,?% 0 0 100% 
-- seeking
> Truncating packet of size 13590303 to 496003
> [aac @ 0xdb5960]channel element 2.14 is not allocated
> A:-226577.3 V:  11.5 A-V:-226588.828 ct: -0.021   0/  0 ??% ??% ??,?% 0 0 0% 
> [h264 @ 0xdb5960]error while decoding MB 28 10, bytestream (-10)
> [h264 @ 0xdb5960]concealing 541 DC, 541 AC, 541 MV errors
> A:-226577.3 V:  11.6 A-V:-226588.875 ct: -0.030   0/  0 ??% ??% ??,?% 0 0 0% 
>
>
> Exiting... (End of file)

Feel free to ask me for more information if needed.

-- 
Anssi Hannula

From Reimar.Doeffinger at gmx.de  Sun Jan 15 12:33:13 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 15 Jan 2012 12:33:13 +0100
Subject: [MPlayer-dev-eng] FLV seeking regression when cache enabled
 (bisected)
In-Reply-To: <4F12ACD2.4080308@iki.fi>
References: <4F12ACD2.4080308@iki.fi>
Message-ID: <20120115113313.GA12153@1und1.de>

On Sun, Jan 15, 2012 at 12:39:14PM +0200, Anssi Hannula wrote:
> I noticed that seeking no longer properly worked for me in FLV files,
> resulting in random demuxing or decoding errors and playback being
> stopped (most of the time).

> Feel free to ask me for more information if needed.

Yes, a sample file. It works just fine for me.

From anssi.hannula at iki.fi  Sun Jan 15 12:50:26 2012
From: anssi.hannula at iki.fi (Anssi Hannula)
Date: Sun, 15 Jan 2012 13:50:26 +0200
Subject: [MPlayer-dev-eng] FLV seeking regression when cache enabled
	(bisected)
In-Reply-To: <20120115113313.GA12153@1und1.de>
References: <4F12ACD2.4080308@iki.fi> <20120115113313.GA12153@1und1.de>
Message-ID: <4F12BD82.9080602@iki.fi>

On 15.01.2012 13:33, Reimar D?ffinger wrote:
> On Sun, Jan 15, 2012 at 12:39:14PM +0200, Anssi Hannula wrote:
>> I noticed that seeking no longer properly worked for me in FLV files,
>> resulting in random demuxing or decoding errors and playback being
>> stopped (most of the time).
> 
>> Feel free to ask me for more information if needed.
> 
> Yes, a sample file. It works just fine for me.

Well, every file I've tried so far, but e.g.
http://samples.mplayerhq.hu/FLV/flash8/mrandmrssmith_320x176_200.flv
has the issue (i.e. play back with e.g. "-cache 1000", then press right
key to seek one or two times).

This is on x86_64, gcc 4.6.2, glibc 2.14.1.

-- 
Anssi Hannula

From Reimar.Doeffinger at gmx.de  Sun Jan 15 13:25:58 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 15 Jan 2012 13:25:58 +0100
Subject: [MPlayer-dev-eng] FLV seeking regression when cache enabled
 (bisected)
In-Reply-To: <4F12BD82.9080602@iki.fi>
References: <4F12ACD2.4080308@iki.fi> <20120115113313.GA12153@1und1.de>
	<4F12BD82.9080602@iki.fi>
Message-ID: <20120115122558.GA12887@1und1.de>

On Sun, Jan 15, 2012 at 01:50:26PM +0200, Anssi Hannula wrote:
> On 15.01.2012 13:33, Reimar D?ffinger wrote:
> > On Sun, Jan 15, 2012 at 12:39:14PM +0200, Anssi Hannula wrote:
> >> I noticed that seeking no longer properly worked for me in FLV files,
> >> resulting in random demuxing or decoding errors and playback being
> >> stopped (most of the time).
> > 
> >> Feel free to ask me for more information if needed.
> > 
> > Yes, a sample file. It works just fine for me.
> 
> Well, every file I've tried so far, but e.g.
> http://samples.mplayerhq.hu/FLV/flash8/mrandmrssmith_320x176_200.flv
> has the issue (i.e. play back with e.g. "-cache 1000", then press right
> key to seek one or two times).

Thanks, for some reason it wasn't really obvious with the
sample I had tried.
I fixed it, though I am unsure if it reintroduced some old issues
(e.g. seeking to the next track when on the last track of a CD
would quit when using -nocache but do nothing -cache).
They probably should be fixed in the protocols though.

From anssi.hannula at iki.fi  Sun Jan 15 13:36:00 2012
From: anssi.hannula at iki.fi (Anssi Hannula)
Date: Sun, 15 Jan 2012 14:36:00 +0200
Subject: [MPlayer-dev-eng] FLV seeking regression when cache enabled
	(bisected)
In-Reply-To: <20120115122558.GA12887@1und1.de>
References: <4F12ACD2.4080308@iki.fi> <20120115113313.GA12153@1und1.de>
	<4F12BD82.9080602@iki.fi> <20120115122558.GA12887@1und1.de>
Message-ID: <4F12C830.9060801@iki.fi>

On 15.01.2012 14:25, Reimar D?ffinger wrote:
> On Sun, Jan 15, 2012 at 01:50:26PM +0200, Anssi Hannula wrote:
>> On 15.01.2012 13:33, Reimar D?ffinger wrote:
>>> On Sun, Jan 15, 2012 at 12:39:14PM +0200, Anssi Hannula wrote:
>>>> I noticed that seeking no longer properly worked for me in FLV files,
>>>> resulting in random demuxing or decoding errors and playback being
>>>> stopped (most of the time).
>>>
>>>> Feel free to ask me for more information if needed.
>>>
>>> Yes, a sample file. It works just fine for me.
>>
>> Well, every file I've tried so far, but e.g.
>> http://samples.mplayerhq.hu/FLV/flash8/mrandmrssmith_320x176_200.flv
>> has the issue (i.e. play back with e.g. "-cache 1000", then press right
>> key to seek one or two times).
> 
> Thanks, for some reason it wasn't really obvious with the
> sample I had tried.
> I fixed it, though I am unsure if it reintroduced some old issues
> (e.g. seeking to the next track when on the last track of a CD
> would quit when using -nocache but do nothing -cache).
> They probably should be fixed in the protocols though.

Confirmed, the regression is fixed.

Thanks for the quick fix :)

-- 
Anssi Hannula

From ib at wupperonline.de  Sun Jan 15 14:51:52 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sun, 15 Jan 2012 14:51:52 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
	tags.
In-Reply-To: <3f188a10-3df7-4932-96e4-07101ae8152f@zose-store-12>
Message-ID: <4f12e747.7edf0471.bm000@wupperonline.de>

Beno?t Th?baudeau wrote on Fri, 13 Jan 2012 21:47:24 +0100 (CET):

> @@ -358,9 +358,11 @@ static int demux_audio_open(demuxer_t* d
>  	step = 4;
>      } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' && (hdr[3] >= 2)) {
>        int len;
> -      stream_skip(s,2);
> +      stream_skip(s,1);
> +      stream_read(s,hdr,1);
> +      len = hdr[0] & 0x10 ? 10 : 0;
>        stream_read(s,hdr,4);
> -      len = (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
> +      len += (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
>        stream_skip(s,len);
>        step = 4;
>      } else if( found_WAVE && hdr[0] == 'f' && hdr[1] == 'm' && hdr[2] == 't' && hdr[3] == ' ' ) {

Why skipping 10 extra bytes? If I understand the specs correctly, the footer
at the end of the file doesn't count for the ID3v2.4 size, so it's compatible
to earlier ID3v2.

> @@ -446,6 +448,17 @@ static int demux_audio_open(demuxer_t* d
>  	g = stream_read_char(s);
>  	demux_info_add(demuxer,"Genre",genres[g]);
>        }
> +      stream_seek(s,demuxer->movi_end-10);
> +      stream_read(s,hdr,4);

I'd prefer reading into tag to better match the "TAG" check.

Are "TAG" and "3DI" mutually exclusive (I don't get it clearly from the
specs)? What if both are present and "TAG" comes before "3DI"?

> +      if( hdr[0] == '3' && hdr[1] == 'D' && hdr[2] == 'I' && (hdr[3] >= 2)) {
> +	int len;
> +	stream_skip(s,1);
> +	stream_read(s,hdr,1);
> +	len = hdr[0] & 0x10 ? 20 : 10;
> +	stream_read(s,hdr,4);
> +	len += (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
> +	demuxer->movi_end = stream_tell(s)-len;
> +      }
>      }
>      if (duration && demuxer->movi_end && demuxer->movi_end > demuxer->movi_start) sh_audio->wf->nAvgBytesPerSec = (demuxer->movi_end - demuxer->movi_start) / duration;
>      sh_audio->i_bps = sh_audio->wf->nAvgBytesPerSec;

Isn't it simply demuxer->movi_end = stream_tell(s)-4?

Ingo

From benoit.thebaudeau at advansee.com  Sun Jan 15 16:29:23 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Sun, 15 Jan 2012 16:29:23 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <4f12e747.7edf0471.bm000@wupperonline.de>
Message-ID: <7bbac0c7-15e8-4a7c-a2f4-7a6df310ab8d@zose-store-12>

Hi Ingo, all,

> > @@ -358,9 +358,11 @@ static int demux_audio_open(demuxer_t* d
> >  	step = 4;
> >      } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> >      (hdr[3] >= 2)) {
> >        int len;
> > -      stream_skip(s,2);
> > +      stream_skip(s,1);
> > +      stream_read(s,hdr,1);
> > +      len = hdr[0] & 0x10 ? 10 : 0;
> >        stream_read(s,hdr,4);
> > -      len = (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
> > +      len += (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
> >        stream_skip(s,len);
> >        step = 4;
> >      } else if( found_WAVE && hdr[0] == 'f' && hdr[1] == 'm' &&
> >      hdr[2] == 't' && hdr[3] == ' ' ) {
> 
> Why skipping 10 extra bytes? If I understand the specs correctly, the
> footer
> at the end of the file doesn't count for the ID3v2.4 size, so it's
> compatible
> to earlier ID3v2.

My reference was:
http://id3.org/id3v2.4.0-structure

"The ID3v2 tag size is the sum of the byte length of the extended
header, the padding and the frames after unsynchronisation. If a
footer is present this equals to ('total size' - 20) bytes, otherwise
('total size' - 10) bytes."

So the ID3v2 tag size from the tag header or footer means the same thing
whatever the ID3v2 revision, but as it does not take the possible footer into
account, the footer size (10 bytes) has to be added in order to be skipped:
"
     +-----------------------------+
     |      Header (10 bytes)      |
     +-----------------------------+
     |       Extended Header       |
     | (variable length, OPTIONAL) |
     +-----------------------------+
     |   Frames (variable length)  |
     +-----------------------------+
     |           Padding           |
     | (variable length, OPTIONAL) |
     +-----------------------------+
     | Footer (10 bytes, OPTIONAL) |
     +-----------------------------+
"

> > @@ -446,6 +448,17 @@ static int demux_audio_open(demuxer_t* d
> >  	g = stream_read_char(s);
> >  	demux_info_add(demuxer,"Genre",genres[g]);
> >        }
> > +      stream_seek(s,demuxer->movi_end-10);
> > +      stream_read(s,hdr,4);
> 
> I'd prefer reading into tag to better match the "TAG" check.

OK, I'll do that.

> Are "TAG" and "3DI" mutually exclusive (I don't get it clearly from
> the
> specs)?

No, they're not.

> What if both are present and "TAG" comes before "3DI"?

See "5.   Tag location". Appended ID3v2.4 tags have to be placed "before tags
from other tagging systems". In that case, the file structure will thus be:
- prepended ID3v2.4 tag:
 * header ("ID3"...),
 * contents (giving size in header/footer),
 * footer ("3DI"..., optional),
- audio,
- appended ID3v2.4 tag:
 * header ("ID3"...),
 * contents (giving size in header/footer),
 * footer ("3DI"..., mandatory: "It is REQUIRED to add a footer to an appended
   tag"),
- ID3v1 tag ("TAG"...).

> > +      if( hdr[0] == '3' && hdr[1] == 'D' && hdr[2] == 'I' &&
> > (hdr[3] >= 2)) {
> > +	int len;
> > +	stream_skip(s,1);
> > +	stream_read(s,hdr,1);
> > +	len = hdr[0] & 0x10 ? 20 : 10;
> > +	stream_read(s,hdr,4);
> > +	len += (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
> > +	demuxer->movi_end = stream_tell(s)-len;
> > +      }
> >      }
> >      if (duration && demuxer->movi_end && demuxer->movi_end >
> >      demuxer->movi_start) sh_audio->wf->nAvgBytesPerSec =
> >      (demuxer->movi_end - demuxer->movi_start) / duration;
> >      sh_audio->i_bps = sh_audio->wf->nAvgBytesPerSec;
> 
> Isn't it simply demuxer->movi_end = stream_tell(s)-4?

No. In that case, the possible I3v1 tag has already been skipped, and an
appended ID3v2.4 tag has been detected thanks to "3DI" in its footer, so the
whole tag size has to be calculated from the tag footer, then skipped by placing
demuxer->movi_end at the beginning of the appended ID3v2.4 tag.

Best regards,
Beno?t

From diego at biurrun.de  Sun Jan 15 21:13:47 2012
From: diego at biurrun.de (Diego Biurrun)
Date: Sun, 15 Jan 2012 21:13:47 +0100
Subject: [MPlayer-dev-eng] [PATCH] Enable os2threads supports on OS/2
In-Reply-To: <4F0D7D67.1000703@chollian.net>
References: <4F0D7D67.1000703@chollian.net>
Message-ID: <20120115201346.GA13144@pool.informatik.rwth-aachen.de>

On Wed, Jan 11, 2012 at 09:15:35PM +0900, KO Myung-Hun wrote:
> 
> This patch enables os2threads support on OS/2.
> 
> --- configure	(revision 34540)
> +++ configure	(working copy)
> @@ -3615,6 +3620,18 @@
>  test "$_w32threads" = yes && def_threads='#define HAVE_THREADS 1' && def_w32threads='#define HAVE_W32THREADS 1'
>  echores "$_w32threads"
> 
> +echocheck "os2threads"

This should only be checked on OS/2, cf some of the other OS/2 tests
we have in configure.

Diego

From komh78 at gmail.com  Mon Jan 16 05:45:52 2012
From: komh78 at gmail.com (KO Myung-Hun)
Date: Mon, 16 Jan 2012 13:45:52 +0900
Subject: [MPlayer-dev-eng] [PATCH] Enable os2threads supports on OS/2
In-Reply-To: <20120115201346.GA13144@pool.informatik.rwth-aachen.de>
References: <4F0D7D67.1000703@chollian.net>
	<20120115201346.GA13144@pool.informatik.rwth-aachen.de>
Message-ID: <4F13AB80.70303@chollian.net>



Diego Biurrun wrote:
> On Wed, Jan 11, 2012 at 09:15:35PM +0900, KO Myung-Hun wrote:
>>
>> This patch enables os2threads support on OS/2.
>>
>> --- configure	(revision 34540)
>> +++ configure	(working copy)
>> @@ -3615,6 +3620,18 @@
>>  test "$_w32threads" = yes && def_threads='#define HAVE_THREADS 1' && def_w32threads='#define HAVE_W32THREADS 1'
>>  echores "$_w32threads"
>>
>> +echocheck "os2threads"
> 
> This should only be checked on OS/2, cf some of the other OS/2 tests
> we have in configure.

Ok.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.0.14
Under OS/2 Warp 4 for Korean with FixPak #15
On Intel Core2Duo T5500 1.66GHz with 2GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: os2threads.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120116/259051c2/attachment-0001.ksh>

From diego at biurrun.de  Mon Jan 16 10:01:05 2012
From: diego at biurrun.de (Diego Biurrun)
Date: Mon, 16 Jan 2012 10:01:05 +0100
Subject: [MPlayer-dev-eng] [PATCH] Enable os2threads supports on OS/2
In-Reply-To: <4F13AB80.70303@chollian.net>
References: <4F0D7D67.1000703@chollian.net>
	<20120115201346.GA13144@pool.informatik.rwth-aachen.de>
	<4F13AB80.70303@chollian.net>
Message-ID: <20120116090105.GA18999@pool.informatik.rwth-aachen.de>

On Mon, Jan 16, 2012 at 01:45:52PM +0900, KO Myung-Hun wrote:
> Diego Biurrun wrote:
> > On Wed, Jan 11, 2012 at 09:15:35PM +0900, KO Myung-Hun wrote:
> >>
> >> This patch enables os2threads support on OS/2.
> >>
> >> --- configure	(revision 34540)
> >> +++ configure	(working copy)
> >> @@ -3615,6 +3620,18 @@
> >>  test "$_w32threads" = yes && def_threads='#define HAVE_THREADS 1' && def_w32threads='#define HAVE_W32THREADS 1'
> >>  echores "$_w32threads"
> >>
> >> +echocheck "os2threads"
> > 
> > This should only be checked on OS/2, cf some of the other OS/2 tests
> > we have in configure.
> 
> Ok.

Thank you, queued.

Diego

From benoit.thebaudeau at advansee.com  Mon Jan 16 13:28:38 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Mon, 16 Jan 2012 13:28:38 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <7bbac0c7-15e8-4a7c-a2f4-7a6df310ab8d@zose-store-12>
Message-ID: <3adc676a-5ea5-4f43-bedd-fa2a039ff05c@zose-store-12>

Hi Ingo, all,

> > > @@ -446,6 +448,17 @@ static int demux_audio_open(demuxer_t* d
> > >  	g = stream_read_char(s);
> > >  	demux_info_add(demuxer,"Genre",genres[g]);
> > >        }
> > > +      stream_seek(s,demuxer->movi_end-10);
> > > +      stream_read(s,hdr,4);
> >
> > I'd prefer reading into tag to better match the "TAG" check.
>
> OK, I'll do that.

Please find attached the new version using tag instead of hdr.

Best regards,
Beno?t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1-demux-audio-skip-id3v2.4.patch
Type: text/x-patch
Size: 1585 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120116/28969d68/attachment.bin>

From ib at wupperonline.de  Mon Jan 16 19:40:44 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 16 Jan 2012 19:40:44 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
	tags.
In-Reply-To: <3adc676a-5ea5-4f43-bedd-fa2a039ff05c@zose-store-12>
Message-ID: <4f147435.29ead86e.bm000@wupperonline.de>

Beno?t,

I was misunderstanding the 3DI footer and thinking of something like
ID3-frames-data-3DI<EOF> (in which case the footer wouldn't have made
much sense).

you wrote on Mon, 16 Jan 2012 13:28:38 +0100 (CET):

> @@ -358,9 +358,11 @@ static int demux_audio_open(demuxer_t* d
>  	step = 4;
>      } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' && (hdr[3] >= 2)) {
>        int len;
> -      stream_skip(s,2);
> +      stream_skip(s,1);
> +      stream_read(s,hdr,1);
> +      len = hdr[0] & 0x10 ? 10 : 0;
>        stream_read(s,hdr,4);
> -      len = (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
> +      len += (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
>        stream_skip(s,len);
>        step = 4;
>      } else if( found_WAVE && hdr[0] == 'f' && hdr[1] == 'm' && hdr[2] == 't' && hdr[3] == ' ' ) {

Should be ok. (Although a stream_read(s,hdr,2) and hdr[1] & 0x10 would save a
call.)

> @@ -446,6 +448,17 @@ static int demux_audio_open(demuxer_t* d
>  	g = stream_read_char(s);
>  	demux_info_add(demuxer,"Genre",genres[g]);
>        }
> +      stream_seek(s,demuxer->movi_end-10);
> +      stream_read(s,tag,4);
> +      if( tag[0] == '3' && tag[1] == 'D' && tag[2] == 'I' && ((uint8_t)tag[3] >= 2)) {

One pair of () is pointless and I personally would prefer an unsigned char
cast, but I don't know what Reimar thinks (he probably would go with hdr).
The version check should be 4.

> +	int len;
> +	stream_skip(s,1);
> +	stream_read(s,tag,1);
> +	len = tag[0] & 0x10 ? 20 : 10;
> +	stream_read(s,tag,4);
> +	len += (tag[0]<<21) | (tag[1]<<14) | (tag[2]<<7) | tag[3];
> +	demuxer->movi_end = stream_tell(s)-len;

Indentation.

Shouldn't the existence of 3DI already prove a len of 20? Hmm, A 3DI without
flag could indicate that it isn't a 3DI footer at all...

Ingo

From Reimar.Doeffinger at gmx.de  Mon Jan 16 20:42:14 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 16 Jan 2012 20:42:14 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <3adc676a-5ea5-4f43-bedd-fa2a039ff05c@zose-store-12>
References: <7bbac0c7-15e8-4a7c-a2f4-7a6df310ab8d@zose-store-12>
	<3adc676a-5ea5-4f43-bedd-fa2a039ff05c@zose-store-12>
Message-ID: <20120116194214.GA4060@1und1.de>

On Mon, Jan 16, 2012 at 01:28:38PM +0100, Beno?t Th?baudeau wrote:
> diff -Nrdup mplayer.orig/libmpdemux/demux_audio.c mplayer/libmpdemux/demux_audio.c
> --- mplayer.orig/libmpdemux/demux_audio.c	2011-11-11 18:29:14.076503000 +0100
> +++ mplayer/libmpdemux/demux_audio.c	2012-01-16 13:19:55.252067960 +0100
> @@ -358,9 +358,11 @@ static int demux_audio_open(demuxer_t* d
>  	step = 4;
>      } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' && (hdr[3] >= 2)) {
>        int len;
> -      stream_skip(s,2);
> +      stream_skip(s,1);
> +      stream_read(s,hdr,1);
> +      len = hdr[0] & 0x10 ? 10 : 0;

Please use stream_read_char() directly instead of going through the tag
variable, there's no need here.

> +	int len;
> +	stream_skip(s,1);
> +	stream_read(s,tag,1);
> +	len = tag[0] & 0x10 ? 20 : 10;
> +	stream_read(s,tag,4);
> +	len += (tag[0]<<21) | (tag[1]<<14) | (tag[2]<<7) | tag[3];

This seems to be exactly the same code.
If so, please extract it into its own function instead of duplicating
it.

From Reimar.Doeffinger at gmx.de  Mon Jan 16 20:44:06 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 16 Jan 2012 20:44:06 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
 tags.
In-Reply-To: <4f147435.29ead86e.bm000@wupperonline.de>
References: <3adc676a-5ea5-4f43-bedd-fa2a039ff05c@zose-store-12>
	<4f147435.29ead86e.bm000@wupperonline.de>
Message-ID: <20120116194406.GB4060@1und1.de>

On Mon, Jan 16, 2012 at 07:40:44PM +0100, Ingo Br?ckl wrote:
> > @@ -446,6 +448,17 @@ static int demux_audio_open(demuxer_t* d
> >  	g = stream_read_char(s);
> >  	demux_info_add(demuxer,"Genre",genres[g]);
> >        }
> > +      stream_seek(s,demuxer->movi_end-10);
> > +      stream_read(s,tag,4);
> > +      if( tag[0] == '3' && tag[1] == 'D' && tag[2] == 'I' && ((uint8_t)tag[3] >= 2)) {
> 
> One pair of () is pointless and I personally would prefer an unsigned char
> cast, but I don't know what Reimar thinks (he probably would go with hdr).

I don't see any point to use "unsigned char" ever, at best it
is a needlessly verbose way to do the same as uint8_t.

From Reimar.Doeffinger at gmx.de  Mon Jan 16 20:47:00 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 16 Jan 2012 20:47:00 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <3adc676a-5ea5-4f43-bedd-fa2a039ff05c@zose-store-12>
References: <7bbac0c7-15e8-4a7c-a2f4-7a6df310ab8d@zose-store-12>
	<3adc676a-5ea5-4f43-bedd-fa2a039ff05c@zose-store-12>
Message-ID: <20120116194700.GA4831@1und1.de>

On Mon, Jan 16, 2012 at 01:28:38PM +0100, Beno?t Th?baudeau wrote:
> +	demuxer->movi_end = stream_tell(s)-len;

And shouldn't this rather be FFMIN with the previous value?
I am sure someone somewhere has managed to combine this with
an ID3v1 tag in a way that overriding the value would result
in trying to play back parts of the ID3v1 tag.

From ib at wupperonline.de  Mon Jan 16 20:44:30 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 16 Jan 2012 20:44:30 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
	tags.
In-Reply-To: <3adc676a-5ea5-4f43-bedd-fa2a039ff05c@zose-store-12>
Message-ID: <4f147ecb.5d835093.bm000@wupperonline.de>

Beno?t Th?baudeau wrote on Mon, 16 Jan 2012 13:28:38 +0100 (CET):

> +	stream_read(s,tag,4);
> +	len += (tag[0]<<21) | (tag[1]<<14) | (tag[2]<<7) | tag[3];
> +	demuxer->movi_end = stream_tell(s)-len;

There probably should be two other checks.

stream_tell(s)-len should not point before the beginning of the file, and
there should be an ID3 v4 tag with footer flag at this position.

Ingo

From benoit.thebaudeau at advansee.com  Mon Jan 16 20:51:11 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Mon, 16 Jan 2012 20:51:11 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <4f147435.29ead86e.bm000@wupperonline.de>
Message-ID: <5fa2473d-89c4-48c8-bbb9-c3d6986bfbfd@zose-store-12>

Ingo,

> I was misunderstanding the 3DI footer and thinking of something like
> ID3-frames-data-3DI<EOF> (in which case the footer wouldn't have made
> much sense).

OK.

> > @@ -358,9 +358,11 @@ static int demux_audio_open(demuxer_t* d
> >  	step = 4;
> >      } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> >      (hdr[3] >= 2)) {
> >        int len;
> > -      stream_skip(s,2);
> > +      stream_skip(s,1);
> > +      stream_read(s,hdr,1);
> > +      len = hdr[0] & 0x10 ? 10 : 0;
> >        stream_read(s,hdr,4);
> > -      len = (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
> > +      len += (hdr[0]<<21) | (hdr[1]<<14) | (hdr[2]<<7) | hdr[3];
> >        stream_skip(s,len);
> >        step = 4;
> >      } else if( found_WAVE && hdr[0] == 'f' && hdr[1] == 'm' &&
> >      hdr[2] == 't' && hdr[3] == ' ' ) {
>
> Should be ok. (Although a stream_read(s,hdr,2) and hdr[1] & 0x10
> would save a
> call.)

I'll do that if you prefer.

> > @@ -446,6 +448,17 @@ static int demux_audio_open(demuxer_t* d
> >  	g = stream_read_char(s);
> >  	demux_info_add(demuxer,"Genre",genres[g]);
> >        }
> > +      stream_seek(s,demuxer->movi_end-10);
> > +      stream_read(s,tag,4);
> > +      if( tag[0] == '3' && tag[1] == 'D' && tag[2] == 'I' &&
> > ((uint8_t)tag[3] >= 2)) {
>
> One pair of () is pointless and I personally would prefer an unsigned
> char
> cast, but I don't know what Reimar thinks (he probably would go with
> hdr).

OK. I used this writing to keep the code as close as possible to the
lines above ("} else if( hdr[0] == 'I' && hdr[1] == 'D' &&
hdr[2] == '3' && (hdr[3] >= 2)) {").

> The version check should be 4.

Or simply removed? The ID3v2 major version does not really matter here
nor above since only the tag header/footer are interpreted and not the
tag contents. However, we could check that it is not 0xff, as specified.

> > +	int len;
> > +	stream_skip(s,1);
> > +	stream_read(s,tag,1);
> > +	len = tag[0] & 0x10 ? 20 : 10;
> > +	stream_read(s,tag,4);
> > +	len += (tag[0]<<21) | (tag[1]<<14) | (tag[2]<<7) | tag[3];
> > +	demuxer->movi_end = stream_tell(s)-len;
>
> Indentation.

What do you mean? These lines are indented exactly like the surrounding
lines. See "g = stream_read_char(s);" for instance. Do you want only spaces
instead?

> Shouldn't the existence of 3DI already prove a len of 20? Hmm, A 3DI
> without
> flag could indicate that it isn't a 3DI footer at all...

Indeed, strictly speaking, but I considered that borderline ID3 generators
could skip the header of appended tags like the footer of prepended tags can
legally be, so it's more robust with this test. I can remove it if you prefer.

Beno?t

From benoit.thebaudeau at advansee.com  Mon Jan 16 20:52:56 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Mon, 16 Jan 2012 20:52:56 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio:
	Skip	ID3v2.4	tags.
In-Reply-To: <20120116194214.GA4060@1und1.de>
Message-ID: <11903dda-0f5d-419e-9f6a-31d490c1061b@zose-store-12>

Reimar,

> > diff -Nrdup mplayer.orig/libmpdemux/demux_audio.c
> > mplayer/libmpdemux/demux_audio.c
> > --- mplayer.orig/libmpdemux/demux_audio.c	2011-11-11
> > 18:29:14.076503000 +0100
> > +++ mplayer/libmpdemux/demux_audio.c	2012-01-16 13:19:55.252067960
> > +0100
> > @@ -358,9 +358,11 @@ static int demux_audio_open(demuxer_t* d
> >  	step = 4;
> >      } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> >      (hdr[3] >= 2)) {
> >        int len;
> > -      stream_skip(s,2);
> > +      stream_skip(s,1);
> > +      stream_read(s,hdr,1);
> > +      len = hdr[0] & 0x10 ? 10 : 0;
> 
> Please use stream_read_char() directly instead of going through the
> tag
> variable, there's no need here.

OK.

> > +	int len;
> > +	stream_skip(s,1);
> > +	stream_read(s,tag,1);
> > +	len = tag[0] & 0x10 ? 20 : 10;
> > +	stream_read(s,tag,4);
> > +	len += (tag[0]<<21) | (tag[1]<<14) | (tag[2]<<7) | tag[3];
> 
> This seems to be exactly the same code.
> If so, please extract it into its own function instead of duplicating
> it.

OK. There is only a difference of 10 that can easily be dealt with.

Beno?t

From benoit.thebaudeau at advansee.com  Mon Jan 16 20:53:34 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Mon, 16 Jan 2012 20:53:34 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
	tags.
In-Reply-To: <20120116194406.GB4060@1und1.de>
Message-ID: <b0223e84-8764-42b9-9f30-f13c32ee1bd5@zose-store-12>

> On Mon, Jan 16, 2012 at 07:40:44PM +0100, Ingo Br?ckl wrote:
> > > @@ -446,6 +448,17 @@ static int demux_audio_open(demuxer_t* d
> > >  	g = stream_read_char(s);
> > >  	demux_info_add(demuxer,"Genre",genres[g]);
> > >        }
> > > +      stream_seek(s,demuxer->movi_end-10);
> > > +      stream_read(s,tag,4);
> > > +      if( tag[0] == '3' && tag[1] == 'D' && tag[2] == 'I' &&
> > > ((uint8_t)tag[3] >= 2)) {
> > 
> > One pair of () is pointless and I personally would prefer an
> > unsigned char
> > cast, but I don't know what Reimar thinks (he probably would go
> > with hdr).
> 
> I don't see any point to use "unsigned char" ever, at best it
> is a needlessly verbose way to do the same as uint8_t.

Agreed.

Beno?t

From benoit.thebaudeau at advansee.com  Mon Jan 16 20:59:52 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Mon, 16 Jan 2012 20:59:52 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio:
	Skip	ID3v2.4	tags.
In-Reply-To: <20120116194700.GA4831@1und1.de>
Message-ID: <d41c750a-c769-47de-86ef-04871de02c3e@zose-store-12>

Reimar,

> > +	demuxer->movi_end = stream_tell(s)-len;
> 
> And shouldn't this rather be FFMIN with the previous value?
> I am sure someone somewhere has managed to combine this with
> an ID3v1 tag in a way that overriding the value would result
> in trying to play back parts of the ID3v1 tag.

I don't see how there could be any issue here. It's exactly like
"demuxer->movi_end = stream_tell(s)-3;" for ID3v1. At this point,
the stream position is exactly between the end of the ID3v2 tag
and either the end of stream or the beginning of the ID3v1 tag
(which can be only after the ID3v2 tag).

Beno?t


From benoit.thebaudeau at advansee.com  Mon Jan 16 21:09:13 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Mon, 16 Jan 2012 21:09:13 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <4f147ecb.5d835093.bm000@wupperonline.de>
Message-ID: <7c8f73d6-4c06-4701-b84c-57ed74640d63@zose-store-12>

Ingo,

> > +	stream_read(s,tag,4);
> > +	len += (tag[0]<<21) | (tag[1]<<14) | (tag[2]<<7) | tag[3];
> > +	demuxer->movi_end = stream_tell(s)-len;
> 
> There probably should be two other checks.
> 
> stream_tell(s)-len should not point before the beginning of the file,
> and
> there should be an ID3 v4 tag with footer flag at this position.

To be thorough, many other things could be checked:
 - major version and revision != 0xff,
 - unsynchronization of size integer (each byte has 0 as bit 8),
 - tag contents
 - ...

Is it really necessary since the stream is anyway broken if these tests
fail?

If one of the checks that you propose fails, we know that there is a
broken tag of unknown size present in the stream, so what should we do?
Abort everything with 'return 0'?

Beno?t

From Reimar.Doeffinger at gmx.de  Mon Jan 16 21:32:29 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 16 Jan 2012 21:32:29 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio:
	Skip	ID3v2.4	tags.
In-Reply-To: <d41c750a-c769-47de-86ef-04871de02c3e@zose-store-12>
References: <20120116194700.GA4831@1und1.de>
	<d41c750a-c769-47de-86ef-04871de02c3e@zose-store-12>
Message-ID: <20120116203229.GA10841@1und1.de>

On Mon, Jan 16, 2012 at 08:59:52PM +0100, Beno?t Th?baudeau wrote:
> Reimar,
> 
> > > +	demuxer->movi_end = stream_tell(s)-len;
> > 
> > And shouldn't this rather be FFMIN with the previous value?
> > I am sure someone somewhere has managed to combine this with
> > an ID3v1 tag in a way that overriding the value would result
> > in trying to play back parts of the ID3v1 tag.
> 
> I don't see how there could be any issue here. It's exactly like
> "demuxer->movi_end = stream_tell(s)-3;" for ID3v1. At this point,
> the stream position is exactly between the end of the ID3v2 tag
> and either the end of stream or the beginning of the ID3v1 tag
> (which can be only after the ID3v2 tag).

Exactly that was my point. If previous behaviour is any indication
there is already some tool out there that munges things together
so that the ID3v1 tag ends up before.
However I just looked at the code again and in that case your code
just wouldn't find the ID3v2 tag, which is fine (of course only
for the case that the ID3v2 tag was written inside the v1 tag,
if it was just appended we won't detect the v1 tag. That seems
like a slightly more likely thing but trying to handle it is
probably not worth the effort).

From benoit.thebaudeau at advansee.com  Mon Jan 16 22:21:28 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Mon, 16 Jan 2012 22:21:28 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH]
	libmpdemux/demux_audio:	Skip	ID3v2.4	tags.
In-Reply-To: <20120116203229.GA10841@1und1.de>
Message-ID: <241a7252-e9bd-4d09-ad99-bb8a2ba824bd@zose-store-12>

Reimar,

> > > > +	demuxer->movi_end = stream_tell(s)-len;
> > > 
> > > And shouldn't this rather be FFMIN with the previous value?
> > > I am sure someone somewhere has managed to combine this with
> > > an ID3v1 tag in a way that overriding the value would result
> > > in trying to play back parts of the ID3v1 tag.
> > 
> > I don't see how there could be any issue here. It's exactly like
> > "demuxer->movi_end = stream_tell(s)-3;" for ID3v1. At this point,
> > the stream position is exactly between the end of the ID3v2 tag
> > and either the end of stream or the beginning of the ID3v1 tag
> > (which can be only after the ID3v2 tag).
> 
> Exactly that was my point. If previous behaviour is any indication
> there is already some tool out there that munges things together
> so that the ID3v1 tag ends up before.
> However I just looked at the code again and in that case your code
> just wouldn't find the ID3v2 tag, which is fine (of course only
> for the case that the ID3v2 tag was written inside the v1 tag,
> if it was just appended we won't detect the v1 tag. That seems
> like a slightly more likely thing but trying to handle it is
> probably not worth the effort).

OK. Please find attached a new version of the patch merging everyone's
comments.

Beno?t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1-demux-audio-skip-id3v2.4.patch
Type: text/x-patch
Size: 3143 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120116/542a5fae/attachment.bin>

From ib at wupperonline.de  Mon Jan 16 22:38:11 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 16 Jan 2012 22:38:11 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
	tags.
In-Reply-To: <5fa2473d-89c4-48c8-bbb9-c3d6986bfbfd@zose-store-12>
Message-ID: <4f149bb7.729b23e2.bm000@wupperonline.de>

Beno?t Th?baudeau wrote on Mon, 16 Jan 2012 20:51:11 +0100 (CET):

> I'll do that if you prefer.

Actually, Reimar is the guy whose approval you'll need.

>> The version check should be 4.

> Or simply removed?

I would check it.

>> Indentation.

> What do you mean?

You used tabs. Please use spaces.

>> Hmm, A 3DI without flag could indicate that it isn't a 3DI footer at
>> all...

> Indeed, strictly speaking, but I considered that borderline ID3 generators
> could skip the header of appended tags like the footer of prepended tags
> can legally be, so it's more robust with this test. I can remove it if you
> prefer.

Without a proper header it could be happen to be data as well.

Ingo

From ib at wupperonline.de  Mon Jan 16 22:44:45 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 16 Jan 2012 22:44:45 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
	tags.
In-Reply-To: <7c8f73d6-4c06-4701-b84c-57ed74640d63@zose-store-12>
Message-ID: <4f149bb7.6768cfdb.bm001@wupperonline.de>

Beno?t Th?baudeau wrote on Mon, 16 Jan 2012 21:09:13 +0100 (CET):

>> There probably should be two other checks.
>>
>> stream_tell(s)-len should not point before the beginning of the file, and
>> there should be an ID3 v4 tag with footer flag at this position.

> To be thorough, many other things could be checked:

Yes, I know. There can be very interesting things and combinations now with
all the different ID3 versions, but I think the two checks mentioned will
ensure that there is a (probably) valid header at a correct position, i.e.
that we really found a 3DI footer.

> If one of the checks that you propose fails, we know that there is a
> broken tag of unknown size present in the stream, so what should we do?

Don't consider it a (valid) tag and go on with the (wrong) size calculated so
far (as we would do with all other unknown tags).

Ingo

From Reimar.Doeffinger at gmx.de  Mon Jan 16 23:23:42 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 16 Jan 2012 23:23:42 +0100
Subject: [MPlayer-dev-eng] [PATCH]
	libmpdemux/demux_audio:	Skip	ID3v2.4	tags.
In-Reply-To: <241a7252-e9bd-4d09-ad99-bb8a2ba824bd@zose-store-12>
References: <20120116203229.GA10841@1und1.de>
	<241a7252-e9bd-4d09-ad99-bb8a2ba824bd@zose-store-12>
Message-ID: <20120116222341.GA20976@1und1.de>

On Mon, Jan 16, 2012 at 10:21:28PM +0100, Beno?t Th?baudeau wrote:
> +static unsigned int id3v2_tag_size(stream_t *s) {
> +  uint8_t tag[4];
> +  unsigned int header_footer_size;
> +  unsigned int size;
> +  int i;
> +
> +  stream_read(s,tag,2);
> +  if(tag[0] == 0xff)
> +    return 0;
> +  header_footer_size = tag[1] & 0x10 ? 20 : 10;
> +
> +  stream_read(s,tag,4);
> +  size = 0;
> +  for(i = 0; i < 4; i++) {
> +    if (tag[i] & 0x80)
> +      return 0;
> +    size = size << 7 | tag[i];
> +  }

"tag" doesn't seem like really good naming to me.
Personally I'd also rather go with either:
1) Read all 6 bytes at once or
2) Use stream_read_char to read one-by-one

> +    } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' && hdr[3] != 0xff &&
> +               (len = id3v2_tag_size(s)) > 0) {
> +      stream_skip(s,len-10);
>        step = 4;

Why accept hdr[3] values of 0 or 1 now? Aren't they invalid, too?
Also when failing id3v2_tag_size has read data and thus the data in
hdr is no longer in sync with the file position, so you must at least
set step to 4 in that case.
So I'm afraid it looks to me that squeezing that into the if made it
both uglier and wrong.
Just
> } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' && hdr[3] != 0xff) {
>   unsigned len = id3v2_tag_size(s);
>   if (len > 0)
>     stream_skip(s,len-10);
>  step = 4;

Should be fine I think.


> +      if( tag[0] == '3' && tag[1] == 'D' && tag[2] == 'I' && (uint8_t)tag[3] != 0xff &&
> +          (len = id3v2_tag_size(s)) > 0) {
> +        if(len > demuxer->movi_end) {
> +          mp_msg(MSGT_DEMUX,MSGL_ERR,"[demux_audio] Bad ID3v2 tag size: larger than stream (%u)!!!\n",len);
> +          len = demuxer->movi_end;

First, you should check against len > demuxer->movi_end - demuxer->movi_start,
because "end" before "start" is not that much better than negative end
:-)
Next, I doubt there is much point in setting it such that the file is
detected as empty, I think most users would prefer if we did our best
to try to play a broken file instead of pretend it is empty.
So IMO if you detect an error set len to 0 - or maybe better 10.

From ib at wupperonline.de  Mon Jan 16 23:05:55 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 16 Jan 2012 23:05:55 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
	tags.
In-Reply-To: <20120116194406.GB4060@1und1.de>
Message-ID: <4f14a4f3.59a4be8f.bm000@wupperonline.de>

Reimar D?ffinger wrote on Mon, 16 Jan 2012 20:44:06 +0100:

> I don't see any point to use "unsigned char" ever, at best it
> is a needlessly verbose way to do the same as uint8_t.

No offense, but if a variable is declared char and I need it unsigned, I'll
cast it unsigned char, even if uint8_t happens to be the same. If the focus
is on "8 bit", it should have been declared int8_t. I'm probably a nit-picker.

Ingo

From Reimar.Doeffinger at gmx.de  Mon Jan 16 23:43:30 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 16 Jan 2012 23:43:30 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
 tags.
In-Reply-To: <4f14a4f3.59a4be8f.bm000@wupperonline.de>
References: <20120116194406.GB4060@1und1.de>
	<4f14a4f3.59a4be8f.bm000@wupperonline.de>
Message-ID: <20120116224330.GA25066@1und1.de>

On Mon, Jan 16, 2012 at 11:05:55PM +0100, Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Mon, 16 Jan 2012 20:44:06 +0100:
> 
> > I don't see any point to use "unsigned char" ever, at best it
> > is a needlessly verbose way to do the same as uint8_t.
> 
> No offense, but if a variable is declared char and I need it unsigned, I'll
> cast it unsigned char, even if uint8_t happens to be the same. If the focus
> is on "8 bit", it should have been declared int8_t. I'm probably a nit-picker.

No, the array should have been declared as uint8_t.
(IMHO signed types are worth avoiding for raw data that needs to be
processed since they have more undefined behaviour etc.,
whereas for program logic the additional "breathing room" of
signed types often makes catching special cases or extending code
easier)
That probably is the real solution.
However the comparison with 0xff already assumes an 8-bit type
so I don't see it really as "need it unsigned" but "need it as
uint8_t". But of course it's all rather moot because it's the
same anyway, so the real argument (besides what I started with)
is that uint8_t IMO makes for clearly more readable code.

From benoit.thebaudeau at advansee.com  Tue Jan 17 00:40:12 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Tue, 17 Jan 2012 00:40:12 +0100 (CET)
Subject: [MPlayer-dev-eng]
	[PATCH]	libmpdemux/demux_audio:	Skip	ID3v2.4	tags.
In-Reply-To: <20120116222341.GA20976@1und1.de>
Message-ID: <abd63a55-60d3-4f9e-9953-a6922358e78c@zose-store-12>

Reimar,

> > +static unsigned int id3v2_tag_size(stream_t *s) {
> > +  uint8_t tag[4];
> > +  unsigned int header_footer_size;
> > +  unsigned int size;
> > +  int i;
> > +
> > +  stream_read(s,tag,2);
> > +  if(tag[0] == 0xff)
> > +    return 0;
> > +  header_footer_size = tag[1] & 0x10 ? 20 : 10;
> > +
> > +  stream_read(s,tag,4);
> > +  size = 0;
> > +  for(i = 0; i < 4; i++) {
> > +    if (tag[i] & 0x80)
> > +      return 0;
> > +    size = size << 7 | tag[i];
> > +  }
> 
> "tag" doesn't seem like really good naming to me.

OK, then what would you like? "hdr"?

> Personally I'd also rather go with either:
> 1) Read all 6 bytes at once or
> 2) Use stream_read_char to read one-by-one

OK, I'll do that. Any preference between 1 and 2?

> > +    } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> > hdr[3] != 0xff &&
> > +               (len = id3v2_tag_size(s)) > 0) {
> > +      stream_skip(s,len-10);
> >        step = 4;
> 
> Why accept hdr[3] values of 0 or 1 now? Aren't they invalid, too?

http://id3.org/id3v2.4.0-structure
"An ID3v2 tag can be detected with the following pattern:
$49 44 33 yy yy xx zz zz zz zz
Where yy is less than $FF, xx is the 'flags' byte and zz is less than
$80."

It does not say that the 1st yy can not be 0 or 1, but I don't find any
information regarding ID3v2.0 or ID3v2.1. Do you think it's better to
discard these major versions as non-existing? What about the possible
future ID3v2.5 and above?

> Also when failing id3v2_tag_size has read data and thus the data in
> hdr is no longer in sync with the file position, so you must at least
> set step to 4 in that case.
> So I'm afraid it looks to me that squeezing that into the if made it
> both uglier and wrong.
> Just
> > } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> > hdr[3] != 0xff) {
> >   unsigned len = id3v2_tag_size(s);
> >   if (len > 0)
> >     stream_skip(s,len-10);
> >  step = 4;
> 
> Should be fine I think.

No, that won't work either. If id3v2_tag_size fails, the tag signature is
not present, so step should be 1. It's the stream position that should be
changed in that case. Does stream_skip work with negative values, or should
stream_seek be used instead?

> > +      if( tag[0] == '3' && tag[1] == 'D' && tag[2] == 'I' &&
> > (uint8_t)tag[3] != 0xff &&
> > +          (len = id3v2_tag_size(s)) > 0) {
> > +        if(len > demuxer->movi_end) {
> > +          mp_msg(MSGT_DEMUX,MSGL_ERR,"[demux_audio] Bad ID3v2 tag
> > size: larger than stream (%u)!!!\n",len);
> > +          len = demuxer->movi_end;
> 
> First, you should check against len > demuxer->movi_end -
> demuxer->movi_start,
> because "end" before "start" is not that much better than negative
> end
> :-)
> Next, I doubt there is much point in setting it such that the file is
> detected as empty, I think most users would prefer if we did our best
> to try to play a broken file instead of pretend it is empty.
> So IMO if you detect an error set len to 0 - or maybe better 10.

OK, I'll do that. Also, the calculation of the duration uses movi_end instead
of (movi_end - movi_start) at the bottom of demuxer_audio.c. Is it on purpose?

Beno?t

From Reimar.Doeffinger at gmx.de  Tue Jan 17 00:56:18 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 17 Jan 2012 00:56:18 +0100
Subject: [MPlayer-dev-eng]
	[PATCH]	libmpdemux/demux_audio:	Skip	ID3v2.4	tags.
In-Reply-To: <abd63a55-60d3-4f9e-9953-a6922358e78c@zose-store-12>
References: <20120116222341.GA20976@1und1.de>
	<abd63a55-60d3-4f9e-9953-a6922358e78c@zose-store-12>
Message-ID: <20120116235618.GB31390@1und1.de>

On Tue, Jan 17, 2012 at 12:40:12AM +0100, Beno?t Th?baudeau wrote:
> > > +static unsigned int id3v2_tag_size(stream_t *s) {
> > > +  uint8_t tag[4];
> > > +  unsigned int header_footer_size;
> > > +  unsigned int size;
> > > +  int i;
> > > +
> > > +  stream_read(s,tag,2);
> > > +  if(tag[0] == 0xff)
> > > +    return 0;
> > > +  header_footer_size = tag[1] & 0x10 ? 20 : 10;
> > > +
> > > +  stream_read(s,tag,4);
> > > +  size = 0;
> > > +  for(i = 0; i < 4; i++) {
> > > +    if (tag[i] & 0x80)
> > > +      return 0;
> > > +    size = size << 7 | tag[i];
> > > +  }
> > 
> > "tag" doesn't seem like really good naming to me.
> 
> OK, then what would you like? "hdr"?

Can't think of anything. "body" maybe?

> > Personally I'd also rather go with either:
> > 1) Read all 6 bytes at once or
> > 2) Use stream_read_char to read one-by-one
> 
> OK, I'll do that. Any preference between 1 and 2?

Not particularly, whatever looks nicer :-)

> > > +    } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> > > hdr[3] != 0xff &&
> > > +               (len = id3v2_tag_size(s)) > 0) {
> > > +      stream_skip(s,len-10);
> > >        step = 4;
> > 
> > Why accept hdr[3] values of 0 or 1 now? Aren't they invalid, too?
> 
> http://id3.org/id3v2.4.0-structure
> "An ID3v2 tag can be detected with the following pattern:
> $49 44 33 yy yy xx zz zz zz zz
> Where yy is less than $FF, xx is the 'flags' byte and zz is less than
> $80."
> 
> It does not say that the 1st yy can not be 0 or 1, but I don't find any
> information regarding ID3v2.0 or ID3v2.1. Do you think it's better to
> discard these major versions as non-existing? What about the possible
> future ID3v2.5 and above?

Let's keep it with your version then, though making such somewhat
unrelated changes is not ideal (e.g. for regression bisecting -
though the code is simple enough it should not be a problem here).

> > Also when failing id3v2_tag_size has read data and thus the data in
> > hdr is no longer in sync with the file position, so you must at least
> > set step to 4 in that case.
> > So I'm afraid it looks to me that squeezing that into the if made it
> > both uglier and wrong.
> > Just
> > > } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> > > hdr[3] != 0xff) {
> > >   unsigned len = id3v2_tag_size(s);
> > >   if (len > 0)
> > >     stream_skip(s,len-10);
> > >  step = 4;
> > 
> > Should be fine I think.
> 
> No, that won't work either. If id3v2_tag_size fails, the tag signature is
> not present, so step should be 1. It's the stream position that should be
> changed in that case.

What are those "should be"s based on?
On error, step = 4 only has the meaning "resync hdr".
Yes, it means that if the file contains ID3 followed by something we
can't parse we will have skipped a few bytes unscanned.
Seems very, very unlikely to matter.

> Does stream_skip work with negative values, or should
> stream_seek be used instead?

Neither is possible or allowed if the stream is not seekable.

> OK, I'll do that. Also, the calculation of the duration uses movi_end instead
> of (movi_end - movi_start) at the bottom of demuxer_audio.c. Is it on purpose?

I'd say that is by mistake.

From benoit.thebaudeau at advansee.com  Tue Jan 17 15:04:11 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Tue, 17 Jan 2012 15:04:11 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <4f149bb7.729b23e2.bm000@wupperonline.de>
Message-ID: <74492320-8d97-433c-98bd-ee58e5f233ff@zose-store-12>

Ingo,

> > I'll do that if you prefer.
>
> Actually, Reimar is the guy whose approval you'll need.

OK.

> >> The version check should be 4.
>
> > Or simply removed?
>
> I would check it.

Reimar said that he finally prefers not to.

> >> Indentation.
>
> > What do you mean?
>
> You used tabs. Please use spaces.

Done.

> >> Hmm, A 3DI without flag could indicate that it isn't a 3DI footer
> >> at
> >> all...
>
> > Indeed, strictly speaking, but I considered that borderline ID3
> > generators
> > could skip the header of appended tags like the footer of prepended
> > tags
> > can legally be, so it's more robust with this test. I can remove it
> > if you
> > prefer.
>
> Without a proper header it could be happen to be data as well.

Done.

(See updated patch in one of the following messages.)

Beno?t

From benoit.thebaudeau at advansee.com  Tue Jan 17 15:04:17 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Tue, 17 Jan 2012 15:04:17 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <4f149bb7.6768cfdb.bm001@wupperonline.de>
Message-ID: <4b35b267-73b5-4fa1-8c2d-e12f7b6f35e0@zose-store-12>

Ingo,

> >> There probably should be two other checks.
> >>
> >> stream_tell(s)-len should not point before the beginning of the
> >> file, and
> >> there should be an ID3 v4 tag with footer flag at this position.
>
> > To be thorough, many other things could be checked:
>
> Yes, I know. There can be very interesting things and combinations
> now with
> all the different ID3 versions, but I think the two checks mentioned
> will
> ensure that there is a (probably) valid header at a correct position,
> i.e.
> that we really found a 3DI footer.

Done.

> > If one of the checks that you propose fails, we know that there is
> > a
> > broken tag of unknown size present in the stream, so what should we
> > do?
>
> Don't consider it a (valid) tag and go on with the (wrong) size
> calculated so
> far (as we would do with all other unknown tags).

Done.

Beno?t

From benoit.thebaudeau at advansee.com  Tue Jan 17 15:04:21 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Tue, 17 Jan 2012 15:04:21 +0100 (CET)
Subject: [MPlayer-dev-eng]
	[PATCH]	libmpdemux/demux_audio:	Skip	ID3v2.4	tags.
In-Reply-To: <20120116235618.GB31390@1und1.de>
Message-ID: <38c5012e-0140-41cf-9e6e-c66a5bece331@zose-store-12>

Reimar,

> > > > +static unsigned int id3v2_tag_size(stream_t *s) {
> > > > +  uint8_t tag[4];
> > > > +  unsigned int header_footer_size;
> > > > +  unsigned int size;
> > > > +  int i;
> > > > +
> > > > +  stream_read(s,tag,2);
> > > > +  if(tag[0] == 0xff)
> > > > +    return 0;
> > > > +  header_footer_size = tag[1] & 0x10 ? 20 : 10;
> > > > +
> > > > +  stream_read(s,tag,4);
> > > > +  size = 0;
> > > > +  for(i = 0; i < 4; i++) {
> > > > +    if (tag[i] & 0x80)
> > > > +      return 0;
> > > > +    size = size << 7 | tag[i];
> > > > +  }
> > >
> > > "tag" doesn't seem like really good naming to me.
> >
> > OK, then what would you like? "hdr"?
>
> Can't think of anything. "body" maybe?
>
> > > Personally I'd also rather go with either:
> > > 1) Read all 6 bytes at once or
> > > 2) Use stream_read_char to read one-by-one
> >
> > OK, I'll do that. Any preference between 1 and 2?
>
> Not particularly, whatever looks nicer :-)

OK. I went for 2 because it kills the variable naming discussion and it
reduces the number of dropped bytes in case of failure.

> > > > +    } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3'
> > > > &&
> > > > hdr[3] != 0xff &&
> > > > +               (len = id3v2_tag_size(s)) > 0) {
> > > > +      stream_skip(s,len-10);
> > > >        step = 4;
> > >
> > > Why accept hdr[3] values of 0 or 1 now? Aren't they invalid, too?
> >
> > http://id3.org/id3v2.4.0-structure
> > "An ID3v2 tag can be detected with the following pattern:
> > $49 44 33 yy yy xx zz zz zz zz
> > Where yy is less than $FF, xx is the 'flags' byte and zz is less
> > than
> > $80."
> >
> > It does not say that the 1st yy can not be 0 or 1, but I don't find
> > any
> > information regarding ID3v2.0 or ID3v2.1. Do you think it's better
> > to
> > discard these major versions as non-existing? What about the
> > possible
> > future ID3v2.5 and above?
>
> Let's keep it with your version then, though making such somewhat
> unrelated changes is not ideal (e.g. for regression bisecting -
> though the code is simple enough it should not be a problem here).

OK.

> > > Also when failing id3v2_tag_size has read data and thus the data
> > > in
> > > hdr is no longer in sync with the file position, so you must at
> > > least
> > > set step to 4 in that case.
> > > So I'm afraid it looks to me that squeezing that into the if made
> > > it
> > > both uglier and wrong.
> > > Just
> > > > } else if( hdr[0] == 'I' && hdr[1] == 'D' && hdr[2] == '3' &&
> > > > hdr[3] != 0xff) {
> > > >   unsigned len = id3v2_tag_size(s);
> > > >   if (len > 0)
> > > >     stream_skip(s,len-10);
> > > >  step = 4;
> > >
> > > Should be fine I think.
> >
> > No, that won't work either. If id3v2_tag_size fails, the tag
> > signature is
> > not present, so step should be 1. It's the stream position that
> > should be
> > changed in that case.
>
> What are those "should be"s based on?
> On error, step = 4 only has the meaning "resync hdr".
> Yes, it means that if the file contains ID3 followed by something we
> can't parse we will have skipped a few bytes unscanned.
> Seems very, very unlikely to matter.

Yes, my concern was these dropped bytes, hence those "should be"s.

> > Does stream_skip work with negative values, or should
> > stream_seek be used instead?
>
> Neither is possible or allowed if the stream is not seekable.

OK, then the choice is easy.

See my updated patch attached. It also takes into account the extra ID3
header check Ingo wanted, as well as what you said regarding uint8_t.

> > OK, I'll do that. Also, the calculation of the duration uses
> > movi_end instead
> > of (movi_end - movi_start) at the bottom of demuxer_audio.c. Is it
> > on purpose?
>
> I'd say that is by mistake.

I'll send a new patch for that.

Beno?t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1-demux-audio-skip-id3v2.4.patch
Type: text/x-patch
Size: 3473 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120117/c7cd9fe1/attachment.bin>

From benoit.thebaudeau at advansee.com  Tue Jan 17 15:18:11 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Tue, 17 Jan 2012 15:18:11 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Fix audio time
	length.
In-Reply-To: <4abd5044-ff9f-4430-a2cd-a5409fef7fa3@zose-store-12>
Message-ID: <e01c4a01-1ede-441d-8f76-bf1b9748a702@zose-store-12>

Hi all,

This patch fixes the lack of use of movi_start by the audio demuxer to compute
the audio time length.

Signed-off-by: "Beno?t Th?baudeau" <benoit.thebaudeau at advansee.com>

Best regards,
Beno?t Th?baudeau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4-fix-audio-length.patch
Type: text/x-patch
Size: 783 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120117/6e3cc79d/attachment.bin>

From mywing81 at gmail.com  Tue Jan 17 18:34:22 2012
From: mywing81 at gmail.com (Giorgio Vazzana)
Date: Tue, 17 Jan 2012 18:34:22 +0100
Subject: [MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out()
 for packets representing a dropped (0-byte) frame.
In-Reply-To: <loom.20120114T232342-563@post.gmane.org>
References: <CACy97@mail.gmail.com> <loom.20120114T232342-563@post.gmane.org>
Message-ID: <CACy97_-mmoS47q2a0MYkmRhbM8n_DXN6whNVkMeNc4LvgDUknw@mail.gmail.com>

2012/1/14 Carl Eugen Hoyos <cehoyos at ag.or.at>:
> Giorgio Vazzana <mywing81 <at> gmail.com> writes:
>
>> this is the last patch I wanted to submit. The subject pretty much
>> says it all: in case of 0-byte packets we don't need to call
>> th_decode_ycbcr_out() to decode the frame because we have a duplicated
>> frame, and so we can use the last frame.
>
> Is this related in any way to the problem mentioned here?
> http://thread.gmane.org/gmane.comp.video.mplayer.devel/59554/focus=59565

That problem is about 0-bytes packets not being handled correctly at
the demuxer level resulting in wrong pts (I've talked about it in one
of my previous mail:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2011-December/069665.html
), while this patch is for correctly dealing with those packets at the
decoder level.
I agree that this function is not used yet (because of that "if (!data
|| !len)" I talked about), but think of it as a way to future-proof
and complete the decoder so that no other work will be required.

>> Note: currently we are returning NULL in decode() if (!data || !len)
>> so basically we are discarding duplicated frames. When/if the
>> demuxer(s) will get fixed, we can delete that 'if' and things will
>> work properly at the decoder end.
>>
>> After this patch, the file needs a reindent, I don't know if there is
>> an automated program/script that can do it. If not let me know and
>> I'll do it by hand, after all it's a small file. Regards,
>
> Don't worry, whoever applies can do that, or ask for a patch later.

Ok,

ps: Not related to this patch, but I've just found two other streams
that only seem to work with -demuxer ogg (although ffplay can play
them):

http://modulix.org:8000/libre.ogg
http://modulix.org:8000/savoir.ogg

From cehoyos at ag.or.at  Tue Jan 17 18:46:41 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Tue, 17 Jan 2012 17:46:41 +0000 (UTC)
Subject: [MPlayer-dev-eng]
	=?utf-8?q?=5BPATCH=5D_Do_not_call_to_th=5Fdecod?=
	=?utf-8?q?e=5Fycbcr=5Fout=28=29_for_packets_representing_a_dropped?=
	=?utf-8?q?_=280-byte=29_frame=2E?=
References: <CACy97@mail.gmail.com> <loom.20120114T232342-563@post.gmane.org>
	<CACy97_-mmoS47q2a0MYkmRhbM8n_DXN6whNVkMeNc4LvgDUknw@mail.gmail.com>
Message-ID: <loom.20120117T184558-525@post.gmane.org>

Giorgio Vazzana <mywing81 <at> gmail.com> writes:

> ps: Not related to this patch, but I've just found two other streams
> that only seem to work with -demuxer ogg (although ffplay can play
> them):
> 
> http://modulix.org:8000/libre.ogg
> http://modulix.org:8000/savoir.ogg

They both work fine with one seek (even an initial back seek) - and -demuxer ogg.

Carl Eugen


From Reimar.Doeffinger at gmx.de  Tue Jan 17 19:23:48 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 17 Jan 2012 19:23:48 +0100
Subject: [MPlayer-dev-eng]
	[PATCH]	libmpdemux/demux_audio:	Skip	ID3v2.4	tags.
In-Reply-To: <38c5012e-0140-41cf-9e6e-c66a5bece331@zose-store-12>
References: <20120116235618.GB31390@1und1.de>
	<38c5012e-0140-41cf-9e6e-c66a5bece331@zose-store-12>
Message-ID: <20120117182347.GC2120@1und1.de>

On Tue, Jan 17, 2012 at 03:04:21PM +0100, Beno?t Th?baudeau wrote:

Seems fine to me.
Anyone volunteering to do a final test and apply?
I prefer to leave the work to others, but if not I'll apply it
after waiting for comments a tiny bit longer.


From Reimar.Doeffinger at gmx.de  Tue Jan 17 19:26:18 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 17 Jan 2012 19:26:18 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Fix audio
 time length.
In-Reply-To: <e01c4a01-1ede-441d-8f76-bf1b9748a702@zose-store-12>
References: <4abd5044-ff9f-4430-a2cd-a5409fef7fa3@zose-store-12>
	<e01c4a01-1ede-441d-8f76-bf1b9748a702@zose-store-12>
Message-ID: <20120117182618.GD2120@1und1.de>

On Tue, Jan 17, 2012 at 03:18:11PM +0100, Beno?t Th?baudeau wrote:
> Hi all,
> 
> This patch fixes the lack of use of movi_start by the audio demuxer to compute
> the audio time length.
> 
> Signed-off-by: "Beno?t Th?baudeau" <benoit.thebaudeau at advansee.com>
> 
> Best regards,
> Beno?t Th?baudeau

> diff -Nrdup mplayer.orig/libmpdemux/demux_audio.c mplayer/libmpdemux/demux_audio.c
> --- mplayer.orig/libmpdemux/demux_audio.c	2012-01-17 15:03:29.757246846 +0100
> +++ mplayer/libmpdemux/demux_audio.c	2012-01-17 15:11:47.549260678 +0100
> @@ -787,7 +787,9 @@ static void demux_close_audio(demuxer_t*
>  
>  static int demux_audio_control(demuxer_t *demuxer,int cmd, void *arg){
>      sh_audio_t *sh_audio=demuxer->audio->sh;
> -    int audio_length = sh_audio->i_bps ? demuxer->movi_end / sh_audio->i_bps : 0;
> +    off_t movi_size = (demuxer->movi_end > demuxer->movi_start) ?
> +                      demuxer->movi_end - demuxer->movi_start : demuxer->movi_end;
> +    int audio_length = sh_audio->i_bps ? movi_size / sh_audio->i_bps : 0;

Hm, is there much point/sense in falling back to just movi_end?
I would have suggest something like e.g.
int audio_length = sh_audio->i_bps && demuxer->movi_end > demuxer->movi_start ? ... : 0;

From benoit.thebaudeau at advansee.com  Tue Jan 17 19:45:02 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Tue, 17 Jan 2012 19:45:02 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Fix audio
	time length.
In-Reply-To: <20120117182618.GD2120@1und1.de>
Message-ID: <c9af45bb-33f1-4561-a0c8-1c0e320d94f3@zose-store-12>

Reimar,

> > diff -Nrdup mplayer.orig/libmpdemux/demux_audio.c
> > mplayer/libmpdemux/demux_audio.c
> > --- mplayer.orig/libmpdemux/demux_audio.c	2012-01-17
> > 15:03:29.757246846 +0100
> > +++ mplayer/libmpdemux/demux_audio.c	2012-01-17 15:11:47.549260678
> > +0100
> > @@ -787,7 +787,9 @@ static void demux_close_audio(demuxer_t*
> >  
> >  static int demux_audio_control(demuxer_t *demuxer,int cmd, void
> >  *arg){
> >      sh_audio_t *sh_audio=demuxer->audio->sh;
> > -    int audio_length = sh_audio->i_bps ? demuxer->movi_end /
> > sh_audio->i_bps : 0;
> > +    off_t movi_size = (demuxer->movi_end > demuxer->movi_start) ?
> > +                      demuxer->movi_end - demuxer->movi_start :
> > demuxer->movi_end;
> > +    int audio_length = sh_audio->i_bps ? movi_size /
> > sh_audio->i_bps : 0;
> 
> Hm, is there much point/sense in falling back to just movi_end?
> I would have suggest something like e.g.
> int audio_length = sh_audio->i_bps && demuxer->movi_end >
> demuxer->movi_start ? ... : 0;

I don't know. I just put that because it was the previous code, and because
it might be a better length indication than 0 even if not accurate.

I attach the patch with your suggestion.

Can someone also take a look at these?
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2012-January/069820.html
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2012-January/069821.html

Beno?t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4-fix-audio-length.patch
Type: text/x-patch
Size: 731 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120117/af2a1fcb/attachment.bin>

From Reimar.Doeffinger at gmx.de  Tue Jan 17 20:25:05 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 17 Jan 2012 20:25:05 +0100
Subject: [MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out()
 for packets representing a dropped (0-byte) frame.
In-Reply-To: <CACy97_-mmoS47q2a0MYkmRhbM8n_DXN6whNVkMeNc4LvgDUknw@mail.gmail.com>
References: <CACy97@mail.gmail.com> <loom.20120114T232342-563@post.gmane.org>
	<CACy97_-mmoS47q2a0MYkmRhbM8n_DXN6whNVkMeNc4LvgDUknw@mail.gmail.com>
Message-ID: <20120117192505.GC14191@1und1.de>

On Tue, Jan 17, 2012 at 06:34:22PM +0100, Giorgio Vazzana wrote:
> ps: Not related to this patch, but I've just found two other streams
> that only seem to work with -demuxer ogg (although ffplay can play
> them):
> 
> http://modulix.org:8000/libre.ogg
> http://modulix.org:8000/savoir.ogg

The fact that ffplay can play them probably is probably
more a bug of ffplay.
If you use ffprobe -show_packets you will see that the
first video packet has a timestamp of 0 and the next
of around 1600 seconds.
That should be about the time MPlayer will start to continue
playing the video part (that it continues to play audio even
though the timestamps are the same is just because it can't any
different).

From mpbob at ezpi.net  Tue Jan 17 22:39:14 2012
From: mpbob at ezpi.net (Bob)
Date: Tue, 17 Jan 2012 22:39:14 +0100
Subject: [MPlayer-dev-eng] [PATCH] YellowBlue/AmberBlue Dubios support for
	stereo3d
Message-ID: <4F15EA82.4040002@ezpi.net>

Hi,
I've patched stereo3d filter to support amber/blue least-square/dubois 
(eric dubois) filter as specified on:
http://www.flickr.com/photos/e_dubois/5230654930/ and 
http://www.site.uottawa.ca/~edubois/anaglyph/

The settings numbers have been converted by taking the 
numbers*65535/1062, and it works for me(TM).
Tinkering with this filter, I realized that there is most likely a large 
room for improvement in speed and gama/hue corrections, but works for 
simple material.
Most likely it could be done a ton better by using hue tables, but 
unfortunately ColorCode 3D has some rather nasty patents that shouldn't 
be tripped over..
If anyone have ideas on how to implement good gamma & hue corrections 
without tripping over US Patent 6,687,003 and EPO 1131658, I'll gladly 
try to implement it...


Index: libmpcodecs/vf_stereo3d.c
===================================================================
--- libmpcodecs/vf_stereo3d.c    (revision 34578)
+++ libmpcodecs/vf_stereo3d.c    (working copy)
@@ -48,6 +48,7 @@
      ANAGLYPH_YB_GRAY,   //anaglyph yellow/blue gray
      ANAGLYPH_YB_HALF,   //anaglyph yellow/blue half colored
      ANAGLYPH_YB_COLOR,  //anaglyph yellow/blue colored
+    ANAGLYPH_YB_DUBOIS,  //anaglyph yellow/blue colored
      MONO_L,             //mono output for debugging (left eye only)
      MONO_R,             //mono output for debugging (right eye only)
      SIDE_BY_SIDE_LR,    //side by side parallel (left eye left, right 
eye right)
@@ -74,7 +75,7 @@
  } component;

  //==global variables==//
-static const int ana_coeff[10][3][6] = {
+static const int ana_coeff[11][3][6] = {
      {{19595, 38470,  7471,     0,     0,     0},    //ANAGLYPH_RC_GRAY
       {    0,     0,     0, 19595, 38470,  7471},
       {    0,     0,     0, 19595, 38470,  7471}},
@@ -102,9 +103,13 @@
      {{    0,     0,     0, 65536,     0,     0},    //ANAGLYPH_YB_HALF
       {    0,     0,     0,     0, 65536,     0},
       {19595, 38470,  7471,     0,     0,     0}},
+
      {{    0,     0,     0, 65536,     0,     0},    //ANAGLYPH_YB_COLOR
       {    0,     0,     0,     0, 65536,     0},
-     {    0,     0, 65536,     0,     0,     0}}
+     {    0,     0, 65536,     0,     0,     0}},
+    {{65535,-12650,18451,   -987, -7590, -1049},    //ANAGLYPH_YB_DUBOIS
+     {-1604, 56032, 4196,    370,  3826, -1049},
+     {-2345,-10676, 1358,   5801, 11416, 56217}}
  };

  struct vf_priv_s {
@@ -200,6 +205,7 @@
      case ANAGLYPH_YB_GRAY:
      case ANAGLYPH_YB_HALF:
      case ANAGLYPH_YB_COLOR:
+    case ANAGLYPH_YB_DUBOIS:
          memcpy(vf->priv->ana_matrix, ana_coeff[vf->priv->out.fmt],
                 sizeof(vf->priv->ana_matrix));
          break;
@@ -325,6 +331,7 @@
          case ANAGLYPH_GM_COLOR:
          case ANAGLYPH_YB_GRAY:
          case ANAGLYPH_YB_HALF:
+        case ANAGLYPH_YB_DUBOIS:
          case ANAGLYPH_YB_COLOR: {
              int i,x,y,il,ir,o;
              unsigned char *source     = mpi->planes[0];
@@ -411,6 +418,8 @@
      {"anaglyph_yellow_blue_half_color",  ANAGLYPH_YB_HALF},
      {"aybc",                             ANAGLYPH_YB_COLOR},
      {"anaglyph_yellow_blue_color",       ANAGLYPH_YB_COLOR},
+    {"aybd",                             ANAGLYPH_YB_DUBOIS},
+    {"anaglyph_yellow_blue_dubois",      ANAGLYPH_YB_DUBOIS},
      {"ml",                               MONO_L},
      {"mono_left",                        MONO_L},
      {"mr",                               MONO_R},




From Reimar.Doeffinger at gmx.de  Tue Jan 17 22:50:35 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 17 Jan 2012 22:50:35 +0100
Subject: [MPlayer-dev-eng] [PATCH] YellowBlue/AmberBlue Dubios support
 for stereo3d
In-Reply-To: <4F15EA82.4040002@ezpi.net>
References: <4F15EA82.4040002@ezpi.net>
Message-ID: <20120117215035.GA8196@1und1.de>

On Tue, Jan 17, 2012 at 10:39:14PM +0100, Bob wrote:
> Tinkering with this filter, I realized that there is most likely a
> large room for improvement in speed and gama/hue corrections, but
> works for simple material.

What do you need to do that you can't just use (if necessary on the
code reuse level) -vf eq2?
And I am sure some of the people on the list who might be employed
at overly paranoid companies would appreciate if you didn't
mention patent numbers.
And another good part probably don't see why you should care,
considering that MPlayer already uses FFmpeg, a good number of
countries don't have software patents and even then it is questionable
whether they can be enforced on source code.

> -     {    0,     0, 65536,     0,     0,     0}}
> +     {    0,     0, 65536,     0,     0,     0}},
> +    {{65535,-12650,18451,   -987, -7590, -1049},    //ANAGLYPH_YB_DUBOIS
> +     {-1604, 56032, 4196,    370,  3826, -1049},
> +     {-2345,-10676, 1358,   5801, 11416, 56217}}

If you just put that comma there right now, the diff
next time you add one will be one line less and more
readable.
Btw. you could also consider changing these to use
the
[ANAGLYPH_YB_DUBOIS] = {...}
syntax instead of putting that as a comment at the end.
Of course that should not be part of this patch but
a separate one.

From mpbob at ezpi.net  Tue Jan 17 23:15:09 2012
From: mpbob at ezpi.net (Bob)
Date: Tue, 17 Jan 2012 23:15:09 +0100
Subject: [MPlayer-dev-eng] [PATCH] YellowBlue/AmberBlue Dubios support
 for stereo3d
Message-ID: <4F15F2ED.4060705@ezpi.net>

Ok, sorry, I just wanted to point out the source of this one to show 
that it doesn't break patents.
And to trigger other developers to think about anaglyph 3d by giving 
some pointers, mostly towards Eric Dubois and the danish 3d gurus.
This is my first patch submitted to MPlayer.

I just continued the same "coding style" that where in that filter, but 
your right, there are some nasty structures in that module :)

/Bob

From ib at wupperonline.de  Wed Jan 18 00:17:37 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 18 Jan 2012 00:17:37 +0100
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip ID3v2.4
	tags.
In-Reply-To: <20120117182347.GC2120@1und1.de>
Message-ID: <4f1601c5.1de3acb7.bm000@wupperonline.de>

Reimar D?ffinger wrote on Tue, 17 Jan 2012 19:23:48 +0100:

> On Tue, Jan 17, 2012 at 03:04:21PM +0100, Beno?t Th?baudeau wrote:

> Seems fine to me.
> Anyone volunteering to do a final test and apply?
> I prefer to leave the work to others, but if not I'll apply it
> after waiting for comments a tiny bit longer.

I personally would only perform a footer flag check and accept the 3DI footer
if version is 4 or above.

AFAIK valid ID3v2 tag headers start with version 2, so we should not drop
this check.

You already mentioned that ("very, very unlikely to matter") in case len is 0
(error or malformed tag), the stream position may be somewhere between ID3v2
flags and ID3v2 size, but we step 4.

If len > demuxer->movi_end - demuxer->movi_start, it cannot be decided
whether this is a malformed footer or just audio data. There should be
neither an error message nor a len setting in this case. (Same, if the
corresponding and valid ID3 header cannot be found.)

Error (wouldn't warning or hint have been sufficient here?) messages, if any,
should be translatable.

I'm not sure whether it is worth the effort to check the whole 3DI footer
data against the ID3 header data. According to the specs they must be copies.

BTW, after applying I would change stream_seek(s,s->end_pos-128) to
stream_seek(s,demuxer->movi_end-128) to avoid problems if the sequence of
checks ever changes or a new check will be prepended.

Just my two cents.

Ingo

From tempn at twmi.rr.com  Wed Jan 18 01:03:07 2012
From: tempn at twmi.rr.com (compn)
Date: Tue, 17 Jan 2012 19:03:07 -0500
Subject: [MPlayer-dev-eng] [PATCH] YellowBlue/AmberBlue Dubios support
 for stereo3d
In-Reply-To: <4F15F2ED.4060705@ezpi.net>
References: <4F15F2ED.4060705@ezpi.net>
Message-ID: <20120117190307.f70d07ed.tempn@twmi.rr.com>

On Tue, 17 Jan 2012 23:15:09 +0100, Bob wrote:
>Ok, sorry, I just wanted to point out the source of this one to show 
>that it doesn't break patents.

no worries. mplayer doesnt care about patents.

-compn

From mywing81 at gmail.com  Wed Jan 18 12:15:03 2012
From: mywing81 at gmail.com (Giorgio Vazzana)
Date: Wed, 18 Jan 2012 12:15:03 +0100
Subject: [MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out()
 for packets representing a dropped (0-byte) frame.
In-Reply-To: <20120117192505.GC14191@1und1.de>
References: <CACy97@mail.gmail.com> <loom.20120114T232342-563@post.gmane.org>
	<CACy97_-mmoS47q2a0MYkmRhbM8n_DXN6whNVkMeNc4LvgDUknw@mail.gmail.com>
	<20120117192505.GC14191@1und1.de>
Message-ID: <CACy97_9=9T8i81Qte_PkPLHgjvQiOxvX1HBOUDD2HH0QLyHiHg@mail.gmail.com>

2012/1/17 Reimar D?ffinger <Reimar.Doeffinger at gmx.de>:
> On Tue, Jan 17, 2012 at 06:34:22PM +0100, Giorgio Vazzana wrote:
>> ps: Not related to this patch, but I've just found two other streams
>> that only seem to work with -demuxer ogg (although ffplay can play
>> them):
>>
>> http://modulix.org:8000/libre.ogg
>> http://modulix.org:8000/savoir.ogg
>
> The fact that ffplay can play them probably is probably
> more a bug of ffplay.

Actually, I think ffplay does the right thing. Look at this sample
I've saved using wget:

http://mywing.altervista.org/tmp/libre.ogg

Using the attached patch it's easy to see that the the first video
packet has the following characteristics:

bytes=4300, granulepos=661456=41341|0, packetno=4, pts=1653.640000

so it's a keyframe, with granulepos != -1, and pts=27m:33s:64. Of
course since it's a live stream we're talking about, we don't want to
wait 27 minutes before start playing the file, so I think ffplay
behaviour is correct.

> If you use ffprobe -show_packets you will see that the
> first video packet has a timestamp of 0 and the next
> of around 1600 seconds.

ffprobe -show_packets for the sample above reports a pts of 0 for the
first video packet, which I think it's wrong, because the correct pts
is 1653.640000

> That should be about the time MPlayer will start to continue
> playing the video part (that it continues to play audio even
> though the timestamps are the same is just because it can't any
> different).
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-theora-show-packets-info.diff
Type: text/x-patch
Size: 1211 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120118/7d184ba7/attachment.bin>

From benoit.thebaudeau at advansee.com  Wed Jan 18 15:19:43 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Wed, 18 Jan 2012 15:19:43 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <4f1601c5.1de3acb7.bm000@wupperonline.de>
Message-ID: <ebb62d55-08e3-4c27-ac07-a9474e6135a1@zose-store-12>

Ingo,

> I personally would only perform a footer flag check and accept the
> 3DI footer
> if version is 4 or above.

Done (see attachment).

> AFAIK valid ID3v2 tag headers start with version 2, so we should not
> drop
> this check.

Done.

> You already mentioned that ("very, very unlikely to matter") in case
> len is 0
> (error or malformed tag), the stream position may be somewhere
> between ID3v2
> flags and ID3v2 size, but we step 4.

The 4 that are stepped here are "ID3" and the major version. At least one
more byte has been read after these by id3v2_tag_size(), so hdr has to be
fully refilled, hence step = 4. id3v2_tag_size() could be modified to fill
hdr before stepping, which would limit the number of dropped bytes, but
that would be ugly, and not very useful as Reimar said.

> If len > demuxer->movi_end - demuxer->movi_start, it cannot be
> decided
> whether this is a malformed footer or just audio data. There should
> be
> neither an error message nor a len setting in this case. (Same, if
> the
> corresponding and valid ID3 header cannot be found.)

No. In both cases, the ID3 footer signature is perfectly verified, so there
is no chance it can be audio data, and it has to be some leftover of an ID3
tag edition. Both cases are really errors because they prove that the stream
is malformed. IMO, it's better to drop the final MP3 frame than to play
garbage.

> Error (wouldn't warning or hint have been sufficient here?)

These are stream structure errors, so they should be reported with the message
level that MPlayer usually sets for such events. "Bad wav header length" and
"truncated extradata" are similar events that are also logged as errors, so
there is no reason to do something different for ID3 tags.

> messages,
> if any,
> should be translatable.

What does it imply for MPlayer? I don't see anything special done for the
two similar messages I mentioned above.

> I'm not sure whether it is worth the effort to check the whole 3DI
> footer
> data against the ID3 header data. According to the specs they must be
> copies.

They're supposed to be, but what if they're not? You have already made me
add a lot of checks for impossible cases if streams are spec-compliant.
We should either support only spec-compliant streams, or stick to 'work
around all possible garbage'.

> BTW, after applying I would change stream_seek(s,s->end_pos-128) to
> stream_seek(s,demuxer->movi_end-128) to avoid problems if the
> sequence of
> checks ever changes or a new check will be prepended.

Yes, and "demuxer->movi_end = stream_tell(s)-3;" could be replaced with
"demuxer->movi_end -= 128;".

Beno?t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1-demux-audio-skip-id3v2.4.patch
Type: text/x-patch
Size: 3634 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120118/3142d5d5/attachment.bin>

From diego at biurrun.de  Thu Jan 19 15:37:30 2012
From: diego at biurrun.de (Diego Biurrun)
Date: Thu, 19 Jan 2012 15:37:30 +0100
Subject: [MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out()
 for packets representing a dropped (0-byte) frame.
In-Reply-To: <CACy97__g7yMHSJggs8KqnGF7kHKg=KHTxaVABYU6AEfpiAhH5w@mail.gmail.com>
References: <CACy97__g7yMHSJggs8KqnGF7kHKg=KHTxaVABYU6AEfpiAhH5w@mail.gmail.com>
Message-ID: <20120119143730.GA2468@pool.informatik.rwth-aachen.de>

On Wed, Jan 11, 2012 at 01:35:52PM +0100, Giorgio Vazzana wrote:
> 
> this is the last patch I wanted to submit. The subject pretty much
> says it all: in case of 0-byte packets we don't need to call
> th_decode_ycbcr_out() to decode the frame because we have a duplicated
> frame, and so we can use the last frame.

Applied.

> After this patch, the file needs a reindent, I don't know if there is
> an automated program/script that can do it. If not let me know and
> I'll do it by hand, after all it's a small file. Regards,

TOOLS/mp-uncrustify-style.cfg

is our configuration file for uncrustify.  You can run that and make
a few corrections by hand.

Diego

From mywing81 at gmail.com  Fri Jan 20 17:14:02 2012
From: mywing81 at gmail.com (Giorgio Vazzana)
Date: Fri, 20 Jan 2012 17:14:02 +0100
Subject: [MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out()
 for packets representing a dropped (0-byte) frame.
In-Reply-To: <20120119143730.GA2468@pool.informatik.rwth-aachen.de>
References: <CACy97__g7yMHSJggs8KqnGF7kHKg=KHTxaVABYU6AEfpiAhH5w@mail.gmail.com>
	<20120119143730.GA2468@pool.informatik.rwth-aachen.de>
Message-ID: <CACy97__bSNCja7dTP=2Ga6CRYH2vWr1Mg+fzLWreD6peymsH+Q@mail.gmail.com>

2012/1/19 Diego Biurrun <diego at biurrun.de>:
> On Wed, Jan 11, 2012 at 01:35:52PM +0100, Giorgio Vazzana wrote:
>>
>> this is the last patch I wanted to submit. The subject pretty much
>> says it all: in case of 0-byte packets we don't need to call
>> th_decode_ycbcr_out() to decode the frame because we have a duplicated
>> frame, and so we can use the last frame.
>
> Applied.

Thanks.

>> After this patch, the file needs a reindent, I don't know if there is
>> an automated program/script that can do it. If not let me know and
>> I'll do it by hand, after all it's a small file. Regards,
>
> TOOLS/mp-uncrustify-style.cfg
>
> is our configuration file for uncrustify. ?You can run that and make
> a few corrections by hand.

Done, see attached patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-theora-uncrustify.diff
Type: text/x-patch
Size: 7566 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120120/8449700b/attachment.bin>

From eclipse7 at gmx.net  Sat Jan 21 13:19:41 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 21 Jan 2012 13:19:41 +0100
Subject: [MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out()
 for packets representing a dropped (0-byte) frame.
In-Reply-To: <CACy97__bSNCja7dTP=2Ga6CRYH2vWr1Mg+fzLWreD6peymsH+Q@mail.gmail.com>
References: <CACy97__g7yMHSJggs8KqnGF7kHKg=KHTxaVABYU6AEfpiAhH5w@mail.gmail.com>
	<20120119143730.GA2468@pool.informatik.rwth-aachen.de>
	<CACy97__bSNCja7dTP=2Ga6CRYH2vWr1Mg+fzLWreD6peymsH+Q@mail.gmail.com>
Message-ID: <20120121121941.GA21863@akuma>

Hi,

Giorgio Vazzana wrote:
> 2012/1/19 Diego Biurrun <diego at biurrun.de>:
> > On Wed, Jan 11, 2012 at 01:35:52PM +0100, Giorgio Vazzana wrote:
[...]
> >> After this patch, the file needs a reindent, I don't know if there is
> >> an automated program/script that can do it. If not let me know and
> >> I'll do it by hand, after all it's a small file. Regards,
> >
> > TOOLS/mp-uncrustify-style.cfg
> >
> > is our configuration file for uncrustify. ?You can run that and make
> > a few corrections by hand.
> 
> Done, see attached patch.

  Looks mostly fine. Just a few remarks:

> Index: libmpcodecs/vd_theora.c
> ===================================================================
> --- libmpcodecs/vd_theora.c	(revision 34581)
> +++ libmpcodecs/vd_theora.c	(working copy)
[...]
> @@ -45,30 +45,32 @@
>  
>  typedef struct theora_struct_st {
>      th_setup_info *tsi;
> -    th_dec_ctx    *tctx;
> -    th_comment     tc;
> -    th_info        ti;
> +    th_dec_ctx *tctx;
> +    th_comment tc;
> +    th_info ti;
>      th_ycbcr_buffer ycbcrbuf;
>  } theora_struct_t;

  Optionally you can align this so it matches with ycbcrbuf. The tabular
layout is a bit easier to scan when skimming over the source code. Choose
whatever you prefer though.

[...]
> @@ -77,15 +79,16 @@
>  /*
>   * init driver
>   */
> -static int init(sh_video_t *sh){
> +static int init(sh_video_t *sh)
> +{
>      theora_struct_t *context = NULL;
> -    uint8_t *extradata = (uint8_t *)(sh->bih + 1);
> -    int extradata_size = sh->bih->biSize - sizeof(*sh->bih);
> +    uint8_t *extradata       = (uint8_t *)(sh->bih + 1);
> +    int extradata_size       = sh->bih->biSize - sizeof(*sh->bih);
>      int errorCode = 0;

  Optionally you may consider aligning the extradata/extradata_size
variable names and the initializer of errorCode to make it look less
haphazard. Or probably don't align anything at all and just use one
space everywhere here. Or leave as you have it now if you prefer.

[...]
> -    mp_msg(MSGT_DECVIDEO,MSGL_V,"INFO: Theora video init ok!\n");
> -    mp_msg(MSGT_DECVIDEO,MSGL_INFO,"Frame: %dx%d, Picture %dx%d, Offset [%d,%d]\n", context->ti.frame_width, context->ti.frame_height, context->ti.pic_width, context->ti.pic_height, context->ti.pic_x, context->ti.pic_y);
> +    mp_msg(MSGT_DECVIDEO, MSGL_V, "INFO: Theora video init ok!\n");
> +    mp_msg(MSGT_DECVIDEO, MSGL_INFO, "Frame %dx%d, Picture %dx%d, Offset [%d,%d]\n", context->ti.frame_width, context->ti.frame_height, context->ti.pic_width, context->ti.pic_height, context->ti.pic_x, context->ti.pic_y);

  This is the only (minor) semantic difference I could spot. Did you
remove the ':' in 'Frame:' intentionally? The message seems more
consistent with that change, so I think you changed it on purpose and
I think it is OK.

  Although the message is at MSGL_INFO, I don't assume anyone relied
on it when parsing mplayer output.


[...]

  Alexander

From mywing81 at gmail.com  Sat Jan 21 15:43:50 2012
From: mywing81 at gmail.com (Giorgio Vazzana)
Date: Sat, 21 Jan 2012 15:43:50 +0100
Subject: [MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out()
 for packets representing a dropped (0-byte) frame.
In-Reply-To: <20120121121941.GA21863@akuma>
References: <CACy97__g7yMHSJggs8KqnGF7kHKg=KHTxaVABYU6AEfpiAhH5w@mail.gmail.com>
	<20120119143730.GA2468@pool.informatik.rwth-aachen.de>
	<CACy97__bSNCja7dTP=2Ga6CRYH2vWr1Mg+fzLWreD6peymsH+Q@mail.gmail.com>
	<20120121121941.GA21863@akuma>
Message-ID: <CACy97__aU_Gsu-eQe=nYk8MZ8g-P_C=0uzKf2V7OCOD5kUcHJg@mail.gmail.com>

2012/1/21 Alexander Strasser <eclipse7 at gmx.net>:
> ?Looks mostly fine. Just a few remarks:
>
>> Index: libmpcodecs/vd_theora.c
>> ===================================================================
>> --- libmpcodecs/vd_theora.c ? (revision 34581)
>> +++ libmpcodecs/vd_theora.c ? (working copy)
> [...]
>> @@ -45,30 +45,32 @@
>>
>> ?typedef struct theora_struct_st {
>> ? ? ?th_setup_info *tsi;
>> - ? ?th_dec_ctx ? ?*tctx;
>> - ? ?th_comment ? ? tc;
>> - ? ?th_info ? ? ? ?ti;
>> + ? ?th_dec_ctx *tctx;
>> + ? ?th_comment tc;
>> + ? ?th_info ti;
>> ? ? ?th_ycbcr_buffer ycbcrbuf;
>> ?} theora_struct_t;
>
> ?Optionally you can align this so it matches with ycbcrbuf. The tabular
> layout is a bit easier to scan when skimming over the source code. Choose
> whatever you prefer though.

Done.

> [...]
>> @@ -77,15 +79,16 @@
>> ?/*
>> ? * init driver
>> ? */
>> -static int init(sh_video_t *sh){
>> +static int init(sh_video_t *sh)
>> +{
>> ? ? ?theora_struct_t *context = NULL;
>> - ? ?uint8_t *extradata = (uint8_t *)(sh->bih + 1);
>> - ? ?int extradata_size = sh->bih->biSize - sizeof(*sh->bih);
>> + ? ?uint8_t *extradata ? ? ? = (uint8_t *)(sh->bih + 1);
>> + ? ?int extradata_size ? ? ? = sh->bih->biSize - sizeof(*sh->bih);
>> ? ? ?int errorCode = 0;
>
> ?Optionally you may consider aligning the extradata/extradata_size
> variable names and the initializer of errorCode to make it look less
> haphazard. Or probably don't align anything at all and just use one
> space everywhere here. Or leave as you have it now if you prefer.

Done.

> [...]
>> - ? ?mp_msg(MSGT_DECVIDEO,MSGL_V,"INFO: Theora video init ok!\n");
>> - ? ?mp_msg(MSGT_DECVIDEO,MSGL_INFO,"Frame: %dx%d, Picture %dx%d, Offset [%d,%d]\n", context->ti.frame_width, context->ti.frame_height, context->ti.pic_width, context->ti.pic_height, context->ti.pic_x, context->ti.pic_y);
>> + ? ?mp_msg(MSGT_DECVIDEO, MSGL_V, "INFO: Theora video init ok!\n");
>> + ? ?mp_msg(MSGT_DECVIDEO, MSGL_INFO, "Frame %dx%d, Picture %dx%d, Offset [%d,%d]\n", context->ti.frame_width, context->ti.frame_height, context->ti.pic_width, context->ti.pic_height, context->ti.pic_x, context->ti.pic_y);
>
> ?This is the only (minor) semantic difference I could spot. Did you
> remove the ':' in 'Frame:' intentionally?

Yes. I had sent a patch to add that message a while back, and an extra
":" had slipped in, so I thought I'd fix it now.

> The message seems more
> consistent with that change, so I think you changed it on purpose and
> I think it is OK.
>
> ?Although the message is at MSGL_INFO, I don't assume anyone relied
> on it when parsing mplayer output.

New patch attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-theora-uncrustify.diff
Type: text/x-patch
Size: 7681 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120121/11ab9bdd/attachment.bin>

From eclipse7 at gmx.net  Sat Jan 21 18:46:26 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 21 Jan 2012 18:46:26 +0100
Subject: [MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out()
 for packets representing a dropped (0-byte) frame.
In-Reply-To: <CACy97__aU_Gsu-eQe=nYk8MZ8g-P_C=0uzKf2V7OCOD5kUcHJg@mail.gmail.com>
References: <CACy97__g7yMHSJggs8KqnGF7kHKg=KHTxaVABYU6AEfpiAhH5w@mail.gmail.com>
	<20120119143730.GA2468@pool.informatik.rwth-aachen.de>
	<CACy97__bSNCja7dTP=2Ga6CRYH2vWr1Mg+fzLWreD6peymsH+Q@mail.gmail.com>
	<20120121121941.GA21863@akuma>
	<CACy97__aU_Gsu-eQe=nYk8MZ8g-P_C=0uzKf2V7OCOD5kUcHJg@mail.gmail.com>
Message-ID: <20120121174626.GA22635@akuma>

Hi Giorgio,

Giorgio Vazzana wrote:
> 2012/1/21 Alexander Strasser <eclipse7 at gmx.net>:
> > ?Looks mostly fine. Just a few remarks:
> >
> >> Index: libmpcodecs/vd_theora.c
[...]
> 
> New patch attached.

  Looks fine and committed.

Thank you,
  Alexander

From cehoyos at ag.or.at  Sun Jan 22 22:40:50 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Sun, 22 Jan 2012 22:40:50 +0100
Subject: [MPlayer-dev-eng] [PATCH]Fix FFmpeg tiff RGBA on big endian
Message-ID: <201201222240.50214.cehoyos@ag.or.at>

Hi!

Attached fixes playback of RGBA tiff on BE.
Alternative might be to completely remove RGB32 and friends but this is the 
smaller patch...

Please comment, Carl Eugen
-------------- next part --------------
Index: etc/codecs.conf
===================================================================
--- etc/codecs.conf	(revision 34586)
+++ etc/codecs.conf	(working copy)
@@ -580,7 +580,7 @@
   fourcc "tiff" ; for TIFF-encoded QuickTime files
   driver ffmpeg
   dll tiff
-  out BGR32,BGR24,BGR8,Y800,RGB48BE,RGB48LE,RGB32,RGB24,RGB8
+  out BGR8,Y800,RGB48BE,RGB48LE,RGBA,RGB24
 
 videocodec ffpcx
   info "FFmpeg PCX"
Index: codec-cfg.c
===================================================================
--- codec-cfg.c	(revision 34582)
+++ codec-cfg.c	(working copy)
@@ -206,6 +206,7 @@
     {"RGB16",       IMGFMT_RGB16},
     {"RGB24",       IMGFMT_RGB24},
     {"RGB32",       IMGFMT_RGB32},
+    {"RGBA",        IMGFMT_RGBA},
     {"BGR4",        IMGFMT_BGR4},
     {"BGR8",        IMGFMT_BGR8},
     {"BGR15",       IMGFMT_BGR15},

From Reimar.Doeffinger at gmx.de  Mon Jan 23 00:30:51 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Mon, 23 Jan 2012 00:30:51 +0100
Subject: [MPlayer-dev-eng] [PATCH]Fix FFmpeg tiff RGBA on big endian
In-Reply-To: <201201222240.50214.cehoyos@ag.or.at>
References: <201201222240.50214.cehoyos@ag.or.at>
Message-ID: <F2C08412-DDC4-4C9A-9E11-2135C7ACD7A7@gmx.de>

On 22 Jan 2012, at 22:40, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Hi!
> 
> Attached fixes playback of RGBA tiff on BE.
> Alternative might be to completely remove RGB32 and friends but this is the 
> smaller patch...

What do you mean by the "completely remove" part?
Also, is this something that recently changed in FFmpeg?
If so it might make sense to keep the old formats in a little longer, they should not cause any issues.

From cehoyos at ag.or.at  Mon Jan 23 00:42:10 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Sun, 22 Jan 2012 23:42:10 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH]Fix FFmpeg tiff RGBA on big endian
References: <201201222240.50214.cehoyos@ag.or.at>
	<F2C08412-DDC4-4C9A-9E11-2135C7ACD7A7@gmx.de>
Message-ID: <loom.20120123T004039-648@post.gmane.org>

Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:

> > Attached fixes playback of RGBA tiff on BE.
> > Alternative might be to completely remove RGB32 and friends but this is the 
> > smaller patch...
> 
> What do you mean by the "completely remove" part?

Remove all RGB32 and BGR32 and replace with RGBA, ARGB, BGRA and ABGR.
But I would prefer not to do that atm.

> Also, is this something that recently changed in FFmpeg?

Not since June 2009, do I have to look further back?

Carl Eugen


From Reimar.Doeffinger at gmx.de  Mon Jan 23 22:04:57 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 23 Jan 2012 22:04:57 +0100
Subject: [MPlayer-dev-eng] [PATCH]Fix FFmpeg tiff RGBA on big endian
In-Reply-To: <loom.20120123T004039-648@post.gmane.org>
References: <201201222240.50214.cehoyos@ag.or.at>
	<F2C08412-DDC4-4C9A-9E11-2135C7ACD7A7@gmx.de>
	<loom.20120123T004039-648@post.gmane.org>
Message-ID: <20120123210457.GB2395@1und1.de>

On Sun, Jan 22, 2012 at 11:42:10PM +0000, Carl Eugen Hoyos wrote:
> Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:
> 
> > > Attached fixes playback of RGBA tiff on BE.
> > > Alternative might be to completely remove RGB32 and friends but this is the 
> > > smaller patch...
> > 
> > What do you mean by the "completely remove" part?
> 
> Remove all RGB32 and BGR32 and replace with RGBA, ARGB, BGRA and ABGR.
> But I would prefer not to do that atm.

The idea is to have exactly those that FFmpeg actually supports.
If you removed RGB32 for example you'd have to add both RGBA and
ABGR (or was it ARGB and BGRA? Whatever) despite the fact that
only even one will ever work with a certain MPlayer build.
That seems to me like making stuff more complicated and increasing
the risk that it will only work on little-endian with not really
much of a benefit I can see.

From cehoyos at ag.or.at  Tue Jan 24 22:00:36 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Tue, 24 Jan 2012 21:00:36 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH]Fix FFmpeg tiff RGBA on big endian
References: <201201222240.50214.cehoyos@ag.or.at>
	<F2C08412-DDC4-4C9A-9E11-2135C7ACD7A7@gmx.de>
	<loom.20120123T004039-648@post.gmane.org>
	<20120123210457.GB2395@1und1.de>
Message-ID: <loom.20120124T214853-515@post.gmane.org>

Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:

> On Sun, Jan 22, 2012 at 11:42:10PM +0000, Carl Eugen Hoyos wrote:
> > Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:
> > 
> > > > Attached fixes playback of RGBA tiff on BE.
> > > > Alternative might be to completely remove RGB32 and friends but this
> > > > is the smaller patch...

Patch applied.

> > > What do you mean by the "completely remove" part?
> > 
> > Remove all RGB32 and BGR32 and replace with RGBA, ARGB, BGRA and ABGR.
> > But I would prefer not to do that atm.
> 
> The idea is to have exactly those that FFmpeg actually supports.

We are currently missing 64bit rgb (which works fine with opengl), I wonder if
changing "|64" in libmpcodecs/img_formats.h (and vo_x11.c) to "|128" hast any
side-effects?
Any other vos that support this "rgb endian-swapping"?

> If you removed RGB32 for example you'd have to add both RGBA and
> ABGR (or was it ARGB and BGRA? Whatever) despite the fact that
> only even one will ever work with a certain MPlayer build.

I do not plan to remove them, I just wondered if that would be possible.

> That seems to me like making stuff more complicated and increasing
> the risk that it will only work on little-endian with not really
> much of a benefit I can see.

Agreed,

Carl Eugen


From Dan.Oscarsson at tieto.com  Thu Jan 26 09:42:06 2012
From: Dan.Oscarsson at tieto.com (Dan Oscarsson)
Date: Thu, 26 Jan 2012 09:42:06 +0100
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
In-Reply-To: <1325523559.20740.15.camel@luna.malmo.kicore.net>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
Message-ID: <1327567326.18541.112.camel@valinor.malmo.kicore.net>

m?n 2012-01-02 klockan 17:59 +0100 skrev Dan Oscarsson:
> Hi
> 
> Attached is a new version of my threaded cache code.
> 
> This version does not have a sleep or timed wait in the cache thread.
> configure need more work, I expect some of you know better then me how
> you want it.

Reimar, any comments on my new code from you? No sleep to absolute time
in this version.

   Dan


From ib at wupperonline.de  Thu Jan 26 17:52:13 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 26 Jan 2012 17:52:13 +0100
Subject: [MPlayer-dev-eng] GUI fails with skin PNG read error
In-Reply-To: <4F1D63EC.8020408@gmail.com>
Message-ID: <4f2187ee.06bfa360.bm000@wupperonline.de>

In mplayer-users there are reports that skin loading fails.

And indeed, after I've updated ffmpeg today, I'm experiencing the same error.

I tracked it down to Carl Eugen Hoyos' "Simplify 32bit png decoding" patch of
libavcodec/pngdec.c.

So far, the call to avcodec_decode_video2() in gui/util/bitmap.c returned
PIX_FMT_BGRA which seems to be the right one:

  $ ffprobe /usr/share/mplayer/skins/Clearlooks/main.png
  [...]
  Input #0, image2, from '/usr/share/mplayer/skins/Clearlooks/main.png':
    Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
      Stream #0:0: Video: png, bgra, 340x120, 25 tbr, 25 tbn, 25 tbc
                               ^^^^
Now it suddenly returns PIX_FMT_RGBA which isn't handled in the GUI.

Carl Eugen, what's going wrong?

Ingo

From onemda at gmail.com  Thu Jan 26 18:35:59 2012
From: onemda at gmail.com (Paul B Mahol)
Date: Thu, 26 Jan 2012 17:35:59 +0000
Subject: [MPlayer-dev-eng] GUI fails with skin PNG read error
In-Reply-To: <4f2187ee.06bfa360.bm000@wupperonline.de>
References: <4F1D63EC.8020408@gmail.com>
	<4f2187ee.06bfa360.bm000@wupperonline.de>
Message-ID: <CAPYw7P7vfRd7tc_8zQg1NvW=hcih5rbwZmzVpKJfCCvUHyng3Q@mail.gmail.com>

On 1/26/12, Ingo Brueckl <ib at wupperonline.de> wrote:
> In mplayer-users there are reports that skin loading fails.
>
> And indeed, after I've updated ffmpeg today, I'm experiencing the same
> error.
>
> I tracked it down to Carl Eugen Hoyos' "Simplify 32bit png decoding" patch
> of
> libavcodec/pngdec.c.
>
> So far, the call to avcodec_decode_video2() in gui/util/bitmap.c returned
> PIX_FMT_BGRA which seems to be the right one:
>
>   $ ffprobe /usr/share/mplayer/skins/Clearlooks/main.png
>   [...]
>   Input #0, image2, from '/usr/share/mplayer/skins/Clearlooks/main.png':
>     Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
>       Stream #0:0: Video: png, bgra, 340x120, 25 tbr, 25 tbn, 25 tbc
>                                ^^^^
> Now it suddenly returns PIX_FMT_RGBA which isn't handled in the GUI.
>
> Carl Eugen, what's going wrong?

Png decoder no longer does transcoding ... :)

Gui code is broken.

From tempn at twmi.rr.com  Thu Jan 26 20:03:56 2012
From: tempn at twmi.rr.com (compn)
Date: Thu, 26 Jan 2012 14:03:56 -0500
Subject: [MPlayer-dev-eng] GUI fails with skin PNG read error
In-Reply-To: <CAPYw7P7vfRd7tc_8zQg1NvW=hcih5rbwZmzVpKJfCCvUHyng3Q@mail.gmail.com>
References: <4F1D63EC.8020408@gmail.com>
	<4f2187ee.06bfa360.bm000@wupperonline.de>
	<CAPYw7P7vfRd7tc_8zQg1NvW=hcih5rbwZmzVpKJfCCvUHyng3Q@mail.gmail.com>
Message-ID: <20120126140356.d5343110.tempn@twmi.rr.com>

On Thu, 26 Jan 2012 17:35:59 +0000, Paul B Mahol wrote:
>On 1/26/12, Ingo Brueckl <ib at wupperonline.de> wrote:
>> In mplayer-users there are reports that skin loading fails.
>>
>> And indeed, after I've updated ffmpeg today, I'm experiencing the same
>> error.
>>
>> I tracked it down to Carl Eugen Hoyos' "Simplify 32bit png decoding" patch
>> of
>> libavcodec/pngdec.c.
>>
>> So far, the call to avcodec_decode_video2() in gui/util/bitmap.c returned
>> PIX_FMT_BGRA which seems to be the right one:
>>
>>   $ ffprobe /usr/share/mplayer/skins/Clearlooks/main.png
>>   [...]
>>   Input #0, image2, from '/usr/share/mplayer/skins/Clearlooks/main.png':
>>     Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
>>       Stream #0:0: Video: png, bgra, 340x120, 25 tbr, 25 tbn, 25 tbc
>>                                ^^^^
>> Now it suddenly returns PIX_FMT_RGBA which isn't handled in the GUI.
>>
>> Carl Eugen, what's going wrong?
>
>Png decoder no longer does transcoding ... :)
>
>Gui code is broken.

so you'd have to add the little bit of code to the gui, to swap the
bytes to get bgra from rgba ?

-compn

From onemda at gmail.com  Thu Jan 26 20:06:39 2012
From: onemda at gmail.com (Paul B Mahol)
Date: Thu, 26 Jan 2012 19:06:39 +0000
Subject: [MPlayer-dev-eng] GUI fails with skin PNG read error
In-Reply-To: <20120126140356.d5343110.tempn@twmi.rr.com>
References: <4F1D63EC.8020408@gmail.com>
	<4f2187ee.06bfa360.bm000@wupperonline.de>
	<CAPYw7P7vfRd7tc_8zQg1NvW=hcih5rbwZmzVpKJfCCvUHyng3Q@mail.gmail.com>
	<20120126140356.d5343110.tempn@twmi.rr.com>
Message-ID: <CAPYw7P7LKwoqkBBYPPYta0mBSYDM=rsr6wnsz547h08iiRp1dQ@mail.gmail.com>

On 1/26/12, compn <tempn at twmi.rr.com> wrote:
> On Thu, 26 Jan 2012 17:35:59 +0000, Paul B Mahol wrote:
>>On 1/26/12, Ingo Brueckl <ib at wupperonline.de> wrote:
>>> In mplayer-users there are reports that skin loading fails.
>>>
>>> And indeed, after I've updated ffmpeg today, I'm experiencing the same
>>> error.
>>>
>>> I tracked it down to Carl Eugen Hoyos' "Simplify 32bit png decoding"
>>> patch
>>> of
>>> libavcodec/pngdec.c.
>>>
>>> So far, the call to avcodec_decode_video2() in gui/util/bitmap.c returned
>>> PIX_FMT_BGRA which seems to be the right one:
>>>
>>>   $ ffprobe /usr/share/mplayer/skins/Clearlooks/main.png
>>>   [...]
>>>   Input #0, image2, from '/usr/share/mplayer/skins/Clearlooks/main.png':
>>>     Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
>>>       Stream #0:0: Video: png, bgra, 340x120, 25 tbr, 25 tbn, 25 tbc
>>>                                ^^^^
>>> Now it suddenly returns PIX_FMT_RGBA which isn't handled in the GUI.
>>>
>>> Carl Eugen, what's going wrong?
>>
>>Png decoder no longer does transcoding ... :)
>>
>>Gui code is broken.
>
> so you'd have to add the little bit of code to the gui, to swap the
> bytes to get bgra from rgba ?

adding case for PIX_FMT_RGBA does not work?

From jom at grosjo.net  Thu Jan 26 21:17:28 2012
From: jom at grosjo.net (Joan Moreau)
Date: Thu, 26 Jan 2012 20:17:28 +0000
Subject: [MPlayer-dev-eng] Compilation error on 64 bit machine
Message-ID: <1fb690c6a06c4f7bb1aceb0be8be293a@grosjo.net>

 

Hi, 

I get to the following error : 

./configure --prefix=/usr
--confdir=/etc/mplayer/ --enable-xv --enable-x11
--codecsdir=/usr/lib/codecs/ --enable-win32dll --enable-qtx
--enable-vf-lavfi 

(... ok ) 

make 

(...) 

loader/wrapper.S:
Assembler messages:
loader/wrapper.S:31: Error: `pusha' is not supported
in 64-bit mode
loader/wrapper.S:34: Error: operand type mismatch for
`push'
loader/wrapper.S:38: Error: operand type mismatch for
`push'
loader/wrapper.S:40: Error: operand type mismatch for
`push'
loader/wrapper.S:45: Error: operand type mismatch for
`push'
loader/wrapper.S:46: Error: operand type mismatch for
`push'
loader/wrapper.S:55: Error: `popa' is not supported in 64-bit
mode
loader/wrapper.S:57: Error: invalid instruction suffix for
`pop'
loader/wrapper.S:58: Error: invalid instruction suffix for
`push'
loader/wrapper.S:64: Error: invalid instruction suffix for
`push'
loader/wrapper.S:65: Error: `pusha' is not supported in 64-bit
mode
loader/wrapper.S:68: Error: operand type mismatch for
`push'
loader/wrapper.S:72: Error: operand type mismatch for
`push'
loader/wrapper.S:74: Error: operand type mismatch for
`push'
loader/wrapper.S:79: Error: operand type mismatch for
`push'
loader/wrapper.S:80: Error: operand type mismatch for
`push'
loader/wrapper.S:87: Error: `popa' is not supported in 64-bit
mode
make: *** [loader/wrapper.o] Error 1 

How to solve this ? 

Thanks


Joan 

 

From ib at wupperonline.de  Thu Jan 26 22:28:56 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 26 Jan 2012 22:28:56 +0100
Subject: [MPlayer-dev-eng] GUI fails with skin PNG read error
In-Reply-To: <CAPYw7P7vfRd7tc_8zQg1NvW=hcih5rbwZmzVpKJfCCvUHyng3Q@mail.gmail.com>
Message-ID: <4f21c6fe.4832ac91.bm000@wupperonline.de>

Paul B Mahol wrote on Thu, 26 Jan 2012 17:35:59 +0000:

> Png decoder no longer does transcoding ... :)

So that means you always get four bytes RGBA (in that order) regardless of
the endianness of the machine now?

Ingo

From cehoyos at ag.or.at  Thu Jan 26 23:48:47 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Thu, 26 Jan 2012 22:48:47 +0000 (UTC)
Subject: [MPlayer-dev-eng] Compilation error on 64 bit machine
References: <1fb690c6a06c4f7bb1aceb0be8be293a@grosjo.net>
Message-ID: <loom.20120126T234713-811@post.gmane.org>

Joan Moreau <jom <at> grosjo.net> writes:

> I get to the following error : 

Please post compilation problems to mplayer-users, this list is for development
related discussions only.

> ./configure --prefix=/usr
> --confdir=/etc/mplayer/ --enable-xv --enable-x11
> --codecsdir=/usr/lib/codecs/ --enable-win32dll --enable-qtx
> --enable-vf-lavfi 

Do not use --enable-*, it does not do what you think it does (consider reading
confgure's output).

Carl Eugen


From rectalogic at rectalogic.com  Thu Jan 26 23:50:56 2012
From: rectalogic at rectalogic.com (Andrew Wason)
Date: Thu, 26 Jan 2012 17:50:56 -0500
Subject: [MPlayer-dev-eng] [PATCH] Link failure when using
	--disable-networking
Message-ID: <CAKad06g-PN2WyGT+LLaSFOkGj6smG3nDXmZsGb_f6Qrqd3n6Mg@mail.gmail.com>

Linking fails when mplayer is configured with --disable-networking:


Undefined symbols for architecture x86_64:
  "_ff_network_init", referenced from:
      _sap_read_header in libavformat.a(sapdec.o)
  "_ff_network_close", referenced from:
      _sap_read_header in libavformat.a(sapdec.o)
      _sap_read_close in libavformat.a(sapdec.o)
ld: symbol(s) not found for architecture x86_64

Attached patch disables sap demuxer when networking disabled.

Andrew
-------------- next part --------------
Index: configure
===================================================================
--- configure	(revision 34601)
+++ configure	(working copy)
@@ -3359,7 +3359,7 @@
   def_networking='#undef CONFIG_NETWORKING'
   def_rtpdec='#define CONFIG_RTPDEC 0'
   libavprotocols=$(echo $libavprotocols | sed -e s/GOPHER_PROTOCOL// -e s/HTTP_PROTOCOL// -e s/RTMP_PROTOCOL// -e s/RTP_PROTOCOL// -e s/TCP_PROTOCOL// -e s/UDP_PROTOCOL// -e s/MMSH_PROTOCOL// -e s/MMST_PROTOCOL//)
-  libavdemuxers=$(echo $libavdemuxers | sed -e s/RTSP_DEMUXER// -e s/SDP_DEMUXER// -e s/RTP_DEMUXER//)
+  libavdemuxers=$(echo $libavdemuxers | sed -e s/RTSP_DEMUXER// -e s/SDP_DEMUXER// -e s/SAP_DEMUXER// -e s/RTP_DEMUXER//)
 fi
 echores "$networking"
 

From cehoyos at ag.or.at  Thu Jan 26 23:51:37 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Thu, 26 Jan 2012 22:51:37 +0000 (UTC)
Subject: [MPlayer-dev-eng] GUI fails with skin PNG read error
References: <CAPYw7P7vfRd7tc_8zQg1NvW=hcih5rbwZmzVpKJfCCvUHyng3Q@mail.gmail.com>
	<4f21c6fe.4832ac91.bm000@wupperonline.de>
Message-ID: <loom.20120126T234925-691@post.gmane.org>

Ingo Br?ckl <ib <at> wupperonline.de> writes:

> Paul B Mahol wrote on Thu, 26 Jan 2012 17:35:59 +0000:
> 
> > Png decoder no longer does transcoding ... :)
> 
> So that means you always get four bytes RGBA (in that order) regardless of
> the endianness of the machine now?

=-)
Exactly as they are found in a png file.

I suspect that when FFmpeg's png decoder was written, no scaler argb -> yuv
existed, only rgb32 -> yuv.

Carl Eugen


From cehoyos at ag.or.at  Fri Jan 27 00:17:36 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Thu, 26 Jan 2012 23:17:36 +0000 (UTC)
Subject: [MPlayer-dev-eng]
	=?utf-8?q?=5BPATCH=5D_Link_failure_when_using?=
	=?utf-8?q?=09--disable-networking?=
References: <CAKad06g-PN2WyGT+LLaSFOkGj6smG3nDXmZsGb_f6Qrqd3n6Mg@mail.gmail.com>
Message-ID: <loom.20120127T001650-935@post.gmane.org>

Andrew Wason <rectalogic <at> rectalogic.com> writes:

> Linking fails when mplayer is configured with --disable-networking:

> Attached patch disables sap demuxer when networking disabled.

Patch applied, thank you!

> +  libavdemuxers=$(echo $libavdemuxers | sed -e s/RTSP_DEMUXER// -e
s/SDP_DEMUXER// -e
> s/SAP_DEMUXER// -e s/RTP_DEMUXER//)

Consider sending patches as attachment, this one was broken by your mailer.

Carl Eugen


From jom at grosjo.net  Fri Jan 27 10:31:45 2012
From: jom at grosjo.net (Joan Moreau)
Date: Fri, 27 Jan 2012 09:31:45 +0000
Subject: [MPlayer-dev-eng] Compilation error on 64 bit machine
In-Reply-To: <loom.20120126T234713-811@post.gmane.org>
References: <1fb690c6a06c4f7bb1aceb0be8be293a@grosjo.net>
	<loom.20120126T234713-811@post.gmane.org>
Message-ID: <89db494a4344c3474a0a0ecf49d226fa@grosjo.net>

 

Ok, but the registration process on mplayer-users is broken (no
confirmation email received) 

Can you please help me on that matter ?


Thanks 

JM 

Le 26/01/2012 22:48, Carl Eugen Hoyos a ?crit : 

> Joan
Moreaugrosjo.net> writes:
> 
>> I get to the following error :
> 
>
Please post compilation problems to mplayer-users, this list is for
development
> related discussions only.
> 
>> ./configure --prefix=/usr
--confdir=/etc/mplayer/ --enable-xv --enable-x11
--codecsdir=/usr/lib/codecs/ --enable-win32dll --enable-qtx
--enable-vf-lavfi
> 
> Do not use --enable-*, it does not do what you
think it does (consider reading
> confgure's output).
> 
> Carl Eugen
>

> _______________________________________________
> MPlayer-dev-eng
mailing list
> MPlayer-dev-eng at mplayerhq.hu
>
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
 

From benoit.thebaudeau at advansee.com  Fri Jan 27 14:06:31 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Fri, 27 Jan 2012 14:06:31 +0100 (CET)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Skip
	ID3v2.4	tags.
In-Reply-To: <ebb62d55-08e3-4c27-ac07-a9474e6135a1@zose-store-12>
Message-ID: <ecc5d905-79d6-4064-a736-5cc2e77e1cb7@zose-store-12>

Hi Ingo, Reimar, all,

> > I personally would only perform a footer flag check and accept the
> > 3DI footer
> > if version is 4 or above.
> 
> Done (see attachment).
> 
> > AFAIK valid ID3v2 tag headers start with version 2, so we should
> > not
> > drop
> > this check.
> 
> Done.
> 
> > You already mentioned that ("very, very unlikely to matter") in
> > case
> > len is 0
> > (error or malformed tag), the stream position may be somewhere
> > between ID3v2
> > flags and ID3v2 size, but we step 4.
> 
> The 4 that are stepped here are "ID3" and the major version. At least
> one
> more byte has been read after these by id3v2_tag_size(), so hdr has
> to be
> fully refilled, hence step = 4. id3v2_tag_size() could be modified to
> fill
> hdr before stepping, which would limit the number of dropped bytes,
> but
> that would be ugly, and not very useful as Reimar said.
> 
> > If len > demuxer->movi_end - demuxer->movi_start, it cannot be
> > decided
> > whether this is a malformed footer or just audio data. There should
> > be
> > neither an error message nor a len setting in this case. (Same, if
> > the
> > corresponding and valid ID3 header cannot be found.)
> 
> No. In both cases, the ID3 footer signature is perfectly verified, so
> there
> is no chance it can be audio data, and it has to be some leftover of
> an ID3
> tag edition. Both cases are really errors because they prove that the
> stream
> is malformed. IMO, it's better to drop the final MP3 frame than to
> play
> garbage.
> 
> > Error (wouldn't warning or hint have been sufficient here?)
> 
> These are stream structure errors, so they should be reported with
> the message
> level that MPlayer usually sets for such events. "Bad wav header
> length" and
> "truncated extradata" are similar events that are also logged as
> errors, so
> there is no reason to do something different for ID3 tags.
> 
> > messages,
> > if any,
> > should be translatable.
> 
> What does it imply for MPlayer? I don't see anything special done for
> the
> two similar messages I mentioned above.
> 
> > I'm not sure whether it is worth the effort to check the whole 3DI
> > footer
> > data against the ID3 header data. According to the specs they must
> > be
> > copies.
> 
> They're supposed to be, but what if they're not? You have already
> made me
> add a lot of checks for impossible cases if streams are
> spec-compliant.
> We should either support only spec-compliant streams, or stick to
> 'work
> around all possible garbage'.

Ping?

> > BTW, after applying I would change stream_seek(s,s->end_pos-128) to
> > stream_seek(s,demuxer->movi_end-128) to avoid problems if the
> > sequence of
> > checks ever changes or a new check will be prepended.
> 
> Yes, and "demuxer->movi_end = stream_tell(s)-3;" could be replaced
> with
> "demuxer->movi_end -= 128;".

Done in the extra patch attached.

Best regards,
Beno?t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1-demux-audio-use-movi-end.patch
Type: text/x-patch
Size: 738 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120127/566b59a5/attachment.bin>

From Reimar.Doeffinger at gmx.de  Sun Jan 29 11:54:39 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 29 Jan 2012 11:54:39 +0100
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
In-Reply-To: <1325581084.4662.13.camel@luna.malmo.kicore.net>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
	<20120102220635.2329D1F02C9@localhost.localdomain>
	<1325581084.4662.13.camel@luna.malmo.kicore.net>
Message-ID: <20120129105438.GA2178@1und1.de>

On Tue, Jan 03, 2012 at 09:58:04AM +0100, Dan Oscarsson wrote:
> > Set s->do_work to 0 while holding the lock inside the if, also to avoid race
> > conditions.
> 
> Quite often it is so, but not in this case (unless my analysis is
> wrong). When cache thread sets do_work to 0 above, it is going to do
> some work (reading data and command processing), so it does not matter
> if do_work is set to 1 by main thread and that is erased by this setting
> to zero.

I don't think that will work, on some architectures there is no
guarantee when writes will happen, so the following is possible without
locks:

do_work = 0 is executed
cache processing is done
on a different CPU, do_work = 1 is executed and due to cache pressures
flushed out into RAM
only now is the write of do_work = 0 executed.

End result is a deadlock.
Note that this _should_ not be possible on x86 since it has quite a
strict coherency model (even though it is still confusing and risky
to rely on such stuff).
However in the case of your code you run into another issue:
you did not mark do_work as volatile, thus since the assignment is
outside the locks, the _compiler_ is perfectly free to actually move
the assignment to after the cache reading.

From Reimar.Doeffinger at gmx.de  Sun Jan 29 11:55:29 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 29 Jan 2012 11:55:29 +0100
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
In-Reply-To: <1327567326.18541.112.camel@valinor.malmo.kicore.net>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
	<1327567326.18541.112.camel@valinor.malmo.kicore.net>
Message-ID: <20120129105529.GB2178@1und1.de>

On Thu, Jan 26, 2012 at 09:42:06AM +0100, Dan Oscarsson wrote:
> m?n 2012-01-02 klockan 17:59 +0100 skrev Dan Oscarsson:
> > Hi
> > 
> > Attached is a new version of my threaded cache code.
> > 
> > This version does not have a sleep or timed wait in the cache thread.
> > configure need more work, I expect some of you know better then me how
> > you want it.
> 
> Reimar, any comments on my new code from you? No sleep to absolute time
> in this version.

Sorry, was busy with FFmpeg stuff and this threading stuff is incredibly
difficult to review, even more so if someone else has written it.

From Dan.Oscarsson at tieto.com  Sun Jan 29 18:20:11 2012
From: Dan.Oscarsson at tieto.com (Dan Oscarsson)
Date: Sun, 29 Jan 2012 18:20:11 +0100
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
In-Reply-To: <20120129105438.GA2178@1und1.de>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
	<20120102220635.2329D1F02C9@localhost.localdomain>
	<1325581084.4662.13.camel@luna.malmo.kicore.net>
	<20120129105438.GA2178@1und1.de>
Message-ID: <1327857611.6093.14.camel@luna.malmo.kicore.net>

s?n 2012-01-29 klockan 11:54 +0100 skrev Reimar D?ffinger:
> 
> I don't think that will work, on some architectures there is no
> guarantee when writes will happen, so the following is possible without
> locks:

> Note that this _should_ not be possible on x86 since it has quite a
> strict coherency model (even though it is still confusing and risky
> to rely on such stuff).

Yes, I missed the cache coherency problem of which people are very
uncertain of on the net. It looks like I have to have all setting and
checking of do_work within the mutex lock to ensure cache coherency.
But even there people on the net are somewhat uncertain about cache
coherency.
Though, it could probably be done more efficient on x86.

This also means that "atomic operations" have to ensure cache coherency.

> However in the case of your code you run into another issue:
> you did not mark do_work as volatile, thus since the assignment is
> outside the locks, the _compiler_ is perfectly free to actually move
> the assignment to after the cache reading.

Yes, fixed.

Attached is a new version.

   Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cache-thread.diff
Type: text/x-patch
Size: 3030 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120129/3714aa8d/attachment.bin>

From Reimar.Doeffinger at gmx.de  Sun Jan 29 20:05:56 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 29 Jan 2012 20:05:56 +0100
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
In-Reply-To: <1327857611.6093.14.camel@luna.malmo.kicore.net>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
	<20120102220635.2329D1F02C9@localhost.localdomain>
	<1325581084.4662.13.camel@luna.malmo.kicore.net>
	<20120129105438.GA2178@1und1.de>
	<1327857611.6093.14.camel@luna.malmo.kicore.net>
Message-ID: <20120129190556.GA16071@1und1.de>

On Sun, Jan 29, 2012 at 06:20:11PM +0100, Dan Oscarsson wrote:
> s?n 2012-01-29 klockan 11:54 +0100 skrev Reimar D?ffinger:
> > 
> > I don't think that will work, on some architectures there is no
> > guarantee when writes will happen, so the following is possible without
> > locks:
> 
> > Note that this _should_ not be possible on x86 since it has quite a
> > strict coherency model (even though it is still confusing and risky
> > to rely on such stuff).
> 
> Yes, I missed the cache coherency problem of which people are very
> uncertain of on the net. It looks like I have to have all setting and
> checking of do_work within the mutex lock to ensure cache coherency.
> But even there people on the net are somewhat uncertain about cache
> coherency.
> Though, it could probably be done more efficient on x86.
> 
> This also means that "atomic operations" have to ensure cache coherency.
> 
> > However in the case of your code you run into another issue:
> > you did not mark do_work as volatile, thus since the assignment is
> > outside the locks, the _compiler_ is perfectly free to actually move
> > the assignment to after the cache reading.
> 
> Yes, fixed.
> 
> Attached is a new version.

Unfortunately the approach in itself breaks the
stream_time_pos/stream_time_len update mechanism so the core
might get severely outdated values of these.

From anssi.hannula at iki.fi  Mon Jan 30 00:30:19 2012
From: anssi.hannula at iki.fi (Anssi Hannula)
Date: Mon, 30 Jan 2012 01:30:19 +0200
Subject: [MPlayer-dev-eng] [PATCH] lavcac3enc: make the filter buildable
	with shared FFmpeg
Message-ID: <1327879819-4743-1-git-send-email-anssi.hannula@iki.fi>

Add some local definitions and a bit rate array to make FFmpeg private
headers and symbols unneeded, allowing lavcac3enc to be built with
shared FFmpeg.

This also fixes the issue that the filter code expects the FFmpeg
private definition AC3_MAX_CHANNELS to be the maximum number of
"logical" channels to be encoded into AC-3, while it actually specifies
the maximum channel count in the bitstream, which may include a coupling
channel which is not an actual full audio channel. The issue is fixed by
making the local AC3_MAX_CHANNELS to have the value of 6, which the
FFmpeg private header also had before the addition of coupling support
in 2011.
---

Dunno if this is something that is wanted or not, but in case of NAK the
different expectation of AC3_MAX_CHANNELS should be fixed in some other
way (e.g. by introducing a new local #define).

 Makefile              |    4 ++--
 libaf/af.c            |    4 +---
 libaf/af_lavcac3enc.c |   17 +++++++++++++----
 3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index 8e80b9e..b5fedcb 100644
--- a/Makefile
+++ b/Makefile
@@ -70,6 +70,7 @@ SRCS_COMMON-$(FAAD)                  += libmpcodecs/ad_faad.c
 SRCS_COMMON-$(FASTMEMCPY)            += libvo/aclib.c
 SRCS_COMMON-$(FFMPEG)                += av_helpers.c                \
                                         av_opts.c                   \
+                                        libaf/af_lavcac3enc.c       \
                                         libaf/af_lavcresample.c     \
                                         libmpcodecs/ad_ffmpeg.c     \
                                         libmpcodecs/ad_spdif.c      \
@@ -86,8 +87,7 @@ SRCS_COMMON-$(FFMPEG)                += av_helpers.c                \
 SRCS_COMMON-$(CONFIG_VF_LAVFI)      +=  libmpcodecs/vf_lavfi.c
 
 # These filters use private headers and do not work with shared FFmpeg.
-SRCS_COMMON-$(FFMPEG_A)              += libaf/af_lavcac3enc.c    \
-                                        libmpcodecs/vf_fspp.c    \
+SRCS_COMMON-$(FFMPEG_A)              += libmpcodecs/vf_fspp.c    \
                                         libmpcodecs/vf_mcdeint.c \
                                         libmpcodecs/vf_qp.c      \
                                         libmpcodecs/vf_spp.c     \
diff --git a/libaf/af.c b/libaf/af.c
index 7cc62ee..8a4dd55 100644
--- a/libaf/af.c
+++ b/libaf/af.c
@@ -72,10 +72,8 @@ static const af_info_t * const filter_list[] = {
 #endif
    &af_info_volnorm,
    &af_info_extrastereo,
-#ifdef CONFIG_FFMPEG_A
-   &af_info_lavcac3enc,
-#endif
 #ifdef CONFIG_FFMPEG
+   &af_info_lavcac3enc,
    &af_info_lavcresample,
 #endif
    &af_info_sweep,
diff --git a/libaf/af_lavcac3enc.c b/libaf/af_lavcac3enc.c
index f66d2cb..5f650c4 100644
--- a/libaf/af_lavcac3enc.c
+++ b/libaf/af_lavcac3enc.c
@@ -33,9 +33,18 @@
 #include "av_helpers.h"
 
 #include "libavcodec/avcodec.h"
-#include "libavcodec/ac3.h"
 #include "libavutil/intreadwrite.h"
 
+#define AC3_MAX_CHANNELS        6
+#define AC3_FRAME_SIZE          1536
+#define AC3_MAX_CODED_FRAME_SIZE 3840
+#define AC3_BIT_RATES_COUNT     19
+
+static const int ac3_bit_rates[AC3_BIT_RATES_COUNT] = {
+    32000, 40000, 48000, 56000, 64000, 80000, 96000, 112000, 128000, 160000,
+    192000, 224000, 256000, 320000, 384000, 448000, 512000, 576000, 640000
+};
+
 // Data for specific instances of this filter
 typedef struct af_ac3enc_s {
     struct AVCodec        *lavc_acodec;
@@ -117,10 +126,10 @@ static int control(struct af_instance_s *af, int cmd, void *arg)
         if (s->bit_rate < 1000)
             s->bit_rate *= 1000;
         if (s->bit_rate) {
-            for (i = 0; i < 19; ++i)
-                if (ff_ac3_bitrate_tab[i] * 1000 == s->bit_rate)
+            for (i = 0; i < AC3_BIT_RATES_COUNT; ++i)
+                if (ac3_bit_rates[i] == s->bit_rate)
                     break;
-            if (i >= 19) {
+            if (i >= AC3_BIT_RATES_COUNT) {
                 mp_msg(MSGT_AFILTER, MSGL_WARN, "af_lavcac3enc unable set unsupported "
                        "bitrate %d, use default bitrate (check manpage to see "
                        "supported bitrates).\n", s->bit_rate);
-- 
1.7.7.2


From Dan.Oscarsson at tieto.com  Mon Jan 30 09:48:34 2012
From: Dan.Oscarsson at tieto.com (Dan Oscarsson)
Date: Mon, 30 Jan 2012 09:48:34 +0100
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
In-Reply-To: <20120129190556.GA16071@1und1.de>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
	<20120102220635.2329D1F02C9@localhost.localdomain>
	<1325581084.4662.13.camel@luna.malmo.kicore.net>
	<20120129105438.GA2178@1und1.de>
	<1327857611.6093.14.camel@luna.malmo.kicore.net>
	<20120129190556.GA16071@1und1.de>
Message-ID: <1327913314.6607.7.camel@valinor.malmo.kicore.net>

s?n 2012-01-29 klockan 20:05 +0100 skrev Reimar D?ffinger:
> > Attached is a new version.
> 
> Unfortunately the approach in itself breaks the
> stream_time_pos/stream_time_len update mechanism so the core
> might get severely outdated values of these.

This because cache_mainloop no longer times out and executes
cache_execute_control regularly?

>From what I can see it is just demux_mpg.c, stream_dvd.c and
stream_dvdnav.c that uses STREAM_CTRL_GET_CURRENT_TIME or
STREAM_CTRL_GET_TIME_LENGTH. Unfortunate to have to add a timed sleep
just for those few formats.

   Dan


From thomas-forum at orgis.org  Mon Jan 30 10:52:27 2012
From: thomas-forum at orgis.org (Thomas Orgis)
Date: Mon, 30 Jan 2012 10:52:27 +0100
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20111213225605.1028790c@orgis.org>
References: <20110920181954.GA32134@1und1.de>
	<20111116114458.GA11607@pool.informatik.rwth-aachen.de>
	<20111121174916.659a838b@orgis.org>
	<20111122204625.GA4952@pool.informatik.rwth-aachen.de>
	<20111202093029.4ac0cf37@orgis.org>
	<20111202200747.198678be@orgis.org>
	<20111211145821.GB26790@pool.informatik.rwth-aachen.de>
	<20111213225605.1028790c@orgis.org>
Message-ID: <20120130105227.51b8c032@orgis.org>

Am Tue, 13 Dec 2011 22:56:05 +0100
schrieb Thomas Orgis <thomas-forum at orgis.org>: 

> On the actual topic of my investigations... I am still hunting the
> reason why gcc produces inferior binary from mpg123's sources compared
> to mp3lib... even when the concerned code is the same (well,
> basically...). This will be a christmas/new year thing... but hopefully
> I can resolve it.

Just a heads-up, I'm spending spare minutes on this as I can. I am
documenting my efforts on

	http://mpg123.org/beating_mp3lib_in_mplayer/

Suggestions welcome...


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120130/2615cb8c/attachment.asc>

From tempn at twmi.rr.com  Mon Jan 30 16:44:58 2012
From: tempn at twmi.rr.com (compn)
Date: Mon, 30 Jan 2012 10:44:58 -0500
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20120130105227.51b8c032@orgis.org>
References: <20110920181954.GA32134@1und1.de>
	<20111116114458.GA11607@pool.informatik.rwth-aachen.de>
	<20111121174916.659a838b@orgis.org>
	<20111122204625.GA4952@pool.informatik.rwth-aachen.de>
	<20111202093029.4ac0cf37@orgis.org>
	<20111202200747.198678be@orgis.org>
	<20111211145821.GB26790@pool.informatik.rwth-aachen.de>
	<20111213225605.1028790c@orgis.org>
	<20120130105227.51b8c032@orgis.org>
Message-ID: <20120130104458.107f0f84.tempn@twmi.rr.com>

On Mon, 30 Jan 2012 10:52:27 +0100, Thomas Orgis wrote:
>Am Tue, 13 Dec 2011 22:56:05 +0100
>schrieb Thomas Orgis <thomas-forum at orgis.org>: 
>
>> On the actual topic of my investigations... I am still hunting the
>> reason why gcc produces inferior binary from mpg123's sources compared
>> to mp3lib... even when the concerned code is the same (well,
>> basically...). This will be a christmas/new year thing... but hopefully
>> I can resolve it.
>
>Just a heads-up, I'm spending spare minutes on this as I can. I am
>documenting my efforts on
>
>	http://mpg123.org/beating_mp3lib_in_mplayer/
>
>Suggestions welcome...

does adding 'fast' e.g. mplayer -ao pcm:fast:file=/dev/null
do anything for testing?

-compn

From tempn at twmi.rr.com  Mon Jan 30 16:50:25 2012
From: tempn at twmi.rr.com (compn)
Date: Mon, 30 Jan 2012 10:50:25 -0500
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20120130105227.51b8c032@orgis.org>
References: <20110920181954.GA32134@1und1.de>
	<20111116114458.GA11607@pool.informatik.rwth-aachen.de>
	<20111121174916.659a838b@orgis.org>
	<20111122204625.GA4952@pool.informatik.rwth-aachen.de>
	<20111202093029.4ac0cf37@orgis.org>
	<20111202200747.198678be@orgis.org>
	<20111211145821.GB26790@pool.informatik.rwth-aachen.de>
	<20111213225605.1028790c@orgis.org>
	<20120130105227.51b8c032@orgis.org>
Message-ID: <20120130105025.7e587b9b.tempn@twmi.rr.com>

On Mon, 30 Jan 2012 10:52:27 +0100, Thomas Orgis wrote:
>Am Tue, 13 Dec 2011 22:56:05 +0100
>schrieb Thomas Orgis <thomas-forum at orgis.org>: 
>
>> On the actual topic of my investigations... I am still hunting the
>> reason why gcc produces inferior binary from mpg123's sources compared
>> to mp3lib... even when the concerned code is the same (well,
>> basically...). This will be a christmas/new year thing... but hopefully
>> I can resolve it.
>
>Just a heads-up, I'm spending spare minutes on this as I can. I am
>documenting my efforts on
>
>	http://mpg123.org/beating_mp3lib_in_mplayer/
>
>Suggestions welcome...

btw this might be stupid idea, but why not just include two copies of
mpg123? our fork and new svn. then we can drop support for our fork and
just focus on mpg123. k-6 users will always have -ac mp3 and the rest
of us will enjoy svn version.

not much reason to spend time optimizing for old cpu i say :P

but this is just me bikesheding, so tilt windmills, tilt!

-compn

From Reimar.Doeffinger at gmx.de  Mon Jan 30 19:00:17 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 30 Jan 2012 19:00:17 +0100
Subject: [MPlayer-dev-eng] [PATCH] threaded cache, round 2
In-Reply-To: <1327913314.6607.7.camel@valinor.malmo.kicore.net>
References: <1325523559.20740.15.camel@luna.malmo.kicore.net>
	<20120102220635.2329D1F02C9@localhost.localdomain>
	<1325581084.4662.13.camel@luna.malmo.kicore.net>
	<20120129105438.GA2178@1und1.de>
	<1327857611.6093.14.camel@luna.malmo.kicore.net>
	<20120129190556.GA16071@1und1.de>
	<1327913314.6607.7.camel@valinor.malmo.kicore.net>
Message-ID: <20120130180017.GA3017@1und1.de>

On Mon, Jan 30, 2012 at 09:48:34AM +0100, Dan Oscarsson wrote:
> s?n 2012-01-29 klockan 20:05 +0100 skrev Reimar D?ffinger:
> > > Attached is a new version.
> > 
> > Unfortunately the approach in itself breaks the
> > stream_time_pos/stream_time_len update mechanism so the core
> > might get severely outdated values of these.
> 
> This because cache_mainloop no longer times out and executes
> cache_execute_control regularly?

Yes.

> From what I can see it is just demux_mpg.c, stream_dvd.c and
> stream_dvdnav.c that uses STREAM_CTRL_GET_CURRENT_TIME or
> STREAM_CTRL_GET_TIME_LENGTH. Unfortunate to have to add a timed sleep
> just for those few formats.

You can make it pass those stream controls completely through the
cache for pthreads I guess, if the performance cost is not too high.

From thomas-forum at orgis.org  Tue Jan 31 00:55:21 2012
From: thomas-forum at orgis.org (Thomas Orgis)
Date: Tue, 31 Jan 2012 00:55:21 +0100
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20120130104458.107f0f84.tempn@twmi.rr.com>
References: <20110920181954.GA32134@1und1.de>
	<20111116114458.GA11607@pool.informatik.rwth-aachen.de>
	<20111121174916.659a838b@orgis.org>
	<20111122204625.GA4952@pool.informatik.rwth-aachen.de>
	<20111202093029.4ac0cf37@orgis.org>
	<20111202200747.198678be@orgis.org>
	<20111211145821.GB26790@pool.informatik.rwth-aachen.de>
	<20111213225605.1028790c@orgis.org>
	<20120130105227.51b8c032@orgis.org>
	<20120130104458.107f0f84.tempn@twmi.rr.com>
Message-ID: <20120131005521.46aac06c@orgis.org>

Am Mon, 30 Jan 2012 10:44:58 -0500
schrieb compn <tempn at twmi.rr.com>: 

> does adding 'fast' e.g. mplayer -ao pcm:fast:file=/dev/null
> do anything for testing?

I did not observe much of an effect there. And, most important: This
should not change anything in the relation of mp3lib and libmpg123,
should it?


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120131/2ea27600/attachment.asc>

From thomas-forum at orgis.org  Tue Jan 31 01:02:52 2012
From: thomas-forum at orgis.org (Thomas Orgis)
Date: Tue, 31 Jan 2012 01:02:52 +0100
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20120130105025.7e587b9b.tempn@twmi.rr.com>
References: <20110920181954.GA32134@1und1.de>
	<20111116114458.GA11607@pool.informatik.rwth-aachen.de>
	<20111121174916.659a838b@orgis.org>
	<20111122204625.GA4952@pool.informatik.rwth-aachen.de>
	<20111202093029.4ac0cf37@orgis.org>
	<20111202200747.198678be@orgis.org>
	<20111211145821.GB26790@pool.informatik.rwth-aachen.de>
	<20111213225605.1028790c@orgis.org>
	<20120130105227.51b8c032@orgis.org>
	<20120130105025.7e587b9b.tempn@twmi.rr.com>
Message-ID: <20120131010252.497f0ae0@orgis.org>

Am Mon, 30 Jan 2012 10:50:25 -0500
schrieb compn <tempn at twmi.rr.com>: 

> btw this might be stupid idea, but why not just include two copies of
> mpg123? our fork and new svn.

Well, that's what is there already: the mp3lib fork as included code
and the libmpg123 binding. The starting topic of this thread was if
mp3lib can be dropped.

> then we can drop support for our fork and
> just focus on mpg123. k-6 users will always have -ac mp3 and the rest
> of us will enjoy svn version.
> 
> not much reason to spend time optimizing for old cpu i say :P

Well, I agree in principle. But, since I already invested time in
getting the test setup running, I really would like to know why the
largely identical mp3lib code is compiled into more efficient binaries.

I don't want people accusing me of dropping some useful enhancement
present in mp3lib but not current mpg123 proper. Especially when I
don't understand where it comes from:-/

In practice, people don't bother that much with mp3 decoding
performance nowadays, I suppose, but as mpg123 maintainer I do bother;-)


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120131/8c663b2b/attachment.asc>

From tempn at twmi.rr.com  Tue Jan 31 02:19:56 2012
From: tempn at twmi.rr.com (compn)
Date: Mon, 30 Jan 2012 20:19:56 -0500
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20120131010252.497f0ae0@orgis.org>
References: <20110920181954.GA32134@1und1.de>
	<20111116114458.GA11607@pool.informatik.rwth-aachen.de>
	<20111121174916.659a838b@orgis.org>
	<20111122204625.GA4952@pool.informatik.rwth-aachen.de>
	<20111202093029.4ac0cf37@orgis.org>
	<20111202200747.198678be@orgis.org>
	<20111211145821.GB26790@pool.informatik.rwth-aachen.de>
	<20111213225605.1028790c@orgis.org>
	<20120130105227.51b8c032@orgis.org>
	<20120130105025.7e587b9b.tempn@twmi.rr.com>
	<20120131010252.497f0ae0@orgis.org>
Message-ID: <20120130201956.c8a1dd0f.tempn@twmi.rr.com>

On Tue, 31 Jan 2012 01:02:52 +0100, Thomas Orgis wrote:
>Am Mon, 30 Jan 2012 10:50:25 -0500
>schrieb compn <tempn at twmi.rr.com>: 
>
>> btw this might be stupid idea, but why not just include two copies of
>> mpg123? our fork and new svn.
>
>Well, that's what is there already: the mp3lib fork as included code
>and the libmpg123 binding. The starting topic of this thread was if
>mp3lib can be dropped.
>
>> then we can drop support for our fork and
>> just focus on mpg123. k-6 users will always have -ac mp3 and the rest
>> of us will enjoy svn version.
>> 
>> not much reason to spend time optimizing for old cpu i say :P
>
>Well, I agree in principle. But, since I already invested time in
>getting the test setup running, I really would like to know why the
>largely identical mp3lib code is compiled into more efficient binaries.
>
>I don't want people accusing me of dropping some useful enhancement
>present in mp3lib but not current mpg123 proper. Especially when I
>don't understand where it comes from:-/
>
>In practice, people don't bother that much with mp3 decoding
>performance nowadays, I suppose, but as mpg123 maintainer I do bother;-)

i sent that mail before i read all of your page. i didnt realize mpg123
had gotten so bloated! hahaha :P

-compn

From rodrigo at sdfg.com.ar  Tue Jan 31 20:55:15 2012
From: rodrigo at sdfg.com.ar (Rodrigo Campos)
Date: Tue, 31 Jan 2012 16:55:15 -0300
Subject: [MPlayer-dev-eng] [PATCH] Use "-nocache" option in
	TOOLS/midentify.sh
Message-ID: <20120131195515.GA15201@sdfg.com.ar>

Hi,

Attached there is a simple patch that adds the "-nocache" option to the script
midentify.sh in TOOLS/.

There are long delays with some hosts and using the cache only makes it take
longer, when we don't really need the cache. For example, from my ISP at
Argentina, using this option reduce *a lot* the time needed to run the script
with certain hosts:

(before the patch)

$ time TOOLS/midentify.sh http://58.69.143.152:8080
ID_AUDIO_ID=0
ID_FILENAME=http://58.69.143.152:8080
ID_DEMUXER=audio
ID_AUDIO_FORMAT=85
ID_AUDIO_BITRATE=40000
ID_AUDIO_RATE=22050
ID_AUDIO_NCH=0
ID_START_TIME=0.00
ID_LENGTH=-0.00
ID_SEEKABLE=0
ID_CHAPTERS=0
ID_AUDIO_BITRATE=40000
ID_AUDIO_RATE=22050
ID_AUDIO_NCH=2
ID_AUDIO_CODEC=mp3
ID_EXIT=EOF

real	0m33.409s
user	0m0.068s
sys	0m0.032s


(after the patch)

$ time TOOLS/midentify.sh http://58.69.143.152:8080
ID_AUDIO_ID=0
ID_FILENAME=http://58.69.143.152:8080
ID_DEMUXER=audio
ID_AUDIO_FORMAT=85
ID_AUDIO_BITRATE=40000
ID_AUDIO_RATE=22050
ID_AUDIO_NCH=0
ID_START_TIME=0.00
ID_LENGTH=-0.00
ID_SEEKABLE=0
ID_CHAPTERS=0
ID_AUDIO_BITRATE=40000
ID_AUDIO_RATE=22050
ID_AUDIO_NCH=2
ID_AUDIO_CODEC=mp3
ID_EXIT=EOF

real	0m5.340s
user	0m0.052s
sys	0m0.044s


The time also improves for some local streams (as expected, I think :))


Attached (inline) it is the path against r34643 (HEAD when  writing this email)
taken from the project root. If there is anything I should change in the patch,
or you want me to try something else, please let me know :)






Thanks a lot,

Rodrigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-no-console-option-tools-midentify.sh.diff
Type: text/x-diff
Size: 441 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120131/e8003cf6/attachment.bin>

From tempn at twmi.rr.com  Tue Jan 31 21:22:16 2012
From: tempn at twmi.rr.com (compn)
Date: Tue, 31 Jan 2012 15:22:16 -0500
Subject: [MPlayer-dev-eng] [PATCH] Use "-nocache" option in
 TOOLS/midentify.sh
In-Reply-To: <20120131195515.GA15201@sdfg.com.ar>
References: <20120131195515.GA15201@sdfg.com.ar>
Message-ID: <20120131152216.8e4225a7.tempn@twmi.rr.com>

On Tue, 31 Jan 2012 16:55:15 -0300, Rodrigo Campos wrote:
>Hi,
>
>Attached there is a simple patch that adds the "-nocache" option to the script
>midentify.sh in TOOLS/.

wonder why you have such a large cache setup anyways...

btw i think -noidx will speed avi over http too, but that may break
something.

-compn

From rodrigo at sdfg.com.ar  Tue Jan 31 21:28:33 2012
From: rodrigo at sdfg.com.ar (Rodrigo Campos)
Date: Tue, 31 Jan 2012 17:28:33 -0300
Subject: [MPlayer-dev-eng] [PATCH] Use "-nocache" option in
 TOOLS/midentify.sh
In-Reply-To: <20120131152216.8e4225a7.tempn@twmi.rr.com>
References: <20120131195515.GA15201@sdfg.com.ar>
	<20120131152216.8e4225a7.tempn@twmi.rr.com>
Message-ID: <20120131202833.GB15201@sdfg.com.ar>

On Tue, Jan 31, 2012 at 03:22:16PM -0500, compn wrote:
> On Tue, 31 Jan 2012 16:55:15 -0300, Rodrigo Campos wrote:
> >Hi,
> >
> >Attached there is a simple patch that adds the "-nocache" option to the script
> >midentify.sh in TOOLS/.
> 
> wonder why you have such a large cache setup anyways...

It's the default with debian marillat packages, if I'm not wrong.

> 
> btw i think -noidx will speed avi over http too, but that may break
> something.

Ohh, I haven't used it with videos. And I really don't know if it may break
something :S





Thanks a lot,
Rodrigo

From despicere at gmail.com  Mon Jan 16 20:56:24 2012
From: despicere at gmail.com (paulus)
Date: Mon, 16 Jan 2012 19:56:24 -0000
Subject: [MPlayer-dev-eng] mplayer
Message-ID: <4F1480E7.10204@gmail.com>

Hi, Developers!
Mplayer best player! :)

Please add to wishlist:
1. In mplayer-gui add option in the settings "Only allow one instance" 
(Put single instance mode into replace and play mode).

2. In mplayer Shortcuts do not work with Cyrillic keyboard layout. Need 
to switch to English. Fix please Bug #720202.
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/720202

3. Fix please Bug #78884
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/78884