opalvoip-devel Mailing List for OpalVOIP (Page 2)
Brought to you by:
csoutheren,
rjongbloed
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(57) |
Nov
(163) |
Dec
(101) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(72) |
Feb
(81) |
Mar
(61) |
Apr
(35) |
May
(40) |
Jun
(49) |
Jul
(27) |
Aug
(15) |
Sep
(71) |
Oct
(41) |
Nov
(37) |
Dec
(22) |
2009 |
Jan
(9) |
Feb
(16) |
Mar
(26) |
Apr
(39) |
May
(70) |
Jun
(26) |
Jul
(27) |
Aug
(30) |
Sep
(25) |
Oct
(62) |
Nov
(43) |
Dec
(13) |
2010 |
Jan
(53) |
Feb
(45) |
Mar
(32) |
Apr
(39) |
May
(24) |
Jun
(58) |
Jul
(5) |
Aug
(14) |
Sep
(10) |
Oct
(10) |
Nov
(16) |
Dec
(4) |
2011 |
Jan
(32) |
Feb
(30) |
Mar
(29) |
Apr
(24) |
May
(70) |
Jun
(26) |
Jul
(27) |
Aug
(23) |
Sep
(44) |
Oct
(18) |
Nov
(28) |
Dec
(45) |
2012 |
Jan
(26) |
Feb
(24) |
Mar
(88) |
Apr
(56) |
May
(84) |
Jun
(64) |
Jul
(14) |
Aug
(46) |
Sep
(70) |
Oct
(13) |
Nov
(40) |
Dec
(5) |
2013 |
Jan
(42) |
Feb
(43) |
Mar
(83) |
Apr
(27) |
May
(57) |
Jun
(39) |
Jul
(29) |
Aug
(21) |
Sep
(31) |
Oct
(31) |
Nov
(3) |
Dec
(22) |
2014 |
Jan
(20) |
Feb
(10) |
Mar
(31) |
Apr
(37) |
May
(24) |
Jun
(15) |
Jul
(11) |
Aug
(5) |
Sep
(2) |
Oct
(4) |
Nov
(4) |
Dec
(11) |
2015 |
Jan
(6) |
Feb
(3) |
Mar
(7) |
Apr
(3) |
May
|
Jun
|
Jul
(9) |
Aug
(8) |
Sep
(12) |
Oct
(3) |
Nov
(4) |
Dec
(6) |
2016 |
Jan
(3) |
Feb
(7) |
Mar
(3) |
Apr
(9) |
May
(4) |
Jun
(2) |
Jul
(3) |
Aug
(17) |
Sep
|
Oct
(11) |
Nov
(10) |
Dec
(7) |
2017 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(4) |
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(1) |
Feb
(7) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Robert J. <ro...@vo...> - 2019-08-08 19:20:10
|
Alan you only ever create on PProcess. The hint is in the name ... You only have one OpalManager too. And one OpalEndPoint for each protocol. Each of those can handle as many calls as you have memory and CPU for via OpalCall and OpalConnection objects. --------- Robert Jongbloed Vox Lucida Pty. Ltd. ------ Original Message ------ From: "Alan Jin" <ala...@gm... <mailto:ala...@gm...> > To: "opa...@li..." <opa...@li... <mailto:opa...@li...> > Sent: 8/08/2019 7:38:21 PM Subject: [Opalvoip-devel] Is it possible to create multiple H323 end points in one task? Hi, I'm trying to create a H323 proxy to translate signals between H323 and WebRTC, it seems working for one to one call, WebRTC peer connection can be established with H323 terminals now. but when I tried to let my H323 proxy to connect to multiple H323 terminals, exception "Assertion fail: Only one instance of PProcess allowed" was thrown. seems only one process, one manager and one endpoint allowed in the machine. I'm wondering what is the best approach to implement some proxy or servers by using Opal in similar scenarios? Should I try to let PProcess having multiple managers, or one manager having multiple endpoints, or one endpoint having multiple calls? Regards, Alan Virus-free. www.avast.com _______________________________________________ Opalvoip-devel mailing list Opa...@li... <mailto:Opa...@li...> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |
From: Alan J. <ala...@gm...> - 2019-08-08 18:38:41
|
Hi, I'm trying to create a H323 proxy to translate signals between H323 and WebRTC, it seems working for one to one call, WebRTC peer connection can be established with H323 terminals now. but when I tried to let my H323 proxy to connect to multiple H323 terminals, exception "Assertion fail: Only one instance of PProcess allowed" was thrown. seems only one process, one manager and one endpoint allowed in the machine. I'm wondering what is the best approach to implement some proxy or servers by using Opal in similar scenarios? Should I try to let PProcess having multiple managers, or one manager having multiple endpoints, or one endpoint having multiple calls? Regards, Alan <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> |
From: Jan W. <ja...@wi...> - 2019-05-29 15:47:54
|
Hi, for GnuGk I needed SNMP SET to work in PSNMPServer (wasn't sending a response), so I fixed it in our PTLib 2.10 fork. Since the SNMP code hasn't changed in over 10 years, the patch also applies to the current PTLib, see attached. Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : ja...@wi... Website: https://www.gnugk.org Support: https://www.willamowius.com/gnugk-support.html Relaxed Communications GmbH Frahmredder 91, 22393 Hamburg, Germany Geschäftsführer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584 |
From: Shi Q. <qiu...@gm...> - 2018-10-16 08:33:12
|
I see it's ok in the windows registry(video->VideoGrabDevice), but after I open openphone, it just displays another video device, maybe the video list is wrong. |
From: Shi Q. <qiu...@gm...> - 2018-10-16 08:27:10
|
On the options-> video tab, when I select application: desktop/media file/fake to preview, it says failed to open video When I select directshow webcam, it just crashed. platform: win 7 x64 stack trace: ucrtbased.dll!_chvalidator(int c, int mask) Line 36 C++ ucrtbased.dll!fast_check(const int c, const int mask) Line 24 C++ ucrtbased.dll!isspace(int c) Line 107 C++ OpenPhone.exe!operator<<(std::basic_ostream<char,std::char_traits<char> > & strm, const PComResult & result) Line 883 C++ OpenPhone.exe!PVideoInputDevice_DirectShow::PlatformOpen() Line 1243 C++ OpenPhone.exe!PVideoInputDevice_DirectShow::Open(const PString & devName, bool startImmediate) Line 559 C++ OpenPhone.exe!PVideoDevice::OpenFull(const PVideoDevice::OpenArgs & args, bool startImmediate) Line 565 C++ > OpenPhone.exe!PVideoInputDevice::CreateOpenedDevice(const PVideoDevice::OpenArgs & args, bool startImmediate) Line 1360 C++ OpenPhone.exe!OptionsDialog::TestVideoThreadMain() Line 5966 C++ OpenPhone.exe!PThreadObj<OptionsDialog>::Main() Line 822 C++ OpenPhone.exe!PThread::InternalThreadMain() Line 3135 C++ OpenPhone.exe!PThread::MainFunction(void * threadPtr) Line 773 C++ ucrtbased.dll!invoke_thread_procedure(unsigned int(*)(void *) procedure, void * const context) Line 92 C++ ucrtbased.dll!thread_start<unsigned int (__cdecl*)(void * __ptr64)>(void * const parameter) Line 115 C++ kernel32.dll!BaseThreadInitThunk() Unknown ntdll.dll!RtlUserThreadStart() Unknown |
From: Alexander S. <ale...@gm...> - 2018-09-26 07:50:26
|
Thanks Robert I've seen it and tried on slightly older source tree (current beta). It's works fine with mentioned buggy software (and zero SN is only one of its bugs, continuous requests of key frames and halting of video stream until key frame arrive raise a lot of other questions) of old Polycom RMX. On 19.09.2018 19:51, Robert Jongbloed wrote: > Another check in made to always accept SN=0 > > ----- > Robert Jongbloed > Vox Lucida Pty. Ltd. > > > >> On 12 Sep 2018, at 11:38, Alexander Sbitnev >> <ale...@gm... <mailto:ale...@gm...>> wrote: >> >> I've checked latest trunk version and found fix only works for first FIR. >> Something should be done inside rtp_session.cxx:2344: >> >> if (ssrc->m_lastFIRSequenceNumber != sequenceNumber) { >> ssrc->m_lastFIRSequenceNumber = sequenceNumber; >> m_connection.ExecuteMediaCommand(OpalVideoUpdatePicture(m_sessionId, >> targetSSRC), true); >> } >> >> Since all FIR sequence numbers from this Polycom are zero (which is >> probably a bug of specific Polycom server, as rfc5104 states "The >> sequence number SHALL be increased by 1 modulo 256 for each new >> command.") only first FIR (if you lucky and m_lastFIRSequenceNumber >> wasn't initially at zero too) is working fine and all next are ignored. >> >> Also with current build there is a constant flooding of those messages: >> >> 0:03.607 RTP-1-media:16766 jitter.cxx(499) >> Jitter Wait frame time : ts=0, delta=0 (0ms), sn=356 >> 0:03.607 RTP-1-media:16766 jitter.cxx(564) >> Jitter Attempt to insert two RTP packets with same timestamp: 0 >> >> >> On 06.09.2018 14:48, Robert Jongbloed wrote: >>> I have checked in a possible fix for this. It isn’t the SSRC==0 that >>> was the problem, but the seq no == 0. >>> >>> ----- >>> Robert Jongbloed >>> Vox Lucida Pty. Ltd. >>> >>> >>> >>>> On 5 Sep 2018, at 16:46, Alexander Sbitnev >>>> <ale...@gm... <mailto:ale...@gm...>> >>>> wrote: >>>> >>>> I found a problem with opal running SIP connection to Polycom >>>> videoconference server. H264 format was used for video. >>>> >>>> It turns out that even under normal network Polycom RMX sometimes >>>> issue FIR request and it is ignored on the opal side as no I-Frame >>>> is being forced into stream. >>>> >>>> Something like that popup in the log: >>>> >>>> 0:09.316 RTP-2-control:15856 rtp_session.cxx(1554) RTP >>>> Session 2, FIR from incorrect SSRC=0 (0x0) >>>> 0:09.316 RTP-2-control:15856 rtp_session.cxx(1730) RTP >>>> Session 2, received RFC5104 FIR: sn=0, last-sn=0, receiver >>>> SSRC=2279148435 (0x87d90b93), sender SSRC=0 (0x0) >>>> >>>> Yes there is warning about zero SSRC and that is how frame looks in >>>> wireshark: >>>> >>>> Frame 1461: 62 bytes on wire (496 bits), 62 bytes captured (496 >>>> bits) on interface 0 >>>> Ethernet II, Src: AccordVi_05:6d:79 (00:90:ca:05:6d:79), Dst: >>>> AsustekC_5c:53:7d (bc:ee:7b:5c:53:7d) >>>> Internet Protocol Version 4, Src: 10.0.55.191, Dst: 10.0.55.197 >>>> User Datagram Protocol, Src Port: 49225, Dst Port: 5669 >>>> Real-time Transport Control Protocol (Payload-specific Feedback) >>>> [Stream setup by SDP (frame 6)] >>>> 10.. .... = Version: RFC 1889 Version (2) >>>> ..0. .... = Padding: False >>>> ...0 0100 = RTCP Feedback message type (FMT): Full Intra >>>> Request (FIR) Command (4) >>>> Packet type: Payload-specific Feedback (206) >>>> Length: 4 (20 bytes) >>>> Sender SSRC: 0x00000000 (0) >>>> Media source SSRC: 0x8ebd4308 (2394768136) >>>> FIR 1 >>>> SSRC: 0x87d90b93 (2279148435) >>>> Command Sequence Number: 0 >>>> Reserved: 1 >>>> [RTCP frame length check: OK - 20 bytes] >>>> >>>> Polycom RMX in it's turn halt video stream to opal until I-Frame is >>>> finally arrive. >>>> >>>> As I remember FUR requests for same purpose works fine and force >>>> I-Frames into the stream. Is there support for FIR proccessing in opal? >>>> >>>> Can be SSRC field of request be the cause of this request ignorance? >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org <http://slashdot.org/>! >>>> http://sdm.link/slashdot >>>> _______________________________________________ >>>> Opalvoip-devel mailing list >>>> Opa...@li... >>>> <mailto:Opa...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel >>> >> > |
From: Robert J. <ro...@vo...> - 2018-09-19 17:09:39
|
Another check in made to always accept SN=0 ----- Robert Jongbloed Vox Lucida Pty. Ltd. On 12 Sep 2018, at 11:38, Alexander Sbitnev <ale...@gm... <mailto:ale...@gm...> > wrote: I've checked latest trunk version and found fix only works for first FIR. Something should be done inside rtp_session.cxx:2344: if (ssrc->m_lastFIRSequenceNumber != sequenceNumber) { ssrc->m_lastFIRSequenceNumber = sequenceNumber; m_connection.ExecuteMediaCommand(OpalVideoUpdatePicture(m_sessionId, targetSSRC), true); } Since all FIR sequence numbers from this Polycom are zero (which is probably a bug of specific Polycom server, as rfc5104 states "The sequence number SHALL be increased by 1 modulo 256 for each new command.") only first FIR (if you lucky and m_lastFIRSequenceNumber wasn't initially at zero too) is working fine and all next are ignored. Also with current build there is a constant flooding of those messages: 0:03.607 RTP-1-media:16766 jitter.cxx(499) Jitter Wait frame time : ts=0, delta=0 (0ms), sn=356 0:03.607 RTP-1-media:16766 jitter.cxx(564) Jitter Attempt to insert two RTP packets with same timestamp: 0 On 06.09.2018 14:48, Robert Jongbloed wrote: I have checked in a possible fix for this. It isn’t the SSRC==0 that was the problem, but the seq no == 0. ----- Robert Jongbloed Vox Lucida Pty. Ltd. On 5 Sep 2018, at 16:46, Alexander Sbitnev <ale...@gm... <mailto:ale...@gm...> > wrote: I found a problem with opal running SIP connection to Polycom videoconference server. H264 format was used for video. It turns out that even under normal network Polycom RMX sometimes issue FIR request and it is ignored on the opal side as no I-Frame is being forced into stream. Something like that popup in the log: 0:09.316 RTP-2-control:15856 rtp_session.cxx(1554) RTP Session 2, FIR from incorrect SSRC=0 (0x0) 0:09.316 RTP-2-control:15856 rtp_session.cxx(1730) RTP Session 2, received RFC5104 FIR: sn=0, last-sn=0, receiver SSRC=2279148435 (0x87d90b93), sender SSRC=0 (0x0) Yes there is warning about zero SSRC and that is how frame looks in wireshark: Frame 1461: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0 Ethernet II, Src: AccordVi_05:6d:79 (00:90:ca:05:6d:79), Dst: AsustekC_5c:53:7d (bc:ee:7b:5c:53:7d) Internet Protocol Version 4, Src: 10.0.55.191, Dst: 10.0.55.197 User Datagram Protocol, Src Port: 49225, Dst Port: 5669 Real-time Transport Control Protocol (Payload-specific Feedback) [Stream setup by SDP (frame 6)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0100 = RTCP Feedback message type (FMT): Full Intra Request (FIR) Command (4) Packet type: Payload-specific Feedback (206) Length: 4 (20 bytes) Sender SSRC: 0x00000000 (0) Media source SSRC: 0x8ebd4308 (2394768136) FIR 1 SSRC: 0x87d90b93 (2279148435) Command Sequence Number: 0 Reserved: 1 [RTCP frame length check: OK - 20 bytes] Polycom RMX in it's turn halt video stream to opal until I-Frame is finally arrive. As I remember FUR requests for same purpose works fine and force I-Frames into the stream. Is there support for FIR proccessing in opal? Can be SSRC field of request be the cause of this request ignorance? ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org <http://slashdot.org/> ! http://sdm.link/slashdot <http://sdm.link/slashdot> _______________________________________________ Opalvoip-devel mailing list Opa...@li... <mailto:Opa...@li...> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |
From: Alexander S. <ale...@gm...> - 2018-09-12 10:38:51
|
I've checked latest trunk version and found fix only works for first FIR. Something should be done inside rtp_session.cxx:2344: if (ssrc->m_lastFIRSequenceNumber != sequenceNumber) { ssrc->m_lastFIRSequenceNumber = sequenceNumber; m_connection.ExecuteMediaCommand(OpalVideoUpdatePicture(m_sessionId, targetSSRC), true); } Since all FIR sequence numbers from this Polycom are zero (which is probably a bug of specific Polycom server, as rfc5104 states "The sequence number SHALL be increased by 1 modulo 256 for each new command.") only first FIR (if you lucky and m_lastFIRSequenceNumber wasn't initially at zero too) is working fine and all next are ignored. Also with current build there is a constant flooding of those messages: 0:03.607 RTP-1-media:16766 jitter.cxx(499) Jitter Wait frame time : ts=0, delta=0 (0ms), sn=356 0:03.607 RTP-1-media:16766 jitter.cxx(564) Jitter Attempt to insert two RTP packets with same timestamp: 0 On 06.09.2018 14:48, Robert Jongbloed wrote: > I have checked in a possible fix for this. It isn’t the SSRC==0 that > was the problem, but the seq no == 0. > > ----- > Robert Jongbloed > Vox Lucida Pty. Ltd. > > > >> On 5 Sep 2018, at 16:46, Alexander Sbitnev >> <ale...@gm... <mailto:ale...@gm...>> wrote: >> >> I found a problem with opal running SIP connection to Polycom >> videoconference server. H264 format was used for video. >> >> It turns out that even under normal network Polycom RMX sometimes >> issue FIR request and it is ignored on the opal side as no I-Frame is >> being forced into stream. >> >> Something like that popup in the log: >> >> 0:09.316 RTP-2-control:15856 rtp_session.cxx(1554) >> RTP Session 2, FIR from incorrect SSRC=0 (0x0) >> 0:09.316 RTP-2-control:15856 rtp_session.cxx(1730) >> RTP Session 2, received RFC5104 FIR: sn=0, last-sn=0, >> receiver SSRC=2279148435 (0x87d90b93), sender SSRC=0 (0x0) >> >> Yes there is warning about zero SSRC and that is how frame looks in >> wireshark: >> >> Frame 1461: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) >> on interface 0 >> Ethernet II, Src: AccordVi_05:6d:79 (00:90:ca:05:6d:79), Dst: >> AsustekC_5c:53:7d (bc:ee:7b:5c:53:7d) >> Internet Protocol Version 4, Src: 10.0.55.191, Dst: 10.0.55.197 >> User Datagram Protocol, Src Port: 49225, Dst Port: 5669 >> Real-time Transport Control Protocol (Payload-specific Feedback) >> [Stream setup by SDP (frame 6)] >> 10.. .... = Version: RFC 1889 Version (2) >> ..0. .... = Padding: False >> ...0 0100 = RTCP Feedback message type (FMT): Full Intra Request >> (FIR) Command (4) >> Packet type: Payload-specific Feedback (206) >> Length: 4 (20 bytes) >> Sender SSRC: 0x00000000 (0) >> Media source SSRC: 0x8ebd4308 (2394768136) >> FIR 1 >> SSRC: 0x87d90b93 (2279148435) >> Command Sequence Number: 0 >> Reserved: 1 >> [RTCP frame length check: OK - 20 bytes] >> >> Polycom RMX in it's turn halt video stream to opal until I-Frame is >> finally arrive. >> >> As I remember FUR requests for same purpose works fine and force >> I-Frames into the stream. Is there support for FIR proccessing in opal? >> >> Can be SSRC field of request be the cause of this request ignorance? >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org <http://Slashdot.org>! >> http://sdm.link/slashdot >> _______________________________________________ >> Opalvoip-devel mailing list >> Opa...@li... >> <mailto:Opa...@li...> >> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel > |
From: Robert J. <ro...@vo...> - 2018-09-06 11:48:28
|
I have checked in a possible fix for this. It isn’t the SSRC==0 that was the problem, but the seq no == 0. ----- Robert Jongbloed Vox Lucida Pty. Ltd. On 5 Sep 2018, at 16:46, Alexander Sbitnev <ale...@gm... <mailto:ale...@gm...> > wrote: I found a problem with opal running SIP connection to Polycom videoconference server. H264 format was used for video. It turns out that even under normal network Polycom RMX sometimes issue FIR request and it is ignored on the opal side as no I-Frame is being forced into stream. Something like that popup in the log: 0:09.316 RTP-2-control:15856 rtp_session.cxx(1554) RTP Session 2, FIR from incorrect SSRC=0 (0x0) 0:09.316 RTP-2-control:15856 rtp_session.cxx(1730) RTP Session 2, received RFC5104 FIR: sn=0, last-sn=0, receiver SSRC=2279148435 (0x87d90b93), sender SSRC=0 (0x0) Yes there is warning about zero SSRC and that is how frame looks in wireshark: Frame 1461: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0 Ethernet II, Src: AccordVi_05:6d:79 (00:90:ca:05:6d:79), Dst: AsustekC_5c:53:7d (bc:ee:7b:5c:53:7d) Internet Protocol Version 4, Src: 10.0.55.191, Dst: 10.0.55.197 User Datagram Protocol, Src Port: 49225, Dst Port: 5669 Real-time Transport Control Protocol (Payload-specific Feedback) [Stream setup by SDP (frame 6)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0100 = RTCP Feedback message type (FMT): Full Intra Request (FIR) Command (4) Packet type: Payload-specific Feedback (206) Length: 4 (20 bytes) Sender SSRC: 0x00000000 (0) Media source SSRC: 0x8ebd4308 (2394768136) FIR 1 SSRC: 0x87d90b93 (2279148435) Command Sequence Number: 0 Reserved: 1 [RTCP frame length check: OK - 20 bytes] Polycom RMX in it's turn halt video stream to opal until I-Frame is finally arrive. As I remember FUR requests for same purpose works fine and force I-Frames into the stream. Is there support for FIR proccessing in opal? Can be SSRC field of request be the cause of this request ignorance? ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org <http://Slashdot.org> ! http://sdm.link/slashdot <http://sdm.link/slashdot> _______________________________________________ Opalvoip-devel mailing list Opa...@li... <mailto:Opa...@li...> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |
From: Robert J. <ro...@vo...> - 2018-09-05 17:41:08
|
Yes, FIR and PLI are supported, and it probably doesn’t;t work due to the invalid SSRC If I have time, I will see if anything can be done. ----- Robert Jongbloed Vox Lucida Pty. Ltd. On 5 Sep 2018, at 16:46, Alexander Sbitnev <ale...@gm... <mailto:ale...@gm...> > wrote: I found a problem with opal running SIP connection to Polycom videoconference server. H264 format was used for video. It turns out that even under normal network Polycom RMX sometimes issue FIR request and it is ignored on the opal side as no I-Frame is being forced into stream. Something like that popup in the log: 0:09.316 RTP-2-control:15856 rtp_session.cxx(1554) RTP Session 2, FIR from incorrect SSRC=0 (0x0) 0:09.316 RTP-2-control:15856 rtp_session.cxx(1730) RTP Session 2, received RFC5104 FIR: sn=0, last-sn=0, receiver SSRC=2279148435 (0x87d90b93), sender SSRC=0 (0x0) Yes there is warning about zero SSRC and that is how frame looks in wireshark: Frame 1461: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0 Ethernet II, Src: AccordVi_05:6d:79 (00:90:ca:05:6d:79), Dst: AsustekC_5c:53:7d (bc:ee:7b:5c:53:7d) Internet Protocol Version 4, Src: 10.0.55.191, Dst: 10.0.55.197 User Datagram Protocol, Src Port: 49225, Dst Port: 5669 Real-time Transport Control Protocol (Payload-specific Feedback) [Stream setup by SDP (frame 6)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0100 = RTCP Feedback message type (FMT): Full Intra Request (FIR) Command (4) Packet type: Payload-specific Feedback (206) Length: 4 (20 bytes) Sender SSRC: 0x00000000 (0) Media source SSRC: 0x8ebd4308 (2394768136) FIR 1 SSRC: 0x87d90b93 (2279148435) Command Sequence Number: 0 Reserved: 1 [RTCP frame length check: OK - 20 bytes] Polycom RMX in it's turn halt video stream to opal until I-Frame is finally arrive. As I remember FUR requests for same purpose works fine and force I-Frames into the stream. Is there support for FIR proccessing in opal? Can be SSRC field of request be the cause of this request ignorance? ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org <http://Slashdot.org> ! http://sdm.link/slashdot <http://sdm.link/slashdot> _______________________________________________ Opalvoip-devel mailing list Opa...@li... <mailto:Opa...@li...> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |
From: Alexander S. <ale...@gm...> - 2018-09-05 15:46:27
|
I found a problem with opal running SIP connection to Polycom videoconference server. H264 format was used for video. It turns out that even under normal network Polycom RMX sometimes issue FIR request and it is ignored on the opal side as no I-Frame is being forced into stream. Something like that popup in the log: 0:09.316 RTP-2-control:15856 rtp_session.cxx(1554) RTP Session 2, FIR from incorrect SSRC=0 (0x0) 0:09.316 RTP-2-control:15856 rtp_session.cxx(1730) RTP Session 2, received RFC5104 FIR: sn=0, last-sn=0, receiver SSRC=2279148435 (0x87d90b93), sender SSRC=0 (0x0) Yes there is warning about zero SSRC and that is how frame looks in wireshark: Frame 1461: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0 Ethernet II, Src: AccordVi_05:6d:79 (00:90:ca:05:6d:79), Dst: AsustekC_5c:53:7d (bc:ee:7b:5c:53:7d) Internet Protocol Version 4, Src: 10.0.55.191, Dst: 10.0.55.197 User Datagram Protocol, Src Port: 49225, Dst Port: 5669 Real-time Transport Control Protocol (Payload-specific Feedback) [Stream setup by SDP (frame 6)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0100 = RTCP Feedback message type (FMT): Full Intra Request (FIR) Command (4) Packet type: Payload-specific Feedback (206) Length: 4 (20 bytes) Sender SSRC: 0x00000000 (0) Media source SSRC: 0x8ebd4308 (2394768136) FIR 1 SSRC: 0x87d90b93 (2279148435) Command Sequence Number: 0 Reserved: 1 [RTCP frame length check: OK - 20 bytes] Polycom RMX in it's turn halt video stream to opal until I-Frame is finally arrive. As I remember FUR requests for same purpose works fine and force I-Frames into the stream. Is there support for FIR proccessing in opal? Can be SSRC field of request be the cause of this request ignorance? |
From: Robert J. <ro...@vo...> - 2018-08-30 13:11:47
|
Should now be fixed. ----- Robert Jongbloed Vox Lucida Pty. Ltd. On 29 Aug 2018, at 12:02, Alexander Sbitnev <ale...@gm... <mailto:ale...@gm...> > wrote: /home/shuras/OpalTrunk/ptlib/src/ptlib/common/contain.cxx: In member function ‘virtual void PHexDump::PrintOn(std::ostream&) const’: /home/shuras/OpalTrunk/ptlib/src/ptlib/common/contain.cxx:582:22: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] In file included from /usr/include/c++/5/iomanip:40:0, from /home/shuras/OpalTrunk/ptlib/include/ptlib/object.h:54, from /home/shuras/OpalTrunk/ptlib/include/ptlib.h:44, from /home/shuras/OpalTrunk/ptlib/src/ptlib/common/contain.cxx:30: /usr/include/c++/5/bits/ios_base.h:630:5: note: initializing argument 1 of ‘std::ios_base::fmtflags std::ios_base::flags(std::ios_base::fmtflags)’ At global scope: cc1plus: warning: unrecognized command line option ‘-Wno-potentially-evaluated-expression’ cc1plus: warning: unrecognized command line option ‘-Wno-unused-private-field’ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org <http://Slashdot.org> ! http://sdm.link/slashdot <http://sdm.link/slashdot> _______________________________________________ Opalvoip-devel mailing list Opa...@li... <mailto:Opa...@li...> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |
From: Alexander S. <ale...@gm...> - 2018-08-30 12:59:48
|
Same fix works for me yesterday. Thanks Robert. On 08/30/2018 03:51 PM, Robert Jongbloed wrote: > Should now be fixed. > > ----- > Robert Jongbloed > Vox Lucida Pty. Ltd. > > > >> On 29 Aug 2018, at 12:02, Alexander Sbitnev >> <ale...@gm... <mailto:ale...@gm...>> wrote: >> >> /home/shuras/OpalTrunk/ptlib/src/ptlib/common/contain.cxx: In member >> function ‘virtual void PHexDump::PrintOn(std::ostream&) const’: >> /home/shuras/OpalTrunk/ptlib/src/ptlib/common/contain.cxx:582:22: >> error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka >> std::_Ios_Fmtflags}’ [-fpermissive] >> In file included from /usr/include/c++/5/iomanip:40:0, >> from >> /home/shuras/OpalTrunk/ptlib/include/ptlib/object.h:54, >> from /home/shuras/OpalTrunk/ptlib/include/ptlib.h:44, >> from >> /home/shuras/OpalTrunk/ptlib/src/ptlib/common/contain.cxx:30: >> /usr/include/c++/5/bits/ios_base.h:630:5: note: initializing argument >> 1 of ‘std::ios_base::fmtflags >> std::ios_base::flags(std::ios_base::fmtflags)’ >> At global scope: >> cc1plus: warning: unrecognized command line option >> ‘-Wno-potentially-evaluated-expression’ >> cc1plus: warning: unrecognized command line option >> ‘-Wno-unused-private-field’ >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org <http://Slashdot.org>! >> http://sdm.link/slashdot >> _______________________________________________ >> Opalvoip-devel mailing list >> Opa...@li... >> <mailto:Opa...@li...> >> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel > |
From: Alexander S. <ale...@gm...> - 2018-08-29 11:03:09
|
/home/shuras/OpalTrunk/ptlib/src/ptlib/common/contain.cxx: In member function ‘virtual void PHexDump::PrintOn(std::ostream&) const’: /home/shuras/OpalTrunk/ptlib/src/ptlib/common/contain.cxx:582:22: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] In file included from /usr/include/c++/5/iomanip:40:0, from /home/shuras/OpalTrunk/ptlib/include/ptlib/object.h:54, from /home/shuras/OpalTrunk/ptlib/include/ptlib.h:44, from /home/shuras/OpalTrunk/ptlib/src/ptlib/common/contain.cxx:30: /usr/include/c++/5/bits/ios_base.h:630:5: note: initializing argument 1 of ‘std::ios_base::fmtflags std::ios_base::flags(std::ios_base::fmtflags)’ At global scope: cc1plus: warning: unrecognized command line option ‘-Wno-potentially-evaluated-expression’ cc1plus: warning: unrecognized command line option ‘-Wno-unused-private-field’ |
From: Alexander S. <ale...@gm...> - 2018-07-11 14:07:24
|
More on this matter. Somehow this problem looks like a problem with search in a map container. I've add debug into factory template in this way: bool InternalRegister(const Key_T & key, WorkerBase * worker, bool autoDeleteWorker) { std::cout << "D1 add " << key << " " << worker << std::endl; PWaitAndSignal mutex(m_mutex); typename WorkerMap_T::iterator it = m_workers.find(key); if (it != m_workers.end()) { std::cout << "D2 found " << it->first << " " << it->second.m_worker << " for " << key << " " << worker << std::endl; return it->second.m_worker == worker; } PMEMORY_IGNORE_ALLOCATIONS_FOR_SCOPE; m_workers.insert(make_pair(key, WorkerWrap(PAssertNULL(worker), autoDeleteWorker))); return true; } And result is: D1 add 15PSSLInitialiser 0x7fce532d5b60 D1 add PVideoOutputDeviceSDL 0x7fce532d5c60 D1 add PVideoInputDeviceFakeVideo 0x7fce532d5da0 D1 add PVideoOutputDeviceNULLOutput 0x7fce532d5d80 D1 add 11PColourPair 0x7fce532d63c0 ..... D1 add 11PColourPair 0x7fce532d5ee0 D1 add PSoundChannelNullAudio 0x7fce532d6520 D1 add Block 0x7fce532d6d40 D1 add Audio 0x7fce532d6d20 D2 found Block 0x7fce532d6d40 for Audio 0x7fce532d6d20 Somehow search for key "Audio" ends up with "Block" element. On 04.07.2018 15:58, Alexander Sbitnev wrote: > Got a crash (codectest, conopal) on Ubuntu 16.04 (gcc version 5.4.0) > during initialization of static areas: > > (gdb) bt > #0 0x00007ffff51e3428 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:54 > #1 0x00007ffff51e502a in __GI_abort () at abort.c:89 > #2 0x00007ffff644f948 in AssertAction (c=97, > msg=0x64be00 "Assertion fail: Factory Worker already registered, > file /home/shuras/OpalTrunk/ptlib/include/ptlib/pfactory.h, line 417, > error=2, when=2018/07/04 14:20:49.692") at > /home/shuras/OpalTrunk/ptlib/src/ptlib/unix/assert.cxx:433 > #3 0x00007ffff644fcf2 in PPlatformAssertFunc (location=..., > msg=0x64be00 "Assertion fail: Factory Worker already registered, > file /home/shuras/OpalTrunk/ptlib/include/ptlib/pfactory.h, line 417, > error=2, when=2018/07/04 14:20:49.692", defaultAction=0 '\000') at > /home/shuras/OpalTrunk/ptlib/src/ptlib/unix/assert.cxx:495 > #4 0x00007ffff646c401 in InternalAssertFunc (location=..., > msg=0x7ffff6479338 "Factory Worker already registered") > at /home/shuras/OpalTrunk/ptlib/src/ptlib/common/object.cxx:216 > #5 0x00007ffff646c61d in PAssertFunc (location=..., > msg=0x7ffff6479338 "Factory Worker already registered") at > /home/shuras/OpalTrunk/ptlib/src/ptlib/common/object.cxx:264 > #6 0x00007ffff625d5f1 in PFactory<PVXMLNodeHandler, > PCaselessString>::Worker<PVXMLTraverseAudio>::Worker > (this=0x7ffff67ed5c0 <PFactoryLoader::PVXMLTraverseAudio_instance>, > key=..., singleton=true) at > /home/shuras/OpalTrunk/ptlib/include/ptlib/pfactory.h:417 > #7 0x00007ffff6256f2e in __static_initialization_and_destruction_0 > (__initialize_p=1, __priority=65535) at > /home/shuras/OpalTrunk/ptlib/src/ptclib/vxml.cxx:119 > #8 0x00007ffff6258376 in _GLOBAL__sub_I_vxml.cxx(void) () at > /home/shuras/OpalTrunk/ptlib/src/ptclib/vxml.cxx:4129 > #9 0x00007ffff7de76ba in call_init (l=<optimized out>, > argc=argc@entry=10, argv=argv@entry=0x7fffffffe338, > env=env@entry=0x7fffffffe390) at dl-init.c:72 > #10 0x00007ffff7de77cb in call_init (env=0x7fffffffe390, > argv=0x7fffffffe338, argc=10, l=<optimized out>) at dl-init.c:30 > #11 _dl_init (main_map=0x7ffff7ffe168, argc=10, argv=0x7fffffffe338, > env=0x7fffffffe390) at dl-init.c:120 > #12 0x00007ffff7dd7c6a in _dl_start_user () from > /lib64/ld-linux-x86-64.so.2 > #13 0x000000000000000a in ?? () > #14 0x00007fffffffe619 in ?? () > #15 0x00007fffffffe664 in ?? () > #16 0x00007fffffffe667 in ?? () > #17 0x00007fffffffe679 in ?? () > #18 0x00007fffffffe67c in ?? () > #19 0x00007fffffffe685 in ?? () > #20 0x00007fffffffe68d in ?? () > #21 0x00007fffffffe690 in ?? () > #22 0x00007fffffffe697 in ?? () > #23 0x00007fffffffe69a in ?? () > #24 0x0000000000000000 in ?? () > |
From: Alexander S. <ale...@gm...> - 2018-07-04 12:58:47
|
Got a crash (codectest, conopal) on Ubuntu 16.04 (gcc version 5.4.0) during initialization of static areas: (gdb) bt #0 0x00007ffff51e3428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff51e502a in __GI_abort () at abort.c:89 #2 0x00007ffff644f948 in AssertAction (c=97, msg=0x64be00 "Assertion fail: Factory Worker already registered, file /home/shuras/OpalTrunk/ptlib/include/ptlib/pfactory.h, line 417, error=2, when=2018/07/04 14:20:49.692") at /home/shuras/OpalTrunk/ptlib/src/ptlib/unix/assert.cxx:433 #3 0x00007ffff644fcf2 in PPlatformAssertFunc (location=..., msg=0x64be00 "Assertion fail: Factory Worker already registered, file /home/shuras/OpalTrunk/ptlib/include/ptlib/pfactory.h, line 417, error=2, when=2018/07/04 14:20:49.692", defaultAction=0 '\000') at /home/shuras/OpalTrunk/ptlib/src/ptlib/unix/assert.cxx:495 #4 0x00007ffff646c401 in InternalAssertFunc (location=..., msg=0x7ffff6479338 "Factory Worker already registered") at /home/shuras/OpalTrunk/ptlib/src/ptlib/common/object.cxx:216 #5 0x00007ffff646c61d in PAssertFunc (location=..., msg=0x7ffff6479338 "Factory Worker already registered") at /home/shuras/OpalTrunk/ptlib/src/ptlib/common/object.cxx:264 #6 0x00007ffff625d5f1 in PFactory<PVXMLNodeHandler, PCaselessString>::Worker<PVXMLTraverseAudio>::Worker (this=0x7ffff67ed5c0 <PFactoryLoader::PVXMLTraverseAudio_instance>, key=..., singleton=true) at /home/shuras/OpalTrunk/ptlib/include/ptlib/pfactory.h:417 #7 0x00007ffff6256f2e in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/shuras/OpalTrunk/ptlib/src/ptclib/vxml.cxx:119 #8 0x00007ffff6258376 in _GLOBAL__sub_I_vxml.cxx(void) () at /home/shuras/OpalTrunk/ptlib/src/ptclib/vxml.cxx:4129 #9 0x00007ffff7de76ba in call_init (l=<optimized out>, argc=argc@entry=10, argv=argv@entry=0x7fffffffe338, env=env@entry=0x7fffffffe390) at dl-init.c:72 #10 0x00007ffff7de77cb in call_init (env=0x7fffffffe390, argv=0x7fffffffe338, argc=10, l=<optimized out>) at dl-init.c:30 #11 _dl_init (main_map=0x7ffff7ffe168, argc=10, argv=0x7fffffffe338, env=0x7fffffffe390) at dl-init.c:120 #12 0x00007ffff7dd7c6a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #13 0x000000000000000a in ?? () #14 0x00007fffffffe619 in ?? () #15 0x00007fffffffe664 in ?? () #16 0x00007fffffffe667 in ?? () #17 0x00007fffffffe679 in ?? () #18 0x00007fffffffe67c in ?? () #19 0x00007fffffffe685 in ?? () #20 0x00007fffffffe68d in ?? () #21 0x00007fffffffe690 in ?? () #22 0x00007fffffffe697 in ?? () #23 0x00007fffffffe69a in ?? () #24 0x0000000000000000 in ?? () |
From: Sagar J. <sj...@fu...> - 2018-04-12 10:27:28
|
Hi Robert, We are testing TLS/SRTP in opal . We have developed an application on top of OPAL MCU. We are using opal3.16 (procyon). We are testing cal SIP/TLS + SRTP video call from Polycom HDX 8000 to our Opal based application. In some occasions we get continuous decryption errors below and call disconnects 2018/02/01 07:26:12.430 2 RTP-1-media:12062 srtp_session.cxx(722) SRTP Session 1, Library error 7 from srtp_unprotect() - authentication failure - SSRC=566990337 (0x21cb9601) 2018/02/01 07:26:12.451 2 RTP-1-media:12062 srtp_session.cxx(722) SRTP Session 1, Library error 7 from srtp_unprotect() - authentication failure - SSRC=566990337 (0x21cb9601) SN=1 2018/02/01 07:26:12.473 2 RTP-1-media:12062 srtp_session.cxx(722) SRTP Session 1, Library error 7 from srtp_unprotect() - authentication failure - SSRC=566990337 (0x21cb9601) SN=2 In the above example we have audio SRTP decryption errors Polycom's encryption key negotiation a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:rf28f1M7avmP25GPWCwHLqzHa+FtriEZlyJHygL9|2^31 Opal's encryption key during negotiation a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:gpwVwPthwquDFhDJVueDCUyMIUC6Oau2ddb5MK9m a=ssrc:609675521 cname:fuJh2I4F6BGE2wAWPlTKMQ Once this error starts it occurs for a while for every call, and then vanishes after sometime. The behavior is quite random. Do you think this is a problem on the OPAL side that it is unable to decode the authentication tag in the packets at certain point of time? Please let me know your inputs Thanks and Regards *Sagar Joshi* Associate Technical Manager Convergence Practice -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.* |
From: Michael P. <mic...@my...> - 2018-01-31 13:56:24
|
I try to understand why this error happens in conjunction with the Frizbox. OpalVoip is registered at Fritzbox and everything works fine except this error 502 Bad Gateway. After a CANCEL from Fritzbox (call completed elsewere) OpalVoip sends this error. We are using opalvoip-3.14.3 running on an embedded device and we cannot update easily. I try only to understand if this error is malconfiguration, is caused by Fritzbox or is a opalvoip lib error. REGISTER sip:192.168.178.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.178.26:5060;branch=z9hG4bK7695ae2c-e5f9-e711-947e-ac0dfe300177;rport CSeq: 15 REGISTER Content-Length: 0 Call-ID: 823d8dd8-e2f9-e711-947e-ac0dfe300177@myGEKKO To: Authorization: Digest username="MyGekko1", realm="fritz.box", nonce="FC8725BE57DD96A0", uri="sip:192.168.178.1", algorithm=MD5, response="6659627a9e8758d222e9525380bc5ebe" Contact: ;expires=300;q=1 Organization: OPAL VoIP Max-Forwards: 70 From: ;tag=7c758dd8-e2f9-e711-947e-ac0dfe300177 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 300 User-Agent: OPAL/1.0alpha0 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.178.26:5060;branch=z9hG4bK7695ae2c-e5f9-e711-947e-ac0dfe300177;rport=5060 From: ;tag=7c758dd8-e2f9-e711-947e-ac0dfe300177 To: ;tag=4D668FD4BE690D29 Call-ID: 823d8dd8-e2f9-e711-947e-ac0dfe300177@myGEKKO CSeq: 15 REGISTER WWW-Authenticate: Digest realm="fritz.box", nonce="2390102456667A9D" User-Agent: FRITZ!OS Content-Length: 0 REGISTER sip:192.168.178.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.178.26:5060;branch=z9hG4bKa8d4b02c-e5f9-e711-947e-ac0dfe300177;rport CSeq: 16 REGISTER Content-Length: 0 Call-ID: 823d8dd8-e2f9-e711-947e-ac0dfe300177@myGEKKO To: Authorization: Digest username="MyGekko1", realm="fritz.box", nonce="2390102456667A9D", uri="sip:192.168.178.1", algorithm=MD5, response="e0e171d6cbc94ae0cb42a7b48b770a63" Contact: ;expires=300;q=1 Organization: OPAL VoIP Max-Forwards: 70 From: ;tag=7c758dd8-e2f9-e711-947e-ac0dfe300177 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 300 User-Agent: OPAL/1.0alpha0 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.178.26:5060;branch=z9hG4bKa8d4b02c-e5f9-e711-947e-ac0dfe300177;rport=5060 From: ;tag=7c758dd8-e2f9-e711-947e-ac0dfe300177 To: ;tag=FCC278DF758346B0 Call-ID: 823d8dd8-e2f9-e711-947e-ac0dfe300177@myGEKKO CSeq: 16 REGISTER Contact: ;q=1;expires=300 User-Agent: AVM FRITZ!Box 6490 Cable 141.06.87 (Nov 20 2017) Supported: 100rel,replaces,timer Allow-Events: telephone-event,refer,reg Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH Accept: application/sdp, multipart/mixed Accept-Encoding: identity Content-Length: 0 INVITE sip:MyGekko1@192.168.178.26:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK03BFDD80FD2385B8 From: "Steve" ;tag=6604AADEEC6815C9 To: ;q=1 Call-ID: 8CE0DA23E6B0B1C6@192.168.178.1 CSeq: 112 INVITE Contact: Max-Forwards: 70 Expires: 120 User-Agent: AVM FRITZ!Box 6490 Cable 141.06.87 (Nov 20 2017) Supported: 100rel,replaces,timer Allow-Events: telephone-event,refer Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH Content-Type: application/sdp Accept: application/sdp, multipart/mixed Accept-Encoding: identity Content-Length: 198 v=0 o=user 12902326 12902326 IN IP4 192.168.178.1 s=call c=IN IP4 192.168.178.1 t=0 0 m=audio 7082 RTP/AVP 8 0 101 a=sendrecv a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp:7083 SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK03BFDD80FD2385B8 CSeq: 112 INVITE Content-Length: 0 Call-ID: 8CE0DA23E6B0B1C6@192.168.178.1 To: ;q=1 From: "Steve" ;tag=6604AADEEC6815C9 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK03BFDD80FD2385B8 CSeq: 112 INVITE Content-Length: 0 Call-ID: 8CE0DA23E6B0B1C6@192.168.178.1 To: "MyGekko" ;tag=2ca0673a-e5f9-e711-947e-ac0dfe300177 Contact: "MyGekko" Organization: OPAL VoIP RSeq: 796679428 From: "Steve" ;tag=6604AADEEC6815C9 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Require: 100rel User-Agent: OPAL/1.0alpha0 PRACK sip:MyGekko1@192.168.178.26 SIP/2.0 Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bKE4111C89019ACEC8 From: "Steve" ;tag=6604AADEEC6815C9 To: "MyGekko" ;tag=2ca0673a-e5f9-e711-947e-ac0dfe300177 Call-ID: 8CE0DA23E6B0B1C6@192.168.178.1 CSeq: 113 PRACK RAck: 796679428 112 INVITE Max-Forwards: 70 User-Agent: AVM FRITZ!Box 6490 Cable 141.06.87 (Nov 20 2017) Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bKE4111C89019ACEC8 CSeq: 113 PRACK Content-Length: 0 Call-ID: 8CE0DA23E6B0B1C6@192.168.178.1 To: "MyGekko" ;tag=2ca0673a-e5f9-e711-947e-ac0dfe300177 Contact: From: "Steve" ;tag=6604AADEEC6815C9 CANCEL sip:MyGekko1@192.168.178.26:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK03BFDD80FD2385B8 From: "Steve" ;tag=6604AADEEC6815C9 To: ;q=1 Call-ID: 8CE0DA23E6B0B1C6@192.168.178.1 CSeq: 112 CANCEL Reason: SIP; cause=200; text="Call completed elsewhere" Max-Forwards: 70 User-Agent: AVM FRITZ!Box 6490 Cable 141.06.87 (Nov 20 2017) Supported: 100rel,replaces,timer Allow-Events: telephone-event,refer Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK03BFDD80FD2385B8 CSeq: 112 CANCEL Content-Length: 0 Call-ID: 8CE0DA23E6B0B1C6@192.168.178.1 To: ;tag=2ca0673a-e5f9-e711-947e-ac0dfe300177 Contact: Organization: OPAL VoIP From: "Steve" ;tag=6604AADEEC6815C9 User-Agent: OPAL/1.0alpha0 SIP/2.0 502 Bad Gateway Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK03BFDD80FD2385B8 CSeq: 112 INVITE Content-Length: 0 Call-ID: 8CE0DA23E6B0B1C6@192.168.178.1 To: "MyGekko" ;tag=2ca0673a-e5f9-e711-947e-ac0dfe300177 Contact: "MyGekko" Organization: OPAL VoIP From: "Steve" ;tag=6604AADEEC6815C9 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK User-Agent: OPAL/1.0alpha0 ACK sip:MyGekko1@192.168.178.26:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK03BFDD80FD2385B8 From: "Steve" ;tag=6604AADEEC6815C9 To: "MyGekko" ;tag=2ca0673a-e5f9-e711-947e-ac0dfe300177 Call-ID: 8CE0DA23E6B0B1C6@192.168.178.1 CSeq: 112 ACK User-Agent: AVM FRITZ!Box 6490 Cable 141.06.87 (Nov 20 2017) Content-Length: 0 Thanks for your help Michael Prader |
From: Ali S. <aj....@gm...> - 2018-01-28 06:54:03
|
Hi guys, Do you know is there any plan to add H.265 to opalvoip in future? Also If there exists a guide on how to add new codec I could make some contribution. Regards, |
From: Abhilash K.V <abh...@gm...> - 2017-12-10 18:47:31
|
Hello, I am new to Opal Voip , trying to compile this using MAC machine and want to run OpenPhone app on my iPhone and Android devices. Could you pls help me on this. 1. From where to clone the required components 2. Steps for building it with dependency information I followed http://wiki.opalvoip.org/index.php?n=Main.BuildingPTLibMacOSX But when I compiled OpenPhone getting following Errors. Maro undefined CODEC_FLAG_EMU_EDGE, CODEC_FLAG_TRUNCATED ... Thanks, Abhilash. |
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 |
From: Alexander S. <ale...@gm...> - 2017-12-06 13:24:54
|
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. Must be a problem of SDL library or lower level DRI/X11 system currently on my setup. I suppose I should do additional testing on other types of linux. I will mail all my finding later. Thank you Robert for new commits. 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... <mailto: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://Slashdot.org>! >> http://sdm.link/slashdot >> _______________________________________________ >> Opalvoip-devel mailing list >> Opa...@li... >> <mailto:Opa...@li...> >> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel > |
From: Robert J. <ro...@vo...> - 2017-12-06 11:48:08
|
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... <mailto: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://Slashdot.org> ! http://sdm.link/slashdot <http://sdm.link/slashdot> _______________________________________________ Opalvoip-devel mailing list Opa...@li... <mailto:Opa...@li...> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |
From: Alexander S. <ale...@gm...> - 2017-11-15 16:59:19
|
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 |
From: Robert J. <ro...@vo...> - 2017-11-15 13:43:05
|
Thank you very much! I have applied the patch. ---------- Robert Jongbloed Vox Lucida Pty. Ltd. On 31 Oct 2017, at 4:39 pm, Bertrand Totti <ber...@gm... <mailto:ber...@gm...> > wrote: Hi, I think there is a quirk in opal's file: include/h224/h281.h Some RequestType are wrong: StoreAsPreset = 0x07, ActivatePreset = 0x08 They should be: StoreAsPreset = 0x06, ActivatePreset = 0x07 Kind regards, Bertrand Totti ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org <http://Slashdot.org> ! http://sdm.link/slashdot_______________________________________________ <http://sdm.link/slashdot_______________________________________________> Opalvoip-devel mailing list Opa...@li... <mailto:Opa...@li...> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |