[FFmpeg-devel] UDP constant bitrate feature (cbr)
Zach Swena
zcybercomputing at gmail.com
Wed Nov 18 20:14:34 CET 2015
> 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 <zcybercomputing at 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 <
> michael at 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 at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>
More information about the ffmpeg-devel
mailing list