[Ffmpeg-devel] Metrics for compressed video

Jon Burgess jkburges
Wed Oct 4 05:33:46 CEST 2006

Hi Loren,

Thanks for the advice.  You're right that in my case I don't need a generic
interface, but...

I guess the point I was getting at (maybe I didn't explain very well) is
that I think I'm going to write a generic interface, since although
initially I will be using MPEG-4 Part 2 video data, I think that we will
want to support H.264 (and maybe other encodings) in our application in the
future, so I want to have something like "get me the amount of motion in
this video frame" that works independantly of video encoding.

So that is my plan - whether you guys want it in the repository or not I
suppose is up to you.  But I would be happy to contribute to the project.

Jono Burgess

On 30/09/06, Loren Merritt <lorenm at u.washington.edu> wrote:
> On Fri, 29 Sep 2006, Jon Burgess wrote:
> > As an aside for those who care, I am using the ratio of intra-coded
> blocks
> > to total blocks in each P or B frame to indicate motion (the more intra
> > coded blocks, then the more motion).  This might not work very well for
> all
> > MPEG-4 Part 2 implementations, but it seems to work quite well for my
> stream
> > (which is coming from an Axis 241QA video server).
> >
> > Anyway, my question comes down to the following: I have two options for
> how
> > to actually implement this "metric extraction" into libavcodec and our
> > company's product.
> > 1) Maintain our own copy of the libavcodec source; or
> > 2) Add some sort of generic metric API into libavcodec itself.
> libavcodec already exports the array of macroblock types, in
> AVFrame.mb_type
> Maybe there's a use for some generic metric API, but I don't see a need
> for it in your case.
> --Loren Merritt
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list