Re: GStreamer 0.01

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Aristotle Pagaltzis
* Torsten Schoenfeld <[hidden email]> [2005-05-26 19:10]:
> The perl-xs guys suggested converting numbers to/from PVs (Perl
> strings) and tell users to use Math::BigInt for calculations.
> I'll see if this works out.

Math::BigInt::FastCalc can help avoid the glacial speed of
vanilla Math::BigInt::Calc. Recent versions of Math::BigInt will
automatically use ::FastCalc in place of ::Calc when available.
Other options include ::GMP or ::Pari, which however have much
larger dependencies.

Then there’s Math::BigInt::Lite, which uses native Perl integer
operations as long as Perl integers have sufficient range, and
upgrades itself to Math::BigInt when Perl integers would
overflow. This must be used in place of Math::BigInt.

Finally, there’s the bigint/bignum/bigfloat pragmata, which
automatically load the corresponding Math:: modules and which
will autobox constants. bignum/bigint will automatically use
::Lite if it’s available.

So yeah, anyway. The point is, vanilla ::BigInt is cosmologically
slow, but with just a moment taken to install another module or
two you can get much better speed for zero programming effort.

This should go somewhere into the GStreamer POD (not necessarily
in as much detail as I went into), because not everyone’s going
to know about it.

Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Jan Hudec
On Fri, May 27, 2005 at 07:48:31 +0200, A. Pagaltzis wrote:

> * Torsten Schoenfeld <[hidden email]> [2005-05-26 19:10]:
> > The perl-xs guys suggested converting numbers to/from PVs (Perl
> > strings) and tell users to use Math::BigInt for calculations.
> > I'll see if this works out.
>
> Math::BigInt::FastCalc can help avoid the glacial speed of
> vanilla Math::BigInt::Calc. Recent versions of Math::BigInt will
> automatically use ::FastCalc in place of ::Calc when available.
> Other options include ::GMP or ::Pari, which however have much
> larger dependencies.
>
> Then there???s Math::BigInt::Lite, which uses native Perl integer
> operations as long as Perl integers have sufficient range, and
> upgrades itself to Math::BigInt when Perl integers would
> overflow. This must be used in place of Math::BigInt.
>
> Finally, there???s the bigint/bignum/bigfloat pragmata, which
> automatically load the corresponding Math:: modules and which
> will autobox constants. bignum/bigint will automatically use
> ::Lite if it???s available.
>
> So yeah, anyway. The point is, vanilla ::BigInt is cosmologically
> slow, but with just a moment taken to install another module or
> two you can get much better speed for zero programming effort.
>
> This should go somewhere into the GStreamer POD (not necessarily
> in as much detail as I went into), because not everyone???s going
> to know about it.
Shouldn't it really be done in Glib? Glib provides the gint64 and
guint64 types and I assume GStreamer just uses them. So it should be the
Glib typemap that maps them to appropriate Math::BigInt types.

Ok, the warning should still exist in GStreamer documentation, since the
type is not used much by other Glib users.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec <[hidden email]>

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Aristotle Pagaltzis
* Jan Hudec <[hidden email]> [2005-05-27 17:50]:
> Shouldn't it really be done in Glib? Glib provides the gint64
> and guint64 types and I assume GStreamer just uses them. So it
> should be the Glib typemap that maps them to appropriate
> Math::BigInt types.

Are you referring to my paragraph about bigint/bignum? That would
be superfluous if GStreamer had Glib typemap, I suppose.

And using Math::BigInt::Lite would be harder (not possible?).

But at least the first paragraph still applies: anyone wanting to
do any amount of math on those values will want an XS-based core
library for Math::BigInt (::FastCalc, ::GMP, ::Pari) instead of
the default ::Calc that is pure-Perl.

Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Jan Hudec
In reply to this post by Jan Hudec
On Fri, May 27, 2005 at 19:36:47 +0200, A. Pagaltzis wrote:

> * Jan Hudec <[hidden email]> [2005-05-27 17:50]:
> > Shouldn't it really be done in Glib? Glib provides the gint64
> > and guint64 types and I assume GStreamer just uses them. So it
> > should be the Glib typemap that maps them to appropriate
> > Math::BigInt types.
>
> Are you referring to my paragraph about bigint/bignum? That would
> be superfluous if GStreamer had Glib typemap, I suppose.
>
> And using Math::BigInt::Lite would be harder (not possible?).
I probably misunderstood the issue in question. I supposed the large
numbers are handled correctly by the bindings, but now I see the issue
is, that the constants are not writable in perl, but if they were
written properly as Math::BigInt, they would be properly passed to the
C level.

> But at least the first paragraph still applies: anyone wanting to
> do any amount of math on those values will want an XS-based core
> library for Math::BigInt (::FastCalc, ::GMP, ::Pari) instead of
> the default ::Calc that is pure-Perl.

Sure. Pure-perl implementation of Math::BigInt is damn slow.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec <[hidden email]>

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Torsten Schoenfeld
In reply to this post by Jan Hudec
On Fri, 2005-05-27 at 09:15 +0200, Jan Hudec wrote:

> > This should go somewhere into the GStreamer POD (not necessarily
> > in as much detail as I went into), because not everyone???s going
> > to know about it.
>
> Shouldn't it really be done in Glib? Glib provides the gint64 and
> guint64 types and I assume GStreamer just uses them. So it should be the
> Glib typemap that maps them to appropriate Math::BigInt types.

Yeah, I think that, if the approach works out and has been tested for
some time in GStreamer, it should end up in Glib so all bindings can
profit.

--
Bye,
-Torsten

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Torsten Schoenfeld
In reply to this post by Aristotle Pagaltzis
On Thu, 2005-05-26 at 19:05 +0200, Torsten Schoenfeld wrote:

> > The GStreamer bindings will probably have to depend on Math::BigInt  
> > for these numbers.
>
> The perl-xs guys suggested converting numbers to/from PVs (Perl strings)
> and tell users to use Math::BigInt for calculations.  I'll see if this
> works out.

I just committed an initial implementation of that approach.  The
converters look like this:

  SV *
  newSVGstInt64 (gint64 value)
  {
        char string[100];
        STRLEN length;
        SV *sv;

        /* newSVpvf doesn't seem to work correctly. */
        length = sprintf(string, "%lli", value);
        sv = newSVpv (string, length);

        return sv;
  }

  gint64
  SvGstInt64 (SV *sv)
  {
        return atoll (SvPV_nolen (sv));
  }

  SV *
  newSVGstUInt64 (guint64 value)
  {
        char string[100];
        STRLEN length;
        SV *sv;

        /* newSVpvf doesn't seem to work correctly. */
        length = sprintf(string, "%llu", value);
        sv = newSVpv (string, length);

        return sv;
  }

  guint64
  SvGstUInt64 (SV *sv)
  {
        return atoll (SvPV_nolen (sv));
  }

In my minimal testing, it seems to work.  It doesn't look like you need
Math::BigInt to do calculations with these numbers.  This worked for me:

  Glib::Timeout -> add(5000, sub {
    my ($format, $pos) = $spider -> query("position", "time");

    $sink -> seek([qw/method-set flag-flush time/], $pos + 5 * GST_SECOND);

    return TRUE;
  });

--
Bye,
-Torsten

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Aristotle Pagaltzis
* Torsten Schoenfeld <[hidden email]> [2005-05-29 16:25]:
> In my minimal testing, it seems to work.  It doesn't look like
> you need Math::BigInt to do calculations with these numbers.

If there’s only a string value in a scalar, Perl converts it to
an integer before doing any math, as we all know. So values
< 2**32 automatically work, but there’s no actual difference to
providing integers.

Did you actually test with values that would overflow a Perl
integer?

Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Torsten Schoenfeld
On Sun, 2005-05-29 at 16:39 +0200, A. Pagaltzis wrote:

> If there’s only a string value in a scalar, Perl converts it to
> an integer before doing any math, as we all know. So values
> < 2**32 automatically work, but there’s no actual difference to
> providing integers.
>
> Did you actually test with values that would overflow a Perl
> integer?

Yeah.  And it seems to work.  This

  Glib::Timeout -> add(5000, sub {
    my ($format, $pos) = $spider -> query("position", "time");

    warn "$pos, ", $pos + 5 * GST_SECOND;
    $sink -> seek([qw/method-set flag-flush time/], $pos + 5 * GST_SECOND);

    return 1;
  });

prints:

  5265102040, 10265102040 at player.pl line 48.
  15127777777, 20127777777 at player.pl line 48.
  24797437641, 29797437641 at player.pl line 48.
  ...

GST_SECOND is 1_000_000_000.  For reference: 2**32 is 4_294_967_296.

I'm attaching the whole test program I used.

--
Bye,
-Torsten

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

player.pl (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Matthias Bläsing-4
In reply to this post by Torsten Schoenfeld
Just checked out GStreamer-Changes and great it's working as expected!

What remains is the  problem of the duration-Tag. This is what I do:

On each "found-tag" Signal put everything into a common hash:
foreach my $key (keys(%{$tags})) {
        $self->{'ts'}->{'info'}->{$key} = $tags->{$key};
}

Then I run the duration Tag through a format routine:
ns2nice($self->{'ts'}->{'info'}->{'duration'}[0]);

The routine:
ns2nice {
        my $ns = shift;
...
}

When called for the return value of a query I get the right log value
when printing $ns (yes even with value > 2^32) and even calculating with
it works all right!

So I think the problem begins when the tags get converted to the hash.

Mfg

Matthias
--
Matthias Bläsing
ICQ: 84617206   AIM: linuxfun81   MSN: [hidden email]
"Diejenigen, die nicht schockiert sind, wenn sie zum ersten mal mit
Quantenmechanik zu tun haben, haben sie nicht verstanden." (Niels Bohr)

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Torsten Schoenfeld
On Mon, 2005-05-30 at 20:16 +0200, Matthias Bläsing wrote:

> When called for the return value of a query I get the right log value
> when printing $ns (yes even with value > 2^32) and even calculating with
> it works all right!
>
> So I think the problem begins when the tags get converted to the hash.

Does it work when you use Math::BigInt for storing the values and doing
the calculations?

--
Bye,
-Torsten

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Matthias Bläsing-4
Am Montag, den 30.05.2005, 20:36 +0200 schrieb Torsten Schoenfeld:

> On Mon, 2005-05-30 at 20:16 +0200, Matthias Bläsing wrote:
>
> > When called for the return value of a query I get the right log value
> > when printing $ns (yes even with value > 2^32) and even calculating with
> > it works all right!
> >
> > So I think the problem begins when the tags get converted to the hash.
>
> Does it work when you use Math::BigInt for storing the values and doing
> the calculations?

Well actually I don't do anything with the values, apart from passing
the between routines. So this is it:

Tags-Hash >> My-Hash >> convert(My-Hash->{'duration'})

And the values passed to the convert function are truncated. I already
tried

convert(Math::BigInt->new(My-Hash->{'duration'})

I doesn't work either!

So I grabbed the duration value in the "found-tags" call back and
printed the value there and yeak its < 2^32! So everything, which
reaches the perl level is already clamped.

HTH

Matthias

--
Matthias Bläsing
ICQ: 84617206   AIM: linuxfun81   MSN: [hidden email]
"Diejenigen, die nicht schockiert sind, wenn sie zum ersten mal mit
Quantenmechanik zu tun haben, haben sie nicht verstanden." (Niels Bohr)

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Torsten Schoenfeld
On Mon, 2005-05-30 at 20:51 +0200, Matthias Bläsing wrote:

> So I grabbed the duration value in the "found-tags" call back and
> printed the value there and yeak its < 2^32! So everything, which
> reaches the perl level is already clamped.

Ok, the problem is that the standard GValue converters don't handle
64bit types correctly yet.  I special-cased them in the GstTagList
wrappers now.  This *should* fix the problem.  I'm unable to test it
though, because neither id3tag nor mad nor spider seem to give me a
`duration' tag.

--
Bye,
-Torsten

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: GStreamer 0.01

Matthias Bläsing-4
Am Mittwoch, den 01.06.2005, 20:03 +0200 schrieb Torsten Schoenfeld:

> On Mon, 2005-05-30 at 20:51 +0200, Matthias Bläsing wrote:
>
> > So I grabbed the duration value in the "found-tags" call back and
> > printed the value there and yeak its < 2^32! So everything, which
> > reaches the perl level is already clamped.
>
> Ok, the problem is that the standard GValue converters don't handle
> 64bit types correctly yet.  I special-cased them in the GstTagList
> wrappers now.  This *should* fix the problem.  I'm unable to test it
> though, because neither id3tag nor mad nor spider seem to give me a
> `duration' tag.

I just had time to check out the cvs Code an yeah! Now I get the
expected values! Thanks!

You should think about pushing that change into the base converters - I
asume this would protect us all from unexpected results, when dealing
with 64Bit Values.

Thanks

Matthias

PS: I don't now from where the duration Tag commes, but I use a
decodebin and at least when reading mp3, it spits it out...

--
Matthias Bläsing
ICQ: 84617206   AIM: linuxfun81   MSN: [hidden email]
"Diejenigen, die nicht schockiert sind, wenn sie zum ersten mal mit
Quantenmechanik zu tun haben, haben sie nicht verstanden." (Niels Bohr)

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list