Timing between MPEG-TS packets

[gekod]

Hello,

I'm currently trying to develop an MPEG-TS streamer.
It's supposed to read an MPEG-TS file and send the packets to a client.
Now I have one problem. I haven't figured out yet how to calculate from the PES packets at what frequency to send the packets.

The first version I've developed reads the PTS and DTS values of PES packets and calculates how many packets one Video second is composed of and then calculates at what frequency it has to send them packets. This doesn't seem the best solution to me though.

I would like to develop a new version that takes fully advantage of the timing information in the TS packets.


Thanks in advance

[Ghitulescu]

Why complicate things? Keep a buffer on the reception side and let the sender know when to start/stop.

[Guest]

Why complicate things? Keep a buffer on the reception side and let the sender know when to start/stop. That would be viable for a single receiver with a back channel. But for broadcast not.

The usual way is to send data at the bitrate of the transport stream. The bitrate can be known because it is specified when the stream is muxed, or it can be determined in retrospect by counting the bits between PCRs.

[gekod]

Hi,

First I want to thank both of you for your help.


Why complicate things? Keep a buffer on the reception side and let the sender know when to start/stop.

Neuron2 is right. It's not intended for a single receiver but for broadcast. That's why I am facing this problem.


That would be viable for a single receiver with a back channel. But for broadcast not.

The usual way is to send data at the bitrate of the transport stream. The bitrate can be known because it is specified when the stream is muxed, or it can be determined in retrospect by counting the bits between PCRs.

I'll give it a try later today to see if I figure out how to do it.

:thanks: for both of you again =)

[gekod]

Hello,

Sorry for only answering now but I've been very busy and had to work on some other project first.

So I've tried reading the PCR values while counting the packets between each packet containing the PCR value.
When I calculate how many bytes that makes for each video second (PCR second), I don't get a constant number... Is that normal?
I'm just asking because normally the MPEG-TS stream has a constant bit rate right? So I would expect to get approximately the same value of bytes for each video second. Or am I getting something wrong?

Thanks

[Ghitulescu]

Neuron2 is right. It's not intended for a single receiver but for broadcast. That's why I am facing this problem.
I know he is right, but you mentioned broadcast only now, most people understand by streaming a sort of data transfer from a storage device to a playing one.

In fact is actually vice-versa: one sets a max bitrate of the encoded MPEG file according to the "reliable"/sustainable bitrate of the communication channel.

When I calculate how many bytes that makes for each video second (PCR second), I don't get a constant number... Is that normal?
I'm just asking because normally the MPEG-TS stream has a constant bit rate right? So I would expect to get approximately the same value of bytes for each video second. Or am I getting something wrong?

It's called VBR. In the header, if any, there is most probably an average bitrate, however my experience with SAT or edited MPEG files is that the bitrate is a "generic" one, like 15000. I'm positive that even CBR files have a slight fluctuation.

[pandy]

It's called VBR. In the header, if any, there is most probably an average bitrate, however my experience with SAT or edited MPEG files is that the bitrate is a "generic" one, like 15000. I'm positive that even CBR files have a slight fluctuation.

Without stuffing it will be always VBR, and yes, even CBR TS have small fluctuation of bitrate - but usually quite small (in theory it should be +- one packet -1504 bps)

[gekod]

Ok guys,

first of all thanks again for your help.

Now I just don't seem to find out what I'm doing wrong.
Here's what I've done so far:

*I read the stream packet per packet
*I read the PCR from every packet that contains one
*I calculate the PCR to Hours, minutes, seconds, miliseconds
*I count the packets(188Bytes) send between two PCRs different one second from each other. So now I should have the number of packets I got in one VIDEO second.
*Then I calculate how many ms i have to wait between sending each UDP packet containing 7 TS packets -> that's my delay between each UDP packet (I don't send packet per packet but I send one 7 TS packets at the time)
*If that delay has passed, I send the packet.

Now, it works, but, sometimes I seem to get a low packet rate per VIDEO second which will translate in a very large delay for sending each packet -> my video will freeze because the delay I have between sending each packet is too big.


I really tried to figure out what the problem is but I still haven't got it.
There seems to be a bigger fluctuation in the Bit rate at some moments.


Hope you guys can help me.


Regards

[Ghitulescu]

Ok guys,

first of all thanks again for your help.

Now I just don't seem to find out what I'm doing wrong.
Here's what I've done so far:

*I read the stream packet per packet
*I read the PCR from every packet that contains one
*I calculate the PCR to Hours, minutes, seconds, miliseconds
*I count the packets(188Bytes) send between two PCRs different one second from each other. So now I should have the number of packets I got in one VIDEO second.
*Then I calculate how many ms i have to wait between sending each UDP packet containing 7 TS packets -> that's my delay between each UDP packet (I don't send packet per packet but I send one 7 TS packets at the time)
*If that delay has passed, I send the packet.

Now, it works, but, sometimes I seem to get a low packet rate per VIDEO second which will translate in a very large delay for sending each packet -> my video will freeze because the delay I have between sending each packet is too big.


I really tried to figure out what the problem is but I still haven't got it.
There seems to be a bigger fluctuation in the Bit rate at some moments.


Hope you guys can help me.


Regards

Because you started from the wrong end.
The bitrate of the video is defined by the available bandwidth, not vice-versa. You can't send a high bitrate-encoded video (eg a blu-ray) with a 56k RS232 modem.

[gekod]

Because you started from the wrong end.
The bitrate of the video is defined by the available bandwidth, not vice-versa. You can't send a high bitrate-encoded video (eg a blu-ray) with a 56k RS232 modem.

I don't really get what you mean.

It actually works, I just don't understand why sometimes the packet count varies so much (on the machine reading the actual file)

[Ghitulescu]

There is nothing wrong in what I said, probably I misunderstood you.
Are you really sure the sending PC stops?

Remember, the TCP/IP requires "theoretically" that all packets (100%) must reach their destination (the sender will keep trying to send the same packet over and over; there are some parameters to be set that govern this behaviour). If you prefer the time over safety, pick up UDP and add redundant data to the packets to reconstruct the missing ones at the destination, should some of them get lost.

However, there can be made a lot of safe assumption simply knowing EXACTLY what you intend to do. Two PCs running the same version of windows/linux and linked with a CAT5+ cable require a lot less effort than doing the same broadcast from Australia to Greenland.

[IanB]

How are you doing your timing delay?

Most windows calls waits for a minimum of the specified delay rounded up to granularity and can delay longer, much longer (due to process scheduling).

You need to measure the actual time that you slept and continually compensate for that. Hopefully the amount of client buffering you have is enough to absorb your worst case "slept for to long".

A better model might be to up front logically schedule each UDP packets to leave at a certain high res clock time. This intrinsically compensates for scheduling delays. So if you sleep past the time for the current and next packet you simply send the current and next packets together and catch up.

This model can also give a debugging cross check of your maths by comparing the schedule time for the UPD frame with the PTS time of a TS packet it contains. They should always be within the buffering limits of your algorithm.

[gekod]

Alright, I probably didn't explain myself too well.
There really seems to be a misunderstanding.

Let's try to clarify the context:
I am reading the MPEG-TS data from a file packet per packet and then trying to send them at a correct frequency to some client (in my case I am simply sending them to VLC media player).

How I am doing it:
To calculate how much time +/- I have to wait between each packet, I read the PCR values in the packets containing some.
Between two packets containing a PCR different at least one second from each other, I count the packets. So, after one PCR second has passed I know how many packets compose that second. Now I simply calculate how many ms I need to wait between each packet.

The problem:
My problem, at least for now, is that when I count how many packets were sent between two PCRs different by one second (which should result in one video second), I sometimes get a very big fluctuation.
One example is a stream where I always get around 600-700 packets per second but then suddenly between two PCRs different by one second, I only count 20 packets. This makes the delay fluctuate a lot and the packets sometimes getting sent with a huge delay one from another.

Hope I explained myself better this time.

Thanks a lot again for your patience.


Best regards

[Ghitulescu]

Doesn't have the VLC project a module that send the data to the VLC player? This is how VLC appeared ....

[gekod]

LOL I simply am trying to program a streamer myself. There surely are many programs already doing this.

I use VLC only for testing. All I want to do is a streamer that reads a file and streams it to some client, no matter what that client is. It only has to stream it a the right rate so it's not too fast or too slow. I want to stream it to an IP address. It isn't important who is reading it.

[gekod]

Hey all,

I just wanted to tell you that I found my error and that it's working now.
I didn't know that the Adaptation Field can be present but have a length of 0 ate the same time. So I was only checking if there was one then reading the values. Whenever there was a packet having an adaptation field present but with a length of zero I would still read the values of the following payload which resulted in a wrong PCR value.

Thanks anyways


Regards