Recherche avancée

Sur d’autres sites (4287)

• Of ctors and dtors

  18 février 2011, par Multimedia Mike — Programming, Sega Dreamcast

  I haven’t given up on the Sega Dreamcast programming. I was able to compile a bunch of homebrew code for the DC many years ago and I can’t make it work anymore. Again, I was working with a purpose-built, open source RTOS named KallistiOS (or KOS). I can make the programs compile but not run. I had ELF files left over from years ago which still executed. But when I tried to build new ELF files, no luck— the programs crashed before even reaching my main() function.

  I found the problem : ELF files are comprised of a number of sections and 2 of these sections are named ’.ctors’ and ’.dtors’ which stand for constructors and destructors. The KOS RTOS performs a manual traversal of .ctors section during program initialization and this is where things go bad. The traversal code doesn’t seem to account for a .ctors section that only contains a single entry. I commented out the function that does the traversal and programs started to work, at least until it was time to exit the program and return control to the program loader. That’s when the counterpart .dtors section traversal code ran and demonstrated the same problem. I’ll exhibit the problematic code at the end of this post.

  So I’m finally tinkering with Sega Dreamcast programming once again and with a slightly better grasp of software engineering than the first time I did this.

  Portable and Compatible C ?
  If nothing else, this low-level embedded stuff exposes you to some serious toolchain arcana, the likes of which you will likely never see working strictly in the desktop arena.

  Still, this exercise makes me wonder why C code from a decade ago doesn’t compile reliably now. Part of it is because gcc has gotten stricter about the syntax it will accept. In the case of this specific crashing problem, I suspect it comes down to a difference in the way the linker generates the final ELF file. I’ve written a list of items I have had to modify in the KOS codebase in order to get it to compile on more recent gcc versions. I wonder if it would be worth publishing the specifics, or if anyone would ever find the information useful ? Oh, who am I kidding ? Of course I’ll write it up, perhaps publish a new version of the code, if only because that’s the best chance I have of finding my own work again some years down the road.

  Problematic C Code
  See if this code makes any sense to you. It somehow traverse a list of 32-bit function pointers (in different directions, depending on constructors or destructors), executing each in turn. However, it appears to fall over if the list of pointers consists of a single entry.
  

  PLAIN TEXT

  C :

  1. typedef void (*fptr)(void) ;
  2.  
  3. static fptr ctor_list[1] __attribute__((section(".ctors"))) = { (fptr) -1 } ;
  4. static fptr dtor_list[1] __attribute__((section(".dtors"))) = { (fptr) -1 } ;
  5.  
  6. /* Call this to execute all ctors */
  7. void arch_ctors() {
  8.     fptr *fpp ;
  9.  
  10.     /* Run up to the end of the list (defined by crtend) */
  11.     for (fpp=ctor_list + 1 ; *fpp != 0 ; ++fpp)
  12.          ;
  13.  
  14.     /* Now run the ctors backwards */
  15.     while (—fpp> ctor_list)
  16.         (**fpp)() ;
  17. }
  18.  
  19. /* Call this to execute all dtors */
  20. void arch_dtors() {
  21.     fptr *fpp ;
  22.  
  23.     /* Do the dtors forwards */
  24.     for (fpp=dtor_list + 1 ; *fpp != 0 ; ++fpp )
  25.         (**fpp)() ;
  26. }

• Revision 33150 : Essayer de suivre les optimisations de la 2.0.10++ SVN

  23 novembre 2009, par real3t@… — Log

  Essayer de suivre les optimisations de la 2.0.10++ SVN

• Streaming RTP with ffmpeg and node.js to voip phone

  5 juillet 2023, par Nik Hendricks

  I am trying to implement SIP in node.js. Here is the library i am working on

  


  Upon receiving an invite request such as

  


  
Received INVITE
INVITE sip:201@192.168.1.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.39:5062;branch=z9hG4bK1534941205
From: "Nik" <sip:nik@192.168.1.2>;tag=564148403
To: <sip:201@192.168.1.2>
Call-ID: 2068254636@192.168.1.39
CSeq: 2 INVITE
Contact: <sip:nik@192.168.1.39:5062>
Authorization: Digest username="Nik", realm="NRegistrar", nonce="1234abcd", uri="sip:201@192.168.1.2:5060", response="7fba16dafe3d60c270b774bd5bba524c", algorithm=MD5
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: Yealink SIP-T42G 29.71.0.120
Supported: replaces
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 306

v=0
o=- 20083 20083 IN IP4 192.168.1.39
s=SDP data
c=IN IP4 192.168.1.39
t=0 0
m=audio 11782 RTP/AVP 0 8 18 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv



  


  I can then parse the SDP into an object like this

  


   
{
    "session":{
        "version":"0",
        "origin":"- 20084 20084 IN IP4 192.168.1.39",
        "sessionName":"SDP data"
    },
    "media":[
        {
            "media":"audio",
            "port":11784,
            "protocol":"RTP/AVP",
            "format":"0",
            "attributes":[
                "rtpmap:0 PCMU/8000",
                "rtpmap:8 PCMA/8000",
                "rtpmap:18 G729/8000",
                "fmtp:18 annexb=no",
                "rtpmap:9 G722/8000",
                "fmtp:101 0-15",
                "rtpmap:101 telephone-event/8000",
                "ptime:20",
                "sendrecv"
            ]
        }
    ]
}


  


  After sending the 100 and 180 responses with my library i attempt to start a RTP stream with ffmpeg

  


  var port = SDPParser.parse(res.message.body).media[0].port
var s = new STREAMER('output.wav', '192.168.1.39', port)


  


  with the following STREAMER class

  


  class Streamer{
    constructor(inputFilePath, rtpAddress, rtpPort){
        this.inputFilePath = 'output.wav';
        this.rtpAddress = rtpAddress;
        this.rtpPort = rtpPort;
    }

    start(){
        return new Promise((resolve) => {
            const ffmpegCommand = `ffmpeg -re -i ${this.inputFilePath} -ar 8000 -f mulaw -f rtp rtp://${this.rtpAddress}:${this.rtpPort}`;
            const ffmpegProcess = spawn(ffmpegCommand, { shell: true });
    
            ffmpegProcess.stdout.on('data', (data) => {
                data = data.toString()
                //replace all instances of 127.0.0.1 with our local ip address
                data = data.replace(new RegExp('127.0.0.1', 'g'), '192.168.1.3');

                resolve(data.toString())
            });
    
            ffmpegProcess.stderr.on('data', (data) => {
              // Handle stderr data if required
              console.log(data.toString())
            });
    
            ffmpegProcess.on('close', (code) => {
              // Handle process close event if required
              console.log('close')
              console.log(code.toString())
            });
    
            ffmpegProcess.on('error', (error) => {
              // Handle process error event if required
              console.log(error.toString())
            });
        })
    }
     
}


  


  the start() function resolves with the SDP that ffmpeg generates. I am starting to think that ffmpeg cant generate proper SDP for voip calls.

  


  so when i create 200 response with the following sdp

  


  v=0
o=- 0 0 IN IP4 192.168.1.3
s=Impact Moderato
c=IN IP4 192.168.1.39
t=0 0
a=tool:libavformat 58.29.100
m=audio 12123 RTP/AVP 97
b=AS:128
a=rtpmap:97 PCMU/8000/2


  


  the other line never picks up. from my understanding the first invite from the caller will provide SDP that will tell me where to send the RTP stream too and the correct codecs and everything. I know that currently, my wav file is PCMU and i can listen to it with ffplay and the provided sdp. what is required to make the other line pickup specifically a Yealink t42g

  


  my full attempt looks like this

  


  Client.on('INVITE', (res) => {
    console.log("Received INVITE")
    var d = Client.Dialog(res).then(dialog => {
        dialog.send(res.CreateResponse(100))
        dialog.send(res.CreateResponse(180))
        var port = SDPParser.parse(res.message.body).media[0].port

        var s = new STREAMER('output.wav', '192.168.1.39', port)
        s.start().then(sdp => {
            console.log(sdp.split('SDP:')[1])
            var ok = res.CreateResponse(200)
            ok.body = sdp.split('SDP:')[1]
            dialog.send(ok)
        })

        dialog.on('BYE', (res) => {
            console.log("BYE")
            dialog.send(res.CreateResponse(200))
            dialog.kill()
        })
    })
})


  


  I have provided a link to my library at the top of this message. My current problem is in the examples/Client folder.

  


  I'm not sure what could be going wrong here. Maybe i'm not using the right format or codec for the VOIP phone i dont see whats wrong with the SDP. especially if i can listen to SDP generated by ffmpeg if i stream RTP back to the same computer i use ffplay on. Any help is greatly appreciated.

  


  Update

  


  As i test i decided to send the caller back SDP that was generated by a Yealink phone like itself. but with some modifications

  


  v=0
o=- ${this.output_port} ${this.output_port} IN IP4 192.168.1.39
s=SDP data
c=IN IP4 192.168.1.39
t=0 0
m=audio ${this.output_port} RTP/AVP 0 8 18 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=fmtp:101 0-15
a=rtpmap:1
01 telephone-event/8000
a=ptime:20
a=sendrecv


  


  Finally, the phone that makes the call in the first place will fully answer but still no audio stream. I notice if I change the IP address or port to something wrong the other phone Will hear its own audio instead of just quiet. so this leads me to believe I am headed in the right direction. And maybe the problem lies in not sending the right audio format for what I'm describing.

  


  Additionaly, Whenever using ffmpeg to stream my audio with rtp I notice that it sees the file format as this pcm_alaw, 8000 Hz, mono, s16, 64 kb/s My new SDP describes using both ulaw and alaw but I'm not sure which it is saying it prefers

  


  v=0
o=- ${this.output_port} ${this.output_port} IN IP4 192.168.1.39
s=SDP data
c=IN IP4 192.168.1.39
t=0 0
m=audio ${this.output_port} RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=ptime:0
a=sendrecv


  


  I have been able to simply the SDP down to this. This will let the other phone actually pickup and not hear its own audio. it's just a completely dead air stream.