It is currently 24 Jun 2017, 18:19



When did a clip finish playing?

CasparCG Server, Client and development

Moderators: Macey, Jonas Hummelstrand, didikunz

When did a clip finish playing?

Postby zbang » 06 Dec 2016, 20:00

Hello,

Today's thoughts... how to tell when a clip has finished (or stopped) playing without scraping the log file for events.

For video clips--
You can issue periodic INFO commands to the channel/layer and look at status=playing or =stopped. (This may not reflect a mid-clip failure; haven't tested that, probably OK.) Seems like a kludge.

You can look at the OSC messages /channel/#/stage/layer/#/file/frame and see if the frame number is increasing; that stops when it runs out of frames to display. You'll still get OSC messages but the numbers won't change.


For audio-only clips (i.e. mp3's)--
The status in the INFO command output will show as 'playing' past the end of that clip (the layer is still playing) and the frame number keeps increasing. One can look at frames-left to see it go negative, but I'm not sure how reliable the total frame count is. (Is the source of that metadata or stream timestamps from the end of the file? I've had trouble getting TRT on video clips.)

There are no OSC /channel/#/stage/layer... messages for audio-only clips.

You can look at the audio level in OSC message /channel/#/mixer/audio/#/dBFS (channel is audio channel, not playout channel); silence is -192.66. This however appears to look at -all- audio output, not just a specific channel/layer. Somewhat kludge-y, but not so bad.


I haven't looked at other producers (html, flash, image, etc).

My current methods use frame-count for video and audio level for audio, but at least the latter seems like a kludge. Is there a better way? (And have I missed anything?)

Two follow-on questions-
Why are there no OSC stage/layer messages for audio-only? Does that code hang on the visual stream processing?
Why doesn't the channel/layer status go from playing to stopped at the end of an audio-only clip? Same reason?
(Are these bugs or "features"? :) )

Thanks,

z!
who hasn't gone sniffing around in the server code looking for answers. yet.
zbang
 
Posts: 44
Joined: 10 Apr 2015, 02:09

Re: When did a clip finish playing?

Postby Rom1 » 13 Dec 2016, 13:54

Hello,

You can look at the OSC messages /channel/#/stage/layer/#/file/frame and see if the frame number is increasing; that stops when it runs out of frames to display. You'll still get OSC messages but the numbers won't change.


Personally I use this method. But it's a little tricky to code and you have a little latency.
User avatar
Rom1
 
Posts: 35
Joined: 21 May 2015, 19:00

Re: When did a clip finish playing?

Postby Rom1 » 13 Dec 2016, 13:56

It should be nice to have a "stop/play" status in OSC protocol of Caspar.
You can ask to the develop team to add this feature.
User avatar
Rom1
 
Posts: 35
Joined: 21 May 2015, 19:00

Re: When did a clip finish playing?

Postby zbang » 16 Dec 2016, 08:10

Followup #1--
If the clip that's playing stops due to error, the OSC 'layer' messages will also stop. If you're looking for the current frame-count to be greater than the last one..... you'll never get a message to compare.

It can also get dicey if one clip interrupts another that's currently running. Again, the frame-count is not helpful unless you detect that major change (expecting >12345, got 2). For that, you can look at the path (i.e. "/channel/1/stage/layer/10/file/path s "media\runningman.avi") and see if that changed but that seems to happen after the file/frame message.

Another option if you're watching the time (i.e. "/channel/1/stage/layer/9/file/time f 1.800000f 10.720000"): if the time reported is less than 1 but the most recent frame-count is greater that the FPS, it must be a new clip playing (and the frame-count will reset with probably the next OSC bundle).

I don't know, but I do hope, that the OSC message order is fixed/predictable; for instance, there will always be a file/time message before a file/frame.

When it's presentable, I'll put out the code I've written to handle this stuff. And if anyone has corrections, please share them.

Later,

z!
zbang
 
Posts: 44
Joined: 10 Apr 2015, 02:09

Re: When did a clip finish playing?

Postby mcdikki » 16 Dec 2016, 08:34

The order of OSC messages is not and will not be predictable. This is a limitation of the underlying UDP protocol.
UDP does not guaranty delivery of packets in order, nor that they are delivered at all. So, OSC messages has to be handled carefully with this in mind. You can't trust the order the messages arrive and you can't use a single message as single point of truth.

cheers
mcdikki
sublan.tv - Wir teilen Begeisterung
User avatar
mcdikki
 
Posts: 1059
Joined: 11 Dec 2012, 15:48
Location: Germany

Re: When did a clip finish playing?

Postby zbang » 16 Dec 2016, 18:34

Hi,

Right, yes, I'd neglected that OSC is delivered via UDP :); call it predictable but not guaranteed. (I haven't looked at whether multiple OSC messages are bundled or not and whether they're going to be in the same order each bundle; liblo takes care of unbundling for me. Probable doesn't matter.)

I do agree with mcdikki's point that a single OSC message can't be taken as a reliable indication of state (for some reasons listed above). OTOH 2 or 3 of them very well may. For my system, I may just set up a 500ms INFO query, too, and use both mechanisms. OTOH that will clog up the server log with INFO commands.

IIRC the 2.1 server has some sort of event delivery mechanism that will "solve" the state-knowledge problem (off to look at that thread again).

Later,

z!
zbang
 
Posts: 44
Joined: 10 Apr 2015, 02:09


Return to Tech and Development

Who is online

Users browsing this forum: No registered users and 5 guests