> 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
