I think I enabled _writing_ timecode info into rendered files (tested mxf) if you set timecode for your timeline manually - it should be respected. If you render selection of your timeline - timecode will be set at start timecode of your render position. if you render selection with already altered (via clapping icon) timeline - it also should work. I found you (sometimes?) need to hit 'align timecodes' menu item for refreshing asset timecode info.... but such action will mes up timeline if some assets had no real timecode info.... Anyway, try to test those patches and told us how useful (or dangerous?) they are... In theory I think this is good idea to get embedded timecodes into rendered files (rel. to your working timeline) , but may be you sometimes want zeroed tc in output files?
Updated patches, this time I tried to import resulting edl into Final Cut Pro for PPC Mac (mac os 9.2.2 on qemu/andoid 0.o) and they worked at least cuts show up, and dissolves (there currently no code for handling wipes) I am not sure if ^z^z tail actually harmless, you can comment writing this tail in patches if unsure/want to test different NLE yeah, I missed newline after FCM line, and last line in file.. for my surprize FCP 1.2.5 (from 1999!) uses Windows line endings (seen as ^M in mcedit) - may be they were re-using dos/windows code there? I simply run 'unix2dos -f' on edl file from patched CinGG and then optionally set Document/creator attribs (mac-specific, under Macos 7.5.5 in Basilisk2 emulator, with ResEdit app) to TEXT/KeyG (four symbols for each, case-sensitive! ) - this allowed FCP to see my edl correctly, but you can select 'show all files' in import->edl menu under 'file' menu item.. On Monday, June 21, 2021, Andrew Randrianasulu <[email protected]> wrote:
I think I enabled _writing_ timecode info into rendered files (tested mxf) if you set timecode for your timeline manually - it should be respected. If you render selection of your timeline - timecode will be set at start timecode of your render position. if you render selection with already altered (via clapping icon) timeline - it also should work.
I found you (sometimes?) need to hit 'align timecodes' menu item for refreshing asset timecode info.... but such action will mes up timeline if some assets had no real timecode info....
Anyway, try to test those patches and told us how useful (or dangerous?) they are...
In theory I think this is good idea to get embedded timecodes into rendered files (rel. to your working timeline) , but may be you sometimes want zeroed tc in output files?
Andrew, I am "planning" on starting to look at export edl mods tomorrow. In the past, some of the video render formats received have had the window ctrl-m on the end and I have had to remove it. Not a problem. Attached is the patch for pluginfclient.C that you alerted me to a few emails ago and I did not want to forget to put it in but do not really know how to test but at least it compiled and executed with the patch in. It should not be a problem and it is best to keep it matching the one you did for ffmpeg.C higher FPS. Thanks for your patience, Phyllis On Mon, Jul 5, 2021 at 11:30 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Updated patches, this time I tried to import resulting edl into Final Cut Pro for PPC Mac (mac os 9.2.2 on qemu/andoid 0.o) and they worked at least cuts show up, and dissolves (there currently no code for handling wipes)
I am not sure if ^z^z tail actually harmless, you can comment writing this tail in patches if unsure/want to test different NLE
yeah, I missed newline after FCM line, and last line in file..
for my surprize FCP 1.2.5 (from 1999!) uses Windows line endings (seen as ^M in mcedit) - may be they were re-using dos/windows code there?
I simply run 'unix2dos -f' on edl file from patched CinGG and then optionally set Document/creator attribs (mac-specific, under Macos 7.5.5 in Basilisk2 emulator, with ResEdit app) to TEXT/KeyG (four symbols for each, case-sensitive! ) - this allowed FCP to see my edl correctly, but you can select 'show all files' in import->edl menu under 'file' menu item..
On Monday, June 21, 2021, Andrew Randrianasulu <[email protected]> wrote:
I think I enabled _writing_ timecode info into rendered files (tested mxf) if you set timecode for your timeline manually - it should be respected. If you render selection of your timeline - timecode will be set at start timecode of your render position. if you render selection with already altered (via clapping icon) timeline - it also should work.
I found you (sometimes?) need to hit 'align timecodes' menu item for refreshing asset timecode info.... but such action will mes up timeline if some assets had no real timecode info....
Anyway, try to test those patches and told us how useful (or dangerous?) they are...
In theory I think this is good idea to get embedded timecodes into rendered files (rel. to your working timeline) , but may be you sometimes want zeroed tc in output files?
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
OK, checked into GIT, the export edl patches for CMX3600 generation. Andrea, if you have time, could you rebuild just to make sure everything compiles OK for you (and maybe try to load into another NLE to see if you have more success or if we just do not know how to do it. Andrew, you should check my work because there were a lot of patches and then patches to the patches, and I am easily confused. So in the end, I believe I got it right. Here is what I ended up doing: (1) added exportedl.c.patch, (2) ignored 0001-..., 0004, 0005, 0006 exportedl patches in this thread, (3) applied patches 0035-..., 0036, 0037, 0038, 0042, 0043. (4) Recompiled and tested cinelerra with a bunch of cuts and moving sections around to generate an Export EDL file. (5) Manually looked at the generated CMX3660 video file and saw that it "seemed" to look comparable to explanations in: https://xmil.biz/EDL-X/CMX3600.pdf pages 11-14 Also, applied Andrew's patch (for high fps) to pluginfclient.C to match the other changes in ffmpeg.C. Like I mentioned previously, I have not tested nor know how to test. Andrew, I found the Android tablet (that has not been powered on for 3-4 years!) and am moving on to checking out Termux. At least I hope I can. Thanks for all the work you do to keep Cinelerra going. ...Phyllis On Mon, Jul 5, 2021 at 11:30 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Updated patches, this time I tried to import resulting edl into Final Cut Pro for PPC Mac (mac os 9.2.2 on qemu/andoid 0.o) and they worked at least cuts show up, and dissolves (there currently no code for handling wipes)
I am not sure if ^z^z tail actually harmless, you can comment writing this tail in patches if unsure/want to test different NLE
yeah, I missed newline after FCM line, and last line in file..
for my surprize FCP 1.2.5 (from 1999!) uses Windows line endings (seen as ^M in mcedit) - may be they were re-using dos/windows code there?
I simply run 'unix2dos -f' on edl file from patched CinGG and then optionally set Document/creator attribs (mac-specific, under Macos 7.5.5 in Basilisk2 emulator, with ResEdit app) to TEXT/KeyG (four symbols for each, case-sensitive! ) - this allowed FCP to see my edl correctly, but you can select 'show all files' in import->edl menu under 'file' menu item..
On Monday, June 21, 2021, Andrew Randrianasulu <[email protected]> wrote:
I think I enabled _writing_ timecode info into rendered files (tested mxf) if you set timecode for your timeline manually - it should be respected. If you render selection of your timeline - timecode will be set at start timecode of your render position. if you render selection with already altered (via clapping icon) timeline - it also should work.
I found you (sometimes?) need to hit 'align timecodes' menu item for refreshing asset timecode info.... but such action will mes up timeline if some assets had no real timecode info....
Anyway, try to test those patches and told us how useful (or dangerous?) they are...
In theory I think this is good idea to get embedded timecodes into rendered files (rel. to your working timeline) , but may be you sometimes want zeroed tc in output files?
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Friday, July 9, 2021, Phyllis Smith via Cin <[email protected]> wrote:
OK, checked into GIT, the export edl patches for CMX3600 generation.
Andrea, if you have time, could you rebuild just to make sure everything compiles OK for you (and maybe try to load into another NLE to see if you have more success or if we just do not know how to do it.
Andrew, you should check my work because there were a lot of patches and then patches to the patches, and I am easily confused. So in the end, I believe I got it right. Here is what I ended up doing: (1) added exportedl.c.patch, (2) ignored 0001-..., 0004, 0005, 0006 exportedl patches in this thread, (3) applied patches 0035-..., 0036, 0037, 0038, 0042, 0043. (4) Recompiled and tested cinelerra with a bunch of cuts and moving sections around to generate an Export EDL file. (5) Manually looked at the generated CMX3660 video file and saw that it "seemed" to look comparable to explanations in: https://xmil.biz/EDL-X/CMX3600.pdf pages 11-14
I looked into patches as they appear in gitweb interface, looks like all pieces are correct.... sorry for so many generations of those...
Also, applied Andrew's patch (for high fps) to pluginfclient.C to match the other changes in ffmpeg.C. Like I mentioned previously, I have not tested nor know how to test.
hm, try to load high fps video and apply ffmpeg (F_*) video plugin(s) to it?
Andrew, I found the Android tablet (that has not been powered on for 3-4 years!) and am moving on to checking out Termux. At least I hope I can. Thanks for all the work you do to keep Cinelerra going. ...Phyllis
modern termux run with X on Android 7+, I hope your tablet can run such version of android.. my current install eats like 5 gb on internal storage (but I can download stuff with wget to one specific location at sdcard after running termux-setup-storage inside termux (it will prompt you to give access to sdcard graphically at first time) see ' install X environment' part of docs https://wiki.termux.com/wiki/Graphical_Environment basically package management should be like Debian, just with 'pkg search/pkg install' instead of still available apt search/install (something to do with load-balancing on their servers) and with *-static instead of -dev/-devel packages... https://wiki.termux.com/wiki/Package_Management https://wiki.termux.com/wiki/Building_packages unfortunately, I still have no idea how to fix sound.... ( so whole exercuse more about 'building CinGG on non-x86 mostly posix system while hopefully not breaking normal x86/x86-64 builds'
On Mon, Jul 5, 2021 at 11:30 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
Updated patches, this time I tried to import resulting edl into Final Cut Pro for PPC Mac (mac os 9.2.2 on qemu/android 0.o) and they worked at least cuts show up, and dissolves (there currently no code for handling wipes)
I am not sure if ^z^z tail actually harmless, you can comment writing this tail in patches if unsure/want to test different NLE
yeah, I missed newline after FCM line, and last line in file..
for my surprize FCP 1.2.5 (from 1999!) uses Windows line endings (seen as ^M in mcedit) - may be they were re-using dos/windows code there?
I simply run 'unix2dos -f' on edl file from patched CinGG and then optionally set Document/creator attribs (mac-specific, under Macos 7.5.5 in Basilisk2 emulator, with ResEdit app) to TEXT/KeyG (four symbols for each, case-sensitive! ) - this allowed FCP to see my edl correctly, but you can select 'show all files' in import->edl menu under 'file' menu item..
On Monday, June 21, 2021, Andrew Randrianasulu <[email protected]> wrote:
I think I enabled _writing_ timecode info into rendered files (tested mxf) if you set timecode for your timeline manually - it should be respected. If you render selection of your timeline - timecode will be set at start timecode of your render position. if you render selection with already altered (via clapping icon) timeline - it also should work.
I found you (sometimes?) need to hit 'align timecodes' menu item for refreshing asset timecode info.... but such action will mes up timeline if some assets had no real timecode info....
Anyway, try to test those patches and told us how useful (or dangerous?) they are...
In theory I think this is good idea to get embedded timecodes into rendered files (rel. to your working timeline) , but may be you sometimes want zeroed tc in output files?
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
1- I created 2 projects in mp4 and ProRes. I exported to EDL CMX3600. Imports into other programs seem to improve, but always end in error: In Kdenlive I no longer have the generic error I had before, but I do have python errors; see images. In Olive same error as before; see image. In OpenShot it can't find the original source and it doesn't open (as before), but it gives the idea to recognize the format. 2- I imported in CinGG an mp4 at 120 fps, edited it with cuts, ffmpeg filters and transitions; then I rendered in DNxHR_proxy.mxf. All OK. I imported the files in other NLEs: all OK. I played them in different players: all OK. (but also in the preceding tests I had not had problems).
On Friday, July 9, 2021, Andrea paz <[email protected]> wrote:
1- I created 2 projects in mp4 and ProRes. I exported to EDL CMX3600. Imports into other programs seem to improve, but always end in error: In Kdenlive I no longer have the generic error I had before, but I do have python errors; see images. In Olive same error as before; see image. In OpenShot it can't find the original source and it doesn't open (as before), but it gives the idea to recognize the format.
yeah, sadly it fails to parse by otio python scripts.. but may be we should set up project with specific fps value _before_ loading edl? $ .local/bin/otiostat ~/my2.edl The file did not successfully parse, with error: Source and record duration don't match: RationalTime(142, 24) != RationalTime(141, 24) for clip 004 $ it looks like it tries 24 fps by default and there is no obvious cli way to change it?
2- I imported in CinGG an mp4 at 120 fps, edited it with cuts, ffmpeg filters and transitions; then I rendered in DNxHR_proxy.mxf. All OK. I imported the files in other NLEs: all OK. I played them in different players: all OK. (but also in the preceding tests I had not had problems).
Partial success! I changed the frame rate of the project to 24 fps. I got the same errors with all programs. I manually edited the created EDL file by putting the path each time the source (test2.mp4) appeared. See attached edl file. Now in OpenShot it opens without problems! In Kdenlive there are the usual errors (maybe a little less? See image); in Olive still the same error.
On Saturday, July 10, 2021, Andrea paz <[email protected]> wrote:
Partial success! I changed the frame rate of the project to 24 fps. I got the same errors with all programs. I manually edited the created EDL file by putting the path each time the source (test2.mp4) appeared. See attached edl file. Now in OpenShot it opens without problems!
cool, but strange (I replaced full path with just filename aerly because other test edls I saw were written this way..) may be we can add '* FROM FILE /full_path/name.ext line' too? from OpenTimelineIO/src/py-opentimelineio/opentimelineio/adapters/cmx_3600.py # this should be a map of all known comments that we can read # 'FROM CLIP' or 'FROM FILE' is a required comment to link media # An exception is raised if both 'FROM CLIP' and 'FROM FILE' are fo und # needs to be ordered so that FROM CLIP NAME gets matched before FROM CLIP comment_id_map = collections.OrderedDict([ ('FROM CLIP NAME', 'clip_name'), ('TO CLIP NAME', 'dest_clip_name'), ('FROM CLIP', 'media_reference'), ('FROM FILE', 'media_reference'), ('LOC', 'locators'), ('ASC_SOP', 'asc_sop'), ('ASC_SAT', 'asc_sat'), ('M2', 'motion_effect'), ('\\* FREEZE FRAME', 'freeze_frame'), ])
In Kdenlive there are the usual errors (maybe a little less? See image);
it looks like kdenlive can't load its own adapter? may be OTIO/Kdenlive/python mismatch?
in Olive still the same error.
not sure about this one.. P.S.: thanks for your video tutirials, I was wondering what _secondary_ color correction term mean and you answered that }
On Saturday, July 10, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Saturday, July 10, 2021, Andrea paz <[email protected]> wrote:
Partial success! I changed the frame rate of the project to 24 fps. I got the same errors with all programs. I manually edited the created EDL file by putting the path each time the source (test2.mp4) appeared. See attached edl file. Now in OpenShot it opens without problems!
cool, but strange (I replaced full path with just filename aerly because other test edls I saw were written this way..)
may be we can add '* FROM FILE /full_path/name.ext line' too?
test patch (on top of those already merged) attached...
from
OpenTimelineIO/src/py-opentimelineio/opentimelineio/adapters/cmx_3600.py
# this should be a map of all known comments that we can read # 'FROM CLIP' or 'FROM FILE' is a required comment to link media # An exception is raised if both 'FROM CLIP' and 'FROM FILE' are fo und # needs to be ordered so that FROM CLIP NAME gets matched before FROM CLIP comment_id_map = collections.OrderedDict([ ('FROM CLIP NAME', 'clip_name'), ('TO CLIP NAME', 'dest_clip_name'), ('FROM CLIP', 'media_reference'), ('FROM FILE', 'media_reference'), ('LOC', 'locators'), ('ASC_SOP', 'asc_sop'), ('ASC_SAT', 'asc_sat'), ('M2', 'motion_effect'), ('\\* FREEZE FRAME', 'freeze_frame'), ])
In Kdenlive there are the usual errors (maybe a little less? See image);
it looks like kdenlive can't load its own adapter? may be OTIO/Kdenlive/python mismatch?
in Olive still the same error.
not sure about this one..
P.S.: thanks for your video tutirials, I was wondering what _secondary_ color correction term mean and you answered that }
I really don't know what to say! The EDL file produced by your new patch seems to me the same as the one I edited manually. But the latter works in OpenShot, the new one doesn't: it doesn't find the source.
On Saturday, July 10, 2021, Andrea paz <[email protected]> wrote:
I really don't know what to say! The EDL file produced by your new patch seems to me the same as the one I edited manually. But the latter works in OpenShot, the new one doesn't: it doesn't find the source.
what if you change order of comments, so *FROM FILE will be first?
On Sunday, July 11, 2021, Andrea paz <[email protected]> wrote:
what if you change order of comments, so *FROM FILE will be first?
Same error!
and if you just leave one line ('from clip name' or 'from file' ) with full path?
On Sunday, July 11, 2021, Andrea paz <[email protected]> wrote:
and if you just leave one line ('from clip name' or 'from file' ) with full path?
I have tried various changes but the result is always the same! It occurs to me that the only working EDL is just a fluke.
( sorry for taking your time... I have something else for tonight, will send separately
Andrew, Andrea, If I understand correctly, it worked a little better before this patch so leaving it out. If anyone comes along who really needs the CMX3600 format to work in a specific case, they can supply further information to help. Did update the manual from the information Andrea supplied concerning the "Export EDL..." capability. On Sat, Jul 10, 2021 at 8:16 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
On Saturday, July 10, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Saturday, July 10, 2021, Andrea paz <[email protected]> wrote:
Partial success! I changed the frame rate of the project to 24 fps. I got the same errors with all programs. I manually edited the created EDL file by putting the path each time the source (test2.mp4) appeared. See attached edl file. Now in OpenShot it opens without problems!
cool, but strange (I replaced full path with just filename aerly because other test edls I saw were written this way..)
may be we can add '* FROM FILE /full_path/name.ext line' too?
test patch (on top of those already merged) attached...
from
OpenTimelineIO/src/py-opentimelineio/opentimelineio/adapters/cmx_3600.py
# this should be a map of all known comments that we can read # 'FROM CLIP' or 'FROM FILE' is a required comment to link media # An exception is raised if both 'FROM CLIP' and 'FROM FILE' are fo und # needs to be ordered so that FROM CLIP NAME gets matched before FROM CLIP comment_id_map = collections.OrderedDict([ ('FROM CLIP NAME', 'clip_name'), ('TO CLIP NAME', 'dest_clip_name'), ('FROM CLIP', 'media_reference'), ('FROM FILE', 'media_reference'), ('LOC', 'locators'), ('ASC_SOP', 'asc_sop'), ('ASC_SAT', 'asc_sat'), ('M2', 'motion_effect'), ('\\* FREEZE FRAME', 'freeze_frame'), ])
In Kdenlive there are the usual errors (maybe a little less? See image);
it looks like kdenlive can't load its own adapter? may be OTIO/Kdenlive/python mismatch?
in Olive still the same error.
not sure about this one..
P.S.: thanks for your video tutirials, I was wondering what _secondary_ color correction term mean and you answered that }
--
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Does this mean that only 24 fps works for this specific NLE? Should that be noted somewhere in the manual too? I can't tell! In the case where it worked, surely the biggest influence was putting the absolute path to the source; so it's not sure that 24 fps is needed too. Other tests with later patches were not successful, so I can't create a clear situation, where a change leads to a sure result.
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith