Python-popen errors with MLT 0.7.4
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenShot Video Editor |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Hi,
In AV Linux 5.0 I used a custom 0.7.3 MLT version from GIT that avoided many of the issues of 0.7.2, since MLT 0.7.4 has been released I am using it here in development and am seeing issues with both Openshot and Kdenlive (Kdenlive is now resolved).
With Openshot 1.3.1 an upgrade to 0.7.4 results in the dreaded 'no codecs found' error which generally seems to imply that the melt executable is not being found correctly or at all. If I launch Openshot from the terminal everything looks normal and there is a large amount of output from the liblrdf scan of the numerous LADSPA audio plugins on the system (also normal due to MLT's blessed new ability to hook into LADSPAs). The problem seems to occur at the end of the scan where I am seeing this error:
There were some errors calling melt using os.Popen()
There were some errors calling melt using os.Popen()
There were some errors calling melt using os.Popen()
The MLT issue with Kdenlive may shed some light on this because MLT 0.7.4 has moved from using 'stderr' for querying melt to using 'stdout'. I asked Dan Dennedy about this on the mlt-mailing list and he personally wasn't seeing this issue with Openshot 1.3.1 and thought that python-popen should be able to handle this change from stderr to stdout. In my experience and using the same build/packaging methods I am now seeing this error and Openshot is not working with MLT 0.7.4.
Let me clarify that the existing 0.7.3GIT MLT is doing the job quite nicely with Openshot 1.3.1 however since you are working on the 1.4 release which will most likely be using MLT 0.7.4 when it's complete I thought I'd share my findings in case there are other similar issues with MLT 0.7.4.
Looking forward to the 1.4 release! Best Regards, Glen MacArthur - AV Linux maintainer.
Changed in openshot: | |
status: | Fix Committed → Fix Released |
Hi Glen, for version 1.4 we will not be using melt to detect the codecs, so hopefully this will not be an issue. I'll be merging into the main trunk the current 1.4 changes in the next few days, maybe you can test this again when the trunk is updated. I'll leave this open until then.