submersible_toaster has asked for the wisdom of the Perl Monks concerning the following question:

Fellow monks, after browsing the CPAN last week , and giving the super-search a try I was forced (by the immediacy of production pressure) to roll something of my own , that I am certain exists somewhere.

The challenge set was to 'rationalise' multiple time ranges, to determine how many, if any overlap hence forming concurrent blocks. Why? - in this case to process a SMPTE EDL (Edit Decision List) and reduce the number of individual 'edits' , particularly overlapping edits required to import the necessary frames, but avoid the duplication of grabbing 00:01:10:00 - 00:01:15:05 then later 00:01:14:02 - 00:01:18:20.

Since EDL's deal with video/film their smallest quantity is the frame (pls nobody remind me about fields!!) , and depending on the format , one second of footage is 24, or 25, or 30 frames. What I was searching for was a module that allowed creating a counter that one can set arbitary values for the carry to next column. For SMPTE PAL video, this would mean 25frames to each second, 60 seconds to each minute, 60 minutes to the hour.

Ultimatly I rolled a module that creates edit objects with properties like in and out point. To apply the range logic to them, timecode in the format HH:MM:SS:FF was converted to integers in its lowest atomic - the frame.

package timecode; our $fps = 25; sub fps { $fps = $_[1]; } sub _smpte2int { my $tc = shift; my @hmsf = split ':' , $tc; my ($hours , $mins, $secs , $frames); $hours = 60*60*$fps*$hmsf[0]; $mins = 60*$fps* $hmsf[1]; $secs = $fps * $hmsf[2]; $frames= $hmsf[3]; return $hours+$mins+$secs+$frames; } sub _int2smpte { my $int = shift; my ($hours , $mins , $secs , $frames); my $r; $r = $int % ($fps*60*60); $hours = sprintf '%02d' , int ( ($int-$r) / ($fps*60*60) ) ; $int = $r; $r = $int % ($fps*60); $mins = sprintf '%02d' , int ( ($int-$r) / ($fps*60) ); $int = $r; $r = $int % ($fps); $secs = sprintf '%02d' , int ( ($int-$r) / ($fps) ); $int = $r; $frames = sprintf '%02d' , $int; return join ":", $hours,$mins,$secs,$frames ; } sub new { my $self = shift; my %tc = @_; #@tc{qw/in out/} = ( _smpte2int($in) , _smpte2int($out) ); die @_ unless ( defined $tc{in} ); die @_ unless (defined $tc{out}); $tc{in} = _smpte2int($tc{in}); $tc{out} = _smpte2int($tc{out}); return bless \%tc, $self; } sub copy { my $self=shift; my $ref =shift; my %tc = %$ref; return bless \%tc, $self; } sub asEdl { my $self = shift; my $in = _int2smpte($self->{in}); my $out= _int2smpte($self->{out}); return join '' , $self->{event}, ' 'x2, $self->{roll}, ' 'x6, $self->{channel}, ' 'x5, $self->{type}, ' 'x8, "$in $out $in $out \n"; } sub check { my $self = shift; return _int2smpte ( $self->{in} ) , _int2smpte( $self->{out} ); }

There's a question in here somewhere I know it... the wisdom I seek is the name of the module I've made bastardized hack of. I'm not sure of the best words to describe it... counters of arbitary range? no... erm... help!


I can't believe it's not psellchecked

Replies are listed 'Best First'.
Re: Processing timeranges with unusual precision.
by gjb (Vicar) on Jan 13, 2003 at 00:06 UTC

    It reminds me of Set::Window's functionality.

    Just my 2 cents, -gjb-

      Aha. . definate ++ gjb for pointing that out, and it would appear that once converted to integers , my timecode is manipulatable (sp.) by Set::Window - Hmm, not too sure what extra logic would be needed to get partial windows from ->cover. I didn't post the logic part of my program (embarrassed).


      Thanks

      I can't believe it's not psellchecked
Re: Processing timeranges with unusual precision.
by fglock (Vicar) on Jan 13, 2003 at 01:37 UTC
    This could be a job for Set::Infinite.
    You could even create an object for 00:01:10:00 format. See Set::Infinite::Date for an example of how to do it.
      It looks like Set::Infinite::Date is deprecated and Date::Set is preferred.

        Set::Infinite::Date is deprecated because Date::Set is more complete.

        But Set::Infinite::Date is simpler, and would be a better start point for a module that is not 'date' related.

Re: Processing timeranges with unusual precision.
by theorbtwo (Prior) on Jan 13, 2003 at 00:35 UTC

    Time::MSF?

    Oh, and also, how does this interact with drop-frame formats, or are they no longer used?


    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

      As far a dropframe formats go I believe that dropframe TC is a display property only - to cope with the fact that NTSC is not truely 30fps but 29.97. So the TC is accuratly counting H:M:S at 30fps , whilst dropframe gives the realtime equiv. it's explained better linked above.


      Update: Another gotcha about EDL format is that TIMTOWT specify dropframe mode.. but that should be the responsibility of a parser , hmm, creating work for someone now , aren't I? (rhet.)


      I can't believe it's not psellchecked