Rocksteady i...@thetube.ch added the comment:
This fix works for me. Thanks.
SunOS osol134 5.11 snv_134 i86pc i386 i86pc Solaris
Fserver version 0.6.1
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1260
Ronald S. Bultje rsbul...@gmail.com added the comment:
Hi,
HAVE_AMD3DNOW means it can be assembled, not that the CPU supports it. Use
enable-runtime-cpudetect configure flag to use runtime cpu detection
which should fix this.
FFmpeg issue
Ronald S. Bultje rsbul...@gmail.com added the comment:
Here is a forward from ffmpeg-devel. Please adjust the patch so it has
the correct message and MAX_STREAMS (100, not 99, since they're numbered
from 0 onwards, not 1 onwards), and then it's OK.
2011/1/24 Måns Rullgård m...@mansr.com:
John Van Sickle john.vansic...@gmail.com added the comment:
Hi rbultje,
Thanks for responding. The solution you mention is, IMO, a rather poor one. How
are users supposed to know that they need --enable-runtime-cpudetect? Because
for me it took:
1) Having FFmpeg crash with any '-vf scale'
2)
pawel p.kub...@gmail.com added the comment:
So it's possible to retrieve information from ffprobe about bitrate and length
of AMR file?
--
priority: wish - normal
FFmpeg issue tracker iss...@roundup.ffmpeg.org
New submission from Robert Johnston anae...@gmail.com:
ffprobe -loglevel debug report is at http://pastebin.com/WZVLX2Hq
Attached is a Wireshark dump of this stream, so you can play it back on your own
system and try and debug this.
File 'StreamCapture' not attached - you can download it from
longstone zhibing@hotmail.com added the comment:
The patch has been adjusted as requested:
1. The comment and log info have been removed;
2. The max stream count has been defined as 100.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
