[Ffmpeg-devel] Problem with ffserver. Stream stops almost immediately.
Thu Feb 9 22:58:20 CET 2006
On 2/7/06, Bryan Mayland <bmayland at leoninedev.com> wrote:
> Pranav Desai wrote:
> > You are right ... the client is terminating the connection .. here is
> > last few pkts of the dump.
> > How would i use the frame rate of 29.97 ... mpeg2video and mpeg1video
> > seem to like that. I also tried frame rate of 30 ...with same result.
> Yeah I looked at the code and there really isn't a way to specify
> 29.97 fps. What we're trying to get is 30,000/1001 fps, but the conf
> loader sets the frame rate to 2999997/100100 fps.
> However, I can reproduce this same problem by enabling audio. The
> pts gets all out of whack. If you add NoAudio option to your stream it
> should work around. I'll figure out what the problem is and fix it when
> I have the time.
> Then you'll hit the next problem I'm facing, which is that the
> stream runs "balls-to-the-wall". That is, ffserver sends data as fast
> as it can to the client and the client displays it at whatever frame
> rate your network connection can support. I'm trying to locate where
> this problem is exactly and whose responsibility is to play things at
> the proper frame rate. I would have *thought* that the player would
> check the pts info of the stream and present things at the proper
> timestamp (otherwise, why have a pts?) and only suck up as much
> bandwidth as required.
> I've also noticed that the feed generator (ffmpeg outputting to
> .ffm) runs as fast as possible too. That seems fundamentally wrong
> because if it encodes faster than real time, it will eventually wrap the
> .ffm file and start overwriting areas clients are still streaming from
> (assuming the clients are playing in real time).
I think I understand what you are saying here, but that doesnt seem to
happen. I have used ffserver previously to watch 4-5 hrs of television live
(200 kbps stream) with my upload bandwidth no greater than 200 kbps, and
never had any problem with the feed wrapping and screwing up the client.
Shouldnt it wrap up, since ffmpeg must be writing it faster than 200kbps?
Is the ffm muxer only supposed to run real-time? I can't see any
> code in it directly which throttles its output.
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel