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. Zach On Wed, Nov 18, 2015 at 11:14 AM, Zach Swena <zcybercomput...@gmail.com> wrote: > > Only for strict CBR streams which FFmpeg cannot know a priori. That's > > why the only correct way is to index the stream as it's received and > > play out at a smooth rate like multicat does. > > I am not sure what you are referencing with regards to multicat. Is this > an output option? Smooth output streams are needed in other applications > then just relaying a stream. Why can't I find the term multicat in any of > the code or documentation? > > Zach > > On Wed, Nov 18, 2015 at 10:37 AM, Zach Swena <zcybercomput...@gmail.com> > wrote: > >> Yea, how it is supposed to happen isn't complicated. To be of any help, >> I have to wrap my mind around how FFmpeg currently times the output >> stream. That mechanism currently does not produce as stable of a >> transmission rate as multiplexer and decoder hardware requires. Since >> there is a bounty available for this, it would be nice if someone more >> qualified could tackle this problem. Until someone steps up, I will be >> poking at it from my end. I am used to reading c++ intead of c code, so my >> reading is still a little slow. Fixing this problem will open up new >> possibilities on how I can use FFmpeg. >> >> Zach >> >> On Wed, Nov 18, 2015 at 9:03 AM, Michael Niedermayer < >> mich...@niedermayer.cc> wrote: >> >>> On Tue, Nov 17, 2015 at 03:06:27PM -0800, Zach Swena wrote: >>> > Hi Pavel, >>> > >>> > I can confirm that there is a problem with the UDP packet engine in >>> > FFmpeg. FFmpeg has excessive jitter in it's UDP streaming output to >>> the >>> > point where hardware decoders can't handle it. My solution was to >>> buffer >>> > to disk and have my own program read and send the datagrams via a very >>> > tight event loop. While increasing the PCR period is not a bad thing, >>> > FFmpeg really should stream at a more consistant rate. Can someone >>> explain >>> > the theory behind how the UDP rate control is currently implemented in >>> > FFmpeg? PCR sounds like a good way to tell when to send a packet, >>> except >>> > not every packet contains one. If FFmpeg uses PCR to tell how long to >>> wait >>> > to send a packet, then do the packets in between go at line speed? I >>> plan >>> > on taking a look at the code that does this, but I would really >>> appreciate >>> > it if someone who knows the code could explain the theory as I usually >>> deal >>> > with a slightly different dev setup. >>> >>> i suggest you read the mpeg specs, they detail when things should be >>> sent down to each byte IIRC >>> also IIRC its not that complicated, more like timestamp + bytepos/rate >>> >>> >>> [...] >>> -- >>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >>> >>> I know you won't believe me, but the highest form of Human Excellence is >>> to question oneself and others. -- Socrates >>> >>> _______________________________________________ >>> 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
