A little bit of background for those who have run the patched Mplayer
with the -v 1 (Linux) or -verbose 1 flag (windows).
The live audio stream is made up of packets which are usually about
116ms apart. Unlike a file where data is buffered, a live stream data
is in sync with the live broadcast. If data is being delayed by the
network, it will be dropped by the server. These dropped packets
caused the choppy/garbled audio and you can see it happens frequently.
Typically only one or two packets are dropped so you will see messages
about gaps of 232-234 or 348-350 but occasionally larger values such as
1742 and my patch handles these gaps. The packets are grouped in blocks
of 16 and I had made an assumption (from observation) that the server
never dropped more than 15 packets at a time. This assumption is wrong
and I believe is the cause of the remaining problem. Unfortunately I
forgot to put in a diagnostic message in the patch to pick up this
situation.
To check for this you can change the patched code to add the additional
"if" and mp_msg after the existing mp_msg for "Packets Lost"
Code:
--------------------
if (((timestamp - priv->a_pts) > priv->ms_per_packet_safety) &&
((timestamp - priv->a_pts) < priv->ms_per_block))
mp_msg(MSGT_DEMUX,MSGL_V, "Packets lost: timestamp gap Actual %d msec
Expected %d Flags %02X\n", timestamp-priv->a_pts, priv->ms_per_packet,flags);
if (timestamp - priv->a_pts > priv->ms_per_block)
mp_msg(MSGT_DEMUX,MSGL_V, "Packets timestamp gap greater than block Actual %d
msec Expected %d Flags %02X\n", timestamp-priv->a_pts,
priv->ms_per_packet,flags);
if ((timestamp - priv->a_pts) < (priv->ms_per_packet-2)) //
This is a diagnostic msg - allow a margin of 2 based on observations of streams
to reduce "noise"
mp_msg(MSGT_DEMUX,MSGL_V, "Packet timestamp gap too short Actual %d msec
Expected %d Flags %02X\n", timestamp-priv->a_pts, priv->ms_per_packet,flags);
--------------------
The gaps where the packets have been dropped have to be filled so I
fill it with old sound samples which result in reverb or choppy sounds.
I cannot splice the streams because this will reduce the amount of data
cached and eventually Mplayer will have no data cached. This issue is
stopping me as I have logged a 25774msec gap on a BBC7 stream.
If you are interested in the live audio tech - RFC 3119 gives the basis
on an MP3 live stream which is v. similar to the RA stream.
--
bpa
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/plugins
