Is it possible to store multiple video paragraphs, each has its owned parameters, in one track of a mp4 file? - mp4

I want to encode a sequence of video frames (FHD) into a h264 stream in a way like this:
From time t1 to time t2: encode with "main" profile, FHD and at 30fps.
From time t3 to time t4: encode with "high" profile, HD(scaled) and at 15fps.
From time t5 to time t6: encode with "main" profile, FHD and at 30fps.
Note: t1 < t2 < t3 < t4 < t5 < t6.
My question is, by complying the MP4 standard, is it possible to put video streams encoded by different parameters into a same video track of a mp4 file? If it is impossible, what is the best alternative?

Yes, at least according to the specification. If you look at ISO/IEC 14496-15 (3rd edition), it contains a definition of Parameter set track:
A sync sample in a parameter set track indicates that all parameter sets needed
from that time forward in the video elementary stream are in that or succeeding parameter stream
samples. Also there shall be a parameter set sample at each point a parameter set is updated. Each
parameter set sample shall contain exactly the sequence and picture parameter sets needed to
decode the relevant section of the video elementary stream.
As I understand it, in this case instead of writing the intial SPS/PPS data into the avcC box in stbl you write a separate track containing the changing SPS/PPS data as sync samples. So at least according to the spec, you would have samples in that stream with presentation times t1,t2,t3,t4,t5 and the samples themselves would contain the updated SPS/PPS data. This quote from the same standard seems to agree:
Parameter sets: If a parameter set elementary stream is used, then the sample in the parameter
stream shall have a decoding time equal or prior to when the parameter set(s) comes into effect
instantaneously. This means that for a parameter set to be used in a picture it must be sent prior to the
sample containing that picture or in the sample for that picture.
NOTE Parameter sets are stored either in the sample descriptions of the video stream or in the parameter set
stream, but never in both. This ensures that it is not necessary to examine every part of the video elementary
stream to find relevant parameter sets. It also avoids dependencies of indefinite duration between the sample that
contains the parameter set definition and the samples that use it. Storing parameter sets in the sample
descriptions of a video stream provides a simple and static way to supply parameter sets. Parameter set
elementary streams on the other hand are more complex but allow for more dynamism in the case of updates.
Parameter sets may be inserted into the video elementary stream when the file is streamed over a transport that
permits such parameter set updates.
ISO/IEC 14496-15 (3rd edition) also defines additional avc3 / avc4 boxes, which, when used should allow to actually write the parameter sets in-band with the video NAL units:
When the sample entry name is 'avc3' or 'avc4', the following applies:
If the sample is an IDR access unit, all parameter sets needed for decoding that sample shall be included either in the sample entry or in the sample itself.
Otherwise (the sample is not an IDR access unit), all parameter sets needed for decoding the sample shall be included either in the sample entry or in any of the samples since the previous random access point to the sample itself, inclusive.
A different question is, even though standard allows at least two ways (in band with avc3, out of band with parameter set track) to achieve this, how many players there are which honor this. I'd assume looking at least into the sources of ffmpeg to find if this is supported there is a good start.
The answers in this question also lean towards the fact that many demuxers are only honoring the avcC box and not separate parameter set track, but a couple of quick google searches show that at least both vlc/ffmpeg forums and newsletters have mentions of these terms, so I'd say it's best to try to mux such a file and simply check what happens.

Related

Adaptive bitrate streaming protocol (for any data)

I'm looking for some ideas/hints for streaming protocol (similar to video/audio streaming) to send any data in so called real-time.
In simple words:
I'm producing some data each second (let's say one array with 1MB of data per second) and I'm sorting that data from most important to not so important (like putting them to priority queues or similar)
I would like to keep streaming those data via some protocol and in perfect case I would like to send all of it
If not possible (bandwidth, dropping packets etc.) I would like to send from each produced array as much as possible (first n-bytes) just to keep data going (it is important to start sending new produced array each second).
And now - I'm looking for such protocol/library that will handle adaptive bit rate stuff for any data. I would expect from it to tell me how much data I can send (put into send buffers or similar approach). The most similar thing is video/audio streaming when in poor network conditions (en)coder is changing quality depending on network conditions.
It is also OK if I miss some send data (so UDP deep down of this stuff is OK) but preferably I would like to send as much data as possible per second without loosing anything (from those first n-bytes send).
Do you have any ideas of what protocol/libraries I could use for client/server? (hopefully some libs in python, C or C++).
I think IPFIX (the generic NetFlow standard) has everything you need.
You can avoid a timestamp per sample by sending a samplingInterval update every time you change your rate. You can also add other updating the change in sampling asynchronously.
As for where to put your data. You can create a new field or just use an existing one with that has a datatype you want. IE: if you are just sending uint64 sample values then it might be easier to use packetDeltaCount then create your own field definition.
There are plenty of IPFIX libraries.

Is there any test link for Mpeg DASH in both: type = "dynamic" and with multiple representations (bitrates)?

As title:
I have tried to find some but I found for most of cases
if the test url is of type = "dynamic" there is ONLY ONE representation (a unique bitrate; CANNOT apply bitrate switch).
Does anyone know if there is a test link?
Thanks
There are several DASH data sets and test vectors out there, lots of them are listed in this blog post. Many don't have live streams, but some have (at least simulated live streams).
The DASH IF Test Vectors might be a good starting point, there are several live streams (look at the column mpd_type and search for the value dynamic), at least some should have multiple representations.

Muxing MP4 with a profile that has multiple SPS/PPS

The ISO/IEC 14496-15 specification "Information technology — Coding of
audio-visual objects — Part 15: Advanced Video Coding (AVC) file format" that describes the avc1 box used in MP4 files states that the avc1 box can contain multiple SPS and PPS entries for a single sample description (not to be confused with repeated SPS/PPS). And I am not sure how to mux such streams:
So far I've seen H.264 high profile streams with multiple PPS nal units for a single sample description. What confuses me is that since I've never personally seen a H.264 stream with multiple SPS units - is that even possible and what is the reasoning behind that?.
If that is possible - what happens to the AVCProfileIndication and AVCLevelIndication fields in the avc1 box? Should they be filled from the first SPS entry? If there are multiple SPS entires, I guess the profile indication should not differ, but what about level?
The sps and pps have ids encoded as a integer. VCL NALUs tell the decoder "to decode me you need data from a pps with id X". Hence theoretically each VCL NALU can reference a SPS/PPS with a different id. I've never seen this done in practice. But it is part of the h.264 spec, so the container supports it. And Yes, Just use the first SPS for the profile/constraints/level bytes.

Determine Remaining Bytes

I'm working on a project where I need to send a value between two pieces of hardware using CoDeSys. The comms system in use is CAN and is only capable of transmitting in Bytes, making the maximum value 255.
I need to send a value higher than 255, I'm capable of splitting this over more than one byte and reconstructing it on the receiving machine to get the original value.
I'm thinking I can divide the REAL value by 255 and if the result is over 1 then deconstruct the value in to one byte holding the remainders and one byte holding the amount of 255's in the whole number.
For example 355 would amount to one byte of 100 and another of 1.
Whilst I can describe this, I'm having a really hard time figuring out how to actually write this in logic.
Can anyone help here?
This is all handled for you in CoDeSys if I understand you correctly.
1. CAN - Yes it's in byte but you must not be using CANopen you are using the low level FB that ask you to send a CAN frame of an 8 byte array?
If it is your own two custom controllers ( you are programming both of them in CoDeSys) just use netvariables. Netvariables allows you to transfer any type of variable and you can take the variable list from one controller and import it to another controller and all the data will show up. You don't have to do any variable manipulation it's handle under the hood for you. But I don't know the specifics of your system and what you are trying to do.
If you are trying to deconstruct construct variables from one size to another that is easy and I can share that code with you.

Sequence number in a midi file. How does it work?

I have been googling about it for a while but all the info I found was a little ambiguous. I'm not an expert in midi, I'm only interested in midi files. I need to know what this meta-event is for, and how it affects the playback of a multi-track midi file (format 1).
For type 1 and type 2 MIDI files, the sequence number indicates that events for the given track will follow this event. If you are only interested in parsing type 1 files, this basically indicates the start of actual MIDI events. However, type 2 files may have several tracks, each one starting with a sequence meta event.
For more information, see: http://home.roadrunner.com/~jgglatt/tech/midifile/seq.htm
My understanding is the Sequence Number is just an additional piece of information that may be used to identify a song. I think of it as a numerical alternative or supplement to the Sequence Name.
Imagine a drum box that can save or load its drum patterns into individual MIDI files (or perhaps into individual tracks in a single Format 2 MIDI file). Or imagine an electronic keyboard that can save or load its accompaniment patterns into individual MIDI files. In a scenario like this, I imagine the Sequence Number could be used to indicate which pattern number or accompaniment number the MIDI file (or Format 2 track) corresponds to.
"Sequence Number" is an ill conceived notion in MIDI files that's never been clearly implemented. For a single file of type 0 or type 1, it has no meaning whatsoever. It's a no-op.
For a file of type 2, or a collection of type 0 or type 1 files, it's intended to identify separate sequences, in order, like a sort of play list. Players could then select a sequence by number.
If the sequence number isn't specified, it's assigned sequentially, although, again, for a single file this pretty much only matters for type 2.
In effect, sequence number has never really been used much to my knowledge. Maybe in embedded applications like games...