On 24/05/15 5:59 PM, Michael Niedermayer wrote: > On Sun, May 24, 2015 at 04:22:42PM -0300, James Almer wrote: >> Use either the WebPEncoder or WebPAnimEncoder APIs depending on availability >> of the latter. >> >> Signed-off-by: James Almer <jamr...@gmail.com> >> --- >> This is an RFC because the resulting encoder will use one of the two APIs, >> which >> is a change from the current behavior of having one encoder for each API. >> The new encoder was added only two days ago so removing it shouldn't be an >> issue. >> Basically, is there any benefit from using the native lavf muxer over letting >> WebPAnimEncoder do the entire process to justify having two encoders? >> >> The resulting ifdeffery is minimal now that the webp muxer can act as a raw >> muxer >> cleanly, so the only concern is the above. We can deal with cosmetics later, >> but >> the functional change needs to be done asap least we want to deal with >> deprecation >> nonsense if the new encoder makes it into a release. > > They are 2 different encoders, the old is partly implemented in > FFmpeg, the new does all steps in an external lib > The 2 variants work differently > command lines for the old encoder do NOT work with WebPAnimEncoder, > at least not with the current implementation we have
My intention was to keep it all as a single encoder, using one of the two APIs depending on availability. If the AVOptions have different results on them then i guess it's not really feasible after all. So patch dropped. > > try it yourself > ./ffmpeg -i matrixbench_mpeg2.mpg -cr_threshold 10000 -cr_size 16 -t 10 -loop > 2 -vcodec libwebp test.webp > > works with the old encoder but after this patch produces a video > that is a flickering checkerboard This happens when the WebPAnimEncoder API is used alongside one or two of those -cr_ options. Unrelated to this patch, but as i said above a good argument against it. It should be fixed, for that matter. CCing Urvang Joshi. > > Also libwebp lacks a maintainer in MAINTAINERs > anyone volunteers ? libwebpenc_animencoder.c should be maintained by the person that wrote/submitted it. > > I might be willing to maintain it when the 2 encoders can be tested > without the need to build ffmpeg twice (they can be in one .c file for > that or in multiple of course), I'm not sure what you mean. The two encoders can be tested without having to build ffmpeg twice, assuming you have a new enough libwebp/mux installed. They are currently independent, and you can use one or the other with -c:v or such. > I know from the xcb/x11 alternative that i practically never bother > to test both variants when i would have to build teh code twice. > So if that becomes needed then someone else should maintain it > > Of course even if both can be build at the same time, i would still > be happy if someone else, maybe you ? does the maintaince > > Thanks > > [...] > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
