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

[David Kuehling]

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

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

> ok, good point :) ...

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

> sorry, I meant it belongs in the library, not in each tool! :)

So you propose extending the liboggz API? :) What about:

   void oggz_set_content_type (OGGZ *oggz, long serialno, 
        const char *content_type) 
   const char *oggz_get_content_type (OGGZ *oggz, long serialno);

And for handling keyframe abstraction:

   int oggz_set_metric_ex (OGGZ *oggz, long serialno, 
        OggzMetricEx metric_ex, void *user_data);

   typedef int (* OggzMetricEx) (OGGZ *oggz, long serialno, void
        *user_data, int command, ...)

The OggzMetricEx would be an interface in anology to `fcntl' which would
be extensible and still provide backwards compatability.  Just return
non-zero if an unknown (unimplemented) command is issued.

What kind of commands would be needed?  Well, if an OggzMetricEx
callback was specified, it could be used for just everything, even
replacing the normal OggzMetric-code :

  metric (oggz, serialno, user_data, OGGZ_METRIC_EX_METRIC, 
        uint64_t granulepos, (unit64_t *)units);

content-type could also be handled by the new interface:
  
  metric (oggz, serialno, user_data, OGGZ_METRIC_EX_CONTENT_TYPE,
        char *content_type, int len);

and for the actual keyframe handling:

  metric (oggz, serialno, user_data, OGGZ_METRIC_EX_ISKEYFRAME,
        const oggz_packet *op, (int *)keyframe_flag);

To help finding the next keyframe to a given frame in O(log(n)), one
could use a somewhat more complex definition:

  metric (oggz, serialno, user_data, OGGZ_METRIC_EX_ISKEYFRAME,
        const oggz_packet *ref_op, const oggz_packet *op, 
        (int *)keyframe_flag);

Returning in keyframe_flag :

    0 : op does not contain a keyframe
    1 : op contains a keyframe (but it is not certain whether it is
        really exactly the next keyframe after ref_op.
    2 : op lies somewhere "to the left" of the keyframe that is searched
        for
    3 : op lies somewhere "to the right" of the keyframe that is
        searched for

And finally:

  metric (oggz, serialno, user_data, OGGZ_METRIC_EX_UNITS_TO_SECONDS,
        uint64_t units, int *seconds, int *nanoseconds);
  metric (oggz, serialno, user_data, OGGZ_METRIC_EX_SECONDS_TO_UNITS,
        int seconds, int nanoseconds, uint64_t *units);
        
Does this sound sensible?

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