Hi,
I noticed that mplayer's video playback starts to skip
if I do some serious copying or grepping on the disk
with movie being played from.
nice helps, but does not eliminate the problem.
I guessed that this is a problem with mplayer
failing to read next portion of input data in time,
so I used Jens's ionice.c from
Documentation/block/ioprio.txt
I am using it this:
ionice -c1 -n0 -p<mplayer pid>
but so far I don't see any effect from using it.
mplayer still skips.
Does anybody have an experience in this?
--
vda
Hi,
Have you followed this:
http://www.mplayerhq.hu/DOCS/HTML/en/rtc.html
Not that it will help, I don't know, but it could be to do with timing.
Nick
On 18/08/06, Denis Vlasenko <[email protected]> wrote:
> Hi,
>
> I noticed that mplayer's video playback starts to skip
> if I do some serious copying or grepping on the disk
> with movie being played from.
>
> nice helps, but does not eliminate the problem.
> I guessed that this is a problem with mplayer
> failing to read next portion of input data in time,
> so I used Jens's ionice.c from
> Documentation/block/ioprio.txt
>
> I am using it this:
>
> ionice -c1 -n0 -p<mplayer pid>
>
> but so far I don't see any effect from using it.
> mplayer still skips.
>
> Does anybody have an experience in this?
> --
> vda
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
08/18/2006 07:37 PM, Denis Vlasenko wrote/a écrit:
> Hi,
>
> I noticed that mplayer's video playback starts to skip
> if I do some serious copying or grepping on the disk
> with movie being played from.
>
> nice helps, but does not eliminate the problem.
> I guessed that this is a problem with mplayer
> failing to read next portion of input data in time,
> so I used Jens's ionice.c from
> Documentation/block/ioprio.txt
>
> I am using it this:
>
> ionice -c1 -n0 -p<mplayer pid>
>
> but so far I don't see any effect from using it.
> mplayer still skips.
>
> Does anybody have an experience in this?
Hello
IOnice only works with CFQ, have you checked that you are using the CFQ
IO scheduler?
# cat /sys/block/hda/queue/scheduler #put the name of YOUR harddisk
In case it's not the default IO scheduler, you can change it with:
# echo cfq > /sys/block/hda/queue/scheduler
My two cents...
See you,
Eric
On Friday 18 August 2006 20:01, Eric Piel wrote:
> 08/18/2006 07:37 PM, Denis Vlasenko wrote/a écrit:
> > Hi,
> >
> > I noticed that mplayer's video playback starts to skip
> > if I do some serious copying or grepping on the disk
> > with movie being played from.
> >
> > nice helps, but does not eliminate the problem.
> > I guessed that this is a problem with mplayer
> > failing to read next portion of input data in time,
> > so I used Jens's ionice.c from
> > Documentation/block/ioprio.txt
> >
> > I am using it this:
> >
> > ionice -c1 -n0 -p<mplayer pid>
> >
> > but so far I don't see any effect from using it.
> > mplayer still skips.
> >
> > Does anybody have an experience in this?
> Hello
>
> IOnice only works with CFQ, have you checked that you are using the CFQ
> IO scheduler?
> # cat /sys/block/hda/queue/scheduler #put the name of YOUR harddisk
>
> In case it's not the default IO scheduler, you can change it with:
> # echo cfq > /sys/block/hda/queue/scheduler
Thanks!
It helps. mplayer skips much less, but still some skipping is present.
I experimented with forcing entire file to be present in the
pagecache, and in this case mplayer almost never skips.
Looks like mplayer have very little tolerance for reads
randomly taking more time to read input stream.
However, I then looked into the mplayer's source
(I wondered why it doesn't do read buffering itself)...
The code is, um, less than pretty.
--
vda
>
>It helps. mplayer skips much less, but still some skipping is present.
Try with -ao alsa, then it should skip less, or at least, if it skip, skip
back so that less audio is lost.
When playing audio-only files, it is always wise to specify e.g. -cache 320
which proved to be a good value for my workloads.
>I experimented with forcing entire file to be present in the
>pagecache, and in this case mplayer almost never skips.
>
>Looks like mplayer have very little tolerance for reads
>randomly taking more time to read input stream.
>
>However, I then looked into the mplayer's source
>(I wondered why it doesn't do read buffering itself)...
>
>The code is, um, less than pretty.
Jan Engelhardt
--
On Sun, 2006-08-20 at 10:22 +0200, Jan Engelhardt wrote:
> >
> >It helps. mplayer skips much less, but still some skipping is present.
>
> Try with -ao alsa, then it should skip less, or at least, if it skip, skip
> back so that less audio is lost.
> When playing audio-only files, it is always wise to specify e.g. -cache 320
> which proved to be a good value for my workloads.
>
Only with the very latest versions of mplayer does ALSA work at all.
It's unusable here because it resets the auduio stream on each underrun
rather than simply ignoring them.
Lee
On Sunday 20 August 2006 16:43, Lee Revell wrote:
> On Sun, 2006-08-20 at 10:22 +0200, Jan Engelhardt wrote:
> > >
> > >It helps. mplayer skips much less, but still some skipping is present.
> >
> > Try with -ao alsa, then it should skip less, or at least, if it skip, skip
> > back so that less audio is lost.
> > When playing audio-only files, it is always wise to specify e.g. -cache 320
> > which proved to be a good value for my workloads.
> >
>
> Only with the very latest versions of mplayer does ALSA work at all.
> It's unusable here because it resets the auduio stream on each underrun
> rather than simply ignoring them.
I'm not sure that I ever got an underrun (may check it
for you if you need that, how to do it?),
but mplayer -ao alsa is working for me just fine.
I eliminated skips due to CPU and disk using
nice and -cache 8000. I still can make it skip
when my KDE background picture is changing.
I think that these skips are caused by the X server.
It has no prioritization for request handling and
thus it does not paint mplayer output fast enough:
it needs to repaint background and semi-transparent
konsole(s), and that is taking a few seconds at least.
This is probably aggravated by serializing nature of Xlib,
according to:
http://en.wikipedia.org/wiki/XLib
http://en.wikipedia.org/wiki/XCB
--
vda
On Sun, 2006-08-20 at 18:43 +0200, Denis Vlasenko wrote:
> On Sunday 20 August 2006 16:43, Lee Revell wrote:
> > On Sun, 2006-08-20 at 10:22 +0200, Jan Engelhardt wrote:
> > > >
> > > >It helps. mplayer skips much less, but still some skipping is present.
> > >
> > > Try with -ao alsa, then it should skip less, or at least, if it skip, skip
> > > back so that less audio is lost.
> > > When playing audio-only files, it is always wise to specify e.g. -cache 320
> > > which proved to be a good value for my workloads.
> > >
> >
> > Only with the very latest versions of mplayer does ALSA work at all.
> > It's unusable here because it resets the auduio stream on each underrun
> > rather than simply ignoring them.
>
> I'm not sure that I ever got an underrun (may check it
> for you if you need that, how to do it?),
> but mplayer -ao alsa is working for me just fine.
>
You probably don't get underruns because your machine is fast. Mine is
a 600Mhz Via board, but I know this is an mplayer ALSA driver bug
because it works perfectly with -ao oss, and because mplayer's ALSA
driver maintainer has acknowledged the bug.
> I eliminated skips due to CPU and disk using
> nice and -cache 8000. I still can make it skip
> when my KDE background picture is changing.
>
I also must run mplayer at nice -20 for it to be usable.
> I think that these skips are caused by the X server.
> It has no prioritization for request handling and
> thus it does not paint mplayer output fast enough:
> it needs to repaint background and semi-transparent
> konsole(s), and that is taking a few seconds at least.
>
> This is probably aggravated by serializing nature of Xlib,
> according to:
>
> http://en.wikipedia.org/wiki/XLib
> http://en.wikipedia.org/wiki/XCB
I think the problem is also due to mplayer's faulty design. It should
be multithreaded and use RT threads for the time sensitive work, like
all professional AV applications and many other consumer players do.
Lee
>> > > >It helps. mplayer skips much less, but still some skipping is present.
>> > >
>> > > Try with -ao alsa, then it should skip less, or at least, if it skip, skip
>> > > back so that less audio is lost.
>> > > When playing audio-only files, it is always wise to specify e.g. -cache 320
>> > > which proved to be a good value for my workloads.
>> >
>> > Only with the very latest versions of mplayer does ALSA work at all.
>> > It's unusable here because it resets the auduio stream on each underrun
>> > rather than simply ignoring them.
>>
>> I'm not sure that I ever got an underrun (may check it
>> for you if you need that, how to do it?),
>> but mplayer -ao alsa is working for me just fine.
>
>You probably don't get underruns because your machine is fast. Mine is
>a 600Mhz Via board, but I know this is an mplayer ALSA driver bug
>because it works perfectly with -ao oss, and because mplayer's ALSA
>driver maintainer has acknowledged the bug.
Good to hear. mpg123 and ogg123 all behave nice (without nice, ionice, or
other priority adjustments) even under disk load.
>I think the problem is also due to mplayer's faulty design. It should
>be multithreaded and use RT threads for the time sensitive work, like
Heh sounds like you need MplayerXP.
>all professional AV applications and many other consumer players do.
Jan Engelhardt
--
> > I eliminated skips due to CPU and disk using
> > nice and -cache 8000. I still can make it skip
> > when my KDE background picture is changing.
> >
>
> I also must run mplayer at nice -20 for it to be usable.
>
> > I think that these skips are caused by the X server.
> > It has no prioritization for request handling and
> > thus it does not paint mplayer output fast enough:
> > it needs to repaint background and semi-transparent
> > konsole(s), and that is taking a few seconds at least.
> >
> > This is probably aggravated by serializing nature of Xlib,
> > according to:
> >
> > http://en.wikipedia.org/wiki/XLib
> > http://en.wikipedia.org/wiki/XCB
>
> I think the problem is also due to mplayer's faulty design. It should
> be multithreaded and use RT threads for the time sensitive work, like
> all professional AV applications and many other consumer players do.
RT - yes, multithreaded - unsure. Witness how squid manages to
serve hundreds of simultaneous streams using just a single process.
Multithreading seems cool on the first glance and it is easier to code
than clever O_NONBLOCK/select/poll/etc stuff. However,
on single-CPU boxes, which are still a majority, multithreading
just incurs context switching penalty. It cannot magically
make CPU do more work in a unit of time.
--
vda
Le mardi 22 ao?t 2006 ? 18:26 +0200, Denis Vlasenko a ?crit :
> > I think the problem is also due to mplayer's faulty design. It should
> > be multithreaded and use RT threads for the time sensitive work, like
> > all professional AV applications and many other consumer players do.
>
> RT - yes, multithreaded - unsure. Witness how squid manages to
> serve hundreds of simultaneous streams using just a single process.
>
> Multithreading seems cool on the first glance and it is easier to code
> than clever O_NONBLOCK/select/poll/etc stuff. However,
> on single-CPU boxes, which are still a majority, multithreading
> just incurs context switching penalty. It cannot magically
> make CPU do more work in a unit of time.
The problem with mplayer is latency more than throughput, and for that
multithreading is king. Squid can get away with a 100ms delay between
two packets, mplayer can't.
Xav
>
>RT - yes, multithreaded - unsure. Witness how squid manages to
>serve hundreds of simultaneous streams using just a single process.
So apache (with the most common MPMs) is badly designed ;-)
Jan Engelhardt
--