openpvr-devel — Development of an Open PVR

[Openpvr-devel] Re: [V4L] OpenPVR project up and running

[Brian J. M. <d16...@in...>]

On Wed, Nov 28, 2001 at 11:08:35PM -0800, Billy Biggs wrote:
> Brian J. Murrell (v4...@in...):
> 
> > > One thing I wrote is a simple prediction-based codec.  It's fast
> > > enough for lossless realtime encoding, but the files it writes are
> > > massive
> > 
> > What's the storage rate in terms of bytes/sec.?
> 
>   I get on average 50-60% compression from raw Y'CbCr images.
> 
>   So, say you downsample to 4:2:0, and you're capturing 525/59.94-style
> video.  Each frame uncompressed is (720*480*12/8) == 518400 bytes.  So,
> I compress down to about 260000 bytes on average per frame.

Wow, that is 26GB/H.

>   Yeah, well, the v4l api sucks.

Do you mean that to include v4l2 as well or specifically v4l1?

>   Doing what you request should be
> pretty trivial,

I thought so.

> but it seems like a waste to me.  The linux scene could
> benefit more from a userspace video capture library that can also do
> things like colourspace conversion and chroma resampling for webcams and
> stuff (and also for live capture).  I'd rather work towards that.

Fair enough.

>   Having a few sample clips in a lossless format (like my codec) would
> be useful then.

Right!  'Cept that when you want to compare v4l[2] capture apps you
need to feed them in via the v4l[2] api.  Not all (indeed probably
less than more) capture apps can read from a file as well.

> I can see about posting up some of the samples I use,
> but it sucks since they're all in about the 1-gig size range.

I could believe it.

>   Is that what you meant?

Half way.  Like I said above, they need to be fed through the API
though.

b.

-- 
Brian J. Murrell

Re: [Openpvr-devel] Re: Open PVR (was Re: [V4L] Sugestions on how to use mp1e for vcr like recording?)

[Brian J. M. <9a3...@in...>]

On Thu, Nov 29, 2001 at 02:27:35AM -0500, ric...@ri... wrote:
> 
> and tivo has their kernel hacks on their webstie
> (http://www.tivo.com/linux/index.html)

Anyone looked into these to see if what they have hacked up is
meaningful to our project?

> The only problem I have
> with TIVO is that I want total control, and they don't offer
> source for their application, not to mention that they like to
> try to keep people out of THEIR data that THEY have recorded.

EXACTLY my reason for an OpenPVR.  It is totally questionable whether
one can be built that rivals Tivo in both performance and cost.  What
I want is the flexibility to do with the recording what I please.

I might want to view the recording on the computer in the bedroom
rather than watch it on the TV in living room.  Maybe I want to burn
it to a CD, or even take it out with me on a portable viewer of some
sorts.

b.

-- 
Brian J. Murrell

[Openpvr-devel] Re: Open PVR (was Re: [V4L] Sugestions on how to use mp1e for vcr like recording?)

[<ric...@ri...>]

On Wed, Nov 28, 2001 at 02:57:23PM +0000, Paul Stoner wrote:
> Got a Tivo which works fine with recording and play back of TV.
> Got it just for the interum, as hoping to get my WinTV-PVR working under
> Linux todo the same as above.
> 

Perhaps that would be a valid option for a hardware platform!  I
have heard good things about the hardware, it runs linux, people
have gotten into them to fire up bash and hacked it to add hard
drives ... and tivo has their kernel hacks on their webstie
(http://www.tivo.com/linux/index.html)  The only problem I have
with TIVO is that I want total control, and they don't offer
source for their application, not to mention that they like to
try to keep people out of THEIR data that THEY have recorded.

But I'm happier to buy from a linux based company than from
anybody else!

[Openpvr-devel] Re: [V4L] OpenPVR project up and running

[Billy B. <ve...@du...>]

Brian J. Murrell (v4...@in...):

> > One thing I wrote is a simple prediction-based codec.  It's fast
> > enough for lossless realtime encoding, but the files it writes are
> > massive
> 
> What's the storage rate in terms of bytes/sec.?

  I get on average 50-60% compression from raw Y'CbCr images.

  So, say you downsample to 4:2:0, and you're capturing 525/59.94-style
video.  Each frame uncompressed is (720*480*12/8) == 518400 bytes.  So,
I compress down to about 260000 bytes on average per frame.

  I also downsample the chroma from 4:2:2 myself since the bttv driver's
chroma downsampling is busted (only takes data from one field).
Something to keep in mind if you're writing a recorder.  Ugh.

  The advantage to this compression method is that it is dirt cheap.
Doing any DCT-based compression scheme is going to take up like at least
10ms per frame (full resolution), and since you only have like 30ms to
play with, it doesn't leave alot of time for, say, displaying the output
to the screen or writing to disk.

> One thing that I think could be useful for both the OpenPVR project as
> well as for V4L in general is a V4L loopback device.  The ability to
> (re-)capture through the V4L API the contents of a fie which is an
> already captured stream would be useful for a) people to play with V4L
> that don't have actual hardware (yet) and b) for doing comparisons of
> codecs and encoding parameters.

  Yeah, well, the v4l api sucks.  Doing what you request should be
pretty trivial, but it seems like a waste to me.  The linux scene could
benefit more from a userspace video capture library that can also do
things like colourspace conversion and chroma resampling for webcams and
stuff (and also for live capture).  I'd rather work towards that.

> I find it very difficult to evaluate the results of differing capture
> programs/parameters when the source data is different.

  Having a few sample clips in a lossless format (like my codec) would
be useful then.  I can see about posting up some of the samples I use,
but it sucks since they're all in about the 1-gig size range.

  I have some really evil 3:2 pulldown inversion stress tests that I've
been meaning to put up anyway.

  Is that what you meant?

-- 
Billy Biggs
ve...@du...

[Openpvr-devel] Re: [V4L] OpenPVR project up and running

[Brian J. M. <v4...@in...>]

On Wed, Nov 28, 2001 at 08:10:49PM -0800, Billy Biggs wrote:
>   Hi Brian,

Hello Billy.

>   You can take a look at my beginnings of a pvr project in CVS at:
> 
>   http://www.sf.net/projects/reetpvr/
> 
>   One thing I wrote is a simple prediction-based codec.  It's fast
> enough for lossless realtime encoding, but the files it writes are
> massive

What's the storage rate in terms of bytes/sec.?

> (so I can do expensive tasks like resampling and 3:2 pulldown
> inversion using off-line algorithms).

One thing that I think could be useful for both the OpenPVR project as
well as for V4L in general is a V4L loopback device.  The ability to
(re-)capture through the V4L API the contents of a fie which is an
already captured stream would be useful for a) people to play with V4L
that don't have actual hardware (yet) and b) for doing comparisons of
codecs and encoding parameters.

I find it very difficult to evaluate the results of differing capture
programs/parameters when the source data is different.

I wonder how well your work could be put towards that sort of goal.

b.

-- 
Brian J. Murrell

[Openpvr-devel] Re: [V4L] OpenPVR project up and running

[Billy B. <ve...@du...>]

  Hi Brian,

> So lets get some discussion going about what people have put together
> and see if we can start writing some recipes.

  You can take a look at my beginnings of a pvr project in CVS at:

  http://www.sf.net/projects/reetpvr/

  One thing I wrote is a simple prediction-based codec.  It's fast
enough for lossless realtime encoding, but the files it writes are
massive (so I can do expensive tasks like resampling and 3:2 pulldown
inversion using off-line algorithms).  You can check out the code for
this codec extracted from reetpvr at:

  http://www.dumbterm.net/graphics/compression

  Currently my pvr is misnamed: it's just a high-quality v4l recorder.
But it has a few unique bits: I record closed captions, the lossless
compressor, I run SCHED_FIFO, I correctly calculate audio drift, I can
record at full frame size, and I reverse 3:2 pulldown.

  Hope I can help,
-- 
Billy Biggs
ve...@du...