强制GStreamer for IOS在框架外使用ffmpeg库

Gstreamer 1.0 for IOS是在一个静态框架中交付的，构建该框架的源代码约为1.2g，该框架非常庞大，并试图为您可能有的任何解码服务器场景提供支持。问题是，它试图做的太多，而IOS端口却没有投入足够的思想

问题是，我们有一个应用程序使用GSTreamer avdec_h264插件通过UDP流显示RTP。这相当有效。最近我们需要做一些特殊的录制功能，所以我们引入了一个api，它有自己的ffmpeg版本。Gstreamer已将Libav编译到框架中。当我们在禁用gst_IOS_restricted_插件的情况下将api放入应用程序时，当我们将GStreamer.framework引入应用程序时，代码运行良好，类似于下面所示的代码失败，并出现协议未找到错误

问题是libav的内部版本似乎禁用了ffmpeg提供的所有协议。因为GSTreamer使用它自己的基于ffmpeg管道协议的自定义AVIO回调

根据Gstreamer的支持，这有点帮助

)使用要使用的libav版本添加新配方，并在gst-libav-1.0中禁用内部libav的构建，方法如下： 配置_选项='--使用系统libav'

您可能需要注释掉这一部分，以防止libav被打包到framewiork中，或者确保libav配方在正确的位置创建这些文件，以便将它们包含在框架中：

42对于['libavcodec'，'libavformat'，'libavutil'，'libswscale']中的f： 43对于['.a'，'.la']中的分机： 44 path=os.path.join（'lib'，f+ext） 45 self.files\u plugins\u codec\u restricted\u devel.append（路径）

2） 更新libav子模块gst libav以使用所需的正确版本

第一种方法不起作用，即使在应用了修补程序以修复此错误报告所导致的错误后，配方仍会被覆盖

我不知道怎么做第二种方法。这正是我需要帮助的地方

有人使用GStreamer 1.0 for iOS吗

1） 针对ffmpeg静态libs（.a）框架集的外部构建get-libav插件

2） 构建内部libav以支持RTP、UDP和TCP协议，或者使用FFPipe协议编写自定义AVIO回调

3） 只是设法让下面的代码与GStreamer一起工作

我不会问很多问题，我已经用ffmpeg、lib555和一些硬件解码器实现了各种编码器/解码器。但是GStreamer的问题让我比很久以前睡不着觉了

AVFormatContext * avctx;
avctx = avformat_alloc_context();

av_register_all();
avformat_network_init();
avcodec_register_all();
avdevice_register_all();



// Set the RTSP Options
AVDictionary *opts = 0;

av_dict_set(&opts, "rtsp_transport", "udp", 0);


int err = 0;
err = avformat_open_input(&avctx, "rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov", NULL, &opts);
av_dict_free(&opts);
if (err) {
    NSLog(@"Error: Could not open stream: %d", err);
    char errbuf[400];
    av_strerror(err,errbuf,400);
    NSLog(@"%s failed with error %s","avformat_open_input",errbuf);



}
else {
    NSLog(@"Opened stream");
}

err = avformat_find_stream_info(avctx, NULL);
if( err < 0)
{
    char errbuf[400];
    av_strerror(err,errbuf,400);
    NSLog(@"%s failed with error %s","avformat_find_stream_info",errbuf);
    return ;
}else {
     NSLog(@"found stream info");
}

AVFormatContext*avctx；
avctx=avformat_alloc_context（）；
av_寄存器_all（）；
avformat_network_init（）；
avcodec_寄存器_all（）；
avdevice_register_all（）；
//设置RTSP选项
AVDictionary*opts=0；
av命令集（&opts，“rtsp传输”，“udp”，0）；
int err=0；
err=avformat\u open\u输入（&avctx，“rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov“，NULL，&opts）；
av_dict_free（&opts）；
如果（错误）{
NSLog（@“错误：无法打开流：%d”，错误）；
char-errbuf[400]；
av_strerror（错误，错误，400）；
NSLog（@“%s”失败，错误为%s”，“avformat\u open\u input”，errbuf）；
}
否则{
NSLog（@“开放流”）；
}
err=avformat\u find\u stream\u info（avctx，NULL）；
如果（误差<0）
{
char-errbuf[400]；
av_strerror（错误，错误，400）；
NSLog（@“%s”失败，错误为%s”，“avformat\u find\u stream\u info”，errbuf）；
返回；
}否则{
NSLog（@“找到流信息”）；
}

---

}

显然，GStreamer的这个端口做出了一些非常糟糕的折衷，内置系统和内部插件方法在桌面系统上非常有效，但没有很好地转化为iOS框架，似乎到处都有与其他静态lib争用的多种可能性。我确实意识到，IOS的一个缺陷是，你只能加载一个stactic lib的副本，很明显，linux甚至android都有共享库。这个问题根本不存在。