Hi, these are a few bits I found while working out why ogginfo was barfing on a stream (see previous oggz-comment patch). It fixes 32/64 bit %lld format bugs (vorbis and kate), adds a missing argument to a warning message, adds comments to what the return values of pageseek mean, and doesn't read more data if unneeded (this will lessen the memory used, but might mean worse performance, so the previous code might have done this on purpose ?) Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: ogginfo-format+missing-argument+read-what-we-need+comments.diff Type: text/x-patch Size: 2155 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20080922/2d587a21/attachment.bin
On 9/22/08, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote:> It fixes 32/64 bit %lld format bugs (vorbis and kate), adds a missing > argument to a warning message, adds comments to what the return values of > pageseek meanSo far so good.> and doesn't read more data if unneeded (this will lessen the memory > used, but might mean worse performance, so the previous code might have done > this on purpose ?)If you meant the "hole" thing, ogginfo seems to be badly coded here because it will just start spamming non-stop that message while reading anything not Ogg, which is quite unlikely to have been the intent, so if it the patch forces it to stop before reaching the end of the file that's probably for the best. Will take a closer look into this in the weekend. Thank you. -Ivo
> If you meant the "hole" thing, ogginfo seems to be badly coded here > because it will just start spamming non-stop that message while > reading anything not Ogg, which is quite unlikely to have been the > intent, so if it the patch forces it to stop before reaching the end > of the file that's probably for the best. Will take a closer look > into this in the weekend.It is not intended to do this, but to only read more data when it is needed to avoid spamming the sync state. I think the amount of TTY spam ought to be the same as before. Maybe it should spam once per hole, whatever the hole size.