[FFmpeg-devel] UDP constant bitrate feature (cbr)
michaelni at gmx.at
Thu Nov 19 11:05:13 CET 2015
On Wed, Nov 18, 2015 at 08:54:13PM -0800, Zach Swena wrote:
> Is udp.c supposed to work with any other multiplexer then
> mpegts? In my experience it doesn't.
udp can work with any muxer that does not require seeking (if all
packets are received at the receiver end)
if OTOH some packets are lost or demuxing starts at a later point
than muxing then only formats which repeat headers would work reliable
These limitations are a result of what udp is and affect any
> If that is by design, then it
> shouldn't be hard to fix this problem. If not, then it becomes a little
> more complicated.
> On Wed, Nov 18, 2015 at 8:14 PM, Kieran Kunhya <kierank at 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 at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel