[libannodex-dev] [BUG] [PATCH] `oggzdump -r' broken

[Conrad Parker]

On Sat, Jan 01, 2005 at 03:51:09PM +0100, David Kuehling wrote:
> Hi, and happy new year!

Happy New Year to you too :)

> >   oggzrip -s 018514714 theora.ogg -o vid.theora.ogg
> 
> Patch attached.  This works different from an `oggzdump | oggzdump -r'
> pipeline, in that it filters on page rather than packet-level.
> Actually, vorbis-files will be somewhat broken if filtered by packet,
> since the granulepos=-1 of packets that don't have a page of their own
> might manifest in the output pages.

excellent, that's the right thing to do :) I've applied the patch to
svn.

I'll want to add a man page before releasing it, do you reckon you could
write one up? it should be pretty trivial to base it on the sgml sources
for oggzmerge(1) and anxrip(1).

> I also encountered some problems with liboggz:
> 
> * `oggz_get_bos (ordata->reader, serialno)' always returned 1, and was
>   thus unusable.

ah, that function's probably badly named. It just returns whether or not
that serialno has written its bos page yet, which is extremely unexciting
... So, I'd like to reclassify that from "unusable" to "useless" ;-)

> * oggz_tell didn't work for OGGZ_WRITE streams, always returning 0.

good point! I guess I didn't care about tell, when you can't seek. Or
something like that. That should be fixed.

> BTW I would like to extend the functionality of `oggzrip' to extracting
> only parts of bitstreams, given start and end-time or byte-offsets.  But
> how do I know, whether a page starts with a keyframe?

you need to know the specific mapping for that codec. We're specifying a
way of just reading this mapping from binary headers, in the latest
version of the Annodex spec -- but, in general (ie. for raw
theora streams etc.) you need to know how to interpret apart the granulepos.

(For theora, it's detailed in the "ogg mapping" part of the theora spec)

> Also I'd like to have access to codec-names for streams opened via
> OGGZ_AUTO, `oggzrip' currently uses its own code for detecting the
> codec.

awesome, that's where that kind of identification belongs.

In general, I'd prefer if the "codec-name" parts were reworded to
"content-type", and to allow content-type matches like "audio/*" in the
tools (in oggzdump as well :)

cheers, thanks for the excellent patch :)

Conrad.