Hello All, When going through the Ogg format, I have a basic question. As per the RFC the Ogg format encapsulates the logical stream. Now consider the scenario where a raw mono stream is being encoded with Opus Codec. The stream is 48KHz and the length of the stream being encoded is worth 20ms of data. This makes it 960 half words (considering 16 bit format). Now if the final output is say 100 half words, then First Packet shall have Header Type as BOS All subsequent Packet (except last one_ shall have Header Type as Continuation Last Packet shall have Header Type as EOS Is this correct? The Page Segment shall have the value as 1 since only one segment will be available and the Segment Table will have the value 100 indicating that the next 100 bytes are belonging to the same stream and is one encoded frame Is this correct? If the above is true then if the Page Segment has the value 20, then the segment table shall look something like (assuming 100 half words is what is encoded evry time) 100, Data.... 20 times before the next Page Segment is started!!! Regards Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160509/2d9df34e/attachment.html>
Amit Ashara wrote:> First Packet shall have Header Type as BOS > All subsequent Packet (except last one_ shall have Header Type as > Continuation > Last Packet shall have Header Type as EOS > > Is this correct?No, the header_type field is a property of a page, not a packet. In it, the continuation flag is used when a single packet spans multiple pages. This is required when a packet is larger than the maximum size of a page (about 64 kB), but in most uses of Opus will almost never be needed.> The Page Segment shall have the value as 1 since only one segment will > be available and the Segment Table will have the value 100 indicating > that the next 100 bytes are belonging to the same stream and is one > encoded frame > > Is this correct?No. You are required to have at least three pages: one for the identification header (OpusHead), which must contain only that packet, one (or more) for the metadata header (OpusTags), which must terminate the page it ends on, and then one more for your 20 ms audio data packet. In the description, you also said that the final output was 100 halfwords (200 bytes). The value in the page segment table is the number of bytes, not the number of halfwords.> If the above is true then if the Page Segment has the value 20, then the > segment table shall look something like (assuming 100 half words is what > is encoded evry time) > > 100, Data.... 20 times before the next Page Segment is started!!!No. The segment table contains the lacing values for all packets on the page, followed by the data for all packets. So it would look more like: 20 (number_page_segments) 100, 100, 100 ... (20 times, the segment_table), data, data, data, ... (again, 20 times). It may be easier for you to work from some examples. I'd recommend looking at the code in opus-tools: <https://git.xiph.org/?p=opus-tools.git>. This gets all of these details correct.
Hello Tim I am referring to the following file https://en.wikipedia.org/wiki/File:Sample_of_%22Another_Day_in_Paradise%22.ogg I opened the file in a HEX editor. I do not see the string OpusHead in the packet. It starts with Oggs. Also checking the occurrence of Oggs, I see that the first packet has BOS, the next all (except last) have 00 (which is not defined in the RFC as continuation) and last one has EOS. The first packet in this ogg file makes sense. The second packet (I am taking a part of it) 4f 67 67 53 = Oggs (THIS IS OK) 00 = Version (THIS IS OK) 00 = Header Type (WHY IS THIS 0)?? 00 00 00 00 00 00 00 00 = Granule Position (THERE IS NO SPECIFIC INFORMATION) 7e 46 00 00 = Bit Stream Serial Number (THIS IS OK) 01 00 00 00 = Page Sequence Number (THIS IS OK) 89 ab 50 5e = Checksum (THIS IS OK) 10 = Page Segments is 16, so there would be 16 segments after this 2d ff ff ff ff ff ff ff ff ff ff ff ff ff ff c1 = Each Segment Size (IS THIS CORRECT)?? 03 76 6f = First 3 data from Segment 0 indicated by the size 2d (IS THIS CORRECT INTERPRETATION)?? Regards Amit On Mon, May 9, 2016 at 1:01 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote:> Amit Ashara wrote: > >> First Packet shall have Header Type as BOS >> All subsequent Packet (except last one_ shall have Header Type as >> Continuation >> Last Packet shall have Header Type as EOS >> >> Is this correct? >> > > No, the header_type field is a property of a page, not a packet. In it, > the continuation flag is used when a single packet spans multiple pages. > This is required when a packet is larger than the maximum size of a page > (about 64 kB), but in most uses of Opus will almost never be needed. > > The Page Segment shall have the value as 1 since only one segment will >> be available and the Segment Table will have the value 100 indicating >> that the next 100 bytes are belonging to the same stream and is one >> encoded frame >> >> Is this correct? >> > > No. You are required to have at least three pages: one for the > identification header (OpusHead), which must contain only that packet, one > (or more) for the metadata header (OpusTags), which must terminate the page > it ends on, and then one more for your 20 ms audio data packet. > > In the description, you also said that the final output was 100 halfwords > (200 bytes). The value in the page segment table is the number of bytes, > not the number of halfwords. > > If the above is true then if the Page Segment has the value 20, then the >> segment table shall look something like (assuming 100 half words is what >> is encoded evry time) >> >> 100, Data.... 20 times before the next Page Segment is started!!! >> > > No. The segment table contains the lacing values for all packets on the > page, followed by the data for all packets. So it would look more like: > > 20 (number_page_segments) 100, 100, 100 ... (20 times, the segment_table), > data, data, data, ... (again, 20 times). > > It may be easier for you to work from some examples. I'd recommend looking > at the code in opus-tools: <https://git.xiph.org/?p=opus-tools.git>. This > gets all of these details correct. > _______________________________________________ > opus mailing list > opus at xiph.org > http://lists.xiph.org/mailman/listinfo/opus >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160509/92f8c3be/attachment.html>
>>> "Timothy B. Terriberry" <tterribe at xiph.org> schrieb am 09.05.2016 um 20:01 inNachricht <5730D079.6040207 at xiph.org>: [...]> It may be easier for you to work from some examples. I'd recommend[...] I'm not deeply in the specs, but quite frequently when you need an example to understand the specs, the specs should be improved. Maybe just because examples aren't normative, but specs should be. MHO... Regards, Ulrich