mirror of
https://github.com/iluvcapra/pycmx.git
synced 2025-12-31 08:50:54 +00:00
Merge branch 'master' into jamie
This commit is contained in:
27
README.md
27
README.md
@@ -64,11 +64,32 @@ False
|
||||
|
||||
```
|
||||
|
||||
## How is this different from `python-edl`?
|
||||
|
||||
There are two important differences between `import edl` and `import pycmx`
|
||||
and motivated my development of this module.
|
||||
|
||||
1. The `pycmx` parser doesn't take timecode or framerates into account,
|
||||
and strictly treats timecodes like opaque values. As far as `pycmx` is
|
||||
concerend, they're just strings. This was done because in my experience,
|
||||
the frame rate of an EDL is often difficult to precisely determine and
|
||||
often the frame rate of various sources is different from the frame rate
|
||||
of the target track.
|
||||
|
||||
In any event, timecodes in an EDL are a kind of *address* and are not
|
||||
exactly scalar, they're meant to point to a particular block of video or
|
||||
audio data on a medium and presuming that they refer to a real time, or
|
||||
duration, or are convertible, etc. isn't always safe.
|
||||
|
||||
2. The `pycmx` parser reads event numbers and keeps track of which EDL rows
|
||||
are meant to happen "at the same time," with two decks. This makes it
|
||||
easier to reconstruct transition A/B clips, and read clip names from
|
||||
such events appropriately.
|
||||
|
||||
## Should I Use This?
|
||||
|
||||
At this time, this is (at best) alpha software and the interface will be
|
||||
changing often. It may be fun to experiment with but it is not suitable
|
||||
at this time for production code.
|
||||
At this time, this is (at best) beta software. I feel like the interface is
|
||||
about where where I'd like it to be but more testing is required.
|
||||
|
||||
Contributions are welcome and will make this module production-ready all the
|
||||
faster! Please reach out or file a ticket!
|
||||
|
||||
Reference in New Issue
Block a user