Hans-Jürgen Ficker <[EMAIL PROTECTED]> writes:
> After some code cleanup[1], I could send the patch to anyone who wants
> it (maybe to the list?).
>
Finally, I have the patch ready. It's against xine-lib 1.1.1, but
should also apply cleanly to the current CVS version.
--- xine-lib-1.1.1/src/demuxers/demux_mpeg_pes.c 2005-02-06 16:26:17.000000000 +0100
+++ xine-lib-1.1.1-rate/src/demuxers/demux_mpeg_pes.c 2006-02-05 23:55:14.000000000 +0100
@@ -27,7 +27,10 @@
* This code might also decode normal MPG files.
*
*/
-
+
+#define ESTIMATE_RATE_FIXED 1
+#define USE_ILL_ADVISED_ESTIMATE_RATE_INITIALLY 1
+
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
@@ -1104,10 +1107,10 @@
*/
/* How many *sucessful* PTS samples do we take? */
-#define MAX_SAMPLES 5
+#define MAX_SAMPLES 10
/* How many times we read blocks before giving up. */
-#define MAX_READS 30
+#define MAX_READS 50
/* TRUNCATE x to the nearest multiple of y. */
#define TRUNC(x,y) (((x) / (y)) * (y))
@@ -1124,6 +1127,7 @@
int count=0; /* Number of sucessful PTS found so far */
int rate=0; /* The return rate value */
int stream_id;
+ int idx;
/* We can't estimate by sampling if we don't thave the ability to
randomly access the and more importantly reset after accessessing. */
@@ -1133,7 +1137,8 @@
mpeg_length= this->input->get_length (this->input);
step = TRUNC((mpeg_length/MAX_SAMPLES), 2048);
if (step <= 0) step = 2048; /* avoid endless loop for tiny files */
- pos = step;
+/* pos = step; */
+ pos = 0;
/* At this point "pos", and "step" are a multiple of blocksize and
they should continue to be so throughout.
@@ -1146,6 +1151,15 @@
p = buf->content; /* len = this->mnBlocksize; */
+ /* It seems that an mpeg frame doesn't always begin on multiples
+ of 2048... */
+ idx = 0;
+ while ((p[0] || p[1] || (p[2] != 0x01) || ((p[3] & 0xF0) != 0xE0))
+ && (idx < (2048 - 13))) {
+ idx += 1;
+ p += 1;
+ }
+
if (p[3] == 0xBA) { /* program stream pack header */
is_mpeg1 = (p[4] & 0x40) == 0;
@@ -1165,7 +1179,9 @@
xprintf (this->stream->xine, XINE_VERBOSITY_DEBUG,
"demux_mpeg_pes: error %02x %02x %02x (should be 0x000001) \n", p[0], p[1], p[2]);
buf->free_buffer (buf);
- return rate;
+/* return rate; */
+ pos += (off_t) 2048;
+ continue;
}
stream_id = p[3];
@@ -1244,7 +1260,6 @@
break;
}
-}
lprintf("est_rate=%d\n",rate);
return rate;
I discovered another issue in xine. After seeking, sometimes you have
to wait 10 seconds for the next seek. It looks like a racing
condition, where a 10 second timeout is triggered. The following patch
sets this timeout to 0.5 seconds.
--- xine-lib-1.1.1/src/xine-engine/xine.c 2005-10-30 03:18:35.000000000 +0100
+++ xine-lib-1.1.1-rate/src/xine-engine/xine.c 2006-02-05 16:34:59.000000000 +0100
@@ -1098,8 +1098,14 @@
struct timeval tv;
struct timespec ts;
gettimeofday(&tv, NULL);
- ts.tv_sec = tv.tv_sec + 10;
- ts.tv_nsec = tv.tv_usec * 1000;
+/* ts.tv_sec = tv.tv_sec + 10; */
+/* ts.tv_nsec = tv.tv_usec * 1000; */
+ ts.tv_sec = tv.tv_sec;
+ ts.tv_nsec = tv.tv_usec * 1000 + 500000000;
+ if (ts.tv_nsec >= 1000000000) {
+ ts.tv_sec += 1;
+ ts.tv_nsec -= 1000000000;
+ }
pthread_cond_timedwait(&stream->first_frame_reached, &stream->first_frame_lock, &ts);
}
pthread_mutex_unlock (&stream->first_frame_lock);
Both patches are ugly hacks, which make xine and freevo play
together, until someone really fixes the problems.
Best regards,
Hans-Jürgen
--
"I used to think that I was stupid, and then I met philosophers."
-- (Terry Pratchett, Small Gods)
