Just trying to debug my theora encoder... just wondering if someone could give me some insight on a few thigns... In the yuv_buffer i'm sending in... i am just setting y_stride = y_width = videoWidth uv_stride = videoWidth/2 y_height = videoHeight uv_height = videoHeight/2 Making the y buffer (width*height) and each of u and v (width*height/4) Am i correct in doing this ? I knwo stride needn't equal width... but from the videos width, can i just make them equal ? Any restrictions ? Also the other encoding parameters... i am just using the default values shown in the encoder example... For the bitrate fields... what happens if i set it to 0 ? Will it do some default action ? Also the aspect ratio fields... i am just setting aspect_numerator = videoWidth aspect_denominator = videoHeight Am i correct in doing this ? Any restrictions ? Also... i'm noticing that most of the filters in directshow output YUY2 and not YUV12... just curious if there is code floating around somewhere to do the conversion before i write it myself... it doesn't look too complex anyway. Also, looking at some wmv output... (which is a format that outputs YV12)... it doesn't set a frame rate in the setup header... so i assume this means it's a variable frame rate if such a thing exists ?? Any thoughts on the best way to map a variable frame rate output onto theoras fixed frame rate ? Thanks, Zen.
> For the bitrate fields... what happens if i set it to 0 ? Will it do some > default action ?as you can see in the example encoder, than bitrates are set to 0 the quality mode is used. you should scale the video quality from 0-10(as the example encoder does) and use the internal values from 0-63.> Also the aspect ratio fields... i am just setting > aspect_numerator = videoWidth > aspect_denominator = videoHeight > Am i correct in doing this ? Any restrictions ?as just discussed on irc this is the *pixel* aspect ratio. here is a nice table to get an idea of the mess. http://www.mir.com/DMG/aspect.html#reftable if you do not want any scaling set it to 0:0 j
----- Original Message ----- From: "Timothy B. Terriberry" <tterribe@vt.edu> To: "illiminable" <ogg@illiminable.com> Sent: Wednesday, June 30, 2004 3:30 AM Subject: RE: [Theora-dev] Encoding theora...> >In the yuv_buffer i'm sending in... i am just setting > > > >y_stride = y_width = videoWidth > >uv_stride = videoWidth/2 > >y_height = videoHeight > >uv_height = videoHeight/2 > > > >Making the y buffer (width*height) and each of u and v (width*height/4) > > > >Am i correct in doing this ? I knwo stride needn't equal width... butfrom> >the videos width, can i just make them equal ? Any restrictions ? > > The stride you provide is derived from the layout in memory of your frame > data. If your data is just a videoWidth*videoHeight array, then settingstride> equal to the width is the correct thing to do. >OK... thanks...> >For the bitrate fields... what happens if i set it to 0 ? Will it do some > >default action ? > > AFAIK encoder_example sets it to 0. > > >Also the aspect ratio fields... i am just setting > > > >aspect_numerator = videoWidth > >aspect_denominator = videoHeight > > > >Am i correct in doing this ? Any restrictions ? > > No, this is incorrect. The aspect ratio is the pixel aspect ratio, not the > frame aspect ratio. For square pixels, set both values to 1. >Aha ! I thought it that was wrong !> >Also... i'm noticing that most of the filters in directshow output YUY2and> >not YUV12... just curious if there is code floating around somewhere todo> >the conversion before i write it myself... it doesn't look too complex > >anyway. > > I'm sure ffmpeg or mplayer or some other GPL'd project has code to dothis. I'd prefer to find something BSD licensed... i might just write it myself.> One thing to be careful about is the chroma sampling positions, whichoften> differ between 4:2:2 and 4:2:0 formats. Not that you can really tell what > they're supposed to be from a FOURCC. >Yeah... i noticed that when looking around... there's a half pixel offset depending whether the sampling positions are aligned to the pixels or aligned between two pixels.> >Also, looking at some wmv output... (which is a format that outputsYV12)...> >it doesn't set a frame rate in the setup header... so i assume this means > >it's a variable frame rate if such a thing exists ?? Any thoughts on the > >best way to map a variable frame rate output onto theoras fixed framerate ?> > As I understand it, a lot of dshow filters don't specify a framerate, evenif> it _is_ constant and known. Most solutions seem to be of the "ask the userfor> one" variety.OK... fair enough.... Thanks very much for your help.... Maybe now i can get it to create something other than a solid pink frame ! :) Zen.
<1088537690.15845.42.camel@x30> Message-ID: <004d01c45e76$34f65fd0$0100000a@tiger> ----- Original Message ----- From: <j@thing.net> To: <theora-dev@xiph.org> Sent: Wednesday, June 30, 2004 3:34 AM Subject: Re: [Theora-dev] Encoding theora...> > > For the bitrate fields... what happens if i set it to 0 ? Will it dosome> > default action ? > as you can see in the example encoder, than bitrates are set to 0 thequality mode> is used. you should scale the video quality from 0-10(as the example > encoder does) and use the internal values from 0-63.But this is coded into the encoder example... not libtheora... ie libtheora expects the application to use those quality numbers to generate a bitrate value... I've actually been playing with that... and setting it to zero really does attempt to make a 0 bitrate file... and i got 4 minutes of 720x480 into 200k of compressed video... So i've tried upping the values to 1000000, and i get larger files... about 900k this time which still seems way too small... it should be about 5-7 megs. When i play it back... i get an all pink frame... with slight movement at the top edge of teh frame and occasionally horizontal white lines at the top of the frame which get brighter then fade then scroll a bit then disappear.... does that mean anything to anyone ? Maybe i need to boost the quality settings right up to. Thanks, Zen.
<004d01c45e76$34f65fd0$0100000a@tiger> Message-ID: <005301c45e79$8886dcd0$0100000a@tiger>> When i play it back... i get an all pink frame... with slight movement at > the top edge of teh frame and occasionally horizontal white lines at thetop> of the frame which get brighter then fade then scroll a bit then > disappear.... does that mean anything to anyone ? > > Maybe i need to boost the quality settings right up to.OK... well i fixed it (kind of)... i was overwriting the buffer and not advancing my pointers properly... which is why the activity was only in the top of the screen as i was overwriting the entire buffer over the first line. Now it does produce proper output at least until it crashes. Now some new crashing bugs to fix ! Thanks, Zen.
<005301c45e79$8886dcd0$0100000a@tiger> Message-ID: <005b01c45e7c$181cc1f0$0100000a@tiger> ----- Original Message ----- From: "illiminable" <ogg@illiminable.com> To: <theora-dev@xiph.org> Sent: Wednesday, June 30, 2004 4:09 PM Subject: Re: [Theora-dev] Encoding theora...> > When i play it back... i get an all pink frame... with slight movementat> > the top edge of teh frame and occasionally horizontal white lines at the > top > > of the frame which get brighter then fade then scroll a bit then > > disappear.... does that mean anything to anyone ? > > > > Maybe i need to boost the quality settings right up to. > > OK... well i fixed it (kind of)... i was overwriting the buffer and not > advancing my pointers properly... which is why the activity was only inthe> top of the screen as i was overwriting the entire buffer over the first > line. Now it does produce proper output at least until it crashes. > > Now some new crashing bugs to fix ! >OK... i found my craching bug... my buffer was not big enough to output to. So what i need to know is what is the maximum possible size packet that theora can output ? Is there some rough guestimation formula i can use to find it based on parameters... or failing that... just the maximum possible size... though considering i think i read theora can handle 2mil pixel squared images... i think an absolute max value is not really realistic... Thanks, Zen.
----- Original Message ----- From: "Timothy B. Terriberry" <tterribe@vt.edu> To: "illiminable" <ogg@illiminable.com> Sent: Wednesday, June 30, 2004 10:55 PM Subject: RE: [Theora-dev] Encoding theora...> >Is there some rough guestimation formula i can use to find it based on > >parameters... or failing that... just the maximum possible size... though > >considering i think i read theora can handle 2mil pixel squared images...i> >think an absolute max value is not really realistic... > > The maximum possible size is... large. 42 bits per sample (up to 3 > samples/pixel in 4:4:4 mode), plus additional motion vectors, quantizer > settings, etc. But that assumes you've chosen the worst possible Huffmancodes> to encode with and managed to construct some horrendous noise to encode.I'm> not even sure you could create an artificial example that would requirethat> much space. >Oh... you've just made me realise it takes formats other than 4:2:0 (YV12 like)... if it can do 4:2:2 then i don't need to translate... as YUY2 is a 4:2:2 type. So that solves that problem... thanks.> A more reasonable "guestimate" would be 1 or 1.25 times the uncompressedframe> size. That's also probably extremely conservative. >So a good max estimate would be... 4:2:0 = width*height* 3 4:2:2 = width*height* 4 4:4:4 = width*height* 6 ?> Of course, it would be better if there were some way to report an error > instead of crashing should the buffer actually be too smal.. >It could report an error, but it would be very difficult to recover from because of the way the allocators work... it could probably be done... but it would be very painful to do without losing data already in the allocators and causing flow on effects in the graph. I think i'd rather just make it big... even if it wastes a few megs of memory... most machines doing encoding are not going to be memory bound... i think i'd rather my encoder uses some excess ram than for it stop with an error part way through a big encode and force you to up the buffer and start again. Thanks for your help, Zen.