ogg dev - Apr 2008 - [PATCH] liboggplay - kate support, build fixes, and misc

Hi,

I've added kate support to liboggplay (a prerequisite to getting kate tracks
to work with the mozilla plugin, which I've now got working on Linux).

In addition to the Kate code:

- a new oggplay-uninstalled.pc file
- configure.ac checks for C++ compiler
- no check for fishsound version - it wanted 0.8.0, but the svn itself
was 0.7.1 !?
- don't use imlib2 (nor dump-first-frame) if it isn't here (I didn't
have this when I started hacking on liboggplay)
- frob the CFLAGS/LIBS in Makefile.am to make it build for me (you
want to look at this and only pick what seems correct to you, as I'm
hazy on that one)
- oggplay_set_track_inactive is now exposed in the API (I needed this
to switch kate tracks
on the fly in the browser plugin)


Cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: liboggplay-with-kate.diff
Type: text/x-patch
Size: 25497 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/ogg-dev/attachments/20080421/3f72bc69/attachment-0001.bin

On 21/04/2008, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at
googlemail.com> wrote:
> Hi,
>
>  I've added kate support to liboggplay (a prerequisite to getting kate
tracks
>  to work with the mozilla plugin, which I've now got working on Linux).
>
great!
>  In addition to the Kate code:
>
>  - a new oggplay-uninstalled.pc file
configure.ac:366: required file `oggplay-uninstalled.pc.in' not found

I think you forgot to include oggplay-uninstalled.pc.in in the patch :-)
>  - configure.ac checks for C++ compiler
>  - no check for fishsound version - it wanted 0.8.0, but the svn itself
>  was 0.7.1 !?
sorry, my bad -- recent releases have been coming out of
http://svn.annodex.net/libfishsound/branches/1.0-stable
The latest version is 0.9.1.

trunk is mostly up-to-date with that, and has some extra, incomplete, stuff.

(the liboggplay README does however specify the branch, just above the
line you added about Kate support ;-)
>  - don't use imlib2 (nor dump-first-frame) if it isn't here (I
didn't
>  have this when I started hacking on liboggplay)
>  - frob the CFLAGS/LIBS in Makefile.am to make it build for me (you
>  want to look at this and only pick what seems correct to you, as I'm
>  hazy on that one)
thanks, you added a missing $(FISHSOUND_CFLAGS) to src/liboggplay/Makefile.am
>  - oggplay_set_track_inactive is now exposed in the API (I needed this
>  to switch kate tracks
>  on the fly in the browser plugin)
ok!

There seems to be some inconsistency in the changes to the type of
sample_in_record and its accessor: the field was changed from int to
ogg_int64_t in src/liboggplay/oggplay_callback_info.h, and the return
type of the accessor function was changed from int to long in the
corresponding .c file and public header.

I've committed (in changeset:3561) everything except:

  - the changes which reference oggplay-uninstalled.pc
  - removal of the fishsound version check
  - the changes to the type of sample_in_record

cheers,

Conrad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: liboggplay-kate-int-long.diff
Type: text/x-patch
Size: 1985 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/ogg-dev/attachments/20080422/92d53b06/attachment.bin

> configure.ac:366: required file `oggplay-uninstalled.pc.in' not found
>
> I think you forgot to include oggplay-uninstalled.pc.in in the patch :-)
Ahem. I must have. I'll send it when I reach my dev machine.
> (the liboggplay README does however specify the branch, just above the
> line you added about Kate support ;-)
Ah, OK. I already had liboggplay svn around from before, so I didn't
think of checking this.
> There seems to be some inconsistency in the changes to the type of
> sample_in_record and its accessor: the field was changed from int to
> ogg_int64_t in src/liboggplay/oggplay_callback_info.h, and the return
> type of the accessor function was changed from int to long in the
> corresponding .c file and public header.
Yes, the reason is that all the routines here return a long (I presume so
they can be used from Python ?) so that's what I did here. However, the
number of samples (here, for me, granules) is an ogg_int64_t, so that's
what I put on the structure. Would you settle on long or ogg_int64_t ?

While there, a couple questions about the mozilla browser plugin, since
this is an annodex project:

- would you welcome kate support here too ?
- would additional optional dependencies beyond libkate be OK (I have
  none at the moment, but I'm thinking of fontconfig, and maybe later
  pango and cairo, though this is more long term)
- I've added new Javascript APIs to handle kate streams, and bumped
  the API version to 1.1 - is there anything I need to be aware of that
  might break with this API change ? Works fine here in a controlled
  environment (firefox 2.0.0.8, streaming from icecast).
- it seems to say it handles "application/liboggplay", but AFAIU, it
can
  understand all ogg streams (and isn't annodex
"application/annodex"
  anyway ?) so shouldn't that be changed to "application/ogg" ? I
know
  my test stream is a plain Ogg stream, and it works fine.
- and would a patch be accepted if there was no implementation of the
  kate code for mac and windows ?

Thanks

> I think you forgot to include oggplay-uninstalled.pc.in in the patch :-)
Attached, plus the oggplay.pc.in as well, as I added @KATE_CFLAGS@
to both.

Also attached is a patch to avoid miscounting the number of active tracks
(a bug in my previous patch), and the current patch to the mozilla plugin
(still work in progress, the Javascript API will change a little) if anyone
feels like commenting.

Cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oggplay.pc.in
Type: application/octet-stream
Size: 343 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/ogg-dev/attachments/20080423/086969e3/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: active_track.diff
Type: text/x-patch
Size: 285 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/ogg-dev/attachments/20080423/086969e3/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oggplay-uninstalled.pc.in
Type: application/octet-stream
Size: 355 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/ogg-dev/attachments/20080423/086969e3/attachment-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: browser_plugin-with-kate.diff.gz
Type: application/x-gzip
Size: 9546 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/ogg-dev/attachments/20080423/086969e3/attachment-0001.bin

> There seems to be some inconsistency in the changes to the type of
> sample_in_record and its accessor: the field was changed from int to
> ogg_int64_t in src/liboggplay/oggplay_callback_info.h, and the return
> type of the accessor function was changed from int to long in the
> corresponding .c file and public header.
Having heard no more about this, I'll make a patch that returns ogg_int64_t,
and hope Python likes it, is it OK ?