Dear all I'm aware that there have been several discussions about the seeking issue and I'm sorry to bring this up again. To solve the problem with Inter-Frame garbage, a seek to the previous keyframe has to be made. The keyframe number should be extracted from the granulepos of the frame where we want to seek to. I hope I understood the theory - unfortunately a few questions have rised during implementation: - How do I extract the keyframe number? Is shifting the granule position by "keyframe_granule_shift" correct? - How can this be implemented using the OGGZ library? My current, _UGLY_, approach is the following: a) At the start of seeking, set the Packet-/Page-Callback to a new "Seek"-Callback b) A first OGGZ seek jumps to the desired frame number. c) OGGZ read() with some Bytes is called until the Seek-Packet/Page Callback was executed d) In the callback function, I get the granule pos (ogg_page_granulepos or oggz_tell_granulepos?), then I extract the keyframe number by shifting the granule position. e) A final OGGZ seek is made to the calculated keyframe number. f) Set callback(s) back to the actual data decoding functions. As the callbacks are being called asynchronously, I'm not even sure if my seek callback is being called with the desired frames/packets. I hope my question was not too confusing... Thanks for your help and any replies. Regards, Stefan
Dear all
Excuse me for pushing this again.
Can't somebody give me a little hint on how to setup OGGZ for seeking
with Theora?
Thanks in advance for your support.
Kind regards,
Stefan
----------------------
Dear all
I'm aware that there have been several discussions about the seeking
issue and I'm sorry to bring this up again.
To solve the problem with Inter-Frame garbage, a seek to the previous
keyframe has to be made. The keyframe number should be extracted from
the granulepos of the frame where we want to seek to. I hope I
understood the theory - unfortunately a few questions have rised during
implementation:
- How do I extract the keyframe number? Is shifting the granule position
by "keyframe_granule_shift" correct?
- How can this be implemented using the OGGZ library? My current,
_UGLY_, approach is the following:
a) At the start of seeking, set the Packet-/Page-Callback to a new
"Seek"-Callback
b) A first OGGZ seek jumps to the desired frame number.
c) OGGZ read() with some Bytes is called until the Seek-Packet/Page
Callback was executed
d) In the callback function, I get the granule pos
(ogg_page_granulepos or oggz_tell_granulepos?), then I extract the
keyframe number by shifting the granule position.
e) A final OGGZ seek is made to the calculated keyframe number.
f) Set callback(s) back to the actual data decoding functions.
As the callbacks are being called asynchronously, I'm not even sure if
my seek callback is being called with the desired frames/packets.
I hope my question was not too confusing...
Thanks for your help and any replies.
Regards,
Stefan
On Mon 28/06/10 7:57 PM , Stefan Weber s_weber at blyth.ch sent:> I'd really like to implement a correct seeking functionality.A quick hack to get visual artifact free seeking with liboggz is to seek to a time which should lie before a keyframe prior to your seek target, and then decode forwards to the target frame. This will mean seeking takes a few more MS (since you'll likely be decoding more than required), but it's better than visual artifacts after seeking, and is easy to implement to get seeking working. We can calculate the maximum time between frames as: max_keyframe_interval_ms = ((1 << th_info.keyframe_granule_shift) - 1) * th_info.fps_denominator / th_info.fps_numerator So seek to max_keyframe_interval_ms before your target and pump the decode until you reach the target frame. You may need to subtract a few extra milliseconds in there if you're not using the seek-rewrite branch of liboggz to work around old edge-edge case bugs. All the best, Chris P.> Whats the best method to get the time representation of a frame? > Regards, > Stefan > Am 21.06.2010 11:58, schrieb Stefan Weber: Dear all > Conrad, thank you for your inputs and your help so far. I will use > and test the seek-rewrite branch as soon as possible. > I figured out that the Keyframe position in the granulepos is the > NUMBER of the keyframe. When seeking with OGGZ, one has to supply the > TIME-position (milliseconds) of the desired frame. So I made a short > workaround by calculating the milliseconds position as follows: > ms = (granulepos >> shift) * 1000 / noFPS; > Needless to say, this won't point me to the exact keyframe > position. Probably this rough calculation is not exact enough? > What is the best approach to calculate the TIME-position for > oggz-seeking out of a given frame number? > Kind regards, > Stefan > >