Udp complains about missing pthreads #18
Comments
|
Exactly what are you doing when you get this "complaint". What is generating the complaint? Ill need complete bug information in order to resolve. |
|
I am streaming video and audio over rtsp. This works fine with the FFmpeg builds from zeranoe. However, when I build it on MSVC I get this error:
You can find the relevant source code at https://ffmpeg.org/doxygen/trunk/udp_8c-source.html, line 557. Note that this is not a problem with ShiftMediaProject itself, I had faced this before when I built using MSVC with MSys2. What I'm asking is whether it would be possible to fix this in ShiftMediaProject. Screenshot of issue: http://i.imgur.com/vYKMVmb.png |
|
OK, the additional info makes it much clearer. Currently only using pthreads will enable the missing functionality of the udp code. However there have been issues with pthreads-win32 reported before so i wouldnt recommend using them and that is why all provided projects use win32 threads. Instead I have a patch that i quickly wrote up to see if it fixes the problem (i.e. enables the functionality without needing pthreads). In order to test to see if it fixes your use case you have to apply the patches and test them yourself. They are linked below so if you can test them out and ensure that it works correctly i will add it the upstream ffmpeg repo myself. Just "git am < [patch]' onto an existing ffmpeg repo to test them. https://gist.github.com/Sibras/08fc183f280eb6451c736ce42182963b |
|
Thanks! I am away from my main work machine right now, I'll try it out tomorrow and let you know how it goes :) |
|
I can confirm that the two patches solve the problem with udp, as in they don't complain anymore. However I am not sure of the implications on functionality, since streaming worked fine for me before and after applying the patches. |
|
udp would still work without the patches, however using the patch enables using a multithreaded packet queue. The previous errors you got was because you were setting certain settings that only applied to this packet queue (in this case the buffer size setting) hence why you got the error. The patch allows the multithreaded functionality when using win32 threads instead of the previous pthread requirement. So the main issue with this patch is to ensure all packets are still being received and are correctly decoded. I have updated the first gist as there was a logic bug in it. But if you can confirm the above requirements with the new patch then i will submit it upstream. |
|
I won't be able to test the updated gist until tomorrow. But other than that, yes I can confirm that this does indeed work. I've been using it for rtsp streaming and so far haven't faced any issues. Many thanks for your prompt response and help in this matter 👍 |
|
OK the previous code patches i supplied were not fully thread safe so some improved versions are now available. These patches are pending inclusion in the main ffmpeg repo so it would be really helpfully if you could test these out and make sure they work for you. https://gist.github.com/Sibras/6792316413f3a595d8a941d924cbe653 If you could test these on a fresh ffmpeg repo and ensure udp streaming works correctly without errors (and also check that the additional udp thread is correctly shutdown) then i will add this to upstream straight away. Of course if you have some specific test cases you want to post (i.e. exact command lines) then i will test them myself as well. |
|
I'm currently held up with some other stuff, so it'll be a while before I can follow up on this. I'm still using the FFmpeg build with your original patches and it works fine, but that's all I can provide for now. Sorry :( |
…ion parameter
If memory allocation fails, ERROR(ENOMEM) '-12' will be returned.
When resample() is done first, the negative size param would cause buffer-overflow and SEGV in swri_rematrix().
When swri_rematrix() is run first, resample() would not cause an error but Err num as a wrong parameter passing.
Err num should be returned immediately. And remove an unneeded term from an assert.
coredump info:
#0 0x499517 in posix_memalign (/home/r1/ffmpeg/ffmpeg_4.4.1+0x499517)
#1 0x6c1f0b4 in av_malloc /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:86:9
#2 0x6c208fe in av_mallocz /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:239:17
#3 0x6c207ad in av_mallocz_array /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:195:12
#4 0x654b2e5 in swri_realloc_audio /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:418:14
#5 0x654f9a1 in swr_convert_internal /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:601:17
#6 0x654d2c0 in swr_convert /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:766:19
#7 0x186cf56 in flush_frame /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/af_aresample.c:251:13
#8 0x186a454 in request_frame /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/af_aresample.c:288:20
#9 0x787d9c in ff_request_frame_to_filter /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:459:15
#10 0x7877f1 in forward_status_change /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1257:19
#11 0x77ed7e in ff_filter_activate_default /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1288:20
#12 0x77e4e1 in ff_filter_activate /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1441:11
#13 0x793b3f in ff_filter_graph_run_once /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfiltergraph.c:1403:12
#14 0x7a7bee in get_frame_internal /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/buffersink.c:131:19
#15 0x7a7287 in av_buffersink_get_frame_flags /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/buffersink.c:142:12
#16 0x792888 in avfilter_graph_request_oldest /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfiltergraph.c:1356:17
#17 0x5d07df in transcode_from_filter /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4639:11
#18 0x59e557 in transcode_step /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4729:20
#19 0x593970 in transcode /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4805:15
#20 0x58f7a4 in main /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:5010:9
#21 0x7f6fd2dee0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
SUMMARY: AddressSanitizer: negative-size-param (/home/r1/ffmpeg/ffmpeg_4.4.1+0x497e67) in __asan_memcpy
Reported-by: TOTE Robot <[email protected]>
Signed-off-by: Michael Niedermayer <[email protected]>
In addition to .eac3, .ec3 is also commonly used by people to name raw E-AC-3 streams. Enables automatic recognition of the eac3 format for the .ac3 extension. For instance Dolby Digital Plus software only support files with .ec3. Files with .eac3 are not supported. Check issue #18 in the public dlb_mp4base repository from DolbyLaboratories. Signed-off-by: Ruben Gonzalez <[email protected]> Signed-off-by: Anton Khirnov <[email protected]>
Using the default project configuration, udp (for example when streaming over rtp) complains that pthreads support is required for circular buffers. Can this be solved with any config option? Or do I have to include
pthread-win32as a dependency?The text was updated successfully, but these errors were encountered: