Defining P1, P2 etc in session manifest file
I'm working on a auto recording upload connector between our Zoom tenant and our on-prem Panopto instance.
When generating a ucs.xml session manifest file using the universal-capture-2.1 schema I am able to successfully specify multiple video files as Primary. However, I also want to be able to definitively assign specific video files to specific tracks (i.e. P1, P2, P3 etc) in the Panopto editor.
How can I guarantee the ordering of video files in Panopto editor tracks via the ucs.xml session manifest?
Best Answer
-
Adis Hrnjica Whiz Kid
Hi John,
When streams have identical start times, the final ordering depends sometimes on database insertion order, not only on the XML document order. Code is doing things in parallel and there is possibility sometimes that this happens.
If this is a problem for you, I could create internal issue and see if we can somehow fix this potentially.
I hope this helps.Adis
0
Answers
Hi John,
Schema Structure: The UCS 2.1 schema defines video types as:
Track Ordering: When you have multiple videos with Type="Primary", Panopto processes them sequentially in the order they appear in the XML's <Videos> array and assigns them to tracks P1, P2, P3, etc.
The UCS schema doesn't have explicit P1/P2/P3 attributes - track assignment is purely based on XML element order. The Panopto backend processes videos in document order using standard XML parsing, so the first Primary video becomes P1, second becomes P2, etc.
I hope this helps.
Thanks,
Adis
Got it, thanks Adis.
In my testing before creating this post I thought that I found this wasn't guaranteed, the videos were showing in Panopto in an order different from what I expected. I have run one more test right now and they are coming in in the correct order, so it's possible there was a bug in my test environment during my initial tests. Will test some more to ensure I'm receiving consistent expected ordering.
Out of curiosity, is it documented anywhere that the track assignment is guaranteed to be based on XML element order?
Hi John,
Based on the code analysis it seems it should work that way. I don't think there is a documentation that I'm aware of.
Thanks,
Adis
Hi Adis,
Apologies for the delay in responding while I found the time to test this some more.
Experimentally, it does appear to me that while we usually find video files are added to Panoptos primary video tracks in the element order of the ucs.xml file, they will occasionally not be assigned to the correct tracks.
To test, I fed the exact same input to my Zoom <> Panopto connector script 5 times, and confirmed that the same ucs.xml definition below was generated by my script each time:
In 4/5 (80%) of my tests:
active_speaker.MP4
gallery_view.MP4
In 1/5 (20%) of my tests:
gallery_view.MP4
active_speaker.MP4
Can you think of any reason why these two videos may occasionally end up swapping tracks on the Panopto session that's generated from the above XML?
Thanks,
John
Hi Adis,
Thank you for confirming, I thought I was going mad.
I think it would be good to create an internal issue for this, as in my case the video streams will always have the same start times and durations (streams are padded with black frames during processing on the Zoom side), and I need to have confidence in which primary video track appears "on top" to a viewer of the Panopto session if no edits are made by the owner. If an internal issue is created, is there any way for me to be able to track its progress?
As a possible workaround, since ISO 8601 permits fractional units of time, do you think setting a start time of something like
<Start>PT0.001S</Start>
for my second primary stream (i.e. start time of 1ms) would give me reliable consistent ordering of my primary video streams? How would you expect Panopto to handle that?Thanks,
John
Hi John,
I'll create internal issue for this, but unfortunately you cannot track the progress of it.
Yes, that is exactly the way to go, 1ms offset is completely imperceptible to humans so no issues (humans can't detect sync differences under ~40ms). I think by doing this you should get consistent P1/P2 assignment.
Thanks,
Adis
Great, thank you Adis!
Re: the internal issue you've created, what would be the best way for me to at least know if this does end up getting fixed in a future Panopto release?
Re: the workaround, awesome! When I get the chance I'll test this out, and will report back to confirm if this has worked as expected.
Thank you for the help!
Hi John,
I can try to respond this this forum post when it happens, but cannot promise since things can change in the meantime.
I think the workaround should work.
Thanks,
Adis
Got it, thanks Adis - much appreciated.