similar to: ogg dirac granulepos in oggz tools

2008/11/14 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: >> I'm wondering if the Dirac granulepos parsing in liboggz and display >> in the oggz tools is currently correct, as I'd like to do a release of >> these soon. > > I believe it is -- although if correct support in the rest of the >

2008/11/26 David Flynn <davidf+nntp at woaf.net>: >>>> http://trac.annodex.net/changeset/3801 >>> >>> I'll test this shortly. > > Ok, i've tested muxing some audio and video together and that works fine. > woo. great, thanks :-) So the last remaining tool to check is oggz-chop. I at first assumed it would not work with Dirac's granulepos,

2008/11/21 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-21, Conrad Parker <conrad at metadecks.org> wrote: >> 2008/11/15 David Flynn <davidf+nntp at woaf.net>: >>> On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >>>> It seems oggz chop, merge and sort will need some attention to deal >>>> with the Dirac

On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: > I'm wondering if the Dirac granulepos parsing in liboggz and display > in the oggz tools is currently correct, as I'd like to do a release of > these soon. I believe it is -- although if correct support in the rest of the liboggz tools is required, a little more work may need to happen. > Here's some

On Thu, Nov 13, 2008 at 06:06:10PM +0900, Conrad Parker wrote: > A couple of days ago David Schleef mentioned there were some problems. > David, is that currently true (ie. since David Flynn's recent updates > to support Dirac), and if so could you please explain what the > problems are, or point me to a bugtracker where they are reported. eg. I mostly meant what you apparently

On Fri, Dec 05, 2008 at 06:34:41AM +0900, Conrad Parker wrote: > So the last remaining tool to check is oggz-chop. I at first assumed it > would not work with Dirac's granulepos, but it seems to do something > vaguely useful: > > conrad at chichai:~/share/oggz-chop$ oggz chop -s 7 -e 11 -o > sage-7-11.ogv ../dirac/sage-640x360.ogg > conrad at chichai:~/share/oggz-chop$

On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: > Should oggz-comment be modified to disallow modification of Dirac > streams, ie. does Ogg Dirac never contain VorbisComment metadata? Correct; there is no metadata handling capability in the current mapping spec. > It seems oggz chop, merge and sort will need some attention to deal > with the Dirac granulepos and

2008/11/15 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >> It seems oggz chop, merge and sort will need some attention to deal >> with the Dirac granulepos and dependency ordering, so let's leave them >> for the next release. > > ok. -- may be worth having them 'warn' if they are operating

dear list, i am trying to write a small program which reads an ogg file and writes it to another ogg file (and changes serial number, granulepos etc on the fly). reading the ogg file is ok (ogg_sync_pageout, ogg_stream_pagein, ogg_stream_packetout). but writing the file doesn't work - the granulepos and page structures don't match with the original file. here's what i am doing.

Hi there, First of all, sorry for my English I'm not a native english speaker. I need to develop and application witch does 3 tasks with oggs files : 1/ chain 2 ogg files 2/ extract a part from an ogg file 3/ add silence between two chained oggs files. Basically, - For the 1st task, I think that the best way to chain ogg files is to use the "cat" (on linux) or "copy

2009/6/18 Adam Rosi-Kessel <adam at rosi-kessel.org>: > Ivo Emanuel Gon?alves wrote, on 6/18/2009 6:14 AM: >> >> On 6/18/09, Conrad Parker<conrad at metadecks.org> ?wrote: >>> >>> This sounds like it needs a new tool specifically for fixing broken >>> Ogg files. >> >> I see two solutions: >> >> 1) the new vcut which I

David Flynn has proposed a new Ogg Dirac mapping. The draft is here: http://davidf.woaf.net/dirac-mapping-ogg.pdf This is a much bigger break from other codecs than my draft (at http://wiki.xiph.org/index.php/OggDirac). We talked a bit about it on IRC today. Below is my summary; hopefully David can correct anything I got wrong or misleading. Comments? There are two main differences

I have over 1,000 ogg vorbis files that are no longer playable or editable. I believe the main cause was a MediaMonkey plugin that automatically fetched album art and added it to the header. The plugin itself just uses the generic MediaMonkey metadata facility, but something happened -- perhaps when the album art bitmap image was too large -- that caused the files to no longer work.

2008/10/29 Romain Beauxis <toots at rastageeks.org>: > > I am currently implementing theora for our application. > In our model for generating ogg streams, we may want to stop > a stream while not providing a new YUV data buffer for encoding. > > Current API doesn't allow such thing, since the eos flag is set by the > packetout function only when the last_p parameter

On 6/18/09, Conrad Parker <conrad at metadecks.org> wrote: > This sounds like it needs a new tool specifically for fixing broken > Ogg files. I see two solutions: 1) the new vcut which I reckon will fix the problem since it has to split and rebuild the audio in a new Ogg 2) an Hex editor, even if just to check what's wrong in the metadata section -Ivo

When I try to 'make' oggz (0.9.9), I get the following compile error make[4]: Leaving directory `/c/liboggz/src/tools/oggz-chop' make[4]: Entering directory `/c/liboggz/src/tools' /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wextra -g -std=gnu99 -Wdeclaration-after-statement -Wno-unused -o oggz-info.exe oggz-info.o skeleton.o oggz_tools.o dirac.o

The definition of granule position for an OggDirac elementary stream isn't the same as theora. Index: tools/oggz_tools.c =================================================================== --- tools/oggz_tools.c (revision 3759) +++ tools/oggz_tools.c (working copy) @@ -454,7 +454,15 @@ iframe = granulepos >> granuleshift; pframe = granulepos - (iframe << granuleshift);

Hi While implementing OSS Ogg/Vorbis encoding and streaming using RTP/RTCP for both unicast and multicast, I have come across a few issues I need to clear out regarding the numbering of ogg_packets and their granulepos value. Below are the result for two different scenarios. <p>In the first scenario, ogg_packets are generated using a) vorbis_analysis_headerout() b) while

2009/6/18 Adam Rosi-Kessel <adam at rosi-kessel.org>: > On Thu, Jun 18, 2009 at 11:12:30PM +0900, Conrad Parker wrote: >> yow, that's pretty badly corrupted, the vorbis codebooks (usually the >> third packet) is completely gone. It looks like you'd need to throw >> away the first 16 packets, start with fresh headers, and copy in the >> rest of the data

2008/11/24 David Flynn <davidf+nntp at woaf.net>: > On a slightly unrelated note, i keep hitting the following error in > liboggz when using the oggz tools on an ogg dirac stream: > > /home/davidf/project/liboggz/src/liboggz/oggz.c:202: oggz_close: > Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed. > > I'll supply an example file tomorrow if that