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
