[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Encoder ideas]



hi -

chema, this is excellent.  

lloyd, can you work with obie to put this sort of thing up on the web
site under documentation and also point to it under FAQ.  I suppose the
on-line archive of the mailing list would be good enough to get started.

obie, under the documentation tab on the website, we should have several
different things of documentation.  The detailed doc you have there now
from the old mash site is one item, but we should have a pointer to the
developers archive with a search mechanism (wes can you help with
this?).

AND, obie the web site looks fantastic.  I like the new logo and the
entire look&feel.  well done.
	Larry
-- 
Professor Lawrence A. Rowe          Internet:  Rowe@BMRC.Berkeley.EDU
Computer Science Division - EECS       Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776            URL: http://bmrc.berkeley.edu/~larry


sanjay@cs.cmu.edu wrote:
> I am just beginning to familiarize myself with the mash code,
> and I don't know too much about video coding. I found Chema's
> documentation very useful.
A similar version of the encoding document for the 
decoding case is in preparation currently. I'll 
broadcast (or should I say multicast :) once it's 
finished. 

> 1. What is the video format expected by the encoder? Is this
>    encoder dependent? 
The way this works is that capture devices suggest 
which format they can provide frames of, while 
encoders decide which format to use. 

Every VideoCaptureXXX class has a parallel XXXDevice 
and XXXScanner class (check any of the 
mash-1/video/video-xxx.cc). The latter checks if a 
VideoCaptureXXX object has sense in your box (i.e., 
if you have the capture card). 

If you have the card, XXXScanner fills a variable called 
attr that contains the possible attributes supported 
by the capture device, and then creates a new XXXDevice 
object. Once you've decided which attributes you want to 
use in the capture device, you call XXXDevice::create() 
with them. You can also change some the attributes 
on-the-fly. 

Be careful: some encoders can use only a fixed 
color-subsampling scheme and size. For example, H.261 
requires 4:2:0 subsampling and CIF or QCIF sizes. In 
other cases you should be able to select both the 
color subsampling and size you prefer. 

> Is it always YUV? Further, is it CIF,
>    or 4:1:1 ?
VideoCapture/XXX objects usually provide YUV frames. I 
think there is the possibility of bypassing the encoder, 
which you may want to use, for example, if you have a 
capture card that provides encoded frames directly. 

The size? One of the suggestions XXXScanner gives you in 
the attr variable is the sizes it supports. For example, 
the Video4Linux one appends attr the string 
"size { small large cif }". 


> 2. Does the video capture device usually result in video of
>    a fixed format? If it can result in different formats, how is
>    that handled?
If with "format" you mean either the size or the color 
subsampling scheme, the answer is you can choose both. 
In vic, for example, there are three radiobuttons 
where you can select the size you prefer. The color 
subsampling is decided in general by the encoder, 
though. 


> 3. If the format of the video capture device is different from the
>    format of the encoder, how does vic handle it?
Again: every video capture device suggests what it can 
provide (color subsampling and size). If a encoder 
needs some configuration the former cannot provide, 
the radiobutton that represents the encoder in vic 
gets disabled. 

Hope this helps. 
-Chema