Re: [Openpvr-devel] filter chains, etc.

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

On Wed, Mar 27, 2002 at 10:39:30PM -0600, Dave Caplinger wrote:
>=20
> I don't know the exact numbers off the top of my head, but I believe=20
> about 2:1 is the best you can really hope for for lossless.

Wow!  That's a lot of space!

> I'm thinking of this from a "regular end user" perspective, where they=20
> (i.e. my wife) aren't going to want to have to manually reencode stuff.=
=20

Of course not.  It would be a background process, niced down to not
interfere with current recording and/or playing tasks.

> But thinking this through for a moment: if this really was=20
> worthwhile, would it be useful to limit captures to 15 minutes per file?=
=20
>  The reason I say this is that if you're going to have to filter and=20
> reencode during "idle" times without any user intervention, you're going=
=20
> to need scratch disk space set aside for the intermediate files (which=20
> means that space can never be used to record into),

Well, the 15 minute files could be useful but not for this.  The
resulting file is going to be tiny compared to the source files (with
numbers like 2:1 for source and 1-2Mb/s for destination files) so
intermediate space is a minimal requirement, but it does mean being
able to free up the space the source files are taking up at 15 minute
chunks, not 1 hour (or more) chunks.  i.e. instead of having to wait
an hour to recover the space used to source record a program you can
recover 25% of the space after only re-encoding 15 minutes.

> So if you recorded in 15-minute (or even smaller, like 5-minute?)=20
> segments, and for any segment you were in the process of re-encoding you=
=20
> kept the original around until the re-encoding was done, the user can=20
> still play the segment that is being currently re-encoded (by suspending=
=20
> the re-encoding and playing the original), and then later the=20
> re-encoding can pick up where it left off.  Any single re-encoding task=
=20
> isn't going to run for tens of hours tying up tens of GB of disk space,=
=20
> but eventually the recoding (and thus disk space savings) will in fact=20
> happen.

I think you are saying what I said, which is probably what you said in
the first place.  :-)

> This would all be predicated on the playback agent being able to peice=20
> together the segments (which could be completely different codecs)=20
> without any a/v-sync hiccups so the user would never notice it.

:-)

> Seems=20
> like a big caveat to me, but I'm no expert at this.

Big indeed.

> Does this seem feasible?

Well, with somebody making a player specifically for this, yes, but I
don't know of a player smart enough to do this right now.

b.

--=20
Brian J. Murrell