Re: [Opalvoip-devel] codectest issues
Brought to you by:
csoutheren,
rjongbloed
From: Alexander S. <ale...@gm...> - 2017-12-06 20:39:40
|
I spent some time trying to find cause of crash inside SDL. I look into code and see no problems with it. This crush itself happening inside SDL_UnlockTexture() function. During debug I seen nothing out of ordinary operation so must be somet Must be a problem of SDL or lower level DRI/X11 system currently on my setup. I suppose I should do additional testing on other types of linux. On 06.12.2017 14:47, Robert Jongbloed wrote: Hi Alexander, finally got around to looking these. Frankly, I have not used Linux camera stuff for many a year. My world revolves around Windows and Mac for clients, and Linux for servers. Anyway, I applied your patch for the v4l2 plug in. I have applied a variant of your encframe.cxx patch, just adding 16. I have had in the past that FFMPEG overruns buffers by up to this much as it uses special processor instructions that operate on that sized block at a time, so if things aren't aligned properly it overruns things. If still a problem I will add the 100. Finally, I am having trouble with the FFMPEG/x264 codec on my Mac, the helper app seems to be crashing. Not sure what is going on there. So, I fired up my Ubuntu in a VirtualBox to see what happens, and it works fine. The exact command you provided, adjust window size, all good. Maybe if you can run under gdb and get me a backtrace? ---------- Robert Jongbloed Vox Lucida Pty. Ltd. On 15 Nov 2017, at 4:59 pm, Alexander Sbitnev <ale...@gm...> wrote: Hi Robert! Is codectest sample become outdated? I've tried to play with version from trunk and got at least three nasty problems under Ubuntu stable. All of each produce segfault at different places. First one is V4L2 input related. At my custom setup with a rtsp camera (i just try to use camera from smartphone) I've found that v4l2 subsystem sometimes returns buffer with size bigger than expected by frame dimensions and buffer overrun happened (probably buggy v4l2loopback code). The cure for this situation is simple: diff --git a/plugins/vidinput_v4l2/vidinput_v4l2.cxx b/plugins/vidinput_v4l2/vidinput_v4l2.cxx index a742cf3..89a0b8d 100644 --- a/plugins/vidinput_v4l2/vidinput_v4l2.cxx +++ b/plugins/vidinput_v4l2/vidinput_v4l2.cxx @@ -975,7 +975,7 @@ PBoolean PVideoInputDevice_V4L2::GetFrameDataNoDelay(BYTE * buffer, PINDEX * byt m_converter->Convert(videoBuffer[buf.index], buffer, bytesReturned); } else { - memcpy(buffer, videoBuffer[buf.index], buf.bytesused); + memcpy(buffer, videoBuffer[buf.index], std::min((size_t)frameBytes, (size_t)buf.bytesused)); if (bytesReturned != NULL) *bytesReturned = buf.bytesused; } Just in case here is my camera setup: application setup on smartphone: "RTSP Camera Server" and retranslator inside Ubuntu: gst-launch-1.0 rtspsrc location=rtsp://192.168.42.129:5554/front ! rtph264depay ! h264parse ! avdec_h264 ! videorate ! videoscale ! videoconvert ! "video/x-raw, format=I420, width=1280, height=720, pixel-aspect-ratio=1/1, interlace-mode=progressive, framerate=25/1" ! v4l2sink device=/dev/video0 sync=false Second problem is also frame related but on another level. I still use valgrind for quick check. Here is detected problem: ==31704== Thread 16 Video:31736: ==31704== Invalid read of size 8 ==31704== at 0xECC3B06: ??? (in /usr/lib/x86_64-linux-gnu/libavcodec-ffmpeg.so.56.60.100) ==31704== by 0xECC5F4F: ??? (in /usr/lib/x86_64-linux-gnu/libavcodec-ffmpeg.so.56.60.100) ==31704== by 0xF04CB75: avcodec_decode_video2 (in /usr/lib/x86_64-linux-gnu/libavcodec-ffmpeg.so.56.60.100) ==31704== by 0xE4C57F0: FFMPEGCodec::DecodeVideoFrame(unsigned char const*, unsigned long, unsigned int&) (ffmpeg.cxx:596) ==31704== by 0xE4B37E3: H264_Decoder::DecodeVideoFrame(unsigned char const*, unsigned long, unsigned int&) (h264-x264.cxx:925) ==31704== by 0xE4C555E: FFMPEGCodec::DecodeVideoPacket(PluginCodec_RTP const&, unsigned int&) (ffmpeg.cxx:574) ==31704== by 0xE4B3559: H264_Decoder::Transcode(void const*, unsigned int&, void*, unsigned int&, unsigned int&) (h264-x264.cxx:902) ==31704== by 0xE4B5331: PluginCodec<x264>::Transcode_s(PluginCodec_Definition const*, void*, void const*, unsigned int*, void*, unsigned int*, unsigned int*) (opalplugin.hpp:884) ==31704== by 0x5D43C22: OpalPluginTranscoder::Transcode(void const*, unsigned int*, void*, unsigned int*, unsigned int*) const (opalpluginmgr.h:223) ==31704== by 0x5D387BE: OpalPluginVideoTranscoder::DecodeFrame(RTP_DataFrame const&, PList<RTP_DataFrame>&) (opalpluginmgr.cxx:1125) ==31704== by 0x5D385CC: OpalPluginVideoTranscoder::DecodeFrames(RTP_DataFrame const&, PList<RTP_DataFrame>&) (opalpluginmgr.cxx:1106) ==31704== by 0x5D37671: OpalPluginVideoTranscoder::ConvertFrames(RTP_DataFrame const&, PList<RTP_DataFrame>&) (opalpluginmgr.cxx:921) ==31704== Address 0x16c4e06f is 10,207 bytes inside a block of size 10,209 alloc'd ==31704== at 0x4C2FD5F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31704== by 0xE4C0E1F: OpalPluginFrame::SetSize(unsigned long) (encframe.cxx:60) ==31704== by 0xE4C1010: OpalPluginFrame::Append(unsigned char const*, unsigned long) (encframe.cxx:73) ==31704== by 0xE4BFB4E: H264Frame::AddDataToEncodedFrame(unsigned char const*, unsigned long, unsigned char, bool) (h264frame.cxx:466) ==31704== by 0xE4BDD65: H264Frame::AddPacket(PluginCodec_RTP const&, unsigned int&) (h264frame.cxx:286) ==31704== by 0xE4C544E: FFMPEGCodec::DecodeVideoPacket(PluginCodec_RTP const&, unsigned int&) (ffmpeg.cxx:562) ==31704== by 0xE4B3559: H264_Decoder::Transcode(void const*, unsigned int&, void*, unsigned int&, unsigned int&) (h264-x264.cxx:902) ==31704== by 0xE4B5331: PluginCodec<x264>::Transcode_s(PluginCodec_Definition const*, void*, void const*, unsigned int*, void*, unsigned int*, unsigned int*) (opalplugin.hpp:884) ==31704== by 0x5D43C22: OpalPluginTranscoder::Transcode(void const*, unsigned int*, void*, unsigned int*, unsigned int*) const (opalpluginmgr.h:223) ==31704== by 0x5D387BE: OpalPluginVideoTranscoder::DecodeFrame(RTP_DataFrame const&, PList<RTP_DataFrame>&) (opalpluginmgr.cxx:1125) ==31704== by 0x5D385CC: OpalPluginVideoTranscoder::DecodeFrames(RTP_DataFrame const&, PList<RTP_DataFrame>&) (opalpluginmgr.cxx:1106) ==31704== by 0x5D37671: OpalPluginVideoTranscoder::ConvertFrames(RTP_DataFrame const&, PList<RTP_DataFrame>&) (opalpluginmgr.cxx:921) Somehow avcodec expect a bigger frame than it has actually. I've just increase buffer and it really helps. Not a real solution, just info: diff --git a/plugins/video/common/encframe.cxx b/plugins/video/common/encframe.cxx index fb4ccae..245529a 100644 --- a/plugins/video/common/encframe.cxx +++ b/plugins/video/common/encframe.cxx @@ -57,7 +57,7 @@ void OpalPluginFrame::SetMaxPayloadSize(size_t size) bool OpalPluginFrame::SetSize(size_t newSize) { - if ((m_buffer = (uint8_t *)realloc(m_buffer, newSize)) == NULL) { + if ((m_buffer = (uint8_t *)realloc(m_buffer, newSize + 100)) == NULL) { PTRACE(1, "FFMPEG", "Could not (re)allocate " << newSize << " bytes of memory."); return false; } It close second segfault issue. But still there is third one. Inside SDL output. Here is gdb output: Core was generated by `obj_linux_x86_64_d/codectest -G Dummy video device (0x0000) -s HD720 H.264-0 -b'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f8f69e311a1 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so [Current thread is 1 (Thread 0x7f8f811b8700 (LWP 3335))] (gdb) bt #0 0x00007f8f69e311a1 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #1 0x00007f8f69e330b4 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #2 0x00007f8f69e33ab3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #3 0x00007f8f69e26004 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #4 0x00007f8f69e260ed in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #5 0x00007f8f69e490ed in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #6 0x00007f8f69b0d21d in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #7 0x00007f8f698eb9ed in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #8 0x00007f8f698721bb in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #9 0x00007f8f69872426 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #10 0x00007f8f69872828 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #11 0x00007f8f7e1bbc54 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 #12 0x00007f8f7e1b5043 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 #13 0x00007f8f7f6383c0 in PVideoOutputDevice_SDL::SetFrameData (this=0x2c5c860, x=0, y=0, width=1280, height=720, data=0x7f8f54760f2c "mnnljhijjjklnnmnmmnmmlklkkjmqru{\203\210\213\215\211\210\ 210\211\213\214\213\216\224\227\226\226\225\225\223\225\ 226\215\177pc_^bgihm\201\215\221\221\220\216\216\216\216\ 215\215\215\215\214\214\214\213\213\213\213\213\213\213\ 213\212\212\212\212\212\211\211\211\211\211\211\211\211\ 210\210\210\210\210\210\210\210", '\207' <repeats 11 times>, "\206\206\206\206\206\206\206\206\205\205\205\205\205\205\ 205\205\204\204\204\204\205\204\204\204\205\204\204\204\ 204\204\204\204\203\203\203\203\203\203\203\203", '\202' <repeats 16 times>, "\201\201\201\201\201\201\201\201", '\200' <repeats 12 times>, "\177\177\200\200"..., endFrame=true) at /home/shuras/OpalTrunk/ptlib/src/ptclib/vsdl.cxx:433 #14 0x000000000041d98e in VideoThread::Write (this=0x7ffd80158798, data=...) at main.cxx:1294 #15 0x000000000041c62a in TranscoderThread::Main (this=0x7ffd80158798) at main.cxx:1099 #16 0x000000000041b003 in VideoThread::Main (this=0x7ffd80158798) at main.cxx:766 #17 0x00007f8f7f85dff5 in PThread::InternalThreadMain (this=0x7ffd80158798) at /home/shuras/OpalTrunk/ptlib/src/ptlib/common/osutils.cxx:2974 #18 0x00007f8f7f83569b in PThread::PX_ThreadMain (arg=0x7ffd80158798) at /home/shuras/OpalTrunk/ptlib/src/ptlib/unix/tlibthrd.cxx:345 #19 0x00007f8f7b7c86ba in start_thread (arg=0x7f8f811b8700) at pthread_create.c:333 #20 0x00007f8f7e77e3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 This error happens without interactions from my side with my RTSP v4l2loopback device after some frames processed. Some times in 1 second some time after 10 sec. But I've also found it can be easily reproduced with opal fake camera in play. Try command from below and then it starts try to resize window aggressively. After some time you get same segfault. obj_linux_x86_64_d/codectest -G "Fake/OriginalMovingBlocks" -s HD720 H.264-0 -b 1024000 -r 30 -tttt ------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Opalvoip-devel mailing list Opa...@li... https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |