[FFmpeg-devel] UDP constant bitrate feature (cbr)
Zach Swena
zcybercomputing at gmail.com
Wed Nov 18 20:28:03 CET 2015
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 <zcybercomputing at 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 <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