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

[David Kuehling]

Hi,

>>>>> "Conrad" == Conrad Parker <conrad at metadecks.org> writes:

>> 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.

It was somehow counter-intuitive as writing has to be done directly,
circumventing the liboggz-write API...  maybe high-level abstraction
just doesn't fit with something as bare-bone as the ogg-container :)

> 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).

When do you plan to release a new version?  If some time still remains,
I'd prefer to add the missing features (ripping between start- and
end-offsets) before adding a man-page.

>> 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.

I thought that liboggz was specifically designed to hide this kind of
codec-specific knowledge.  After all, it uses its own codec-detection
code when opening ogg-streams with OGGZ_AUTO.  And it can already
interpret theora granulepos-values.  What does codec-independant seeking
help, if I cannot find the next keyframe?

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

To be able to find keyframes, I'd have to decode the first header packet
to look for the granulepos bit-shift used.  I guess that the
liboggz-code already does something like this, which is why I'm
reluctant of reimplementing it.

>> 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.

I don't understand, you mean that duplicating the auto-detection code is
really a good idea?

> 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 :)

Well, that shouldn't be a problem.  Is `fnmatch' supported with the
windows-compiler toolchain you use? :)

regards,

David
-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40