[FFmpeg-user] mmsh streams and immense buffering

Patrick Cornwell pat at nerdy.co.uk
Tue May 22 18:40:33 CEST 2012


Hi,

 

I am a novice with FFMPEG but have over the years fudged a live streaming
service using the Windows Media format and Windows Media Services. In
hindsight, not perhaps the best course but that's where we are.

 

Myself and a few developers have been attempting to use FFMPEG to transcode
some streams for playback on different devices with some success.  The
problem comes with certain streams. For example, this stream, which works
fine in Windows Media Player or VLC:

 

http://209.105.232.35/cssaitek1

 

(I pass it in as mmsh:// within FFMPEG). The result is:

[wmv3 @ 00000000(some random hex)] Extra data: 8 bits left, value: 0

 

which sits there for a good 3-4 minutes before any data seems to come out
the other side. Sniffing the NIC and looking at the media server stats shows
that data is flowing right from the start however, so something is holding
FFMPEG up.

 

Some streams do not do this, e.g.

 

http://209.105.232.35/csdigitaldanuk

 

(also an mmsh://)

 

These are both live feeds using the same software to encode the streams.

 

The first stream gives this warning after its several minute wait (even
though it goes on to process fine):

[asf @ 00000000003deec0] Stream #0: not enough frames to estimate rate;
consider increasing probesize

 

Whereby the second doesn't.

 

I'm guessing there's an issue with stream #1 at the encoding stage. I have
about 120-140 live streams I can probe and it seems about a third are
affected with this. Is there a hack to make FFMPEG just process example
stream 1 (above) like it does example stream 2 (above) in a timely manner?
I've tried setting -probesize to various random values but I am really a
novice at this and it doesn't seem to make a difference.

 

Any help would be appreciated... I think the issue is fairly easy to
replicate.

 

Thanks,

 

Pat

 



More information about the ffmpeg-user mailing list