[theora-dev] FW: Is TH_ENCCTL_SET_DUP_COUNT compatible with TH_ENCCTL_SET_VP3_COMPATIBLE?

[Id Kong]

> Date: Sat, 13 Mar 2010 16:21:26 -0500
> From: tterribe at email.unc.edu
> 
> Id Kong wrote:
> > 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
> 
> Right, but again, this depends on _how_ you're simulating VFR. A base
> frame rate of 1000 fps is, in practice, very different from, say, 120
> fps. There are two problems with the old-style "inter frame with no
> coded blocks" as a substitute for dropped/duplicate frames.
> 
> 1) They are 9 bytes instead of 0 (which, when adding Ogg container
> overhead, translates into 10 bytes instead of 1). At 1000 fps, that
> increases the VFR overhead from 8 kbps (which is not great, but maybe
> acceptable) to 80 kbps (which is bad).
> 
> 2) The decoder application has no way of distinguishing them from
> regular frames, and so must do color conversion, display, etc., on every
> one. I suspect many of the applications that _do_ handle this correctly
> (e.g., which could actually display a 1000 fps file with 24-30 _real_
> frames per second without choking) are simply looking for 0-byte packets
> and special casing them.

	I see.  You're worried about people who need good codec efficiency, even in VP3 mode, who also need high variable frame rate resolution and whose client players have performance constraints.  I don't really know but I'm guessing these people are few.  If you're worried about me in particular, I have none of these concerns.  As long as Theora isn't outrageously inefficient, I'm fine with that.  I settled for VP3 mode, didn't I?  I would have simply stored uncompressed frames but that was a bit much...	I'm using a base frame rate of 30 fps so the container overhead per frame doesn't concern me.  Similarly, with such a pedestrian frame rate, client performance doesn't worry me either...


> I hacked up your program to actually work on a platform other than
> Windows (and removed the dependency on CxImage, which appears to be
> hopelessly Windows-only, and converted it from C++ to C). However, I was
> not able to reproduce your problem with ffmpeg (I tested on Linux, and
> thus did not have ffdshow; it may be specific to the DirectShow
> filters). VLC, however, was quite clearly broken (it probably discards
> 0-byte packets and _then_ adds timestamps to the packets that are
> missing them, and so plays along quickly until it hits a packet with an
> explicit timestamp, and then stalls until that time passes). 0-byte
> packet handling was broken in mplayer until this week, as well.

	I'm sorry about the Microsoft specific stuff.  If I had known this would have been an obstacle, I would have converted the image I was using into a very large array in a C source file for you.	It's interesting that ffmpeg doesn't exhibit these bugs 'cause I recently updated (my very old installation of) ffdshow and it's still very broken in this regard.  Your DirectShow filter theory may be correct...

> Thus I changed the encoder to emit the old-style 9-byte packets in VP3
> compatibility mode. Because of 1), this makes this mode unsuitable for
> 1000 fps VFR content; it may still work okay for more reasonable base
> frame rates. To address 2), I modified the decoder to return TH_DUPFRAME
> from th_decode_packetin() for _any_ frame with no coded blocks (before
> it, too, would only return this for 0-byte packets). However, I doubt
> much, if any, software other than our player_example is actually
> checking this return code. It gives the hope that once these changes are
> release and disseminated some future application _could_ be written
> which would handle these files efficiently, but for the immediate
> future, you can expect 2) will still be a problem. In the mean time,
> however, VLC now plays the resulting output of your test program without
> problems, though the resulting file is somewhat larger.

	Thank you for doing this.  Because so many players were broken, I highly doubt anyone was simulating variable frame rate with such a high base frame rate in the old VP3 format...

> You can get the changes from r16966 of the current development branch:
> http://svn.xiph.org/experimental/derf/theora-ptalarbvorm/

	As an aside, I recently decided to quit my childish file0, file1 backup system in favour of an actual revision control system and found that Mercurial served my needs best... except in one regard which hadn't occurred to me until recently.  I never realized how important interoperability would be in an RCS but often people who want to distribute source code simply point to a RCS server of some kind and, so far, it has never been a Mercurial host.	In order to download your changes I had to install a subversion client onto my system.  That's okay since both Mercurial and Subversion work behind their respective command line programs and thus won't conflict with each other and I had to solve this growing problem of not being able to download people's Subversion'ed code anyway.	I'm happy to say that, so far, your changes have been a brilliant success.  ffdshow and, most importantly, YouTube accepts the video happily and the video stays in sync with the audio.  All is well with the world again, thank you very much!  If you're curious as to what I'm doing, you can find an example of it here:
http://www.youtube.com/watch?v=-n2cQJjr0JA
	I've wanted to do this for some time now but have only gotten around to it recently...	Thank you! 		 	   		  
Don't miss a beat Get Messenger on your phone 		 	   		  
_________________________________________________________________
Live connected with Messenger on your phone
http://go.microsoft.com/?linkid=9712958
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/theora-dev/attachments/20100319/d559c355/attachment.htm