[Ffmpeg-devel] 3G Video phone encoder behaviour (discussion)

[Tomas Stenlund]

----- Original Message ----- 
From: "Michael Niedermayer" <michaelni at gmx.at>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at mplayerhq.hu>
Sent: Saturday, November 04, 2006 1:01 PM
Subject: Re: [Ffmpeg-devel] 3G Video phone encoder behaviour (discussion)


> Hi
>
> On Sat, Nov 04, 2006 at 08:46:56AM +0100, Tomas Stenlund wrote:
>> Hi,
>>
>> As I'm sure you are aware of a 3G mobile phone (during
>> a video call) have one 64 kbits channel on the CS side
>> and for all the terminals I have seen they adopt the
>> following strategy:
>>
>> 1) During call setup you send an I-frame.
>>
>> 2) All of the consecutive frames are P-frames. They never
>> send an I-frame again, unless requested (from other terminal
>> or maybe loss of radio-link - aka VFU Video Fast Update).
>>
>> 3) The encoder cycles the MB:s as INTRA in different
>> patterns for the P-frames. Some as a scan line from left
>> to right, other from up to down, other in a more random
>> pattern.
>>
>> So, now to my question. I have tried to look through the source
>> code in ffmpeg to see if this encoder behaviour is implemented
>> and can be switched on. It does not look like it but I have
>> just "skimmed" the source and did not really grasp all.
>>
>> Is this possible to do ? If not is this something you have
>> discussed of supporting or am I on my own in this case ;-)
>>
>> Comments ?
>
> implement the following:
> 1. have an integer per macroblock, and a refresh_addr variable per
>   encoder instance (both in MpegEncContext, first in an array)

Ok.

> 2. if a MB is coded as intra set its integer to 0, if its not increase
>   it by 1
Ok.

> 3. if a MB differs from the previous frame by more then a threshold
>   then set its integer to a large value (or increase it by a difference
>   dependant value but that would need some extensive testing to determine
>   how to select such values)
This to force an early INTRA ? Wouldn't the normal algorithms select this as
an INTRA if the difference is too high anyway ... or ... just curious ?

> 4. if the macroblock at refresh_addr has a integer >
>   AVCodecContext->intra_refresh_threshold (add this to AVCodecContext)
>   then code it as intra
Ok.

> 5. increase refresh_addr
Ok.

> 6. if the number of macroblocks you forced to intra is <
>   AVCodecContext->max_intra_refresh (add this too) and you havnt reached
>   the end of the frame then goto 4
Ok ! So this would then give an band on INTRA MB:s  sweeping down the
frame of max_intra_refresh length at the beginning of the video sequence
and then as time goes by and depending on how the video will look more and
more random on consecutive frames until next I-frame is sent (because there 
might
be other INTRA MB:s in the frame for other reasons).

Simple and works for me.

> 7. if refresh_addr is at the end of the frame set it to 0
Ok !

>
> and send a patch when your done :)
Hehe, I hear what you are saying. I'll just have to dig into it and give it 
a try ;-)

so

ffmpeg ... -cir <threshold> <maxintra> [difference] ...

"cir" being cyclic intra refresh or "cimb" cyclic intra MB or ?

>
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>