[Ffmpeg-devel] FFMPEG BUFFERING
Tue Oct 31 02:49:06 CET 2006
Sherlock, John wrote:
[that Michael Niedermayer wrote:]
>> dont top post
Quoting fixed (by hand). Please learn to quote and to snip correctly.
>> On Mon, Oct 30, 2006 at 04:10:09PM -0000, Sherlock, John wrote:
>>> The Issues, are when attempting playback of live video/audio
>>> media greater than 8mb in size of Live, ffmpeg posts errors in
>>> player regarding the file size of the buffer being unable to
>>> handle the media file and attempts three times to restructure
>>> the stream before crashing.
> As I mentioned the player using ffmpeg for media streaming support,
> attempts three times to downsize the size of the stream being sent in
> order to except and begin playback, no other text other than that
> before the medium players closes the stream and closes back to a
> prompt. I never mentioned that ffmpeg crashed. I can't make the
> player, give error messages it doesn't have.
Which "player" are you talking about? ffplay? A program you're writing
yourself, which uses the FFmpeg project's libav* libraries? Something
Also, one near-universal rule, for free:
If you are posting a report about a problem with one of the FFmpeg
project's binary executables (which are named 'ffmpeg', 'ffplay' and
'ffserver'), ALWAYS post the ENTIRE command line you used which produced
the error, AND the ENTIRE (copy-pasted if possible, certainly
non-snipped, byte-for-byte match) text output by that command - no
matter how irrelevant it may seem. This is one of the pieces of
information you would have found, at least implicitly, if you had
bothered to read bugreports.html.
(The same applies to the MPlayer project, though not necessarily to all
other open-source projects. One other rule which *does* apply to all
open-source projects is: if one of the developers asks you for more
information to help them work on a problem you want fixed, you provide
>> and the error messages are what? am i supposed to guess? futhermore
>> i say it again READ AND FOLLOW docs/bugreports.html or do NOT
>> post any further messages here, we cannot help you as long as you
>> refuse to provide ALL details and bugreports.html also clearly says
>> that gdb output is needed if there is a crash
> I don't really care for conforming to how somebody says I should post
> requests for information, if it doesn't meet your standards why
> bother replying unless you've got nothing better to do. Likewise
> other people don't have the time to waste reading some pointless
Actually, you're looking at this question from completely the wrong
If you don't care enough to provide the information asked for in a form
which the people capable of answering your questions are willing to
accept, why should they bother even reading your questions?
The information you have posted so far is not remotely enough to be able
to even diagnose much less fix most types of problems. The developers
know what kind of information they need; bugreports.html explains the
general rules of that, and their own posts explain the specifics.
If you don't care about how you present your question, why should the
developers care about answering it?
>>> The buffers relate to the buffers ffmpeg is supposedly creating
>>> and failing to restructure within the PS2, which according to
>>> several VLC developers is the codec within the source designated
>>> to control media streaming.
>> now i know as much as before ...
> Simply, if you aware of whether it possible to pre-set the size of
> the buffers being created for playback using the FFMPEG codec without
> the platform taking control over the size of buffers then please
> answer yes or no, with some explanition if your capable. Or are you
> just wasting my time??
There is no such thing as "the FFmpeg codec".
"the buffers being created for playback" is not necessarily sufficient
information for him to be able to figure out exactly which buffers you
mean, much less actually answer your question.
Also, from where I sit, it looks like *you* are wasting *his* time. He
is the primary developer of FFmpeg at present; as such, his time (at
least around here) is rather more valuable than yours. He has told you
how to find out what information he needs to be able to work on your
problem - in fact, he's done it twice; you have responded by not
providing that information and by being rude. This is not exactly the
best way to get him to *want* to work on your problem.
>>> I'm attempting to decode and playback live media of a frame rate
>>> of at least 400kbps.
>> kbps means kilo bits per second and thats a bitrate not a framerate
> Yes very good, let see if you make some little mistake after writing
> a 40,000 word report on the basis of your research & development for
> 6months just to keep some exec's happy.
Belligerence helps nobody and nothing. A simple "Oops, you're right, I
think my brain was tired" (or something like that) would have conveyed
the same basic information without antagonizing the people whom you are
trying to persuade to help you.
(And, believe it or not, we *have* seen people who apparently didn't
know the difference between a bitrate and a frame rate - and more.
Michael was not necessarily trying to be condescending.)
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
More information about the ffmpeg-devel