[Libav-user] Encoding with variable frame rate

[Brad O'Hearne]

On May 22, 2013, at 11:58 PM, Kalileo <kalileo at universalx.net> wrote:

> Some more examples: I just re-read last night other threads on the search for some Info about planar aac which I remembered having seen somewhere here, threads such as "AAC with FLV", "Audio quality loss while encoding ", and "av_samples_fill_arrays and memory".
> 
> Please reread them. You'll find the theories you elaborate, the attempts to point you to the errors in the basic assumptions / misunderstandings on which you based your theories (alignment/ packed / planar), then your elaborate justifications of your theories, then some desperate attempts to point you to the errors, and at the end you revisit your assumptions and then it works.

If you had actually bothered to read my posts, or looked at the source code I provided, and were interested in helping rather than taking another condescending swipe at me, you'd know that I quit using the AAC encoder nearly a month ago, when two of the more vocal personalities on this list were diametrically opposed on the view of whether the AAC encoder was "worthless" and not being developed further, or whether it was very important, and surely to be supported and improved further. I've been using libmp3lame for nearly a month. And the quality loss issue was solved soon after switching codecs.  That issue hasn't been on the table for some time now. 

I have had source code posted for 2 months, and my questions during this time have derived directly from the things I was seeing, which you and everyone else have been able to read yourself and run. I even put a nice UI and log file on it so anyone could run and demonstrate the use case without reading source code. Furthermore, it has been posted that most or all of the devs don't run OS X.-- exactly how is everyone so sure and can rule out that what I'm seeing couldn't possibly be an aberration which manifests itself specifically on OS X? Has such a thing ever been possible in the computing world, or is that just not a possibility? So who is talking in theories here, the guy with source code saying "here is what I'm seeing", or the guy who obviously hasn't looked at the source code, likely doesn't run on the same platform, and isn't even aware of what the current problem on the table is? 

> If you expect full code examples to be worked out for you it might indeed be better to hire someone. Otherwise the 'one-liner' you get here is giving you quite often exactly the hint you need to continue.

You were asked a direct question yesterday -- no "theory" -- how do you use AudioFrameQueue. I have found zero discussion of it. The code examples don't address it -- in fact grepping the FFmpeg source shows it is barely referenced throughout FFmpeg. And you have neglected to answer it. If you have no clue, just say you don't know. Otherwise, don't try to cover the fact that you have no answer with a condescending jab insinuating that another developer needs to hire someone because he isn't up to the task. 

This is exactly what I've been talking about in regards to the tone on this list. There is more passion on this list for knocking someone and telling them they are wrong, then actually listening to the problem and helping them. It isn't a climate that breeds either civility or productivity. Kalileo -- why don't you just delete my posts and not reply to them. I'm not much interested in taking continual digs from you, or for that matter, Paul -- and even more so, I am wearying of having to respond continually to both of you guys with explanation as to why whatever zinger you fired off did not solve the problem, so those others on the list who might be interested in giving actual help know the question is still on the table. 

I've tried to be friendly with you guys, but it is clear neither of you are interested in that, and I'm not interested in conflict. I need to get a problem solved. So just delete any posts from me and don't reply. I and I'm sure everyone else would appreciate the end of these exchanges. 

Brad