Hi, On Sat, Oct 3, 2015 at 2:46 PM, James Darnley <james.darn...@gmail.com> wrote:
> On 2015-10-03 04:08, Ronald S. Bultje wrote: > > Hi, > > > > On Fri, Oct 2, 2015 at 4:58 PM, Hendrik Leppkes <h.lepp...@gmail.com> > wrote: > > > >> On Fri, Oct 2, 2015 at 7:16 PM, Timothy Gu <timothyg...@gmail.com> > wrote: > >>> On Fri, Oct 2, 2015 at 10:08 AM James Darnley <james.darn...@gmail.com > > > >>> wrote: > >>> > >>>> The third patch uses them in the remaining inline assembly. > >>>> > >>> > >>> That's the crux of the problem: inline asm uses these constants, but > will > >>> be unable to without yasm. Either we drop compatibility for inline asm > >> for > >>> x86 platforms w/o yasm, or we can't do this. > >>> > >> > >> A build without yasm is gimped as it is, so disabling inline asm in > >> the same go doesn't seem like a too terrible thing. > > > > > > I'm leaning towards this as well. > > Then you will all be pleased to hear that I have fixed building with > --disable-yasm by adding a HAVE_YASM check to a few functions in cavs > (the Chinese H.264 knockoff) and many functions in vc1. One conditional > in inline_asm has also been extended. At least this fixes building > ffmpeg for the people who use --disable-yasm. > > As for porting, I know I said "how hard can this be"...quite a lot > actually. I ported 1 function in cavs last night but after going though > vc1 to fix building I can see just how much work that would be. We've had various efforts in that direction. The problem is that typically people add new inline asm over time, even if it's discouraged. Any effort you're willing to put into conversion of that code would be hugely appreciated. But as you can also see, people don't care much about vc1/cavs, not remotely as much as they do about mpeg1/2/4/h264/etc. Which is why their conversion is lagging :) Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel