[MPlayer-dev-eng] [RFC] rc2 at the beginning of October
Michael Niedermayer
michaelni at gmx.at
Sat Sep 29 00:52:07 CEST 2007
Hi
On Fri, Sep 28, 2007 at 06:43:27PM +0200, Diego Biurrun wrote:
> On Wed, Sep 26, 2007 at 10:00:26PM +0200, Roberto Togni wrote:
> >
> > The patch...
> >
> > --- vd_ffmpeg.c (revision 24617)
> > +++ vd_ffmpeg.c (working copy)
> > @@ -249,7 +249,7 @@
> >
> > - if(lavc_codec->capabilities&CODEC_CAP_DR1 && !do_vis_debug && lavc_codec->id != CODEC_ID_H264 && lavc_codec->id != CODEC_ID_INTERPLAY_VIDEO)
> > + if(lavc_codec->capabilities&CODEC_CAP_DR1 && !do_vis_debug && lavc_codec->id != CODEC_ID_H264 && lavc_codec->id != CODEC_ID_INTERPLAY_VIDEO && lavc_codec->id != CODEC_ID_ROQ)
>
> Hmmm, CODEC_ID_H264 ...
>
> Does this slow down H.264 decoding? How much?
yes and it depends on the VO, if direct rendering isnt used theres no
difference if it would be used without the check above then an extra
memcpy() will be needed per picture
> And what is the problem?
libmpcodecs design, it doesnt support things beyond MPEG2/MPEG4 IPB style
that is if there are more than 1 reference frames or if a b frame is used
as reference it breaks
you might be able to test the speed effect with a simple IP(B) h.264 with
the encoder configured su it uses just a single reference frame
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070929/b9bdcaa4/attachment.pgp>
More information about the MPlayer-dev-eng
mailing list