On Apr 30, 2013, at 11:30 PM, Kalileo <[email protected]> wrote:
> Then, Paul did not recommend to remove it, but _you_ did. If useless, why keep useless code? If not useless, keep it. Whether useless or not, that's for you to debate with who claimed it, which wasn't me. I don't care either way -- I just would prefer no cruft in the code. > Others called that FUD, I call it half-theories. The reason people have to conjecture about how FFmpeg works is that there is no manual, guide, or sufficient document explaining it adequately -- the only answers are locked in certain people's heads. If you don't want people coming to the mailing list and trying in earnest to understand how FFmpeg works, then document it. > So far, from what I remember, despite all the theories about mysterious > problems in ffmpeg the solution to the problems you reported and elaborated > here have not resulted in any bug report for ffmpeg. The solution was always > that the assumptions you made, and based your elaborations on, were wrong. I think this probably tells the tale more than anything. This was never a competition or matter of "I'm right, you're wrong" to me. I came here to solve a problem for a client, not pit my code vs. FFmpeg, and use it to pump my ego and take a victory lap at someone else's expense in a public forum. I've literally spent weeks on this, and have done far more testing and "rechecking" than I've indicated, at no one's prompting or direction on this mailing list. Here is a direct summary of the reason my problem (which was actually the combination of several problems) was difficult to solve: 1. Inadequate examples and documentation. 2. Partially accurate/inaccurate information received on this mailing list about the nature of pts, dts, and time_base. 3. At worst a bug in documentation, at best very confusing documentation about the AVCodecContext's frame_size. 4. Questions of alignment. (on a side note -- why does this question ever have to be asked -- if FFmpeg requires it, either assert or check / return error in the code, so there's no question) Some of the info was helpful. Some of it was not. It took many, many hours of testing to sift through it and figure out what was accurate, and what was not. In the end, it was someone off-list who had used FFmpeg in the past and had gone on to roll his own video / audio encoding toolset who listened to the bad audio and immediately knew it wasn't an alignment problem (even though I had tested that out and knew it too), which freed me to turn my turrets elsewhere. Dumping AAC and going against what it appears the API doc says regarding AVCodecContext frame_size resulted in the resolution. Brad _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
