[FFmpeg-devel] full swscale relicensing to LGPL

[Michael Niedermayer]

On Fri, Mar 27, 2009 at 11:37:30AM +0100, Ivan Schreter wrote:
> Hi Carl Eugen,
>
> Carl Eugen Hoyos wrote:
>> Michael Niedermayer <michaelni <at> gmx.at> writes:
>>
>>   
>>>>> -vsync  0' options still belong?
>>>>>         
>>>> I did not test yet (manually), because I wanted to ask first if you (or
>>>> Michael) have an automated way doing it, but my next intention was to 
>>>> find
>>>> out.
>>>>       
>>> i dont, and we lack some timestamp handling code yet for it to work 
>>> except
>>> by luck and its not moving us forward if such luck is tested for by fate
>>>     
>>
>> Could you explain the issue? Is this the reason current MPlayer fails for 
>> all
>> PAFF samples, even the ones that (more or less) played fine before?
>> Both ffmpeg and ffplay svn work fine with all my samples.
>>
>>   
> Actually, timestamp handling as such should be correct by now for H.264 
> (except some exotic things like discontinuities). But there are some small 

the current implementation depends on optional SEI, this is not correct.
For example it does not work with many of the reference streams.


> 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?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20090328/308433ed/attachment.pgp>