[FFmpeg-devel] UDP constant bitrate feature (cbr)

[Zach Swena]

> How have you confirmed MPEG-TS compliance?

While not completely definitive, I looked at it with a transport stream
analyser and tested it at our TV station.  At the TV station stream the
file from our server through a remultiplexer that assembles the multi
program transport stream with our various subchannels.  The signal goes
through our ATSC transmitter and decodes fine on every TV I have tested.

> Seven TS packets go inside a single UDP packet.

This is not dictated by the standards.  They support anywhere between 1-7
TS packets per datagram.  Seven packets per datagram is by far the most
common though due to common MTU size limitations.

> udp can work with any muxer that does not require seeking (if all
> packets are received at the receiver end)

The reason I asked is that I am trying to figure out where is best to
determine the UDP rate.  It may be more efficient to do that in the muxer
as it has more information on the subject available and also already knows
how the time stamps are saved in each packet.  In that case, we need a list
of all the FFmpeg muxers that currently support udp as an output.  By
reading PCR from the packets to determine the rate, we have to assume or
set a header format and PCR location and format.  If limiting smooth packet
transmission to using the mpegts muxer is sufficient, then we could just
implement a rate output option for the mpegts muxer and
a corresponding rate control option in udp.c.

> FYI, our awful hack looks like almost working except sometimes effective
bitrate lost for 1-2 seconds, then spike and > then returns to normal (it
can be once after 15 minutes or after more than 4 hours before this issue).

This is probably a side effect of your UDP burst kicking in.  The type of
implementation you used would be better if it assumed a constant bitrate
set by an input option.  If you want to cover vbr streams also, you need a
more complex rate control and measurement method.

> Also there is a question: how it supposed schedule to send packets of
1316 size when muxer produces packets of > > 188 length?

For mpegts, some of the muxer packets contain a PCR, or program clock
reference.  You count the number of bits between PCR values and derive a
bitrate.  From that you can calculate the datagram period based on datagram
size and send at that constant rate.  I havent' found a reference that
specifies maximum datagram jitter, but my test setup using TV sets to
decode works with datagrams that are late up to about 250 micro seconds.

The console output of FFmpeg contains a bitrate value in the status line.
If we can grab that at a high enough frequency and pass it to udp.c, then
we no longer have to worry about header formats and bit rate calculations.
I assume that originates in the muxer?  Given the datagram size and the
bitrate it should be simple to calculate the packet period and control the
datagram transmission frequency.

Zach


On Thu, Nov 19, 2015 at 4:18 AM, Kieran Kunhya <kierank at obe.tv> wrote:

> On 19 November 2015 at 12:00, Pavel Meshkov <pmeshkov at kwikflixtv.com>
> wrote:
> > FYI, our awful hack looks like almost working except sometimes effective
> > bitrate lost for 1-2 seconds, then spike and then returns to normal (it
> can
> > be once after 15 minutes or after more than 4 hours before this issue).
> >
> > Also there is a question: how it supposed schedule to send packets of
> 1316
> > size when muxer produces packets of 188 length?
>
> Seven TS packets go inside a single UDP packet.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>