[FFmpeg-user] mmsh streams and immense buffering

Thu May 24 02:00:45 CEST 2012

Quick note from phone: i am seeing this with aac audio and h264 video through mpegts muxer using udp transport. I've been able to mitigate it sometimes using codec:a libfaac. Source is a hauppauge hd pvr.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Patrick Cornwell <patrick at cornwell.org> wrote:

> I am not able to reproduce (two of) your problem(s).
> ffmpeg does not crash here, the reason might be that my FFmpeg is not
> compiled with x264 support, but I don't know because as far as I know
> you did not test without -vcodec libx264 (Note that crashes are
> important, so there is a high chance that the crash is fixed once it is
> either reproduced or a backtrace is
> provided.)

It does not crash when encoding the non problematic streams utilising
(presumably) the libx264 codecs when outputting a .flv or .mp4. 

As you pointed out, there does seem to be an issue with timestamps.

I only know what I see. In FFplay, I get the following with:

ffplay -i "mmsh://209.105.232.35/cssaitek1"

ffplay version N-40640-g5edd4fc Copyright (c) 2003-2012 the FFmpeg
developers
built on May 13 2012 18:02:34 with gcc 4.6.3
configuration: --enable-gpl --enable-version3 --disable-w32threads
--enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r
--enable-libass --enable-libcelt --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libfreetype --enable-libgsm
--enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp
--enable-libschroedinger --enable-libspeex --enable-libtheora
--enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs
--enable-libxvid --enable-zlib
libavutil 51. 50.100 / 51. 50.100
libavcodec 54. 21.101 / 54. 21.101
libavformat 54. 4.100 / 54. 4.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 72.105 / 2. 72.105
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 11.100 / 0. 11.100
libpostproc 52. 0.100 / 52. 0.100
[wmv3 @ 0000000001dd76a0] Extra data: 8 bits left, value: 0

(THREE MINUTE DELAY)

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

(NO PROBESIZE OPTION IN FFPLAY?)

[asf @ 000000000402ce60] Estimating duration from bitrate, this may be
inaccurate
Input #0, asf, from 'mmsh://209.105.232.35/cssaitek1':
Metadata:
WMFSDKVersion : 12.0.7600.16385
WMFSDKNeeded : 0.0.0.0000
IsVBR : 0
Duration: N/A, start: 917.823000, bitrate: 266 kb/s
Stream #0:0(eng): Audio: wmav2 (a[1][0][0] / 0x0161), 22050 Hz, 1 channels,
s16, 16 kb/s
Stream #0:1(eng): Video: wmv3 (Main) (WMV3 / 0x33564D57), yuv420p, 640x480,
250 kb/s, 12.50 tbr, 1k tbn, 1k tbc
[wmv3 @ 0000000001dd76a0] Extra data: 8 bits left, value: 0
1337813179.42 A-V:1337812261.575 fd= 0 aq= 0KB vq= 5085KB sq= 0B
f=0/0
1337813179.68 A-V:1337812261.544 fd= 0 aq= 0KB vq= 5085KB sq= 0B
f=0/0
1337813179.72 A-V:1337812261.712 fd= 0 aq= 0KB vq= 5083KB sq= 0B
f=0/0
1337813179.81 A-V:1337812261.716 fd= 0 aq= 0KB vq= 5081KB sq= 0B
f=0/0
1337813179.91 A-V:1337812261.715 fd= 0 aq= 0KB vq= 5079KB sq= 0B
f=0/0
1337813179.98 A-V:1337812261.712 fd= 0 aq= 0KB vq= 5077KB sq= 0B
f=0/0
1337813180.04 A-V:1337812261.710 fd= 0 aq= 0KB vq= 5078KB sq= 0B
f=0/0
1337813180.15 A-V:1337812261.717 fd= 0 aq= 0KB vq= 5076KB sq= 0B
f=0/0
1337813180.20 A-V:1337812261.710 fd= 0 aq= 0KB vq= 5074KB sq= 0B
f=0/0
1337813180.32 A-V:1337812261.717 fd= 0 aq= 0KB vq= 5102KB sq= 0B
f=0/0
1337813180.37 A-V:1337812261.717 fd= 0 aq= 0KB vq= 5099KB sq= 0B
f=0/0
1337813180.45 A-V:1337812261.717 fd= 0 aq= 0KB vq= 5097KB sq= 0B
f=0/0
1337813180.56 A-V:1337812261.714 fd= 0 aq= 0KB vq= 5095KB sq= 0B
f=0/0
1337813180.63 A-V:1337812261.719 fd= 0 aq= 0KB vq= 5093KB sq= 0B
f=0/0

etc

Unlike the non problematic streams, this scrolls up in the window rather
than replaces the same line while FFplay window plays stream. The timestamp
in the stream indicates it's playing from the immediate aftermath of the
command and not from the 3 minute point.

So this is when I tried:

ffplay -i "mmsh://209.105.232.35/cssaitek1" -sync video

C:\ffmpeg\bin>ffplay -i "mmsh://209.105.232.35/cssaitek1" -sync video
ffplay version N-40640-g5edd4fc Copyright (c) 2003-2012 the FFmpeg
developers
built on May 13 2012 18:02:34 with gcc 4.6.3
configuration: --enable-gpl --enable-version3 --disable-w32threads
--enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r
--enable-libass --enable-libcelt --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libfreetype --enable-libgsm
--enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp
--enable-libschroedinger --enable-libspeex --enable-libtheora
--enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs
--enable-libxvid --enable-zlib
libavutil 51. 50.100 / 51. 50.100
libavcodec 54. 21.101 / 54. 21.101
libavformat 54. 4.100 / 54. 4.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 72.105 / 2. 72.105
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 11.100 / 0. 11.100
libpostproc 52. 0.100 / 52. 0.100
[wmv3 @ 0000000000347780] Extra data: 8 bits left, value: 0

(AGAIN, 3 MIN DELAY, BUT DUE TO PROBESIZE OPTION MISSING)

[asf @ 00000000042cce60] Stream #0: not enough frames to estimate rate;
consider increasing probesize
[asf @ 00000000042cce60] Estimating duration from bitrate, this may be
inaccurate
Input #0, asf, from 'mmsh://209.105.232.35/cssaitek1':
Metadata:
WMFSDKVersion : 12.0.7600.16385
WMFSDKNeeded : 0.0.0.0000
IsVBR : 0
Duration: N/A, start: 1406.418000, bitrate: 266 kb/s
Stream #0:0(eng): Audio: wmav2 (a[1][0][0] / 0x0161), 22050 Hz, 1 channels,
s16, 16 kb/s
Stream #0:1(eng): Video: wmv3 (Main) (WMV3 / 0x33564D57), yuv420p, 640x480,
250 kb/s, 25 tbr, 1k tbn, 1k tbc
[wmv3 @ 0000000000347780] Extra data: 8 bits left, value: 0
1413.05 A-V:1337812262.940 fd= 0 aq= 0KB vq= 5127KB sq= 0B f=0/0

The above line is all that was on the screen when I ctrl+c'd it. It did not
scroll up like the other method.

I know that's hardly scientific, but the 'non scrolly' view is what I get
with a non problematic stream also, so in my mind at least, it 'means
something'. Hence, my assumption that if I could replicate the '-sync video'
option within ffmpeg, I could get some desired output?

Sorry for mildly snapping before. I appreciate the support and understand
it's all done on a completely voluntary basis. 

I've seen the streams all work in various apps which utilise FFMpeg
components on different devices, so fundamentally I believe the probesize
thing has fixed a great deal (the problem streams take 3 minutes to start on
the apps I've tried) - I guess I'm trying to just make sure I can do some
transcoding of some kind here before instructing developers of any special
requirements for FFMpeg. Saves money them scratching their heads (and in my
experience not even delving this deep and giving up)

> ffmpeg does not convert the problematic streams here, I do not know
> why, but if you look at the ffplay console output, it indicates that
> FFmpeg is unable to correctly read the timestamps (I tried to explain
> that in my very first mail iirc), that seems like a reason, and I do
> not know how to fix it.

What's mildly odd is that it will play in FFPlay and look fine - so if it's
able to do that, why can't those frames be transcoded? I know it sounds
incredibly simplistic from me, but obviously it feels -so close- to working
it's head scratching to say the least.

If there's any specific ffmpeg/ffplay outputs which would help, just ask.

Thanks,

Pat

_____________________________________________

ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user