I could force it in the openh264 sources, if you could tell me where to modify the code. Since I'm using openh264 through FFmpeg, I don't think I have direct access to a function that sets the tracing level. If you or someone else would care to investigate, please let me know the best way we can communicate. But, I'm not sure the comments section of this issue is the best way to deal with this. I'd certainly like to see FFmpeg working with openh264, but about all I can offer in terms of furthering this goal are specifics on the warnings, as well as the code that triggers them. Unfortunately, I don't have enough experience with FFmpeg, or knowledge of its internals, to be effective in debugging my way through these issues. I understand completely that openh264 is relatively new, and its use with FFmpeg even newer, so these sorts of things are expected. On the other hand, it's also possible I'm just unfortunately running into a bug in openh264. I expect some of the warnings might be addressed by some additional settings in my use of the FFmpeg API, and these may also be contributing to the encoding failure. However, with openh264 I get a number of somewhat ominous-sounding warnings, and then end up with "EncodeFrame failed" after just a few frames. I can switch to openh264 using the configure args you pointed out. I have some code that encodes "raw" RGB data (via conversion to YUV) nicely, when used with x264.
I'm attempting to make use of openh264 with FFmpeg, but for now am not dealing with the "downloaded shared library" issue - I'm just compiling both from their latest git repositories.
0 kommentar(er)
