headers
Mike Melanson | 1 Oct 2010 01:01

Re: [PATCH] Google WebP support

On 09/30/2010 03:55 PM, Pascal Massimino wrote:
> On Thu, Sep 30, 2010 at 3:53 PM, Pascal Massimino<
> pascal.massimino <at> gmail.com>  wrote:
>
>>
>> Mike!
>> you're too fast!

Sorry; had the day off and was a bit bored when I saw this news come 
through.

>> what about  http://pastebin.com/FbUvG77M
>>
>>
> attached, too. That's easier

I was about to take the independent demuxer route as well. But then I 
decided to figure out how the general image handling system operates. It 
looks like the trade-off here is that the general image approach is less 
code while the independent demuxer allows for the more advanced features 
like metadata.

Commence the bikeshedding regarding which approach will go into FFmpeg.

--

-- 
     -Mike Melanson
Permalink | Reply | 13 comments |
headers
Michael Niedermayer | 1 Oct 2010 01:11
Picon
Picon

Re: [RFC] clobbers for XMM registers

On Thu, Sep 30, 2010 at 10:01:11AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> 2010/9/28 Måns Rullgård <mans <at> mansr.com>:
> > Michael Niedermayer <michaelni <at> gmx.at> writes:
> >> On Tue, Sep 28, 2010 at 09:36:40AM -0400, Ronald S. Bultje wrote:
> >>> On Tue, Sep 28, 2010 at 8:34 AM, Michael Niedermayer <michaelni <at> gmx.at> wrote:
> >>> > you want to execute code from vp3dsp_sse2.c on a pre SSE cpu?
> >>>
> >>> All _sse2 files are templates files that are included in dsputil_mmx.c
> >>> or similar.
> >>
> >> we could add the flags to dsputil_mmx then
> >
> > That would allow the compiler to use SSE instructions in functions
> > that should be MMX only.
> 
> I'm gonna start kicking this subject until it's solved. Come on guys,
> keep this moving. Why don't we make it (the clobbering) a macro and
> only enable this on x86-64. Don't forget all xmm registers are
> caller-save on x86-32 and x86-64 has no issues with marking clobbers
> (and even if it did, -msse is fine, there is no single x86-64 CPU that
> does not support SSE).

-msse is enabled by default on x86-64 (this is documented in the gcc docs).
i do not know what default it has on x86-32 on the various gcc versions

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Niedermayer | 1 Oct 2010 01:17
Picon
Picon

Re: [RFC] clobbers for XMM registers

On Thu, Sep 30, 2010 at 03:36:08PM -0400, Alexander Strange wrote:
> 
> On Sep 30, 2010, at 12:59 PM, Måns Rullgård wrote:
> 
> > Alexander Strange <astrange <at> ithinksw.com> writes:
> > 
> >> On Thursday, September 30, 2010, Måns Rullgård <mans <at> mansr.com> wrote:
> >>> "Ronald S. Bultje" <rsbultje <at> gmail.com> writes:
> >>> 
> >>>> Hi,
> >>>> 
> >>>> 2010/9/28 Måns Rullgård <mans <at> mansr.com>:
> >>>>> Michael Niedermayer <michaelni <at> gmx.at> writes:
> >>>>>> On Tue, Sep 28, 2010 at 09:36:40AM -0400, Ronald S. Bultje wrote:
> >>>>>>> On Tue, Sep 28, 2010 at 8:34 AM, Michael Niedermayer <michaelni <at> gmx.at> wrote:
> >>>>>>>> you want to execute code from vp3dsp_sse2.c on a pre SSE cpu?
> >>>>>>> 
> >>>>>>> All _sse2 files are templates files that are included in dsputil_mmx.c
> >>>>>>> or similar.
> >>>>>> 
> >>>>>> we could add the flags to dsputil_mmx then
> >>>>> 
> >>>>> That would allow the compiler to use SSE instructions in functions
> >>>>> that should be MMX only.
> >>>> 
> >>>> I'm gonna start kicking this subject until it's solved. Come on guys,
> >>>> keep this moving. Why don't we make it (the clobbering) a macro and
> >>>> only enable this on x86-64. Don't forget all xmm registers are
> >>>> caller-save on x86-32 and x86-64 has no issues with marking clobbers
> >>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Niedermayer | 1 Oct 2010 01:24
Picon
Picon

Re: [RFC] clobbers for XMM registers

On Thu, Sep 30, 2010 at 04:02:00PM -0300, Ramiro Polla wrote:
> 2010/9/30 Måns Rullgård <mans <at> mansr.com>:
> > Ramiro Polla <ramiro.polla <at> gmail.com> writes:
> >> 2010/9/30 Måns Rullgård <mans <at> mansr.com>:
> >>> Ramiro Polla <ramiro.polla <at> gmail.com> writes:
> >>>> What about
> >>>> #if HAVE_XMM_CLOBBERS
> >>>> #    define XMM_CLOBBERS(a, ...) __VA_ARGS__
> >>>> #else
> >>>> #    define XMM_CLOBBERS(a, ...) a
> >>>> #endif
> >>>>
> >>>> to be used as in lavc/x86/fft_sse.c:
> >>>>         :"+r"(j), "+r"(k)
> >>>>         :"r"(output+n4), "r"(output+n4*3),
> >>>>          "m"(*m1m1m1m1)
> >>>>         XMM_CLOBBERS(, : "%xmm0", "%xmm1", "%xmm7")
> >>>>     );
> >>>
> >>> That falls over if any other clobbers are needed.
> >>
> >> If any other clobbers are needed they could be written before the macro.
> >
> > That won't work.
> 
> : "eax" XMM_CLOBBERS(,, "%xmm0", "%xmm1", "%xmm7")
> 
> But I agree having "cc" as dummy is simpler.

it may be simpler but your variant is more correct
(Continue reading)

Permalink | Reply | 14 comments |
headers
Michael Niedermayer | 1 Oct 2010 01:27
Picon
Picon

Re: [PATCH] Add a time_base field to AVFilterPad.

On Thu, Sep 30, 2010 at 10:35:41PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2010-09-28 20:29:48 +0200, Michael Niedermayer encoded:
> > On Tue, Sep 28, 2010 at 02:34:05AM +0200, Stefano Sabatini wrote:
> > > On date Monday 2010-09-27 23:28:47 +0200, Stefano Sabatini encoded:
> > > > On date Thursday 2010-07-22 00:47:32 +0200, Stefano Sabatini encoded:
> > > > > On date Wednesday 2010-07-21 21:12:04 +0200, Michael Niedermayer encoded:
> > > > > > On Wed, Jul 21, 2010 at 05:56:27PM +0200, Stefano Sabatini wrote:
> > > > > [...]
> > > > > > > I did more tests and I noticed this problem.
> > > > > > > 
> > > > > > > In the case of a filterchain of the kind:
> > > > > > > 
> > > > > > > buffer -> filter -> ffmpeg_output
> > > > > > > 
> > > > > > > After configuration this results like this:
> > > > > > > 
> > > > > > > buffer [TB1] <-> [TB1] filter [AVTB] <-> [TB1] ffmpeg_output
> > > > > > > 
> > > > > > > while I want to avoid conversions, that is I want this:
> > > > > > > 
> > > > > > > buffer [TB1] <-> [TB1] filter [TB1] <-> [TB1] ffmpeg_output
> > > > > > > 
> > > > > > > This is done configuring by default the output link to make it use the
> > > > > > > same timebase of the *first* input pad if it exists.
> > > > > > 
> > > > > > by default the output tb should be choose so that all input timestamps can be
> > > > > > exactly represented or if this timebase exceeds 32/32bit then AVTB
> > > > > > 
> > > > > > and (inexact) convertion should of course be avoided when possible as its
> > > > > > a recipe for turning timestamps into non strictly increasing sequences
(Continue reading)

Permalink | Reply | 28 comments |
headers
Michael Niedermayer | 1 Oct 2010 01:32
Picon
Picon

Re: [PATCH] Google WebP support

On Thu, Sep 30, 2010 at 04:01:18PM -0700, Mike Melanson wrote:
> On 09/30/2010 03:55 PM, Pascal Massimino wrote:
>> On Thu, Sep 30, 2010 at 3:53 PM, Pascal Massimino<
>> pascal.massimino <at> gmail.com>  wrote:
>>
>>>
>>> Mike!
>>> you're too fast!
>
> Sorry; had the day off and was a bit bored when I saw this news come  
> through.
>
>>> what about  http://pastebin.com/FbUvG77M
>>>
>>>
>> attached, too. That's easier
>
> I was about to take the independent demuxer route as well. But then I  
> decided to figure out how the general image handling system operates. It  
> looks like the trade-off here is that the general image approach is less  
> code while the independent demuxer allows for the more advanced features  
> like metadata.
>
> Commence the bikeshedding regarding which approach will go into FFmpeg.

i prefer your patch mike, currently 

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
(Continue reading)

Permalink | Reply | 12 comments |
headers
Måns Rullgård | 1 Oct 2010 01:39

Re: mpegtsenc: Improve PCR generation and output

Michael Niedermayer <michaelni <at> gmx.at> writes:

> On Thu, Sep 30, 2010 at 04:07:59PM +0200, Tomas Härdin wrote:
>
> a bit off topic but our mpeg-ps muxer works correctly maybe it would be
> easier to throw the ts timestamping code where it belongs and use the
> working ps code instead of years of trying to build on quicksand

This has been a gsoc task twice iirc.  The student vanished both times.

> If not iam curious what iam missing? TS & PS are very similar when it
> comes to bufering and tgiming from what i remember

The buffering and timing models are identical.

--

-- 
Måns Rullgård
mans <at> mansr.com
Permalink | Reply | 2 comments |
headers
Måns Rullgård | 1 Oct 2010 01:42

Re: [RFC] clobbers for XMM registers

Michael Niedermayer <michaelni <at> gmx.at> writes:

> On Thu, Sep 30, 2010 at 04:02:00PM -0300, Ramiro Polla wrote:
>> 2010/9/30 Måns Rullgård <mans <at> mansr.com>:
>> > Ramiro Polla <ramiro.polla <at> gmail.com> writes:
>> >> 2010/9/30 Måns Rullgård <mans <at> mansr.com>:
>> >>> Ramiro Polla <ramiro.polla <at> gmail.com> writes:
>> >>>> What about
>> >>>> #if HAVE_XMM_CLOBBERS
>> >>>> #    define XMM_CLOBBERS(a, ...) __VA_ARGS__
>> >>>> #else
>> >>>> #    define XMM_CLOBBERS(a, ...) a
>> >>>> #endif
>> >>>>
>> >>>> to be used as in lavc/x86/fft_sse.c:
>> >>>>         :"+r"(j), "+r"(k)
>> >>>>         :"r"(output+n4), "r"(output+n4*3),
>> >>>>          "m"(*m1m1m1m1)
>> >>>>         XMM_CLOBBERS(, : "%xmm0", "%xmm1", "%xmm7")
>> >>>>     );
>> >>>
>> >>> That falls over if any other clobbers are needed.
>> >>
>> >> If any other clobbers are needed they could be written before the macro.
>> >
>> > That won't work.
>> 
>> : "eax" XMM_CLOBBERS(,, "%xmm0", "%xmm1", "%xmm7")
>> 
>> But I agree having "cc" as dummy is simpler.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Pascal Massimino | 1 Oct 2010 01:48
Picon

Re: [PATCH] Google WebP support

Mike, Michael,

On Thu, Sep 30, 2010 at 4:32 PM, Michael Niedermayer <michaelni <at> gmx.at>wrote:

> On Thu, Sep 30, 2010 at 04:01:18PM -0700, Mike Melanson wrote:
> > On 09/30/2010 03:55 PM, Pascal Massimino wrote:
> >> On Thu, Sep 30, 2010 at 3:53 PM, Pascal Massimino<
> >> pascal.massimino <at> gmail.com>  wrote:
> >>
> >>>
> >>> Mike!
> >>> you're too fast!
> >
> > Sorry; had the day off and was a bit bored when I saw this news come
> > through.
> >
> >>> what about  http://pastebin.com/FbUvG77M
> >>>
> >>>
> >> attached, too. That's easier
> >
> > I was about to take the independent demuxer route as well. But then I
> > decided to figure out how the general image handling system operates. It
> > looks like the trade-off here is that the general image approach is less
> > code while the independent demuxer allows for the more advanced features
> > like metadata.
>

it's also useful to *encode* images using libvpx.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jason Garrett-Glaser | 1 Oct 2010 01:48
Picon

Re: [PATCH] Google WebP support

On Thu, Sep 30, 2010 at 3:52 PM, Mike Melanson <mike <at> multimedia.cx> wrote:
> Google released a new image format called WebP. It's basically a VP8 golden
> frame wrapped with a 20-byte header. Attached is a first pass at support.
> Here is a ready-made sample:
>
> http://samples.mplayerhq.hu/image-samples/webp/

Should we really support every single arbitrary file format released
by everyone, even if it isn't actually used by anyone for anything?

Mozilla has already rejected WebP.  I suspect this is going to be dead
on arrival.

Dark Shikari
Permalink | Reply | 5 comments |

Gmane