[FFmpeg-devel] full swscale relicensing to LGPL
Sat Mar 28 14:26:49 CET 2009
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
>>> i dont, and we lack some timestamp handling code yet for it to work
>>> 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
>> 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
copying & droping? what makes you belive anything is copying and droping
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel