fame-users — users mailing list

[Fame-users] libfame 0.8.7 released

[Vivien C. <viv...@en...>]

Hi everyone,

a new version of libfame has been released, introducing half-pixel motion
estimation/compensation as well as an extension of the library interface.
fame and recmpeg have been updated accordingly.

Vivien.

[Fame-users] Re: MPEG-1 Status in Fame

[Vivien C. <viv...@en...>]

On Fri, 3 Aug 2001, David Moore wrote:

> Thanks for the info.

> I'll probably just wait for a public release so I don't have to worry
> about the P-frame bugs.

	I've been working very hard for the past days and now these bugs
should be fixed for MPEG-1 and MPEG-4. The encoded stream seems to be good
when using less than about 20 P frames between each I frame, when using
more the error due to derivation between different implementations of the
iDCT start to be visible.

	Compression performance really depends on the input, and
unfortunately I've not implemented half-pel compensation so the motion
estimation/compensation is not yet very accurate.

	I've still have a small bug to fix in an optimized loop before
public release but it is disabled, using the slowest one for now, so you
can already try the current version (0.8.4) and send me feedback, as you
have higher chances of being objective than I have :)
	It's brand new from this evening :)

> I'm interested mainly in MPEG-1 because of
> the java player available from sureplayer.org.  I want to stream video
> through a browser without requiring a plugin on the user's side, so
> MPEG-1 to sureplayer seems like the best bet for now.

Sure but Java is really slow :(
 
> Actually, something else that might be handy in fame would be simulation
> of lower frame rates by inserting "empty" B or P frames.  MPEG-1 is kind
> of annoying in that 24 fps is the slowest standard frame rate.  The
> sureplayer people say that it's possible to insert empty B frames by
> saying there are 0 motion vectors or something like that.  That could chop
> frame rates without going outside of the spec.  Does this seem like
> something useful in fame?

Sure it would be.. once someone gets the time to implement it :)

see ya,
Vivien.

[Fame-users] Re: MPEG-1 Status in Fame

[David M. <dm...@it...>]

Thanks for the info.  I'll probably just wait for a public release so I
don't have to worry about the P-frame bugs.  I'm interested mainly in
MPEG-1 because of the java player available from sureplayer.org.  I want
to stream video through a browser without requiring a plugin on the user's
side, so MPEG-1 to sureplayer seems like the best bet for now.

Actually, something else that might be handy in fame would be simulation
of lower frame rates by inserting "empty" B or P frames.  MPEG-1 is kind
of annoying in that 24 fps is the slowest standard frame rate.  The
sureplayer people say that it's possible to insert empty B frames by
saying there are 0 motion vectors or something like that.  That could chop
frame rates without going outside of the spec.  Does this seem like
something useful in fame?

Anyway, just some thoughts.  Thanks again.

Regards,

David

On Wed, 1 Aug 2001, Vivien Chappelier wrote:

> On Tue, 31 Jul 2001, David Moore wrote:
>
> > Hi Vivien,
>
> Hello,
>
> > I've been using libfame 0.1.0 for a while to encode mpeg1 video.  The
> > performance is great and the API is very nice to use.
>
> Thanks, but it's becoming old :) last version is 0.8.0 :)
> Yet I've not made a new release yet...
>
> > I'd be interested in lowering my bitrate though, and I suspect B- and
> > P-frames will help.  I notice that you've been working on libfame in
> > CVS.
>
> Indeed, I'm trying to finish a last few things before releasing 1.0.0 and
> announcing on freshmeat.
>
> > What is the status of B- and P-frames for mpeg1?
> >  Does it get faster, slower, or stay about the
> > same?
>
> Well, P frame support is nearly finished. I just need to correct two minor
> bugs, one in dequantisation and one concerning colors. I hope to fix that
> before the end of the next week ...
> I haven't started working on B frames yet but I've a couple of thougths
> concerning it. I'm thinking of starting it after a first public release.
>
> > Is there anything usable yet?
>
> Well, these bugs need to be fixed first otherwise the output will look
> bad for long sequences of P frames.
>
> >  Also, how is the performance with the addition of B- and P-frames?
>
> Quite bad currently concerning speed.. it's about 5 times slower than I
> frame only.. but motion estimation isn't optimized for mpeg-1 (actually it
> does the search of 8x8 block for mpeg-4 which isn't useful for mpeg-1
> since this is not supported :(... ) and reconstruction of P frames isn't
> optimized either (all-zero blocks should be skipped whereas they are
> currently decoded).
> Concerning compression ratio, the use of P frames can reduce the size by a
> factor of about 2 for slow motion.. B frames would reduce the size much
> more if they were implemented :)
>
> However, the speed of the mpeg-1 I frame only coder has been much improved
> since 0.1.0.
>
> >  Thanks for the great product!
>
> Thanks for using it and testing it!
>
> Note, you can also use MPEG-4 now, to encode standard video and video with
> arbitrary shape... but there aren't that much players available
> unfortunately..
>
> regards,
> Vivien Chappelier.
>

------------------------------------------------------
  David Moore       California Institute of Technology
 <dc...@ac...>     http://www.ugcs.caltech.edu/~dmoore
------------------------------------------------------

[Fame-users] Re: MPEG-1 Status in Fame

[Vivien C. <viv...@en...>]

On Tue, 31 Jul 2001, David Moore wrote:

> Hi Vivien,

Hello,

> I've been using libfame 0.1.0 for a while to encode mpeg1 video.  The
> performance is great and the API is very nice to use. 

Thanks, but it's becoming old :) last version is 0.8.0 :)
Yet I've not made a new release yet...

> I'd be interested in lowering my bitrate though, and I suspect B- and
> P-frames will help.  I notice that you've been working on libfame in
> CVS. 

Indeed, I'm trying to finish a last few things before releasing 1.0.0 and
announcing on freshmeat.

> What is the status of B- and P-frames for mpeg1?
>  Does it get faster, slower, or stay about the
> same?

Well, P frame support is nearly finished. I just need to correct two minor
bugs, one in dequantisation and one concerning colors. I hope to fix that
before the end of the next week ...
I haven't started working on B frames yet but I've a couple of thougths
concerning it. I'm thinking of starting it after a first public release.

> Is there anything usable yet?

Well, these bugs need to be fixed first otherwise the output will look
bad for long sequences of P frames.

>  Also, how is the performance with the addition of B- and P-frames?

Quite bad currently concerning speed.. it's about 5 times slower than I
frame only.. but motion estimation isn't optimized for mpeg-1 (actually it
does the search of 8x8 block for mpeg-4 which isn't useful for mpeg-1
since this is not supported :(... ) and reconstruction of P frames isn't
optimized either (all-zero blocks should be skipped whereas they are
currently decoded).
Concerning compression ratio, the use of P frames can reduce the size by a
factor of about 2 for slow motion.. B frames would reduce the size much
more if they were implemented :)

However, the speed of the mpeg-1 I frame only coder has been much improved
since 0.1.0.

>  Thanks for the great product!

Thanks for using it and testing it!

Note, you can also use MPEG-4 now, to encode standard video and video with
arbitrary shape... but there aren't that much players available
unfortunately..

regards,
Vivien Chappelier.