Cloud Recording - Seektable attribute in cloud object metadata #446
Conversation
|
I prefer to refer to existing standards as much as possible. |
|
Is this seek table object attribute mandatory or optional ? concerned about the extra work on the device (mainly multi source cameras) side to create this table additionally and dynamically merge fragment offset to maintain a list not exceeding 20 for each track (audio, video and metadata) separately in case of CMAF. |
|
This seek table object would be optional, like all other blob metadata fields. It's presence doesn't add much functionality, but can improve greatly performance of some use cases. |
|
Instead of defining own format suggest to use hex or base64 encoded MP4 track random access box (TRAF). Please note that this information typically can only be written after file upload has completed which may introduce extra cost depending on provider policies. |
|
I updated this PR and applied Hans's recommendations. Please have a look again :) |
| <title>Typical structure of a Movie Fragment Random Access ('mfra') box</title> | ||
| <mediaobject> | ||
| <imageobject> | ||
| <imagedata fileref="media/RecordingControl/seekTableStructure.svg" contentwidth="130mm"/> |
There was a problem hiding this comment.
The Image is not rendering for the seekTableStructure.svg. All I see is the following issue rendering the image outside the scope of the document.
I believe what I should be seeing is the following file rendered;
There was a problem hiding this comment.
You mentioned Internet Explorer? Is that a goal to be able to render in there? That's been discontinued/end-of-life/retired two years ago and removed from most Windows installations and I certainly did not expect to hear about it in 2024! 😄
There was a problem hiding this comment.
Ha!!, I took down the full PR and opened the recording xml in Microsoft Edge and rendered the file in compatibility mode. The same issue will happen when published on the ONVIF web site. It will need fixed 👍
There was a problem hiding this comment.
I'm learning about the publishing process apparently, wasn't aware it relied on the IE engine :o I guess we could replace the SVG with a regular image if there's issue rendering that
There was a problem hiding this comment.
We don't actually render the xml/svg in the browser when we publish, as we ship the pdf on the onvif website. So I don't think this will be an issue if it renders properly in the generated PDF
There was a problem hiding this comment.
On a side note, its possible the contentwidth or some other property is badly set which triggers that time of rendering
There was a problem hiding this comment.
As mentioned by the colleagues, rendering of the development pages requires a state of the art browser base like Chromium, Firefox or Safari. Edge is nowadays based on Chromium. Compatibility mode is no option.
There was a problem hiding this comment.
@HansBusch I use Edge and Chrome.
To be reasonable and it is an expectation that all content of a specification inclusive of images should render properly regardless of what browser you use to review the content.
I do agree with @jflevesque-genetec that it should display properly in the PDF! Does it?
The primary point before it is missed by all !! Is that the image in the recordingcontrol.xml is not rendering as being shown in the screen shot and the images in the rest of the file do render correctly!!
There was a problem hiding this comment.
@kieran242 could you tell us how you render the page? Because on my side, it seems to render fine (and scales properly if I zoom in/out)
There was a problem hiding this comment.
@jflevesque-genetec I was using the link https://developer.onvif.org/pub/specs/ and selected branches/video/seektable-cloud-recording/doc/RecordingControl.xml.
I have just went and reviewed the same on Edge, and Chrome and it is rendering now. Did you make an update? If not ??? if so renders great :)
I have just re-reviewed and I also see it is for 25.12. Is there more update for this PR?
With the Cloud Recording feature, the devices will push video files (or "segments" in this context) on cloud object storage. When a user wish to playback these files, if they are big enough the callup time will be delayed by the need to download the entire file. This is especially true if the user wish to use HLS or MPEG-DASH to play video across multiple files.
By adding a simple seek table in the metadata of the blob, a video player could download a smaller part to start playing faster. It also allows the player to only download the parts that the user wants to play, and thus seeking in the file more efficiently.
This seek table leverage the fact that a file (or segment in this context) can be built of multiple individual and autonomous fragments according to the CMAF/fragmented MP4 standards.
Accessing this information in the metadata is much faster (and less costly) than downloading part of the file to parse the "SIDX" box at the start (or "MFRA" at the end); which are currently optional. Additionally, this feature would be compatible with a potential future full-file encryption option.