[Theora-dev] Directshow filters 0.65.7923 (was: Re: [Theora-dev]Directshow filters 0.64.7878)

illiminable ogg at illiminable.com
Sat Oct 9 11:52:43 PDT 2004


----- Original Message ----- 
From: "Robert Huitl" <theora-dev at huitl.de>
To: <theora-dev at xiph.org>
Sent: Sunday, October 10, 2004 1:09 AM
Subject: Re: [Theora-dev] Directshow filters 0.64.7923 (was: Re: 
[Theora-dev]Directshow filters 0.64.7878)

>On Thursday 07 October 2004 09:53, illiminable wrote:
>
>I tried the new 7923 build, the format blocks now read (without bitrates 
>and
>quality):
>-> THEORA FORMAT BLOCK
>---> sizeof = 48
>---> theoraVersion = 3131961357
>---> width = 160
>---> height = 128
>---> frameWidth = 160
>---> frameHeight = 120
>---> frameRateNumerator = 5
>---> frameRateDenominator = 1
>---> aspectNumerator = 0
>---> aspectDenominator = 0
>---> maxKeyframeInterval = 3
>---> xOffset = 0
>---> yOffset = 4
>---> colourSpace = 0
>The version is still missing. Maybe this isn't a problem, since it works :)

Bah... i knew i'd miss one ! The version field isn't used at the moment... 
so it won't cause a bug... but i will fix it.

>
>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.
>

See the post i made a second ago... as far as i know it is correct...

It's half the difference between the frame and the video. So 4 would be 
correct (following the example of the example player in libtheora). And 
since both the encoder and decoder both use centralised values, it doesn't 
greatly matter which is used so long as both agree on a convention.

As i mentioned in the other post... are you sure the offset values are being 
correctly propagated ?

If they are, let me know... as it's some other bug.

>I'm not sure about maxKeyframeInterval, since I configured the video 
>encoder
>to a keyframe freq of 15.

Yes... it stores the log2 value (rounded down).

>> If you need to see how to do that... look in TheoraStream, SpeexStream,
>> VorbisStream etc class in the demuxer, for the method createFormatBlock
>> which parses the headers. Or look in the spec docs for the appropriate
>> codec.
>
>Ok, I will have a look at this. Please upload the 7923 source code :)

Ooops... sorry about that... i just looked around for it... seems i didn't 
even make it... damn ! I've repackaged it and I'm uploading it now... then 
i'll send you an email when it's up on the site (probably take about 15 
mins)... not sure how i forgot that... but it certainly explains why no-one 
was downloading it ! :)

>
>While we're at it, maybe you can answer another DirectShow-related 
>question:
>              /------> Theora Decoder ---------> VMR Video Renderer
>NCDShowFilter |
              \------> Speex Decoder ----------> Some audio device
>
>With this decoder graph (or two separate NCDShowFilters for video and 
>audio),
>I get no audio playback, unless there are video packets fed to the graph. 
>It
>would be nice though to be able to only send audio to the peer.
>Synchronization is turned off for this graph. I guess the video renderer is
>waiting for its buffer to fill up, and blocks the graph until this happens. 
>I

Yeah... graphs won't start until each renderer in the graph has at least 1 
sample.

>could not yet find a solution to do audio/video playback independently. 
>Sure,
>I could use two filter graphs, but I'd lose the possibility to synchronize
>A/V (which I need to do soon), won't I?

I'm not sure i really understand what you are trying to do.

What is NCDShowFilter ?? Is this your network filter ?

If the peer doesn't want ever video in this sessoin, it probably shouldn't 
connect the Video Renderer... ie just connect a nothing filter (you might 
have to write it... but it's pretty simple... since the provided NULL 
renderer is also blocking).

Or another way, which is actually probably better if you would prefer to be 
able to turn on and off the video while the graph is still running... is 
just send a dummy theora frame which is all black (or a fancy logo or some 
kind of avatar if you are so inclined). This is a better way... you can 
either just send a single frame... i think a frame will persist until one 
replaces it even if it's presentation time has passed (but i'm not totally 
sure on that)...

You can definately... just keep sending the static frame at 1/2 second 
intervals say (with appropriate time stamps)... or you could even have a 
moving logo if you want to get fancy... and just a loop that sends the 
frames of the animation over and over. ie in NCDFilter... if video is 
disabled, it just generates frames itself rather than displaying those 
grabbed off the network.

You might have to do a bit of experimentation with theora to do this... ie 
create the filler video, and just use that as the video if there is none 
from the network... you will have to make sure you get the time stamping 
right though at the times when the video is switched back on.

If you use two FilterGraph objects yes... sync will be hard (probably very 
very hard)... but if you have two seperate filter chains within one 
FitlerGraph object they will sync just as if they were all one.

But with two chains you will still have the problem that all renderers must 
see at least one sample before the graph will transition.

Zen. 




More information about the Theora-dev mailing list