On Wed, Nov 05, 2014 at 07:39:19PM +0100, wm4 wrote:
> On Wed, 5 Nov 2014 18:06:42 +1100
> Matt Oliver wrote:
>
> > Currently the extra filters provided by mpcodecs require inline asm support
> > to compile. However these filters all provide non-asm alternatives that can
> > be used with the corr
On Wed, 5 Nov 2014 18:06:42 +1100
Matt Oliver wrote:
> Currently the extra filters provided by mpcodecs require inline asm support
> to compile. However these filters all provide non-asm alternatives that can
> be used with the correct pre-processor guard.
>
> Based on some recent discussions it
On Thu, Nov 06, 2014 at 12:43:35AM +1100, Matt Oliver wrote:
> >
> >
> > did you post this to mplayer-dev ?
> >
>
> No not as yet, thought I would put it up here for feedback first. Also
> someone more familiar with mpcodecs in mplayer might know of other places
> that could benefit from a similar
>
>
> did you post this to mplayer-dev ?
>
No not as yet, thought I would put it up here for feedback first. Also
someone more familiar with mpcodecs in mplayer might know of other places
that could benefit from a similar change.
___
ffmpeg-devel mailing
On Wed, Nov 05, 2014 at 06:06:42PM +1100, Matt Oliver wrote:
> Currently the extra filters provided by mpcodecs require inline asm support
> to compile. However these filters all provide non-asm alternatives that can
> be used with the correct pre-processor guard.
>
> Based on some recent discussi
Matt Oliver gmail.com> writes:
> if anyone knows of why the _INLINE variants
> werent/shouldnt be used then feel free to let me know.
^^
To keep the source code in sync with MPlayer iirc.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@
Currently the extra filters provided by mpcodecs require inline asm support
to compile. However these filters all provide non-asm alternatives that can
be used with the correct pre-processor guard.
Based on some recent discussions it appears that some of these filters are
still used but with the r
