FS#7943 - FFMPEG should be recompiled with --enable-swscaler
Attached to Project:
Arch Linux
Opened by tardo (tardo) - Sunday, 02 September 2007, 23:28 GMT
Last edited by Paul Mattal (paul) - Monday, 21 January 2008, 02:08 GMT
Opened by tardo (tardo) - Sunday, 02 September 2007, 23:28 GMT
Last edited by Paul Mattal (paul) - Monday, 21 January 2008, 02:08 GMT
|
Details
aka, software image scaling support. Mainly because libmlt
should be built with this so that kdenlive stops
crashing.
Builds fine on x86_64 and doesn't seem to affect other programs. |
This task depends upon
Closed by Paul Mattal (paul)
Monday, 21 January 2008, 02:08 GMT
Reason for closing: Implemented
Additional comments about closing: Included in ffmpeg 20071204-1.
Monday, 21 January 2008, 02:08 GMT
Reason for closing: Implemented
Additional comments about closing: Included in ffmpeg 20071204-1.
VLC 9 does not suffer from the swscaler problem. I built from SVN today (with --disable-qt4), and it plays fine. Next week the VLC people are going to iron out the bugs in the QT interface, then it looks like it's going live.
Swfdec when rebuilt against FFMPEG with --enable-swscaler works. I thought I was seeing some A/V sync issues, but it looks as if it was the test video.
http://bbs.archlinux.org/viewtopic.php?id=38373
I haven't read anything about any patches to VLC < 9.x to fix the swscalar problem. 9.x works fine with swscalar, but it's not good enough to release as a replacement for 8.6.x.
Otherwise, since it seems like we can't resolve this deadlock by making everyone happy (at least until VLC 9.x is released), I'm planning to release ffmpeg with swscaler turned on this week. It doesn't seem fair to keep the rest of the world waiting on the swscaler feature because of a bug in VLC.
If anyone believes this logic is flawed or any of the facts on which it is based are incorrect, please respond here within a week. Otherwise I'll be releasing the new ffmpeg.