opalvoip-devel — Discussions relating to OpalVoip development

Re: [Opalvoip-devel] Is it possible to create multiple H323 end points in one task?

[Robert J. <ro...@vo...>]

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

[Opalvoip-devel] Is it possible to create multiple H323 end points in one task?

[Alan J. <ala...@gm...>]

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>

[Opalvoip-devel] Patch for SNMP SET

[Jan W. <ja...@wi...>]

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

[Opalvoip-devel] openphone failed to reading video settings

[Shi Q. <qiu...@gm...>]

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.

[Opalvoip-devel] openphone failed to preview video

[Shi Q. <qiu...@gm...>]

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

Re: [Opalvoip-devel] FIR requests under SIP connection

[Alexander S. <ale...@gm...>]

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
>>>
>>
>

Re: [Opalvoip-devel] FIR requests under SIP connection

[Robert J. <ro...@vo...>]

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
 
 
 
 
 
 


 

 

Re: [Opalvoip-devel] FIR requests under SIP connection

[Alexander S. <ale...@gm...>]

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
>

Re: [Opalvoip-devel] FIR requests under SIP connection

[Robert J. <ro...@vo...>]

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

Re: [Opalvoip-devel] FIR requests under SIP connection

[Robert J. <ro...@vo...>]

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

[Opalvoip-devel] FIR requests under SIP connection

[Alexander S. <ale...@gm...>]

   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?

Re: [Opalvoip-devel] ptlib GNU build regression

[Robert J. <ro...@vo...>]

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

Re: [Opalvoip-devel] ptlib GNU build regression

[Alexander S. <ale...@gm...>]

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
>

[Opalvoip-devel] ptlib GNU build regression

[Alexander S. <ale...@gm...>]

/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’

Re: [Opalvoip-devel] latest trunk, samples crashing

[Alexander S. <ale...@gm...>]

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 ?? ()
>

[Opalvoip-devel] latest trunk, samples crashing

[Alexander S. <ale...@gm...>]

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 ?? ()

[Opalvoip-devel] [OPAL 3.16 Procyon] Library error 7 from srtp_unprotect() - authentication failure

[Sagar J. <sj...@fu...>]

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.*

[Opalvoip-devel] Bad Gateway 502 - Fritzbox

[Michael P. <mic...@my...>]

  

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 

   

[Opalvoip-devel] Is there any plan to support H.265?

[Ali S. <aj....@gm...>]

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,

[Opalvoip-devel] Fwd: Compilation error in Opal Voip

[Abhilash K.V <abh...@gm...>]

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.

Re: [Opalvoip-devel] codectest issues

[Alexander S. <ale...@gm...>]

 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

Re: [Opalvoip-devel] codectest issues

[Alexander S. <ale...@gm...>]

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
>

Re: [Opalvoip-devel] codectest issues

[Robert J. <ro...@vo...>]

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

[Opalvoip-devel] codectest issues

[Alexander S. <ale...@gm...>]

   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

Re: [Opalvoip-devel] H281 quirk

[Robert J. <ro...@vo...>]

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