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.
Related
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.
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.
I have edited EXIF properties on digital pictures, and would like to be able to identify them as identical. I believe this implies extracting the payload stream and computing a hash. What is the best way to do this, ideally in the Java language, most ideally in Java using a native implementation for performance.
JPEG files are a series of 'segments'. Some contain image data, others don't.
Exif data is stored in the APP1 segment. You could write some code to compare the other segments, and see if they match. A hash seems like a reasonable approach here. For example, you might compare a hash of only the SOI, DQT or DHT segments. You'd need to experiment to see which of these gives the best result.
Check out the JpegSegmentReader class from my metadata-extractor library.
Java: https://github.com/drewnoakes/metadata-extractor
.NET: https://github.com/drewnoakes/metadata-extractor-dotnet
With that class you can pull out specific segment(s) from a JPEG for processing.
Let us know how you get on!
Can tags and readers do some calculations in a RFID system? I found many papers designed security protocols to enhance the security of RFID systems. In those protocols, tags and readers are required to do necessary calculations, such as exclusive OR (XOR), random number generation, and even hash operation and so on.
However, to my understanding, tags and readers do not have the calculation ability, then how to implement these protocols? We need design special tags and readers? Thank you very much!
This heavily depends on the type of RFID system (frequency, communication standard, etc) and the type of tag (passive or active/semi-passive).
For instance, with UHF backscatter systems, passive tags usually contain only a small memory (and logic to process commands).
In the HF range, there is ISO/IEC 14443. For that standard, there exist lots of passive tags (contactless smartcards) that contain a processing unit and can even execute complex program code. ISO/IEC 15693 (same frequency range, different standard) passive tags usually conain only memory and some additional control logic (e.g. password-based locking/unlocking). The same applies to tags in the LF range.
Active tags (regardless of the standard, as long as the standard contains some form of command response protocol if you want to interact with that functionality), however could do pretty much any calculation if they contain an appropriate processing unit.
According to wikipedia (I read the German version) one can build complex microchips into any RFID. It's also possible to add Sensor as for example GPS. RFID chips do not need to be passive, they can have a battery to power the whole RFID chip (active) or just the microprocessor (semi passive).
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...