GNOME Bugzilla – Bug 583935
QoS problem with theora and overlapping clips
Last modified: 2010-02-23 00:31:44 UTC
This is a courtesy reminder bug report :) <bilboed-pi> found the bug... in gnonlin. one easy way to fix it... don't have overlapping clips <bilboed-pi> for example, in the 0.13.1.xptv project... make the screencast ogv start at the end of the png clip <bilboed-pi> it fixed it for me here <nekohayo> bilboed-pi: that doesn't seem to work. /me checks some more oh yes seems to work. <bilboed-pi> hmm... still fails in fact although no ---------- This happens with this sample PiTiVi project: http://jeff.ecchi.ca/public/gnonlin-theora-qos-bug.tar
Created attachment 135401 [details] debug log
the ogv file is simply broken, it skips frame with totem as well. Looking at the granule pos i'm seeing alessandro@pappotti:~/src/pitivi$ oggzdump pro/importing\ media.ogv | grep -E "1739461783,.*granulepo" | head -n10 00:00:00.000: serialno 1739461783, granulepos 0|0, packetno 0 *** bos: 42 bytes 00:00:00.000: serialno 1739461783, granulepos 0|0, packetno 2: 2.552 kB 00:00:00.033: serialno 1739461783, granulepos 1|0, packetno 3: 91.590 kB 00:00:02.133: serialno 1739461783, granulepos 1|63, packetno 66: 9 bytes 00:00:02.166: serialno 1739461783, granulepos 65|0, packetno 67: 91.590 kB 00:00:03.800: serialno 1739461783, granulepos 65|49, packetno 116: 15 bytes 00:00:04.266: serialno 1739461783, granulepos 65|63, packetno 130: 14 bytes 00:00:04.600: serialno 1739461783, granulepos 129|9, packetno 140: 9 bytes 00:00:04.633: serialno 1739461783, granulepos 129|10, packetno 141: 30.691 kB 00:00:05.433: serialno 1739461783, granulepos 129|34, packetno 165: 19 bytes 1739461783 is the theora stream. It's missing pretty much all the frames at the beginning. Granulepos should be 1|0, 1|1, 1|2 ... 1|62, 1|63, 65|0, 65|1, 65|2...
For reference, this is what the beginning of a good theora stream produced by theoraenc looks like alessandro@pappotti:~/src/host2/pitivi$ oggzdump a.ogg | grep -E "0296045764,.*granulepo" | head -n10 00:00:00.000: serialno 0296045764, granulepos 0|0, packetno 0 *** bos: 42 bytes 00:00:00.000: serialno 0296045764, granulepos 0|0, packetno 2: 2.552 kB 00:00:00.033: serialno 0296045764, granulepos 1|0, packetno 3: 3.996 kB 00:00:00.066: serialno 0296045764, granulepos 1|1, packetno 4: 3.351 kB 00:00:00.100: serialno 0296045764, granulepos 1|2, packetno 5: 1.563 kB 00:00:00.133: serialno 0296045764, granulepos 1|3, packetno 6: 1.552 kB 00:00:00.166: serialno 0296045764, granulepos 1|4, packetno 7: 1.571 kB 00:00:00.200: serialno 0296045764, granulepos 1|5, packetno 8: 1.580 kB 00:00:00.233: serialno 0296045764, granulepos 1|6, packetno 9: 1.575 kB 00:00:00.266: serialno 0296045764, granulepos 1|7, packetno 10: 1.575 kB
blame me for not having an intimate knowledge of ogg :( The reason why I mentionned on IRC that it was a gnonlin bug was because... we werent starting playing back the source from the start/media-start position (because something else was 'above' it)... but I'll blame that on a tiring hacking day. I looked at the code in gnonlin again,... and we're doing the right thing. Replacing that ogg file with another format doesn't trigger the issue. I guess we'll *really* need to have format-validation code when importing files in pitivi :( Can we fix those files using some gstreamer pipeline and vorbisparse/theoraparse ?
Yes, remuxing with theoraparse will fix the granulepos.
Reported https://sourceforge.net/tracker/?func=detail&aid=2827013&group_id=172357&atid=861428 on recordmydesktop to have their view on this.
I have a vague feeling that the latest qos fixes in pitivi/gnonlin have solved the user-visible part of this problem. Is the fact that recordmydesktop creates "broken" files still relevant?
Jeff, if you can't reproduce the bug anymore, please tell us so we can mark this fixed for the upcoming release.
Yes, the user-visible part (freezing frames) is fixed. But as I was asking, Is the fact that recordmydesktop creates "broken" files still relevant? I guess it doesn't matter anymore.
There is no evidence provided here of broken files. Oggzdump annoyingly changes the string it uses to identify the granule position: It uses "granulepos" for packets which are the last packet on a page and "calc. gpos" for packets where are not the last packet on the page. [gmaxwell@helmholtz tmp]$ oggzdump "0.13.1 version 2/demonstration screencast pitivi 0.13.1 - third shot.ogv" | grep 'serialno 0943335736'| head 00:00:00.000: serialno 0943335736, granulepos 0|0, packetno 0 *** bos: 42 bytes 00:00:00.000: serialno 0943335736, calc. gpos 0|0, packetno 1: 77 bytes 00:00:00.000: serialno 0943335736, granulepos 0|0, packetno 2: 2.552 kB 00:00:00.033: serialno 0943335736, granulepos 1|0, packetno 3: 90.312 kB 00:00:00.066: serialno 0943335736, granulepos 1|1, packetno 4: 6.906 kB 00:00:00.100: serialno 0943335736, calc. gpos 1|2, packetno 5: 71 bytes 00:00:00.133: serialno 0943335736, calc. gpos 1|3, packetno 6: 21 bytes 00:00:00.166: serialno 0943335736, calc. gpos 1|4, packetno 7: 15 bytes 00:00:00.200: serialno 0943335736, calc. gpos 1|5, packetno 8: 15 bytes 00:00:00.233: serialno 0943335736, calc. gpos 1|6, packetno 9: 15 bytes (Also keep in mind that zero byte packets are perfectly valid and will be found in very still content or in variable frame rate files).