search for: ogg_theora_decod

...ing a binary tree search of this first can help narrow the = initial search range for keyframes which have already been discovered<br> <br>It&#39;s all in the code here:<br><a href=3D"http://lives.svn.sourcefor= ge.net/viewvc/lives/trunk/lives-plugins/plugins/decoders/ogg_theora_decoder= .c">http://lives.svn.sourceforge.net/viewvc/lives/trunk/lives-plugins/plugi= ns/decoders/ogg_theora_decoder.c</a><br> <br>The only function to really consider is get_frame() which takes a (cons= t) char *URI (actually the current version really only takes a local file...

...h the keyframe, dropping packets until then. 6) Continue counting down until we reach the target frame, we are now decoding each frame/packet. At the target frame produce the YUV output. You can see this in code here: http://lives.cvs.sourceforge.net/viewvc/lives/lives-plugins/plugins/decoder= s/ogg_theora_decoder.c?view=3Dmarkup My code also builds an index of file_offset/granulepos at it discovers them, so it is ultra-efficient. Feel free to make use of this code. By the way, if anybody wants to use this code in liboggz I would recommend it. I and other users have been testing it for several weeks no...

...h the keyframe, dropping packets until then. 6) Continue counting down until we reach the target frame, we are now decoding each frame/packet. At the target frame produce the YUV output. You can see this in code here: http://lives.cvs.sourceforge.net/viewvc/lives/lives-plugins/plugins/decoder= s/ogg_theora_decoder.c?view=3Dmarkup My code also builds an index of file_offset/granulepos at it discovers them, so it is ultra-efficient. Feel free to make use of this code. By the way, if anybody wants to use this code in liboggz I would recommend it. I and other users have been testing it for several weeks no...

...est granule pos -> keyframe as this is discovered. Doing a binary tree search of this first can help narrow the initial search range for keyframes which have already been discovered It's all in the code here: http://lives.svn.sourceforge.net/viewvc/lives/trunk/lives-plugins/plugins/decoders/ogg_theora_decoder.c The only function to really consider is get_frame() which takes a (const) char *URI (actually the current version really only takes a local file name), and an int64_t frame number and returns the output in void *pixel_data[3] which should be pre-allocated to take a correctly sized YUV420 frame...

One of the issues I've consistently run into with the cortado player app is seek behavior, so I was curious to see how cortado handles video encoded with the latest ffmpeg2theora (0.26) and the new -seek-index option, so I tried converting an h.264 video: ffmpeg2theora tronlegacy-tsr1_480p.mov --seek-index This output the following advisory messages: > Allocated 372 bytes for theora

Hi, I am continuing to try to debug my ogg/theora decoder. The issue seems to be that not enough packets are being pulled from the bitstream, here is some sample output from my player with some debugging comments put in: (playback began at first frame, this is from the middle of the clip) get page at 1765027 got packet frame++, skip is 0 frame decoded page processed, kframe=414 : offs=442 get