[FFmpeg-devel] full swscale relicensing to LGPL

Michael Niedermayer michaelni
Sun Mar 29 01:25:04 CET 2009


On Sat, Mar 28, 2009 at 11:22:29PM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
>> [...]
>>> deficiencies regarding frame rate detection in MPEG-TS/PS streams (and 
>>> possibly other containers). For instance, 25 fps *interlaced* H.264 coded 
>>> as field pictures (50 fields per second) gets double frame rate (50Hz 
>>> instead of 25Hz) and produces a full frame in decode_picture only for 
>>> each second tick (i.e., actual full frame rate is 25Hz). This is handled 
>>> correctly by ffplay and ffmpeg, simply by copying the frame and dropping 
>>> it again when encoding back to 25 fps, but may confuse other programs 
>>> using lavf/lavc.
>>>     
>>
>> copying & droping? what makes you belive anything is copying and droping
>> frames?
>>
>>   
> Well, maybe ffmpeg printing 1 dup in verbose mode for each input frame when 
> converting 25 fps interlaced video? The resulting video is 50 fps instead 
> of 25 fps and contains each frame twice => it's obviously copying it.

you spoke from copying and droping, if the output video is 50fps and vsync=1
then obviously it will duplicate frames from 25fps input


>
> When specified frame rate explicitly with -r 25, then it produces correct 
> video with 25 fps. If internally copying & dropping is done or not, I'm not 
> sure.

then please dont claim that it is done


>
> Anyway, detection of container frame rate is wrong (see also my other 
> e-mail).

i can only repeat to the hundreads time that we dont have a frame rate
variable with your definition of frame rate

let me also repeat the possible solutions
A. add another frame rate field
B. use some flag to change the behavior of r_frame_rate when it is used
   for transcoding to a target container in which frame duplication is
   needed explicitly 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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/ffmpeg-devel/attachments/20090329/fb14336a/attachment.pgp>



More information about the ffmpeg-devel mailing list