> A proper ts remuxer is quite a different beast to what FFmpeg is > designed to do. As much as people try it can't be hacked into the > FFmpeg paradigm which is largely based around converting static files > of fixed codecs/resolutions in a nonrealtime environment from A to B.
Why is there a udp stream output option then? Are you trying to say that this isn't a bug because FFmpeg isn't supposed to be able to stream? I am using FFmpeg mpeg2video as the encoder and multiplexing with mpegts. The data FFmpeg produces is fine, it just doesn't send it quite right. This isn't a multiplexing problem, it is a udp streaming option. I asked a simple question. Is udp.c supposed to work with any other multiplexer then mpegts? In my experience it doesn't. If that is by design, then it shouldn't be hard to fix this problem. If not, then it becomes a little more complicated. Zach On Wed, Nov 18, 2015 at 8:14 PM, Kieran Kunhya <kier...@obe.tv> wrote: > > 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. > > A proper ts remuxer is quite a different beast to what FFmpeg is > designed to do. As much as people try it can't be hacked into the > FFmpeg paradigm which is largely based around converting static files > of fixed codecs/resolutions in a nonrealtime environment from A to B. > _______________________________________________ > 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
