Ah, got it. Thanks for the clarification. I think that was a good design
decision! Thanks!
Cheers,
Allan
allan.reyes.sh | keybase.io/allanbreyes
On Thu, Apr 26, 2018 at 6:02 PM, Dan Dennedy <d...@dennedy.org> wrote:
> The IDs are only needed to facilitate XML references. There are no rules
> other than standard XML ID/IDREF rules: within a document IDs must be
> unique and IDREFs should refer to valid IDs. Anything beyond that is
> external to MLT and probably onerous. Shotcut uses the xml consumer to
> generate MLT XML, and its convention. Applications can use any ID
> convention of their choosing and may change them. With that said, Kdenlive,
> Shotcut, and the Wikimedia Video Editing Server all use the same algorithm
> to generate a hash over media files that is faster than hashing the entire,
> possibly very large, media file.
> https://github.com/mltframework/shotcut/blob/master/src/mainwindow.cpp#
> L1040
> https://github.com/ddennedy/wikimedia-video-editing-server/blob/master/
> application/controllers/Job.php#L181
> Obviously, there is some potential for hash collision, but there is no
> mechanism in place to handle it.
>
>
> On Thu, Apr 26, 2018 at 5:39 PM Allan Reyes <al...@reyes.sh> wrote:
>
>> Hey folks,
>>
>> A bit of a strange question, but I don't see any mention of this in the
>> MLT documentation. Is there any central specification or convention on how
>> NLEs handle IDs? I know the naming conventions tend to be a bit different,
>> e.g. Shotcut (producer0, producer1...), but is there anything with regards
>> to ID stability? Specifically, are NLEs "allowed" to change IDs if they're
>> already set? e.g. a user adds some resource in the middle of the playlist,
>> is there any restriction in the spec that the NLE implementation should
>> only create a unique ID for that specific resource without modifying the
>> other IDs?
>>
>> The motivation here is that I'm looking for a stable identifier for
>> assets (images, video clips, etc.) to map to uploaded assets (e.g. AWS S3)
>> and want to make sure it covers as many MLT-backed editors as possible. If
>> this isn't in the MLT spec, is it something worth considering?
>>
>> Thanks!
>>
>> Cheers,
>> Allan
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
>> _________________________________________
>> Mlt-devel mailing list
>> Mlt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
