I use RFC2833 as the DTMF transmitting method for the calls.
Q1: Must the "telephone-event" have the same frequency as the codec used in the call?
E.g. If I use SPEEX 16000 then can I have telephone-event/8000?
Q2: And can I have SDP without any audio codecs but, with specified "telephone-event"?
E. g. can I have an SDP like that:
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15,66,70
Q1: Yes. Here is the proof, taken from RFC errata:
Named telephone events are carried as part of the audio stream and if
they use the same SSRC (therefore the same timing and sequence number
space), they MUST use the same timestamp clock rate as the regular
audio channel.
Q2: Most probably, yes. But, still, I'm not very sure.
Interesting question, I am wondering what usage you have in mind.
First some standard related piece of information:
rfc4733 is applicable here. rfc4733 has obsoleted rfc2833.
In rfc4733, play-out in audio stream of telephone-events is described, it is recommended to use the same rate of the audio stream.
So Q1 answer is positive, in theory you can have mixed rates. It means you do not follow the recommendation, you are on your own! In practice, only equipment supporting multiple rates would accept it.
Q2 is not really clear I guess. If it is a special case of Q1 with no audio stream, I doubt that use-case is supported at all. After all, both share the same RTP SSRC field.
Related
Is SIFS, DIFS, AIFS or nothing used before beacon frame is sent?
I got the frame duration in us by adding 192 us preample and data_bits/1Mbps together but I don't know if I should add DIFS SIFS etc to get total airtime that is required to send one beacon.
I am not totally clear about what you are trying to ask.There are so many parameters regarding airtime for any 802.11 frame.
You mentioned 192us that [Long preamble] is time taken to send PHY layer header of 802.11 Beacon frame.
And Beacon frame is kept in Highest Priority queue in AP and uses the same CSMA/CA method to gain access to wireless medium.I am not sure about which IFS time AP uses before sending beacon.I will get back to you on this.
Update:
--Please ignore my comment.I was not allowed to edit :P --
After discussing with Experienced WLAN Developer,this is the best information i got.
There is no special facilities are given for Beacon.This means, to send Beacon AP has to content the Wireless medium as usual.But beacon is given higher priority than other TX packets ,present in Queue.Thats why you will notice there will be delay [ from actual TBTT ] in Beacon Timestamps [As medium was busy so AP could not able to send Beacon in TBTT]. But STAs will be synchronized according to TimeStamp in Beacon.
Before transmitting a Beacon APs shall use DIFS.
Beacons follow the same channel access procedure that data frames (See IEEE 802.11-2016, Section 11.1.3.2), this is, the AP shall perform a backoff and wait for the channel to be idle during DIFS before sending the Beacon.
Beacons shall be scheduled at the nominal beacon interval, that's why they shall be prioritised (as mentioned by #Bamdeb), but again, they must follow the regular IEEE 802.11 channel access procedure and wait for DIFS.
So far I thought they are the same as bytes are made of bits and that both side needs to know byte size and endiannes of the other side and transform stream accordingly. However Wikipedia says that byte stream != bit stream (https://en.wikipedia.org/wiki/Byte_stream ) and that bit streams are specifically used in video coding (https://en.wikipedia.org/wiki/Bitstream_format). In this RFC https://www.rfc-editor.org/rfc/rfc107 they discuss these 2 things and describe Two separate kinds of inefficiency arose from bit streams.. My questions are:
what's the real difference between byte stream and bit stream?
how bit stream works if it's different from byte stream? How does a receiving side know how many bits to process at a given time?
why is bit stream better than byte stream in some cases?
This is a pretty broad question, I'll have to give the 10,000 feet view. Bit streams are common in two distinct usages:
very low-level, it is the fundamental way that lots of hardware operates. Best examples are the data stream that comes off a hard disk or a optical disk or the data sent across a transmission line, like a USB cable or the coax cable or telephone line through which you received this post. The RFC you found applies here.
high-level, they are common in data compression, a variable number of bits per token allows packing data tighter. Huffman coding is the most basic way to compress. The video encoding subjects you found applies here.
what's the real difference between byte stream and bit stream?
Byte streams are highly compatible with computers which are byte-oriented devices and the ones you'll almost always encounter in programming. Bit streams are much more low-level, only system integration engineers ever worry about them. While the payload of a bit stream is often the bytes that a computer is interested in, more overhead is typically required to ensure that the receiver can properly interpret the data. There are usually a lot more bits than necessary to encode the bytes in the data. Extra bits are needed to ensure that the receiver is properly synchronized and can detect and perhaps correct bit errors. NRZ encoding is very common.
The RFC is quite archeological, in 1971 they were still hammering out the basics of getting computers to talk to each other. Back then they were still close to the transmission line behavior, a bit stream, and many computers did not yet agree on 8 bits in a byte. They are fretting over the cost of converting bits to local bytes on very anemic hardware and the need to pack as many bits into a message as possible.
How does a receiving side know how many bits to process at a given time?
The protocol determines that, like that RFC does. In the case of a variable length bit encoding it is bit values themselves that determine it, like Huffman coding does.
why is bit stream better than byte stream in some cases?
Covered already I think, because it is better match for its purpose. Either because the hardware is bit-oriented or because variable bit-length coding is useful.
A bit is a single 1 or 0 in computer code, also known as a binary digit.
The most common use for the bit stream is with the transmission control protocol, or TCP. This series of guidelines tells computers how to send and receive messages between each other. The World Wide Web and e-mail services, among others, rely on TCP guidelines to send information in an orderly fashion. Sending through the bit stream ensures the pieces arrive in the proper order and the message isn't corrupted during delivery, which could make it unreadable.So a bit stream sends one bit after another.
Eight bits make up a byte, and the byte stream transmits these eight-bit packets from computer to computer.
The packets are decoded upon arrival so the computer can interpret them.Thus a byte stream is a special case of bits sent together as a group in sequential order.For a byte stream to be most effective, it flows through a dedicated and reliable path sometimes referred to as a pipe, or pipeline.
When it comes to sending a byte stream over a computer network, a reliable bi-directional transport layer protocol, such as the transmission control protocol (TCP) used on the Internet, is required. These are referred to as a byte stream protocol. Other serial data protocols used with certain types of hardware components, such as the universal asynchronous receiver/transmitter (UART) technique, is a serial data channel that also uses a byte stream for communication. In this case, the byte, or character, is packaged up in a frame on the transmitting end, where an extra starting bit and some optional checking bits are attached and then separated back out of the frame on the receiving end. This technique is sometimes referred to as a byte-oriented protocol.
Taking a general life example,suppose you have a lot of match sticks to send.Then you could send them one stick after the other,one at a
time.. or you could pack a few of them in a match box and send them
together ,one matchbox after the other in sequence.the first is like
bitstream and the latter like bytestream.
Thus it all depends on what the hardware wants or is best suited for..If your hand is small and you cant accept matchboxes but you still want matchsticks then you take them one at a time or else take the box.Also byte streams are better in a sense that every bit does not need to be checked and data can be sent in batches of 8,.if any of it fails the entire 8bits can be re sent.
To add to the other good answers here:
A byte stream is a type of bit stream. A byte stream describes the bits as meaningful "packages" that are 8 bits wide.
Certain (especially low-level) streams may be agnostic of meaning in each 8 bit sequence. It would be a poor description to call these "byte streams"
Similar to how every Honda Civic is a car, but not every car is a Honda Civic...
I would like to request a 16k Hz sample rate without using an audio session, but have thus far not been successful.
Querying the hardware via AudioUnitGetProperty / SampleRate before configuring the mic / speakers reveals an mSampleRate of 0, which is described in the documentation as implying that any sample rate is supported, but it is also stated that the hardware will actually give you the nearest one that it supports. After I request 16k and query the hardware again the mSampleRate is 44100 for both mic and speakers respectively. Querying the input/output scope of the input/output busses using AudioUnitGetProperty / SampleRate returns 0 in all cases, as does using the equivalent query with StreamFormat instead. Querying with AudioSessionGetProperty / CurrentHardwareSampleRate, despite the session not being configured or initialized, returns 44100. Everything works as expected when using an audio session, but this is not described as necessary in the documentation, except for submitting to the app store which I am not doing.
It is also not clear to me whether, when using an audio session and requesting 16k Hz, the session quietly converts to 16k between the input and output scopes of the input bus, or whether the hardware does actually support "any" sample rate as mentioned in the documentation. It would also be nice to have a list of sample rates supported by the hardware - it's hard to understand why there isn't a queryable list.
I'm interested in any relevant documentation that describes how to do this (without a session), or explains exactly which sample rates I can set the output scope of the input bus to. I have seen discussion in various threads here that it must be a downshift of 44.1k, but I have thus far not found any documentation supporting that assertion.
Many thanks.
I used a ts analyzer for a .ts file i have with mpeg-2 codec and i found out that it splits in 7311 packets.
I m trying to find this through matlab by using fopen to open the ts file in binary and fread to read the file but all i get is a column with a huge collection of numbers(way above the number of packets). Does anyone know how can i determine which of these data are the packets? Or if someone knows another way to find the packets would help me a lot.
Thank you in advance
From some quick googling, the MPEG-2 transport stream ('ts') format consists of packets 188-bytes in length, each having a 4-byte header followed by a 184-byte payload. Essentially, you can count the number of packets by counting the number of headers you find - but beware that, if you are only interested in counting the number of, e.g., video packets in the stream, then you will need some deeper analysis of the headers, because the stream may contain any number of interleaved "elementary streams" (which can be video, audio, or arbitrary data). Each elementary packet type in the stream is denoted by a unique "PID" which is contained in the header.
Aside from the above, you will also have to handle synchronisation - each header begins with the "synchronisation byte", which has a value 0x47 (or 01000111 in binary). According to this resource, decoders begin by looking for this synchronisation byte; once they find one, they may have found a packet header. To make sure, they try to find three consecutive synchronisation bytes (188 bytes apart in the stream); if three are found, synchronisation can occur and the packet boundaries may from then on be assumed at 188-byte intervals. Note, however, that the first byte of each assumed header should be checked to see if it is a synchronisation byte - if it is not, then this is called "sync loss" and the syncrhonisation process must start again.
Once you have some code to syncrhonise to a stream, it should be fairly easy to extract the PIDs from the header of each packet and count the number of packets associated with each unique PID you find. You should probably also check the first bit after the synchronisation byte as, if set to 1, this indicates a transport error, and the packet's payload is invalid. Detailed information on the format of packet headers can be found here.
To me this is not possible. But I can't be too sure. Can somebody confirm this? If it's possible, how?
Thanks
No. According to MPEG2 systems standard - each packet of Transport streams belongs to one PID - which is Packet ID - which correspond to unique component (either audio or video). Hence, it is not possible to put two stream data within 188 packets.