GNOME Bugzilla – Bug 634715
[commandline] rendering doesn't work if you change the quality quantizer of x264enc
Last modified: 2011-05-22 23:03:07 UTC
Created attachment 174362 [details] project files and diff Attached are two xptv files. As you can see, the *only* difference between the two is this line: <vcodec-settings quantizer="(guint64) 43L" /> Which causes bin/pitivi --no-ui --render foo.mkv\ "Snowy hackfest and Boston Summit 2010 - high bitrate.xptv" To fail with the following traceback: Traceback (most recent call last):
+ Trace 224646
_run_pitivi()
sys.exit(ptv.main(sys.argv))
ptv.run(sys.argv[1:])
self.projectManager.loadProject(project)
formatter.loadProject(uri)
self._loadProjectUnchecked(location)
self._loadProject(location, project)
project.setSettings(self._loadProjectSettings(self._settingsnode))
settings.vcodecsettings = self._deserializeDict(sett)
d[a] = self._parsePropertyValue(b)
return gst.Caps("meh, name=%s" % value)[0]["name"]
Love the "meh" variable name, by the way.
Actually, projects like these don't load in pitivi's ui either (same traceback). How to reproduce: change the "quantizer" slider of the x264enc settings (seems like any change triggers the bug)
I also see this problem. For example, if the bitrate for the x264enc video codec is set to 4096: <export-settings aencoder="faac" audiochannels="2" audiodepth="16" audiorate="44100" muxer="matroskamux" vencoder="x264enc" videoheight="1080" videopar-denom="1" videopar-num="1" videorate-denom="1" videorate-num="50" videowidth="1920" > <vcodec-settings bitrate="(guint64) 4096L" /> </export-settings> ..a TypeError is raised when the project is loaded: $ bin/pitivi x.xptv Traceback (most recent call last):
+ Trace 226628
debug=options.debug)
self._loadProject(project_filename)
I tried to see when this error appeared, and the code @2009-07-02 does the same.. for some reason I don't think this is useful. It seems gst.Caps() does not know what "guint64" represents. I'm not sure what the correct fix would be here: - should the "bitrate" attribute be saved as some other value, for example "(int)123" instead of "(guint64)123L"? - should GST support "guint64"? - should etree.ElementTreeFormatter._parsePropertyValue() support "guint64"? I'd like to write a fix. Edward, I understand you wrote gst, do you have any suggestions? Is this a Pitivi bug, or is it a GST bug? I see the _parsePropertyValue() method already has a hack for "(GEnum)..." values.. Why exactly do we need that?
I see etree.py has been modified two years ago to create "guint64" elements: http://git.pitivi.org/?p=pitivi.git;a=commitdiff;h=1d043c01db47b26dd2fd5dd7284cc2467d731ec0 1d043c01 (Edward Hervey 2009-05-14 17:05:06 +0200 260) element.attrib[a] = "(guint64) %r" % b The options currently are: - change etree.ElementTreeFormatter._parsePropertyValue() support "guint64", - fix GST to support Caps parsing of "guint64" values, - use something else instead of "guint64", although I think this will break projects saved for which the xptv file has "guint64" values, so it's not really an option. Can anyone comment, did anything change in GST to cause the Caps parsing of "meh, name=(guint64)9" to fail? Any pointers are appreciated. Thanks.
I found the problem: ElementTreeFormatter._serializeDict() serializes all int-type values as "(guint64) %r" % b, and the problem is when "b" is a longinteger, for example "4L", then gst fails to parse the value: $ python -c 'import gst; print gst.Caps("meh, name=(guint64) 4")' meh, name=(guint64)4 $ python -c 'import gst; print gst.Caps("meh, name=(guint64) 4L")' Traceback (most recent call last):
+ Trace 226910
I'll make a patch to fix the serialization. The users of the devel version, in case they will have problems, will have to remove the "L"s from the xptv files..
Created attachment 186853 [details] [review] Patch to fix the deserialization of guint64 values in formatters/etree.py The problem exists in PiTiVi v0.13.5, so I changed the deserialization to be able to parse guint64 values which have an "L" at the end.
commit 727ea84d630952490ec3d777a9e8c08371bbeffc Author: Alex Băluț <alexandru.balut@gmail.com> Date: Thu Apr 28 23:39:14 2011 +0200 Deserialize correctly the longinteger values. Fixes bug 634715.