[FFmpeg-devel] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)

Michael Niedermayer michael at niedermayer.cc
Mon Jun 20 09:57:41 CEST 2016


On Sun, Jun 19, 2016 at 11:42:42PM +0200, Eric Beuque wrote:
> 2016-06-19 16:14 GMT+02:00 Michael Niedermayer <michael at niedermayer.cc>:
> 
> > On Sun, Jun 19, 2016 at 09:59:22AM +0200, Eric Beuque wrote:
> > > 2016-06-18 13:46 GMT+02:00 Michael Niedermayer <michael at niedermayer.cc>:
> > >
> > > > On Fri, Jun 17, 2016 at 07:26:59PM +0200, Eric Beuque wrote:
> > > > > 2016-06-17 19:16 GMT+02:00 Michael Niedermayer
> > <michael at niedermayer.cc>:
> > > > >
> > > > > > On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > i'm posting here for a feature that is missing in ffmpeg (or may
> > be i
> > > > > > > missed something), which consist of decoding H.264 frame with a
> > > > scaling
> > > > > > > factor of 1/2, 1/4, 1/8...
> > > > > > >
> > > > > > > I found the parameter lowres, which works well with MJPEG stream
> > but
> > > > it's
> > > > > > > not working with the H.264 decoder.
> > > > > > >
> > > > > > > I don't know if it's something possible to implement in the
> > decoder,
> > > > but
> > > > > > if
> > > > > > > yes, my compagny agreed to sponsor the feature (depending on the
> > > > cost of
> > > > > > > course), if a developer qualified is interested to do it.
> > > > > > >
> > > > > > > Is someone know if it is possible, and if it can exist someone
> > > > interested
> > > > > > > to develop this feature?
> > > > > >
> > > > > > is it acceptable if the encoder enforces some restrictions on the
> > used
> > > > > > features ?
> > > > > >
> > > > > > most general h264 likely cannot efficiently be decoded in lower
> > > > > > resolution with acceptable quality
> > > > > > Restricting the used intra modes may make it possible to do it
> > though
> > > > > > i dont know what the quality would be but better than without
> > > > > > restrictions
> > > > > >
> > > > > > [...]
> > > > > >
> > > > >
> > > > >
> > > > > Actually, the main goal is for motion detection algorithm, so we need
> > > > small
> > > > > resolution and best quality is not required. We just need good
> > estimation
> > > > > for the moving pixel.
> > > > >
> > > > > For now, we decode in H.264, and scale it close 320x240, the then we
> > > > > perform motion detection on it. The goal is to speed up the process
> > and
> > > > > reduce the memory usage since decoding a 2048x1536 picture lead
> > around a
> > > > 5
> > > > > MB for the decoded image in memory.
> > > > >
> > > > > So i think it could be OK.
> > > >
> > > > i dont think that withut restrictions it would be good enough for
> > > > motion detection
> > > >
> > >
> > > I don't really understand what will be changed in the decoder with or
> > > without restriction...
> >
> > some of the features of h.264 will not decode "right" without the
> > full resolution
> >
> 
> Ok what features do you mean? Maybe it's out of our scope.

some restrictions on intra modes
constrained intra prediction at least
The GOP size should be small too and there may be other things
like disabling the loop filter

cant you just use the IP camera in lower resolution if memory is a
problem ? maybe it can encode 2 streams of different resolution

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160620/69fec54e/attachment.sig>


More information about the ffmpeg-devel mailing list