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.
Related
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.
Sorry if this question has been asked before (I could not find any questions similar to mine), but is there a "maximum" buffer size that I should be sending over a socket at one time? If I were to for example send over data with a buffer size equal to that of the maximum allowed by sockets, would there be anything bad about that? Thanks in advance for any help.
It depends on the kind of sockets. With TCP a connection is a byte stream and the OS will take care of how best to split the bytes into packets and concatenate these together at the other side.
With UDP instead each send will result in a single UDP message (datagram) and there is an upper limit of 64k for the size of a datagram. But even while UDP supports 64k datagrams in theory it is not a good idea to use that large messages. Since the maximum transfer unit of the underlying layer is much smaller (like around 1500 bytes for Ethernet) the message needs to be fragmented and it is easy to loose a single fragment - in which case the whole message is considered lost.
You can send as much data as you want - that's the point of the abstraction. The underlying layers will do what they want, breaking things into chunks as necessary, but you shouldn't have to care about that as a user of the interface. The read and write interfaces both will return the length actually transmitted in the case of a partial read, so a simple loop should be sufficient to do a large transfer.
What I mean is whether or not there is an algorithm which can make it possible to tell, when comparing two UDP packets, which one of them was sent first?
I would need to implement this in C# using libraries such as these: System.Net.Sockets and System.Net.
Also the answer to this question helps me build a reliable UDP protocol (that is the final goal I am trying to achieve, so if anyone knows a good optimized implementation of reliable UDP that would also solve my problem).
Sent first? Not possible, unless the sender(s) are putting a timestamp, or a sequence number, in the application level packet payload.
Take a look at MoldUDP -- its a popular protocol in the financial sector for a single sender to reliably broadcast a data feed to many consumers.
Assume I have defined my own application layer protocol on top of TCP for Instant Messaging. I have used a packet structure for the messages. As I am using symmetric (AES) and asymmetric (RSA) encryption, I obtain a different
packet size for different message types. Now to my questions.
How to read from a socket that I receive a single application layer packet?
What size should I specify?
Thanks in advance.
I have two approaches in mind.
Read from the TCP stream a fixed amount of bytes that represents the
actual packet size, and finally re-read from the stream the former gathered size of bytes.
Read the maximal packet size from the stream. Verify the actual size of
obtained bytes and decide so which message type it was.
Now, a more general question. Should I provide metadata like the packet size, encryption method, receiver, sender, etc.? If yes, should I encrypt these meta data as well?
Remember that with TCP, when reading from the network, there is no guarantee about the number of bytes received at that point in time. That is, a client might send a full packet in its write(), but that does not mean that your read() will receive the same number of bytes. Thus your code will always need to read some number of bytes from the network, then verify (based on the accumulated data) that you have received the necessary number of bytes, and then you can verify the packet (type, contents, etc) from there.
Some applications use state machine encoders/decoders and fixed size buffers for reading/writing their network data; other applications dynamically allocate buffers large enough for the "full packet", then continue reading bytes from the network until the "full packet" buffer is full. Which approach you take depends on your application. Thus the size you use for reading is not as important as how your code ensures that it has received a full packet.
As for whether you should encrypt additional metadata, that depends very much on your threat model (i.e. what threats your protocol wants to guard against, what assurances your protocol needs to provide to its clients/users). There's no easy way to answer that question without more context/details.
Hope this helps!
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.