[MPlayer-dev-eng] [RFC] rc2 at the beginning of October

[Loren Merritt]

On Sat, 29 Sep 2007, Michael Niedermayer wrote:
> 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:
>>>
>>> --- 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

What does number of reference frames have to do with anything? They don't 
affect reordering.

--Loren Merritt