theora dev - Jan 2005 - Re: PC-based video server

On Wednesday 26 January 2005 02:20 pm, Andrey wrote:
> >  I've seen pretty good quality theora format video at less than 1
Mbps.
>
> What was the resolution/frame/rate/type of the movie.
A sample video can be downloaded, using BitTorrent, from www.theora.org. 
 It's in the Contents section on the left side of the page, and labeled
"CC
 spots." What you actually get is three short videos for a total of about
20
 MBytes. In my opinion, the video named "Mixtape.small.ogg" is the
best.
 It's a two minute, fun video that uses 8.8 MB of storage, and looks to be
 about 352x240 and 30 fps.
> What you mean by "after" - buffering the streams in memory? I
thought OS
> can handle it on it's own.
I meant that the video from camera1 would be saved at 00:00, again at 00:10,
and every ten minutes on an automated basis.  The video from camera2 would be
saved at 00:01, again at 00:11, and so on.  So, video from camera2 would be
saved one minute "after" video from camera1.  Spacing the timing of
saving
the video from the different network camera is just a way to avoid trying to
write too much data to the hard drive(s) at the same time.
> Initially that server should do 2 (or 3) parallel jobs:
> 1 - uninterruptedly store all the high-res video on disks (DVR);
That's relatively easy.
> 2 - serve lower resolution video from live data in parallel with recording
> with minimal delay.
This is the tricky part because, as you describe below, the theora format
video needs to be transcoded into something like MJPEG format AND streamed at
the same time.  I really don't know what kind of CPU power you need to do
that.  If it was a single network camera, I suspect that a high-end PC today
could do the job, but 10-20 network cameras, that almost sounds like a
cluster, or a rack, of PCs to me.

I think the only way you can proceed is to record some video with your
 network camera while the FPGA encodes it into theora format.  It could be as
 simple as someone walking or running in front of the camera.  That will give
 you the bits per second and bytes per minute for the quality that your
 customers require.  Then you will also be able to determine how much
 processing power you need to convert that theora format video realtime into
 MJPEG format.
> Actually it will be possible to use 2 different servers for these 2 tasks
> if needed - anyway there will be multicast stream.
>
> and only the 3rd job will be to serve the stored video.
>
> > If people wanted to watch the live video, they would just go to the
> > address of that network camera, right?  So, the PC-based video server
> > would not be required to do much, if any, streaming video.  People who
> > want to watch the stored video could just download the desired files,
> > right?
>
> Not exactly - and here is the main point.
>
> At the first stage all this high-performance GNU/Linux + Theora stuff is
> confined to server+cameras. External interface of the system as a whole
> will be MJPEG (other standard software codecs possible), "server
push"
> that majority of the video management software used in videosecuruity
> business - the software they are currently using and don't want to get
rid
> of immediately. So the proposed server can be plugged in their system and
> behave as a set of regular network cameras, not as a server+cameras.
>
> That, from one side, will not scare off customers who got used to some
> system immediately and will significanbtly simplify our job - security
> systems have much more than cameras alone (i.e. other sensors) and many
> companies work for a long time in this area and I don't think it is
> possible to design something similar in short time and using limited
> resources.
>
> So I consider such server as intermediate step to get Theora into this
> application area. It will be then next step to get rid of intermediate
> formats.
Considering the constraints of the legacy software your customers are using,
what you are considering makes sense to me.  I hope all of it can be done at
a practical price.  Eliminating the intermediate formats would simply things
a lot.  Good luck.
John

-------------------------------------------------------

> This is the tricky part because, as you describe below, the theora format
> video needs to be transcoded into something like MJPEG format AND streamed
> at
> the same time.  I really don't know what kind of CPU power you need to
do
> that.  If it was a single network camera, I suspect that a high-end PC
> today
> could do the job, but 10-20 network cameras, that almost sounds like a
> cluster, or a rack, of PCs to me.
Yes, playing MJPEG from our current model 313 cameras requires 2.5-3GHz
processor to keep pace with the camera. But I am not talking about
recoding everything - I'm counting that in most cases there will be just
one operator who will watch the cameras (remember - full resolution
recording is still running), so the total number of pixels he/she sees at
any given moment will be not more that the computer screen. So I propose
to recompress an send as multicast just DC components from each of 10-20
streams as 256*192 small windows. That should be easy - as you do not need
even huffman-decode all the incoming Theora stream - just Huffman-decode
(no resource-hungry IDCT) DC (first) dta from each stream and jump to he
next frame. And you have to read all DC components from Theora anyway,
even if you need subwindow. Then, in addition to o these 10-20 multicast
MJPEG 256x192 streams server can recode several more according to "digital
PTZ" request - selected window and resolution. Maybe just 1-2-4-8 to use
abbreviated DCT.
>
> I think the only way you can proceed is to record some video with your
>  network camera while the FPGA encodes it into theora format.  It could be
> as
>  simple as someone walking or running in front of the camera.  That will
> give
>  you the bits per second and bytes per minute for the quality that your
>  customers require.  Then you will also be able to determine how much
>  processing power you need to convert that theora format video realtime
> into
>  MJPEG format.
Unfortunately I just don't have this time. When testing FPGA so far I was
manually (using several programs and cat running on the PC after wget the
data from the camera)  making ogg encapsulation and adding Theore headers
to the frame data.
And I need to provide response to RFI in just 2 days :-(
> Considering the constraints of the legacy software your customers are 
using,
> what you are considering makes sense to me.  I hope all of it can be
done at
> a practical price.  Eliminating the intermediate formats would simply
things
> a lot.  Good luck.
> John
I believe that requirement is quite common and will be useful in any case,
even if not for these particular customer:
1. most use some kind of legacy (or new - but still of the same kind)
software and that will likely stay so for some time;
2. Storing all videodata locally (in cluster) and resending farther only
some portion will be useful even if that resending will later be also in
the Theora format - it can just combine the requirement of saving all the
data and not saturating the networks in big systems - anyway human
operators have limited field of view and can monitor just a fraction of
the whole data.
3. It is really difficult to implement everything it a short time. So
don't caring about user interface and non-camera issues of complete
security systems can make the job doable.