4) Subtract 1 from the keyframe, then repeat step 3).
5) Begin reading from the frame discovered in step 4. Drop any packets
which are output on the first page. Count down until we reach 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/decoders/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
now, and this code is running flawlessly. There was one problem with
files with odd sized heights, that has been taken care of now.
Regards,
Gabriel.
http://lives.sourceforge.net
On Mon, Feb 16, 2009 at 9:20 AM, Conrad Parker <conrad at metadecks.org>
wrote:> 2009/2/16 Robin Siegemund <r.siegemund at digitalpublishing.de>:
>>
>> Thanks for your fast reply.
>>
>> Well, my decoding loop is based on the sample code that comes with
Theora so there are all necessary checks included. I think there is even no
other way to decode video/audio properly without checking the function results
because you need the feedback if more data is needed, a page is ready, packetOut
is successfully, etc.
>> And those -1 packets have correct packet numbers (in order) and they
are true content data.
>>
>> I also checked out the results from oggzdump. But this tool is even
more confusing because it seems not telling the truth. In the output you have
packets like:
>> 00:00:11.200: serialno 0000025769, granulepos 129|39, packetno 170: 513
bytes
>>
>> But also packets like:
>> 00:00:11.266: serialno 0000025769, calc. gpos 129|40, packetno 171:
1.013 kB
>>
>> So why it shows "calc. gpos"? I think this means oggzdump has
to calculate the position because it's originally not there. So I suppose
it's the same issue here but the tool doesn't want to print a -1.
>
> that's right -- there is no granulepos recorded in the file for those
> packets. Oggz is calculating the granulepos by keeping track of frame
> numbers and parsing the Theora packet headers.
>
> Older versions of oggz-dump printed -1, before the code to calculate
> the missing values was added.
>
>> It should be mentioned that I still use an aged 1.0alpha7 version of
libtheora but if the -1 granulepos is already in some packets of a file then
this is not decoder related at all. So maybe there was a bug in the old encoder
and the latest ffmpeg2theora still uses it, I don't know.
>
> It's not a bug (in theora or in your code). The granulepos of a packet
> is only recorded in the stream if it is the last packet ending on some
> page. So even in a case as simple as having a page that contains two
> complete packets, one after another, the first one will not have its
> granulepos recorded in the stream -- even though the encoder passed a
> granulepos value to libogg for writing.
>
> When that stream is parsed with libogg, libogg will set a value of -1
> in the ogg_packet structure for that first packet of the page.
>
> Ogg is a lossy container format, in that it will discard some
> timestamp information. (That information can usually be reconstructed,
> as oggz does, with some understanding of the codec).
>
> This is one reason that Ogg formats which require granulepos on all
> packets (like CMML and Kate :) mandate that only one packet is allowed
> per page.
>
> Conrad.
> _______________________________________________
> theora-dev mailing list
> theora-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/theora-dev
>
_______________________________________________
theora-dev mailing list
theora-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/theora-dev
