[ILUG] Streaming video
blf at blf.utvinternet.ie
Wed Sep 21 18:56:32 IST 2005
| Date: Wed, 21 Sep 2005 10:23:17 +0100
| From: P at draigBrady.com
| Niall O Broin wrote:
| > On 21 Sep 2005, at 08:44, Andres Jimenez wrote:
| >> I don't think "Streaming video" is an accurate title for the thread,
| >> because you are only exporting a Samba share....
| > I did actually think about that, and you're possibly right - but from my
| > POV as a watcher of said video, I'm having problems streaming them from
| > the server, even though reading may be a more correct term. But what is
| > streaming but reading anyway? And what's in a name?
| Well a lot really. Streaming is not just reading. There is
| generally a streaming protocol that is used to efficiently
| fill the network connection and the buffers at each end.
| I.E. Quality Of Service parameters are actively monitored.
if I may elaborate on this ... in a past life, I was
one step removed from A/V streaming issues, and in my
current job I'm a few more steps removed ....
first, when there are playback problems, the usual
recommendation is to continue playing the audio
seamlessly. drop video frames if you have to, but
continue with the audio. try to never drop audio
frames! the reason is the human ear is much more
preceptive that the eye, and will notice astonishingly
small/short glitches in audio. the eye is more
tolerant, and the odd dropped frame is no big deal.
( of course, the problem in this thread is lots of
video frames are vanishing or being delayed, so it
becomes noticeable. )
the difference between streaming and reading can
be thought of as the difference between the player
pulling (reading) and the server pushing (streaming)
the frames to be played.
an even better way to think of it is the model A/V
playback designers often(?) use: frames are pulled
through the entire system, from DVD/server/whatever
through the decoders et.al. by the audio speakers.
the sound has to be delivered to the speakers at
a very precise fixed rate. the decoded samples
must be available at predicatable times. that timing
constraint must be met, so it is the governing factor
in pulling the frames from the origin through the
entire system into the speakers.
reading from the disk is only loosely connected with
this. taking ready-in-time frames served up over a
streaming connection is, as Pádraig explains, a very
different thing. indeed, often in streaming systems
there isn't a read/write loop in the traditional sense,
but an dequeue/enqueue loop or even H/W assist, with
deadlines and feedback to adjust the QoS to the extent
| Over a filesystem interface your player (xine or vlc)
| may be making assumptions. I.E. they're tuned for
| working with hard disks so the more you deviate from 30MB/s
| or so the choppier the video will become.
| It may be possible to tune the sizes of the reads/seeks/buffers
| in the players to something more appropriate?
| Also the samba server will have a lot to do with things,
| if it is not buffering and servicing that buffer appropriately.
| There are a multitude or things to consider there. [ ... ]
Experienced (20+ yrs) kernel/software Eng: | Brian Foster Montpellier,
• Unix, embedded, &tc; • Linux; • doc; | blf at utvinternet.ie FRANCE
• IDL, automated testing, process, &tc. | Stop E$$o (ExxonMobile)!
Résumé (CV) http://www.blf.utvinternet.ie | http://www.stopesso.com
More information about the ILUG