Bug 77399 - error with 3rd party library concurrently running with streamer on iOS
Summary: error with 3rd party library concurrently running with streamer on iOS
Status: NEW
Alias: None
Product: GStreamer SDK
Classification: Unclassified
Component: iOS SDK distribution (show other bugs)
Version: 2013.6
Hardware: ARM other
: high blocker
Assignee: bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-13 13:40 UTC by michelle
Modified: 2014-04-24 02:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description michelle 2014-04-13 13:40:07 UTC
I have been tasked with building a recording mechanism for RTP over UDP streams emitted from an embedded in vehicle device.

There is already a third party framework that uses ffmpeg that the customer wants to use, the app uses Gstreamer for extensively for operations other than recoding.

The problem I see is that libav built for streamer as get-libav has the following options --disable-protocols  --disable-filters

2014-04-12 22:36:43.301 Road-iQVS[763:60b] Error: Could not open stream: -816688904
2014-04-12 22:36:43.302 Road-iQVS[763:60b] avformat_open_input failed with error Protocol not found

this message is from the third party framework that does not use ffmpeg pipes or custom AVIO, simply does avformat_open_input 

There doesn't seem to be anyway to override the default installation without rebuilding from source.

I follow the doc to build the sdk which says to use the included Cerbero script, this seems to be very monolithic one shot process.

Ideally I would like to just link to my own libav which is outside the streamer.framwork

Seems to me that Gstreamer,framework for IOS was put together haphazardly without regard for its coexistence with other static libs.

I do really that this is unique to IOS because of the way it doesn't allow static libs , but nonetheless is maddening. 

This will probably cost me the contract on less I can figure out a way around this.

test code is below using just common libav.


-(void) gst_ffmpeg_stream  {
    
    avctx = avformat_alloc_context();
    
    
    // Set the RTSP Options
    AVDictionary *opts = 0;
    
    av_dict_set(&opts, "rtsp_transport", "rtsp", 0);
    
    
    int err = 0;
    err = avformat_open_input(&avctx, "rtsp://test.tscplayer.net/test/8300", 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");
    }
    
}
Comment 1 michelle 2014-04-13 14:34:09 UTC
would doing this in the libav static recipe

      self.use_system_libs = True



Keep Gstreamer from loading the .a, than I could manually link the plugin's against my delivered ffmpeg version.
Comment 2 michelle 2014-04-14 19:49:11 UTC
I created a small test to illustrate the problem. Please give me an email your server will not allow me to upload the app as an attachment

if I disable the loading of libav   use an external libav and run the test app I get stream successfully opened. the code is below


-(void) gst_ffmpeg_stream  {
    
    
    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", "rtsp", 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");
    }
    
}


But if I uncomment the code and let the internal libav load I get this

0x50f58c:  add    r2, pc
0x50f58e:  bl     0x77b50c                  ; _gst_debug_category_new at gstinfo.c:1506
0x50f592:  str    r0, [r5]
0x50f594:  movw   r0, #57
0x50f598:  movt   r0, #0
0x50f59c:  add    r0, pc
0x50f59e:  blx    0x48cf60                  ; av_log_set_callback
0x50f5a2:  bl     0x511b84                  ; gst_ffmpeg_init_pix_fmt_info at gstavutils.c:112
0x50f5a6:  blx    0x3e2068                  ; av_register_all
0x50f5aa:  mov    r0, r4
0x50f5ac:  bl     0x5008dc                  ; gst_ffmpegaudenc_register at gstavaudenc.c:701
0x50f5b0:  mov    r0, r4
0x50f5b2:  bl     0x50fe88                  ; gst_ffmpegvidenc_register at gstavvidenc.c:881
0x50f5b6:  mov    r0, r4
0x50f5b8:  bl     0x507938                  ; gst_ffmpegauddec_register at gstavauddec.c:816
0x50f5bc:  mov    r0, r4
0x50f5be:  bl     0x502194                  ; gst_ffmpegviddec_register at gstavviddec.c:1814
0x50f5c2:  mov    r0, r4
0x50f5c4:  bl     0x512f30                  ; gst_ffmpegdemux_register at gstavdemux.c:1909
0x50f5c8:  mov    r0, r4
0x50f5ca:  bl     0x51776c                  ; gst_ffmpegmux_register at gstavmux.c:870
0x50f5ce:  mov    r0, r4
0x50f5d0:  bl     0x50f8a4                  ; gst_ffmpegdeinterlace_register at gstavdeinterlace.c:338
0x50f5d4:  movs   r0, #1
0x50f5d6:  pop    {r4, r5, r7, pc}
Comment 3 Andoni Morales Alastruey 2014-04-15 17:54:06 UTC
Hi,

If I understood correctly the problems comes from a 3rd party framework that also uses libav and there are conflicts between the 2 versions used.

I see 2 options:

1) Add a new recipe with the libav version you want to use and disable the build of the internal libav in gst-libav-1.0 with:
configure_options = '--with-system-libav'

You might need to comment out this part to prevent libav being packaged in the framewiork or make sure that your libav recipe creates these files in the correct place to include them in the framework:

42         for f in ['libavcodec', 'libavformat', 'libavutil', 'libswscale']:
43             for ext in ['.a', '.la']:
44                 path = os.path.join('lib', f + ext)
45                 self.files_plugins_codecs_restricted_devel.append(path)

2) Update libav submodule gst-libav to use the correct version you need.

libav's API is changes from times to time and gst-libav is compiled against a version of libav that's know to build and work fine. If you change it things might not work as expected.
Comment 4 michelle 2014-04-21 15:56:38 UTC
This is Blocking not one but two client projects for me!


is this documented somewhere, I've searched there doesn't seem to be any documentation on this anywhere.

1) Add a new recipe with the libav version you want to use and disable the build of the internal libav in gst-libav-1.0 with:
configure_options = '--with-system-libav'

So how can I "tell" gst-libav to use my version of the ffmpeg libraries, that will not be bundled into the framework.

Ideally I'd like to use an ffmpeg bundled into a framework. ffmpeg.framework





The only method that works is to disable loading libav , load the .a's outside the streamer.framework 

But then I am left with the issue that all the pipelines that use avdec_h264 or ffdec_h264 are broken.  

I've already been given direction to incrementally get rid of streamer entirely from the code, but it appears that we may not have the luxury of doing that incrementally.

seeing my client is vendor to the auto industry, GStreamer may be losing some very important penetration.

I just don't get the philosophy of building such a "heavy framework" that is not very extensible. I do understand these problems are unique to IOS but still....
Comment 5 michelle 2014-04-24 02:39:48 UTC
nothing seems to work, I tried all the methods you've suggested.
I don't seem to be able to get the with-system-lib method to work, do you have an IOS example.

I put the question to stack overflow maybe someone will come up with an answer. 

http://stackoverflow.com/questions/23258681/force-gstreamer-for-ios-to-use-ffmpeg-library-outside-of-the-framework


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.