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

[Zach Swena]

> FFmpeg is trying to remux this file and breaking its compliance then.
> It's the same problem VLC has had for years (and why multicat was
> written).

No, I don't think FFmpeg is not trying to remux the file.  I use FFmpeg to
transcode and mux the file as a single program transport stream and output
to a ts file.  If I then read the file using my own program that doesn't
touch the data of the stream at all, just shovels bytes, it works fine.  If
I take the same transcode command and output to udp instead of a ts file,
then there are buffer problems.  This has to do with the erratic datagram
transmission pattern FFmpeg uses.  Multicat does not support the platforms
I am running on and VLC doesn't produce a broadcast compliant PCR.

Take a look at the data rate graphs on Trac ticket 4155 and try to convince
me that should be normal for a CBR stream.  I think the best implementation
would be to have the muxer send the bit rate to udp.c at the same frequency
as it writes PCR values and use that to set the output cadence.  For VBR
streams, this would result in a stepped transmission rate that varies with
the bit rate.  Data shouldn't be late because the transmission rate would
change with each pcr.  This would also reduce network storms induced by the
heavy packet flow of bursty multicast streams.

Zach

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

> On 19 November 2015 at 16:15, Zach Swena <zcybercomputing at gmail.com>
> wrote:
> >> 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.
>
> FFmpeg is trying to remux this file and breaking its compliance then.
> It's the same problem VLC has had for years (and why multicat was
> written).
>
> Kieran
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>