Technology and Trends
 Video for Linux Mailing List Archives
  
List:       linux-video
Subject:    [video4linux] v4l2 and video-editing tools?
From:       "Rene K. Mueller" <kiwi () the-labs ! com>
Date:       1998-11-26 6:52:48


Mark, and V4L2 Listers,

Mark, you may remember me as the one who extended your gif tool
to gifmerge :-) I finally went to put all my tools at
	http://the-labs.com/

Introduction for V4L2 list-members: I just started to discover the 
v4l2 thing four weeks ago. My main interest is developing programs like 
PBMPLUS for audio and video. So far RawSoundStudio is such a package 
(source not yet released), and now I'm investigating whether I use an
AVI alike video-format which is simple enough to implement to 
record, play and create videos (ie from still pics).

Another long-term idea is to write a tcl/tk or perltk app which
would be like AdobePremiere, which would use GIMP plugins to render
effects, this very long-term.

So, I'm not really into kernel programming, but rather interested
in the user API of v4l2.

My question goes out, is there someone already writing something
like an AVI library? Or an MPEG-1/4 library which could go hand
in hand with the v4l2?

Check	
	http://the-labs.com/VideoLab/
and
	http://the-labs.com/RawVideoStudio/

So far I'm still checking out all resources regarding video-formats,
and search for the easiest and most extentable one to write the
toolset asap. Mark, you are most knowledgable in all the formats,
would you consider to build things on AVI, MJPEG or MPEG4, I speak about 
a "native" video-format (simple enough to code fast), which could 
then always be converted into more sophisticated formats. Anyway,
not sure if this has been already discussed, if so I'm would be
grateful someone let me know.

Regards,

Rene

-- 
----
    /\     Rene K. Mueller <kiwi@the-labs.com> <kiwi@span.ch>
  //  \\      Phone +49 1 261 4743 - HyperMedia Designer & Programmer
  \\  //      http://the-labs.com/ - The Labs: Graphic & Web Tools,
    \/                               Corporate Web Consulting

List:       linux-video
Subject:    Re: [video4linux] v4l2 and video-editing tools?
From:       Bill Dirks <bill.dirks () rendition ! com>
Date:       1998-11-26 4:00:19

Rene K. Mueller wrote:
> Another long-term idea is to write a tcl/tk or perltk app which
> would be like AdobePremiere, which would use GIMP plugins to render
> effects, this very long-term.
> So, I'm not really into kernel programming, but rather interested
> in the user API of v4l2.

Well, you're just in time. We're just starting to define it! :-)
V4L2 right now is a set of kernel driver specs. I created V4L2 with the
hope that it would form the basis for higher-level APIs and applications
such as video editing, internet broadcasting, and others, for Linux. I'm
glad to find now someone interested in the application side.


> So far I'm still checking out all resources regarding video-formats,
> and search for the easiest and most extentable one to write the
> toolset asap. Mark, you are most knowledgable in all the formats,
> would you consider to build things on AVI, MJPEG or MPEG4, I speak about
> a "native" video-format (simple enough to code fast), which could
> then always be converted into more sophisticated formats. Anyway,
> not sure if this has been already discussed, if so I'm would be
> grateful someone let me know.

Personally, I would like to see something along the lines of AVI. In
other words, a compression-algorithm neutral format for streaming any
kind of data into. Also there could be something like MJPEG which is a
compression spec as well as a file format spec.

Bill.

List:       linux-video
Subject:    Re: [video4linux] v4l2 and video-editing tools?
From:       podlipec () BayNetworks ! COM (Mark Podlipec)
Date:       1998-11-26 4:57:57

Bill Dirks wrote:
> 
> Rene K. Mueller wrote:
> 
> > So far I'm still checking out all resources regarding video-formats,
> > and search for the easiest and most extentable one to write the
> > toolset asap. Mark, you are most knowledgable in all the formats,
> > would you consider to build things on AVI, MJPEG or MPEG4, I speak about
> > a "native" video-format (simple enough to code fast), which could
> > then always be converted into more sophisticated formats. Anyway,
> > not sure if this has been already discussed, if so I'm would be
> > grateful someone let me know.
> 
> Personally, I would like to see something along the lines of AVI. In
> other words, a compression-algorithm neutral format for streaming any
> kind of data into. Also there could be something like MJPEG which is a
> compression spec as well as a file format spec.

It comes down to either AVI or Quicktime if you want to choose an
existing format(which may be a good idea if you want the rest
of the world to view it). Plus it's less work to adopt(or adapt :)
an already existin format.

While Quicktime is more flexible it's also more complex and is *not*
good for capturing live video/audio.  The reason is the header increases
in size with the number of frames.  

On the mac, you'd write the header to one file(the .rsrc) and the
data to another(.data). So that wasn't a problem.  You could always
make is "single-fork" later - which was essentially cat'ing them together.

No reason you couldn't do the same thing I suppose.

On a PC, the common solution for capturing video to a quicktime file
of unknown length is to reserve a bunch of space in front of the capture
file and if the header grows beyond it, you just keep the header in memory
and tack it on the end. The space up front becomes a "skip" or "free" chunk
and is wasted space.

I vote for AVI.  It's pretty straight forward if you just want
video/audio.  IMO, it's main drawback is that there is a fixed frame rate.

And certainly we can always modify it to better suite our needs and 
quite possibly do so without breaking it for W95/Mac users.

For example, create a frame_info chunk that contains per frame
timing(probably a small one each time it changed).  Mac/W95 readers 
should ignore chunks they don't understand. Just a thought.

Mark

List:       linux-video
Subject:    Re: [video4linux] v4l2 and video-editing tools?
From:       Alan Cox < alan () cymru ! net>
Date:       1998-11-26 11:37:01

> It comes down to either AVI or Quicktime if you want to choose an

Quicktime has too many patent problems. I've not checked AVI

The format that hits disk should be codec dependant anyway. But it would
be good to have a couple of standard forms always in the lib - some kind
of AVI format and the real time jpeg stuff seem the obvious candidates

List:       linux-video
Subject:    [video4linux] Re: Video4Linux 2
From:       Bill Dirks <bill.dirks () rendition ! com>
Date:       1998-11-30 23:11:26
[Download message RAW]

[I'll forward this to the list. -Bill]

--
Bill Dirks wrote:
> I'm already fairly familiar with VfW. We're heading for something
> vaguely like that, but more flexible and full-featured. People are
> talking about adopting AVI or an extended AVI-like format for a Linux
> standard video file format. Others would like to see Quicktime in that
> role.
 
My opinions on the matter:
- Stick with AVI.  The majority of the installed (and future) Linux base
  is on the x86 platform.  The VAST majority of software packages for
  the PC (everything from mid-level non-linear video editing, to 3D
  packages from the $3500 3D Studio MAX) deals with AVI files, not
  Quicktime.
 
- Most capture cards (at least, ones that mortals can afford) generate
  AVI data.  Common examples:  Iomega Buz, Matrox Marvel/Rainbow Runner,
  Miro DC20/30/30+/50+.  All of these capture an MJPEG-compressed AVI
  stream.
 
Using Quicktime (or anything more elaborate) introduces added overhead,
headache, etc.  It's MUCH easier to code applications dealing with
standard AVI files (think of each frame as simply a HHHxYYY x-bit
BMP file)...
 
If this is ever to get off the ground, follow rule #1 of software
design:
Keep it Stupid, Simple!  (Er...)
 
-----------------------------------
------------------------------------------
Chris Harshman, sysadmin           |  The avalanche has already started.
harshman@paradigm.uor.edu          |  It's too late for the pebbles to
vote.
http://paradigm.uor.edu/~harshman  |                   -- Kosh

List:       linux-video
Subject:    Re: [video4linux] Re: Video4Linux 2
From:       "Rene K. Mueller" < kiwi () the-labs ! com>
Date:       1998-12-01 6:44:38


> My opinions on the matter:
> - Stick with AVI.  The majority of the installed (and future) Linux base
>   is on the x86 platform.  The VAST majority of software packages for
>   the PC (everything from mid-level non-linear video editing, to 3D
>   packages from the $3500 3D Studio MAX) deals with AVI files, not
>   Quicktime.

Ok, if we go into AVI direction, what about (c) of our cloned friend
Gates holds on AVI? There are several different codecs used, and most 
are (tm) to some companies, I guess Mark (XAnim) can tell us more.
Mark, do you think we could adapt few public-domain codecs, plus
write some by ourselves (ie. Justin's RTJpeg codec), maybe even
some may (bummer) write win95/98 drivers for it ;-) to push a public
domain or GPL based video-codec in the windows-world as well?

One advantage would be, if the wintv cards become more stable (I
really dislike when my system freezes upon a /dev/bttv open-call
and I have to boot and fix my file-system) then some other companies
could become interested to produces cards for Linux and a 
semi-professional market which sticks with UNIX, maybe a bit far 
fetched to think already about this.

> - Most capture cards (at least, ones that mortals can afford) generate
>   AVI data.  Common examples:  Iomega Buz, Matrox Marvel/Rainbow Runner,
>   Miro DC20/30/30+/50+.  All of these capture an MJPEG-compressed AVI
>   stream.

But it's not sure if the JPEG-encoder (Justin or LM33 developers may
answer this) matters, and I'm not certain if MJPEG are compatible
to each other, and if you get documentation on it.

I must admit, I tend to invent my own file-format and then
write a simple converter to write MJPEG, MPEG, or AVI then, than
adapting AVI per-se. If you have good arguments against it, let
me know. But having a library for encoding/decoding AVI on GPL
would be nice, but has someone (c) on AVI itself (not talking
about the codecs running under it)?

Rene

-- 
----
    /\     Rene K. Mueller  
  //  \\      Phone +49 1 261 4743 - HyperMedia Designer & Programmer
  \\  //      http://the-labs.com/ - The Labs: Graphic & Web Tools,
    \/                               Corporate Web Consulting

List:       linux-video
Subject:    Re: [video4linux] Re: Video4Linux 2
From:       podlipec () BayNetworks ! COM (Mark Podlipec)
Date:       1998-12-01 2:13:28

Rene K. Mueller wrote:
> 
> > My opinions on the matter:
> > - Stick with AVI.  The majority of the installed (and future) Linux base
> >   is on the x86 platform.  The VAST majority of software packages for
> >   the PC (everything from mid-level non-linear video editing, to 3D
> >   packages from the $3500 3D Studio MAX) deals with AVI files, not
> >   Quicktime.
> 
> Ok, if we go into AVI direction, what about (c) of our cloned friend
> Gates holds on AVI? There are several different codecs used, and most 
> are (tm) to some companies, I guess Mark (XAnim) can tell us more.
> Mark, do you think we could adapt few public-domain codecs, plus
> write some by ourselves (ie. Justin's RTJpeg codec), maybe even
> some may (bummer) write win95/98 drivers for it ;-) to push a public
> domain or GPL based video-codec in the windows-world as well?

Obtaining a compression license is usually more difficult than for
decompression.  Codec companies usually make their money on the
compression side of things and but want the decompression market to
be as big as possible.

JPEG(and all it's variants/mutations) is an okay choice. It's a little
on the cpu intensive side, but machines are getting faster. The problem
is that a lot of hardware implementations are pretty much incompatible.

I'm working on porting Intel's Indeo 4.0/5.0(decompression only). But
Intel is realizing the linux runs on their processors.  At some point
in the future, it may be possible for someone to license their compression
code.

IBM had an codec for OS/2 called Ultimotion that one could license
the specs for. There wasn't a fee several years ago and I'm not
sure what the status of that is now. I've done a decoder and was
going to attempt an encoder(but who was I kidding, I didn't even
have enough time to breathe).

H.263 is an open standard(not sure what the patent/copyright status
of it is). Telenor has put out source code for a base line H.263.

I remember seeing some public domain wavelet codecs floating around?


We'll want a group of codecs for differnet uses.  A low bit rate
codec for teleconferencing or sending across the net. Capture
codecs for realtime capturings.  Other codecs for higher quality
were compression isn't as critical.


Mark

List:       linux-video
Subject:    Re: [video4linux] Re: Video4Linux 2
From:       Alan Cox < alan () cymru ! net>
Date:       1998-12-01 16:50:56

> H.263 is an open standard(not sure what the patent/copyright status
> of it is). Telenor has put out source code for a base line H.263.

Its patent trapped. Open to the ISO people means "anyone can buy a patent
for the same fee". So its useless to US citizens.

NV has several codecs of its own for low band video with variou slicenses

List:       linux-video
Subject:    Re: [video4linux] Re: Video4Linux 2
From:       Frode Vatvedt Fjeld <frodef () acm ! org>
Date:       1998-12-01 18:11:01

[Alan Cox]

> > H.263 is an open standard(not sure what the patent/copyright status
> > of it is). Telenor has put out source code for a base line H.263.
> 
> Its patent trapped. Open to the ISO people means "anyone can buy a patent
> for the same fee". So its useless to US citizens.

Do you mean that the H.263 standard per se is patented, or that
telenor's implementation is patented? If you mean the former, I find
that very hard to believe, and I've not seen it mentioned in the H.263
spec document. If you mean the telenor implementation, it doesn't
matter much, as that codec isn't very suitable for our use. Also,
there are other implementations (and they're not that difficult to
do), for example < URL:http://huizen.dds.nl/~roalt/h263.html>.

-- 
Frode Vatvedt Fjeld

List:       linux-video
Subject:    Re: [video4linux] Re: Video4Linux 2
From:       Alan Cox alan () cymru ! net>
Date:       1998-12-01 18:23:22

> Do you mean that the H.263 standard per se is patented, or that
> telenor's implementation is patented? If you mean the former, I find
> that very hard to believe, and I've not seen it mentioned in the H.263
> spec document. If you mean the telenor implementation, it doesn't
> matter much, as that codec isn't very suitable for our use. Also,
> there are other implementations (and they're not that difficult to
> do), for example <URL:http://huizen.dds.nl/~roalt/h263.html>.

The stuff I got is from the telenor codec itself. They were originally
going to release it GPL but released it public domain because of the
patent related stuff. Its in the docs.

Alan

List:       linux-video
Subject:    Re: [video4linux] Re: Video4Linux 2
From:       Frode Vatvedt Fjeld <frodef () acm ! org>
Date:       1998-12-01 19:10:20

[Alan Cox]

> The stuff I got is from the telenor codec itself. They were originally
> going to release it GPL but released it public domain because of the
> patent related stuff. Its in the docs.

Hum.. only thing I can find is this rather vague statement:

    Commercial implementations of H.263, including shareware, are
    subject to royalty fees to patent holders.  Many of these patents
    are general enough such that they are unavoidable regardless of
    implementation design.

If they are saying that any piece of software capable of outputting an
h.263 bitstream is subject to patents, that'd be pretty
absurd. Especially as the entropy redundancy of your average h.263
bitstream is pretty low, so in theory, most any random bitstream is
h.263 compliant. I'm going to ask the telenor folks what it means.

-- 
Frode Vatvedt Fjeld

List:       linux-video
Subject:    Re: [video4linux] Re: Video4Linux 2
From:       Alan Cox <alan () cymru ! net>
Date:       1998-12-01 20:21:07

> Hum.. only thing I can find is this rather vague statement:

Thats the one. 

>     Commercial implementations of H.263, including shareware, are
>     subject to royalty fees to patent holders.  Many of these patents
>     are general enough such that they are unavoidable regardless of
>     implementation design.
> 
> If they are saying that any piece of software capable of outputting an
> h.263 bitstream is subject to patents, that'd be pretty
> absurd. Especially as the entropy redundancy of your average h.263
> bitstream is pretty low, so in theory, most any random bitstream is
> h.263 compliant. I'm going to ask the telenor folks what it means.

Cool - having a usable v4l h263 setup (yours or theirs) would be nice

Alan

List:       linux-video
Subject:    Re: [video4linux] Re: Video4Linux 2
From:       Gerd Knorr <kraxel () goldbach ! in-berlin ! de>
Date:       1998-12-01 20:29:50

Alan Cox <alan@cymru.net> writes:

>> Do you mean that the H.263 standard per se is patented, or that
>> telenor's implementation is patented? If you mean the former, I find
>> that very hard to believe, and I've not seen it mentioned in the H.263
>> spec document. If you mean the telenor implementation, it doesn't
>> matter much, as that codec isn't very suitable for our use. Also,
>> there are other implementations (and they're not that difficult to
>> do), for example <URL:http://huizen.dds.nl/~roalt/h263.html>.

>The stuff I got is from the telenor codec itself. They were originally
>going to release it GPL but released it public domain because of the
>patent related stuff. Its in the docs.

Only the arithmetic coding has patent problems.  Arithmetic coding is
_not_ H.263 baseline, but in one of the _optional_ extentions (Annex E).

   Gerd

-- 
Beware "We should", extend a hand to "How do I"...
	-- Alan Cox on /.

List:       linux-video
Subject:    Re: [video4linux] Re: Video4Linux 2
From:       Frode Vatvedt Fjeld <frodef () acm ! org>
Date:       1998-12-02 10:26:49

[Gerd Knorr]

> Only the arithmetic coding has patent problems.  Arithmetic coding
> is _not_ H.263 baseline, but in one of the _optional_ extentions
> (Annex E).

It is also shown in at least one paper that arithmetic coding provides
only a very minimal improvement over ordinary Huffman tables. So this
is no worry.

BTW, I asked the Telenor people about this patent stuff. This is a
paraphrase (and translation) of the answer:

    Companies that participated in developing H.263 holds patents on
    those parts of the standard. Patent holders may demand royalties
    when others use their patent in comercial implementations. Some
    patents are such that they are unavoidable in order to stay H.263
    compliant. [[ this sentence really puzzles me.. like I said, if
    this is actually possible, patents are truly absurd ]] 

She didn't know exactly who has patents or what their policies
are. Telenor has some patents, and she gave me an address where I
could ask what their policy would be.

I think H.263 is more or less a subset of MPEG video. So what is the
patent situation on MPEG?

My position on this patent stuff is to ignore it until it actually
becomes a problem.

Another alternative: It wouldn't be too difficult to create a new
format that could easily be transcoded into H.263 or MPEG.

-- 
Frode Vatvedt Fjeld