GNOME Bugzilla – Bug 576126
av_iformat_next and av_oformat_next compile errors using FFmpeg v0.5 release and MSVC
Last modified: 2009-05-07 10:59:28 UTC
Missing symbols "first_iformat" and "first_oformat" in FFmpeg-generated .lib files for use with MSVC. The generated .lib files alias the external symbols calling them "_first_iformat" and "_first_oformat" respectively. This can be remedied using the FFmpeg API to get the intended values. Instead of (gstffmpegdemux.c): in_plugin = in_plugin->next; Use: in_plugin = av_iformat_next(NULL); Instead of (gstffmpegmux.c): in_plugin = first_oformat; Use: in_plugin = av_oformat_next(NULL);
Created attachment 131047 [details] [review] Potential fixes This should fix the problem. It also addresses using FFmpeg APIs to get the next format rather than using the private (according to FFmpeg documentation) "next" field.
Whoops. In the code mentioned above, thiss: in_plugin = in_plugin->next; Should be: in_plugin = first_iformat; The patch should be clearer as to the intent.
commit da8d4abad2d023888f560fb91b1d347e975ed38a Author: David Hoyt <dhoyt@llnl.gov> Date: Thu May 7 12:57:10 2009 +0200 Use av_{i,o}format_next instead of the private next field This fixes compilation with MSVC where the initializer variables are aliased to different names. Fixes bug #576126.