[ILUG] Streaming video

[Brian Foster]

  | 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
 possible.

cheers!
	-blf-

  | 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