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

Zach Swena zcybercomputing at gmail.com
Thu Nov 19 00:41:04 CET 2015


> Because FFmpeg again cannot know a priori whether the input signal is
> fully VBV compliant for use within MPEGTS.
> An RTMP feed is an example of a feed which certainly isn't and so
> FFmpeg has to make some numbers up in order to make a valid TS.
> Such guessing might work in the file world but in the standards
> compliant MPEGTS world it is guaranteed to cause problems.

Of course if the user copies a video stream that isn't complaint there will
be problems if the decoder requires that.  The issue here is two fold.
First, the current udp transmission model can cause problems with
networking equipment because of it's bursty nature.  Second, FFmpeg can
make an otherwise compliant stream fail to decode properly because of these
same UDP bursts.

As far as I know, using the udp output requires use of the -f mpegts
muxer.  Is that correct?

Zach

On Wed, Nov 18, 2015 at 2:38 PM, Kieran Kunhya <kierank at obe.tv> wrote:

> On 18 November 2015 at 19:28, Zach Swena <zcybercomputing at gmail.com>
> wrote:
> > Are you referring to this seperate applciation?
> >
> > https://github.com/mmalecki/multicat/blob/master/trunk/README
> >
> > While using that makes sense for Pavel's application, why should FFmpeg
> > produce a problematic UDP stream in the first place?  For applications
> like
> > I need that involve encoding the stream in the first place, why should I
> > have to use a seperate program to make the output stream complient?
> FFmpeg
> > should keep track of the number of bytes between pcr and smoothly output
> > the stream regardless of what the input is.  I would argue that this very
> > much is a bug, not a feature.  Just because an external applciation can
> fix
> > the problem in some instances doesn't mean it isn't a problem in the
> first
> > place.
>
> Because FFmpeg again cannot know a priori whether the input signal is
> fully VBV compliant for use within MPEGTS.
> An RTMP feed is an example of a feed which certainly isn't and so
> FFmpeg has to make some numbers up in order to make a valid TS.
> Such guessing might work in the file world but in the standards
> compliant MPEGTS world it is guaranteed to cause problems.
>
> Kieran
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list