Hi I'm trying to store video I encode to a file using Theora and Ogg. The video I record is from my webcam and although the framerate is set to 30 fps I rarely get more then 28-29 fps. Since Theora is fed with a framerate which isn't precise the time of each frame when I play it in VLC doesn't match the exact time of when the frame occurred. So basically I wonder how can I sync a video frame to a clock using Theora and Ogg? I tried looking at?th_granule_time() and?ogg_page_granulepos() but they seem to be concerned with the frame number and not time of the frame. Thanks for a great video codec! Regards Bjoern
On 03/15/2011 01:36 PM, Bjoern D. Rasmussen wrote:> Since Theora is fed with a > framerate which isn't precise the time of each frame when I play it in > VLC doesn't match the exact time of when the frame occurred. So > basically I wonder how can I sync a video frame to a clock using > Theora and Ogg?Ogg Theora operates at a strictly fixed framerate. If you start the stream at 30 fps, then it is a 30 fps stream, and the time of each frame is exactly determined by its number. If your webcam is dropping frames then you must fill in the gaps. You can most easily do this by submitting frames multiple times to make up for any dropped frames. The encoder has various optimizations for the special case of duplicate frames, but these are not important for your immediate problem. --Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20110315/15ea3e01/attachment.pgp
On 15/03/11 18:45, Ralph Giles wrote:> On 15 March 2011 10:54, Richard Watts<rrw at kynesim.co.uk> wrote: > >> What generally happens in video codec land is that the codec headers contain a >> nominal frame rate, but you will only use that in practice to set your expectations >> of the approximate rate of arrival of frames. >> >> Pacing is generally done by a more accurate clock delivered around the side >> (e.g. via Ogg's granulepos - which is a completely abstract value that can mean >> anything you like, but in practice tends to be a timestamp in ms). > > While what you describe is indeed a common way to support variable > framerate encodings, what Ben said is correct. Theora video in the Ogg > container is strictly fixed framerate and the encoder must take care > of this.There's a difference between fixed frame rate and fixed timing; I'll accept that I'm just wrong in using this to implement VFR - though as I understand it, Bjoern's problem is dropped frames, so my technique would be legitimate in his case, albeit somewhat hard for the decoder to cope with. But I can't see any sensible way to maintain AVsync over long periods without putting my timestamps somewhere - if I don't do this, I can't recover the source clock and my A and my V will eventually drift away from each other. Does the scheme given in A.2.2 / A.2.3 somehow ensure this - I'm not sure I see how it can? [snip]> I believe many players do support per-frame presentation timestamps on > theora video in the MKV container. While that also goes against the > wording of the theora bitstream specification, unlike the case with > Ogg there's no technical reason it can't be done.Eh? The Theora standard has a section on encapsulating Theora in Ogg which, as you say, explicitly reserves the granulepos field and uses it for a kind of 'fast seek'. It says nothing about encapsulating Theora in MKV .. (does it?) Richard.
On Tue, Mar 15, 2011 at 3:54 PM, Richard Watts <rrw at kynesim.co.uk> wrote:> ?But you're still using (many!) more bits than you need to represent > what is, in essence, a timer. Worse, you have now lost any information > you ever had as to the actual underlying frame rate. Even worse, the > decoder now needs to make some sort of decision as to which of these > frames it should actually output (unless you really do have VSYNC > 1kHz in which case I want your monitor).And yet a 32bit 1ms timer (which would probably wrap far too fast) attached to every vorbis frame, e.g. would impose 5kbit/sec. overhead (or twice that for 64bit counters) in the worst case. Ogg avoids this by not attaching the granpos to every packet. But this means the special care must be taken in order to support variable rate things cleanly. Of course, this can be improved by adding more special cases. What cortado does for drop frames (zero byte frames) is that it just doesn't paint them. Why would it? They're drops. They don't change the output, they don't change the buffer states. Of course, if the encoder outputs too many real frames and it falls behind, then it has to drop more. But thats just the normal mechanism for falling behind. (Cortado does paint every two seconds or so even during drops, because the graphics api in use doesn't deal with damage completely, so it needs to periodically repaint in order to recover the screen) [sniping a bunch of stuff that I find completely agreeable]> ?CBR gets you out of more of it, but as you observe, there is very > little to stop a VFR encoder emitting ghastly numbers of frames > (of course, that emission of ghastly numbers of frames is precisely > what you are suggesting for timekeeping, so I'd think it ungentlemanly > of you to then complain about it!).There is a difference between a zero byte placeholder and a frame that takes work to decode! Yes, it's an extra condition, but so is the logic required to decode frame durations elsewhere.