Id Kong spam_receptacle_ at hotmail.com
Tue Feb 23 19:31:49 PST 2010

> Date: Tue, 23 Feb 2010 20:29:40 -0500
> From: tterribe at email.unc.edu
> Id Kong wrote:
> > Hello!  Have you had a chance to look at this issue?  If not, will you
> > be able to look into it in the near future?  Did or will my sample
> > program help in any way?
> I have not... since your problems appear to be with 3rd party software,
> they most likely do not support 0-byte packets properly at all. It may
> be possible to work around the issue by emitting explicit frames with no
> blocks coded (which are about 9 bytes each) in VP3 compatibility mode,
> but depending on what you're using SET_DUP_COUNT for, this may be a poor
> substitute. I can probably find some time this weekend to confirm my
> hypothesis with the help of your program.

	Thank you for your response.	I'm using TH_ENCCTL_SET_DUP_COUNT for the purpose I believe it was intended for: simulating variable frame rate video.  It turns out that the frame rate of the video I am generating varies (since it's very dynamic and simply generates frames as quickly as it can in real time) so the video moves greatly out of sync with the captured audio, even when the average frame rate matches (sometimes it'll be ahead, other times it'll be behind).	While I can sympathize with the frustration of third party software being far out of date with the current specification (few things are more infuriating than incorrect software), the reality is that compatibility is important.  It's the only reason why MS Windows still dominates the OS market.  It may be worth breaking an older protocol for new gains but if the point of the TH_ENCCTL_SET_VP3_COMPATIBLE setting is to work with older, arguably broken implementations, it makes sense to modify current software to work with these implementations in that mode.  In short, I'm saying that your suggested work around is well worth it if it works!	If my understanding of TH_ENCCTL_SET_DUP_COUNT is correct and it is cheap to execute (it would have to be or you'd just call th_encode_ycbcr_in() with the same frame) then it should solve my problems.  Nine bytes per frame is nothing!	Thank you for any help you can offer!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/theora-dev/attachments/20100223/5b20ad67/attachment.htm 

More information about the theora-dev mailing list