Updated again... theora works and seeks properly (not to keyframe) in WMP 9 and 10. You can encode from a bunch of onew input types like RGB32, RGB24, IYUV etc. And fixed a bug that was stopping the filters being used in a activeX control in an IE browser. www.illiminable.com/ogg/ Enjoy, Zen.
Hi Zen, On Saturday 25 September 2004 10:08, illiminable wrote:> You can encode from a bunch of onew input types like RGB32, RGB24, IYUV > etc.Thanks a lot, no need to use the ffdshow filter anymore :) I achieved some good progress during the last days. Now I can extract samples with the sample grabber and write them to files (for debugging). A custom Direct Show filter feeds these sample to a filter graph: /------> Theora Decoder ----1)---> VMR Video Renderer NCDShowFilter | \------> Speex Decoder ----------> Some audio device This works perfectly if the connection marked as 1) is NOT established. I can hear the sound encoded with Speex, and it doesn't care much about packet loss. But I somehow messed the video part up. As soon as I connect the decoder's output pin to the video renderer's input pin, the application crashes: -> Unhandled exception in netcam.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception. -> Thread 0xA00 terminated with Code 0 (0x0). -> Unhandled exception in netcam.exe (NTDLL.DLL): 0xC0000005: Access Violation. -> Unhandled exception in netcam.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception. -> Thread 0x970 terminated with Code 0 (0x0). -> "C:\Programme\illiminable\oggcodecs\dsfTheoraEncoder.dll" loaded. No symbol information. -> "C:\Programme\illiminable\oggcodecs\dsfAbstractVideoEncoder.dll" loaded. No symbol information. -> HEAP[netcam.exe]: Invalid allocation size - 96BE0100 (exceeded 7ffdefff) -> Unhandled exception in netcam.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception. This first exception occurs somewhere deep down in quartz.dll. When the debugger finally pops up, the stack trace reads: KERNEL32! 77e53887() MSVCR71! 7c359aed() MSVCP71! 7c3c8b5a() DSFTHEORAENCODER! 02186b0c() baadf010() As I'm using the same code for the NCDShowFilter-Video- and -Audio-Pins, I cannot think of a reason why this happens. Must be something special about the theora filter. You can have a look at my filter at http://www.huitl.de/NCDShowFilter.cpp and http://www.huitl.de/NCDShowFilter.h Bye, Robert P.S.: The MediaTypes have some weird values, but I got them by dumping the Theora/Speex-Encoders MediaTypes. So I guess this should be ok. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040928/f37d1f8a/attachment.pgp
----- Original Message ----- From: "Thomas Vander Stichele" <thomas@apestaart.org> To: "illiminable" <ogg@illiminable.com> Sent: Saturday, September 25, 2004 6:14 PM Subject: Re: [Theora-dev] Directshow filters 0.64.7878> Hi Zen, > > > On Sat, 2004-09-25 at 10:08, illiminable wrote: >> Updated again... theora works and seeks properly (not to keyframe) in WMP >> 9 >> and 10. >> >> You can encode from a bunch of onew input types like RGB32, RGB24, IYUV >> etc. >> >> And fixed a bug that was stopping the filters being used in a activeX >> control in an IE browser. >> >> www.illiminable.com/ogg/ > > Still, thanks for all the work you're doing on this. >No worries...> We are releasing our server next month, and we're wondering what your > timeline is wrt. having the ds filters play network streams nicely as > well. We'd like to be able to recommend that people install your > filters to watch streams. >I had a good look at it today... and have found that it's actually extremely difficult to reconfigure a running graph even under ideal conditions. Doing it properly for homogenous chains in all cases... is really hard... doing it for arbitrary chains looks like way way more trouble than it's worth... and i don't think any other player can do that yet anyway, so i'm not going to lose any sleep over that. I've found a world class dodgy way to do it for single stream vorbis network stream... which seems to have worked... i've been listening to virgin radio through 10 or so transitions and it seems to work (though it does look like WMP is getting a bit confused about what time it should be showing) I'm pretty sure i can do the same for a theora stream... though i can see some potential for losing sync particularly if one stream is actually longer than the other, but i'm sure i can hack my way around that. Is there a test server somewhere with a theora+vorbis stream ? The conditions under which i can get chaining to work with this hack are... a) The stream is non-seekable. b) Each chain contains the same number and type of codecs with the same settings (ie can't change the samplerate or the number of channels) c) The stream is valid. Which as far as i know this means it should be fine for icecast. I'm unsure at this stage what the effect is if the codebook changes mid stream... i'd have to check with conrad about what libfishsound will do in that situation. I've a feeling it's just dropping the extra headers. It's pretty likely i can do the same for speex, but flac looks like it will be much harder... but that's not really streamed often anyway. Also something i noticed on virgins site(http://www.virginradio.co.uk/thestation/listen/ogg.html)... which may interest you wrt to this... is that they supply links as .pls files. However WMP doesn't support .pls files (though winamp and iTunes do)... there may be a special filter around somewhere for it... but it's not instaled by default... so that may be something to keep in mind. In order to play the stream you need to save the .pls file and copy/paste the naked link out of the file into WMP. I think there's probably another playlist format that is windows friendly... maybe .m3u ? Cheers, Zen.
Hi Zen, Great work there! The filters are getting more stable and more functional in each revision. Is there any chance you could also compile an version where theora encoding is optimized in MMX, in the similar way that you did with SSE versions? Pretty please with sugar on top? :) Without MMX, video decoding is very slow. 640x480 video with sound takes about 50% CPU time of a 1.7GHz Athlon XP. Thanks, Alen ----- Original Message ----- From: "illiminable" <ogg@illiminable.com> To: <vorbis-dev@xiph.org> Cc: <flac-dev@xiph.org>; <theora-dev@xiph.org>; <speex-dev@xiph.org> Sent: Saturday, September 25, 2004 08:08 Subject: [Theora-dev] Directshow filters 0.64.7878> Updated again... theora works and seeks properly (not to keyframe) in WMP9> and 10. > > You can encode from a bunch of onew input types like RGB32, RGB24, IYUVetc.> > And fixed a bug that was stopping the filters being used in a activeX > control in an IE browser. > > www.illiminable.com/ogg/ > > Enjoy, > > Zen. > > > _______________________________________________ > Theora-dev mailing list > Theora-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/theora-dev >
----- Original Message ----- From: "Timothy B. Terriberry" <tterribe@vt.edu> To: "Robert Huitl" <theora-dev@huitl.de> Cc: <theora-dev@xiph.org> Sent: Sunday, October 10, 2004 1:24 AM Subject: Re: [Theora-dev] Directshow filters 0.64.7923>> The yOffset is wrong, though. With this theora block for decoding, the >> result is as seen on http://www.huitl.de/theora/wrong-yoffset.jpg. I get >> correct results using this formula: >> xOffset = width % 16 >> yOffset = height % 16 >> For the example shown above, yOffset will then be 8. With resolution 320 >> x 240, yOffset will be 0 and this seems to be correct, too. > > This is probably a confusion over whether yOffset is counted from the top > or from the bottom of the image (I actually forget which way is which in > the reference library). Also, note that both xOffset and yOffset should be > made even by the encoder to make chroma siting work as expected. See > Chapter 4 of the spec for details.I followed the code in example_player... which centralises the offsets... if there will be x_offset at the left and right and y_offset at the top and bottom. frame_x_offset=(video_x-frame_x)/2; frame_y_offset=(video_y-frame_y)/2; So in the example shown above... i think 4 is correct... Are you sure the offset values are being correctly propagated to the decoder ? Zen.> _______________________________________________ > Theora-dev mailing list > Theora-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/theora-dev > > >
> I followed the code in example_player... which centralises the > offsets... if there will be x_offset at the left and right and y_offset > at the top and bottom. > > frame_x_offset=(video_x-frame_x)/2; > frame_y_offset=(video_y-frame_y)/2;Does the example_encoder still do this? It should instead always make the offsets even, otherwise you suffer a half-pixel shift in the chroma components.> So in the example shown above... i think 4 is correct... Are you sure > the offset values are being correctly propagated to the decoder ?I just checked the reference code: the value specified in the theora_info struct is stored directly into the bitstream, and read directly back. Therefore, it should be the offset from the _bottom_ of the frame, not the top. Personally, I think the API should use the offset from the top, even though the offset from the bottom is what is in the bitstream, because the rest of the API uses a left-handed coordinate system where Y increases from top to bottom. This is the way it is set up in the experimental encoder/decoder.
----- Original Message ----- From: "Timothy B. Terriberry" <tterribe@vt.edu> To: "illiminable" <ogg@illiminable.com> Sent: Sunday, October 10, 2004 3:17 AM Subject: Re: [Theora-dev] Directshow filters 0.64.7923>> I think i previously tried just putting it at the top or the bottom and >> it didn't work, that's why i centred it. Maybe it's just a product of the >> files i tested on... perhaps a flag that indicates what the offset >> represents might be an idea ? Though i guess once things are finalised, >> it doesn't matter... though there's still the problem of the videos that >> are already floating around. > > No, it is already finalized. We froze the bitstream some time ago. The > offset _in the bitstream_ indicates the offset from the bottom. The API is > of course free to compute the offset from the top and return that to the > user, just like it flips the video upside down. This can still be changed, > but it does not affect anything that was already encoded. >OK... just curious why files that were apparently created with the latest release, seem to work with centred offsets but not with offsets at the top or bottom ? Zen.