gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2021-09-24T13:32:32Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/395osxvideosink crashes on start, OSX 10.13 Beta (17A330h)2021-09-24T13:32:32ZBugzilla Migration Userosxvideosink crashes on start, OSX 10.13 Beta (17A330h)## Submitted by Kirill Novichikhin
**[Link to original bug (#786047)](https://bugzilla.gnome.org/show_bug.cgi?id=786047)**
## Description
Created attachment 357262
High Sierra crash workaround
Crash in _CFRunLoopSetCurrent wh...## Submitted by Kirill Novichikhin
**[Link to original bug (#786047)](https://bugzilla.gnome.org/show_bug.cgi?id=786047)**
## Description
Created attachment 357262
High Sierra crash workaround
Crash in _CFRunLoopSetCurrent when running osxvideosink on last MacOS beta
Assert "Attempting to deallocate CFRunLoop outside of thread destructor -- this is likely an over-release of the run loop"
Apparently releasing previous runloop outside of thread destructor is now frowned upon.
Workaround: retain previous thread runloop before switching (see patch)
$ lldb -- gst-launch-1.0 tcpserversrc port=5001 ! gdpdepay ! h264parse ! avdec_h264 ! osxvideosink
(lldb) target create "gst-launch-1.0"
ruCurrent executable set to 'gst-launch-1.0' (x86_64).
(lldb) settings set -- target.run-args "tcpserversrc" "port=5001" "!" "gdpdepay" "!" "h264parse" "!" "avdec_h264" "!" "osxvideosink"
(lldb) run
Process 33630 launched: '/usr/local/bin/gst-launch-1.0' (x86_64)
Setting pipeline to PAUSED ...
Process 33630 stopped
```
* thread #4, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x00007fff29b73fe5 CoreFoundation`__CFRunLoopDeallocate + 485
CoreFoundation`__CFRunLoopDeallocate:
-> 0x7fff29b73fe5 <+485>: ud2
0x7fff29b73fe7 <+487>: nopw (%rax,%rax)
```
CoreFoundation`__CFRunLoopCleanseSources:
```
0x7fff29b73ff0 <+0>: pushq %rbp
0x7fff29b73ff1 <+1>: movq %rsp, %rbp
Target 0: (gst-launch-1.0) stopped.
(lldb) bt
* thread #4, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
* frame #0: 0x00007fff29b73fe5 CoreFoundation`__CFRunLoopDeallocate + 485
frame #1: 0x00007fff29c08f9c CoreFoundation`_CFRelease + 300
frame #2: 0x00007fff29b505a6 CoreFoundation`_CFRunLoopSetCurrent + 134
frame #3: 0x00000001007de83e libgstosxvideo.so`-[GstOSXVideoSinkObject nsAppThread] + 30
frame #4: 0x00007fff2bc6c4f8 Foundation`__NSThread__start__ + 1197
frame #5: 0x00007fff517ae6c1 libsystem_pthread.dylib`_pthread_body + 340
frame #6: 0x00007fff517ae56d libsystem_pthread.dylib`_pthread_start + 377
frame #7: 0x00007fff517adc5d libsystem_pthread.dylib`thread_start + 13
0x7fff29b73fd7 <+471>: leaq 0x310d5e(%rip), %rax ; "Attempting to deallocate CFRunLoop outside of thread destructor -- this is likely an over-release of the run loop"
0x7fff29b73fde <+478>: movq %rax, 0x5a372ac3(%rip) ; gCRAnnotations + 8
-> 0x7fff29b73fe5 <+485>: ud2
0x7fff29b73fe7 <+487>: nopw (%rax,%rax)
```
**Patch 357262**, "High Sierra crash workaround":
[runloop.patch](/uploads/a95cbe24c3f19c28ebd6c7ac7adf1644/runloop.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/201osxvideosink: pipeline still doesn't want to stop on closing osxvideosink's w...2021-09-24T13:31:15ZBugzilla Migration Userosxvideosink: pipeline still doesn't want to stop on closing osxvideosink's window## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#752146)](https://bugzilla.gnome.org/show_bug.cgi?id=752146)**
## Description
Similar to this one (marked as fixed): https://bugzilla.gnome.org/show_bug.cgi?id=523134
...## Submitted by Kyrylo V. Polezhaiev
**[Link to original bug (#752146)](https://bugzilla.gnome.org/show_bug.cgi?id=752146)**
## Description
Similar to this one (marked as fixed): https://bugzilla.gnome.org/show_bug.cgi?id=523134
Steps to reproduce:
1. gst-launch-1.0 videotestsrc ! osxvideosink
2. close osxvideosink's window
Expected behaviour:
Setting pipeline to NULL ...
Freeing pipeline ...
Actual behaviour:
Pipeline hangs.
Also: debugging this with Xcode makes Xcode freeze :)
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/123iOS: AudioUnit on iOS produces echo with in/out streams2021-09-24T13:30:43ZBugzilla Migration UseriOS: AudioUnit on iOS produces echo with in/out streams## Submitted by Elio Francesconi
Assigned to **Ilya Konstantinov**
**[Link to original bug (#732896)](https://bugzilla.gnome.org/show_bug.cgi?id=732896)**
## Description
The osxaudiosrc plugin is Remote I/O unit it is not suited f...## Submitted by Elio Francesconi
Assigned to **Ilya Konstantinov**
**[Link to original bug (#732896)](https://bugzilla.gnome.org/show_bug.cgi?id=732896)**
## Description
The osxaudiosrc plugin is Remote I/O unit it is not suited for VoIP purpose because no echo cancellator.
According to the Apple documentation, The Voice-Processing I/O unit extends the Remote I/O unit by adding acoustic echo cancelation for use in a VoIP or voice-chat application.
https://developer.apple.com/library/ios/documentation/MusicAudio/Conceptual/AudioUnitHostingGuide_iOS/AudioUnitHostingFundamentals/AudioUnitHostingFundamentals.html
To use Voice-rocessing I/O unit I did these changes:
in gstosxcoreaudioremoteio.c
static gboolean
gst_core_audio_open_impl (GstCoreAudio * core_audio)
{
return gst_core_audio_open_device (core_audio, kAudioUnitSubType_VoiceProcessingIO,
"VoiceProcessingIO");
//return gst_core_audio_open_device (core_audio, kAudioUnitSubType_RemoteIO,
// "RemoteIO");
}
This patch was not enough to solve the issue because I received status = -50 after some calls of AudioUnitRender in getosxaudiosrc.c, it seems AudioUnitRender modifies buf->core_audio->recBufferList->mBuffers[0].mDataByteSize based on data returned, so before call AudioUnitRender it requires to set mDataByteSize today I’ve created mine osxaudio plugin with these changes, hardcoding "bytes per frame” and “channels” and solved my problem, I did’d check the buffer allocated because it’s big enough.
buf->core_audio->recBufferList->mNumberBuffers=1;
buf->core_audio->recBufferList->mBuffers[0].mDataByteSize=inNumberFrames*4/*where 4 is bytes per frame*/;
buf->core_audio->recBufferList->mBuffers[0].mNumberChannels=1 /*num of channels*/;
status = AudioUnitRender (buf->core_audio->audiounit, ioActionFlags,
inTimeStamp, inBusNumber, inNumberFrames, buf->core_audio->recBufferList);
if (status) {
GST_WARNING_OBJECT (buf, "AudioUnitRender returned %d", (int) status);
return status;
}
Version: 1.x