> 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 <kier...@obe.tv> wrote: > On 18 November 2015 at 19:28, Zach Swena <zcybercomput...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
