Advanced search

On other websites (3462)

• Can build & make video call with pjsip and ffmpeg

  10 May 2023, by QViet

  I try to build PJSIP with ffmpeg with this config:

  


  i Follow those step:

  


  

  • build need lib and place in thirdparty folder name ffmpeg

  


  • setup link lib & header already.

  


  • run build with "$configure —with-ffmpeg="

  


  • config_site.h add:

  


  


  


  #define PJMEDIA_HAS_OPENH264_CODEC 1 
#define PJMEDIA_HAS_VIDEO 1 
#define PJMEDIA_VIDEO_DEV_HAS_FFMPEG 1 
#define PJMEDIA_HAS_FFMPEG_VID_CODEC 1 
#define PJMEDIA_HAS_FFMPEG 1 
#define PJMEDIA_HAS_FFMPEG_CODEC_H264 1 
#define PJMEDIA_HAS_LIBAVDEVICE 1 
#define PJMEDIA_HAS_OPENH264_CODEC 1


  


  


  I see have to enable PJMEDIA_HAS_OPENH264_CODEC , if not, can build success but when import will receive this error:

  


  Undefined symbol: _WelsCreateDecoder


  


  cause miss wels package exits in openh264 lib.

  


  The build with success after all with above config but in this:

  


     pj_status_t status = pjsua_vid_enum_codecs(videoCodecInfo, &videoCodecCount);


  


  the codec info just show 1 codec is "H264/97" -> is OpenH264 codec, i can't see ffmpeg here.
When im start call like normal, see log openh264 init call/ open camera .

  


  What i need step to using ffmpeg, i can see any docs about it

  


  can you help me?

  


  ** this i log call stack:**

  


  2023-04-24 10:17:21.522976+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.523 [SIPSample -[SIPSample startEndpointWithEndpointConfiguration:error:]:272] Creating new PSUASIP Endpoint instance.
10:17:21.525         os_core_unix.c !pjlib 2.13-dev for POSIX initialized
10:17:21.526         sip_endpoint.c  .Creating endpoint instance...
10:17:21.527                  pjlib  .select() I/O Queue created (0x1050a32c8)
10:17:21.527         sip_endpoint.c  .Module "mod-msg-print" registered
10:17:21.527        sip_transport.c  .Transport manager created.
10:17:21.527           pjsua_core.c  .PJSUA state changed: NULL --> CREATED
2023-04-24 10:17:21.528077+0700 PSUAKitSample[83000:15642817] 10:17:21.528         sip_endpoint.c  .Module "mod-pjsua-log" registered

2023-04-24 10:17:21.528204+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.528 [SIPSample void logCallBack(int, const char *, int):1034]         sip_endpoint.c  .Module "mod-PSUA-log" registered
2023-04-24 10:17:21.529375+0700 PSUAKitSample[83000:15642817] 10:17:21.529         sip_endpoint.c  .Module "mod-tsx-layer" registered

2023-04-24 10:17:21.529477+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.529 [SIPSample void logCallBack(int, const char *, int):1034]         sip_endpoint.c  .Module "mod-tsx-layer" registered
2023-04-24 10:17:21.529491+0700 PSUAKitSample[83000:15642817] 10:17:21.529         sip_endpoint.c  .Module "mod-stateful-util" registered

2023-04-24 10:17:21.529592+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.530 [SIPSample void logCallBack(int, const char *, int):1034]         sip_endpoint.c  .Module "mod-stateful-util" registered
2023-04-24 10:17:21.529895+0700 PSUAKitSample[83000:15642817] 10:17:21.529         sip_endpoint.c  .Module "mod-ua" registered

2023-04-24 10:17:21.530024+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.530 [SIPSample void logCallBack(int, const char *, int):1034]         sip_endpoint.c  .Module "mod-ua" registered
2023-04-24 10:17:21.530068+0700 PSUAKitSample[83000:15642817] 10:17:21.530         sip_endpoint.c  .Module "mod-100rel" registered

2023-04-24 10:17:21.530181+0700 PSUAKitSample[83000:15642817] 10:17:21.530         sip_endpoint.c  .Module "mod-pjsua" registered

2023-04-24 10:17:21.530217+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.530 [SIPSample void logCallBack(int, const char *, int):1034]         sip_endpoint.c  .Module "mod-100rel" registered
2023-04-24 10:17:21.530283+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.530 [SIPSample void logCallBack(int, const char *, int):1034]         sip_endpoint.c  .Module "mod-PSUA" registered
2023-04-24 10:17:21.530865+0700 PSUAKitSample[83000:15642817] 10:17:21.530         sip_endpoint.c  .Module "mod-invite" registered

2023-04-24 10:17:21.530970+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.531 [SIPSample void logCallBack(int, const char *, int):1034]         sip_endpoint.c  .Module "mod-invite" registered
2023-04-24 10:17:21.677206+0700 PSUAKitSample[83000:15642817] 10:17:21.677        coreaudio_dev.c  .. dev_id 0: iPhone IO device  (in=1, out=1) 8000Hz

2023-04-24 10:17:21.677497+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.677 [SIPSample void logCallBack(int, const char *, int):1034]        coreaudio_dev.c  .. dev_id 0: iPhone IO device  (in=1, out=1) 8000Hz
2023-04-24 10:17:21.677588+0700 PSUAKitSample[83000:15642817] 10:17:21.677        coreaudio_dev.c  ..core audio initialized

2023-04-24 10:17:21.677804+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.678 [SIPSample void logCallBack(int, const char *, int):1034]        coreaudio_dev.c  ..core audio initialized
2023-04-24 10:17:21.678538+0700 PSUAKitSample[83000:15642817] 10:17:21.678                  pjlib  ..select() I/O Queue created (0x1060684a8)

2023-04-24 10:17:21.678743+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.679 [SIPSample void logCallBack(int, const char *, int):1034]                  pjlib  ..select() I/O Queue created (0x1060684a8)
2023-04-24 10:17:21.683380+0700 PSUAKitSample[83000:15642817] 10:17:21.683            pjsua_vid.c  ..Initializing video subsystem..

2023-04-24 10:17:21.683585+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.683 [SIPSample void logCallBack(int, const char *, int):1034]            PSUA_vid.c  ..Initializing video subsystem..
2023-04-24 10:17:21.684058+0700 PSUAKitSample[83000:15642817] 10:17:21.684             vid_conf.c  ...Created video conference bridge with 32 ports

2023-04-24 10:17:21.684260+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.684 [SIPSample void logCallBack(int, const char *, int):1034]             vid_conf.c  ...Created video conference bridge with 32 ports
2023-04-24 10:17:21.684983+0700 PSUAKitSample[83000:15642817] 10:17:21.684           openh264.cpp  ...OpenH264 codec initialized

2023-04-24 10:17:21.685168+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.685 [SIPSample void logCallBack(int, const char *, int):1034]           openh264.cpp  ...OpenH264 codec initialized
2023-04-24 10:17:21.685237+0700 PSUAKitSample[83000:15642817] 10:17:21.685           opengl_dev.c  ...OpenGL device initialized

2023-04-24 10:17:21.685370+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.685 [SIPSample void logCallBack(int, const char *, int):1034]           opengl_dev.c  ...OpenGL device initialized
2023-04-24 10:17:21.715616+0700 PSUAKitSample[83000:15642817] 10:17:21.715           darwin_dev.m  ...Darwin video initialized with 5 devices:

2023-04-24 10:17:21.715796+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.716 [SIPSample void logCallBack(int, const char *, int):1034]           darwin_dev.m  ...Darwin video initialized with 5 devices:
2023-04-24 10:17:21.715812+0700 PSUAKitSample[83000:15642817] 10:17:21.715           darwin_dev.m  ... 0: [Renderer] iOS - UIView

2023-04-24 10:17:21.715917+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.716 [SIPSample void logCallBack(int, const char *, int):1034]           darwin_dev.m  ... 0: [Renderer] iOS - UIView
2023-04-24 10:17:21.715921+0700 PSUAKitSample[83000:15642817] 10:17:21.715           darwin_dev.m  ... 1: [Capturer] AVF - Front Camera

2023-04-24 10:17:21.716006+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.716 [SIPSample void logCallBack(int, const char *, int):1034]           darwin_dev.m  ... 1: [Capturer] AVF - Front Camera
2023-04-24 10:17:21.716033+0700 PSUAKitSample[83000:15642817] 10:17:21.716           darwin_dev.m  ... 2: [Capturer] AVF - Back Camera

2023-04-24 10:17:21.716137+0700 PSUAKitSample[83000:15642817] 10:17:21.716           darwin_dev.m  ... 3: [Capturer] AVF - Back Dual Camera

2023-04-24 10:17:21.716152+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.716 [SIPSample void logCallBack(int, const char *, int):1034]           darwin_dev.m  ... 2: [Capturer] AVF - Back Camera
2023-04-24 10:17:21.716218+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.716 [SIPSample void logCallBack(int, const char *, int):1034]           darwin_dev.m  ... 3: [Capturer] AVF - Back Dual Camera
2023-04-24 10:17:21.716247+0700 PSUAKitSample[83000:15642817] 10:17:21.716           darwin_dev.m  ... 4: [Capturer] AVF - Back Telephoto Camera

2023-04-24 10:17:21.716375+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.716 [SIPSample void logCallBack(int, const char *, int):1034]           darwin_dev.m  ... 4: [Capturer] AVF - Back Telephoto Camera
2023-04-24 10:17:21.716409+0700 PSUAKitSample[83000:15642817] 10:17:21.716         colorbar_dev.c  ...Colorbar video src initialized with 2 device(s):

2023-04-24 10:17:21.716673+0700 PSUAKitSample[83000:15642817] 10:17:21.716         colorbar_dev.c  ... 0: Colorbar generator

2023-04-24 10:17:21.716764+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.717 [SIPSample void logCallBack(int, const char *, int):1034]         colorbar_dev.c  ...Colorbar video src initialized with 2 device(s):
2023-04-24 10:17:21.716918+0700 PSUAKitSample[83000:15642817] 10:17:21.716         colorbar_dev.c  ... 1: Colorbar-active

2023-04-24 10:17:21.716938+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.717 [SIPSample void logCallBack(int, const char *, int):1034]         colorbar_dev.c  ... 0: Colorbar generator
2023-04-24 10:17:21.717192+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.717 [SIPSample void logCallBack(int, const char *, int):1034]         colorbar_dev.c  ... 1: Colorbar-active
2023-04-24 10:17:21.717528+0700 PSUAKitSample[83000:15642817] 10:17:21.717         sip_endpoint.c  .Module "mod-evsub" registered

2023-04-24 10:17:21.717645+0700 PSUAKitSample[83000:15642975] 💚 DEBUG   10:17:21.718 [SIPSample void logCallBack(int, const char *, int):1034]         sip_endpoint.c  .Module "mod-evsub" registered
2023-04-24 10:17:21.717710+0700 PSUAKitSample[83000:15642817] 10:17:21.717         sip_endpoint.c  .Module "mod-presence" registered


  


• How do you use Node.js to stream an MP4 file with ffmpeg?

  27 April 2023, by LaserJesus

  I've been trying to solve this problem for several days now and would really appreciate any help on the subject.

  



  I'm able to successfully stream an mp4 audio file stored on a Node.js server using fluent-ffmpeg by passing the location of the file as a string and transcoding it to mp3. If I create a file stream from the same file and pass that to fluent-ffmpeg instead it works for an mp3 input file, but not a mp4 file. In the case of the mp4 file no error is thrown and it claims the stream completed successfully, but nothing is playing in the browser. I'm guessing this has to do with the meta data being stored at the end of an mp4 file, but I don't know how to code around this. This is the exact same file that works correctly when it's location is passed to ffmpeg, rather than the stream. When I try and pass a stream to the mp4 file on s3, again no error is thrown, but nothing streams to the browser. This isn't surprising as ffmpeg won't work with the file locally as stream, so expecting it to handle the stream from s3 is wishful thinking.

  



  How can I stream the mp4 file from s3, without storing it locally as a file first? How do I get ffmpeg to do this without transcoding the file too? The following is the code I have at the moment which isn't working. Note that it attempts to pass the s3 file as a stream to ffmpeg and it's also transcoding it into an mp3, which I'd prefer not to do.

  



  .get(function(req,res) {
    aws.s3(s3Bucket).getFile(s3Path, function (err, result) {
        if (err) {
            return next(err);
        }
        var proc = new ffmpeg(result)
            .withAudioCodec('libmp3lame')
            .format('mp3')
            .on('error', function (err, stdout, stderr) {
                console.log('an error happened: ' + err.message);
                console.log('ffmpeg stdout: ' + stdout);
                console.log('ffmpeg stderr: ' + stderr);
            })
            .on('end', function () {
                console.log('Processing finished !');
            })
            .on('progress', function (progress) {
                console.log('Processing: ' + progress.percent + '% done');
            })
            .pipe(res, {end: true});
    });
});


  



  This is using the knox library when it calls aws.s3... I've also tried writing it using the standard aws sdk for Node.js, as shown below, but I get the same outcome as above.

  



  var AWS = require('aws-sdk');

var s3 = new AWS.S3({
    accessKeyId: process.env.AWS_ACCESS_KEY_ID,
    secretAccessKey: process.env.AWS_SECRET_KEY,
    region: process.env.AWS_REGION_ID
});
var fileStream = s3.getObject({
        Bucket: s3Bucket,
        Key: s3Key
    }).createReadStream();
var proc = new ffmpeg(fileStream)
    .withAudioCodec('libmp3lame')
    .format('mp3')
    .on('error', function (err, stdout, stderr) {
        console.log('an error happened: ' + err.message);
        console.log('ffmpeg stdout: ' + stdout);
        console.log('ffmpeg stderr: ' + stderr);
    })
    .on('end', function () {
        console.log('Processing finished !');
    })
    .on('progress', function (progress) {
        console.log('Processing: ' + progress.percent + '% done');
    })
    .pipe(res, {end: true});


  



  =====================================

  



  Updated

  



  I placed an mp3 file in the same s3 bucket and the code I have here worked and was able to stream the file through to the browser without storing a local copy. So the streaming issues I face have something to do with the mp4/aac container/encoder format.

  



  I'm still interested in a way to bring the m4a file down from s3 to the Node.js server in it's entirety, then pass it to ffmpeg for streaming without actually storing the file in the local file system.

  



  =====================================

  



  Updated Again

  



  I've managed to get the server streaming the file, as mp4, straight to the browser. This half answers my original question. My only issue now is that I have to download the file to a local store first, before I can stream it. I'd still like to find a way to stream from s3 without needing the temporary file.

  



  aws.s3(s3Bucket).getFile(s3Path, function(err, result){
    result.pipe(fs.createWriteStream(file_location));
    result.on('end', function() {
        console.log('File Downloaded!');
        var proc = new ffmpeg(file_location)
            .outputOptions(['-movflags isml+frag_keyframe'])
            .toFormat('mp4')
            .withAudioCodec('copy')
            .seekInput(offset)
            .on('error', function(err,stdout,stderr) {
                console.log('an error happened: ' + err.message);
                console.log('ffmpeg stdout: ' + stdout);
                console.log('ffmpeg stderr: ' + stderr);
            })
            .on('end', function() {
                console.log('Processing finished !');
            })
            .on('progress', function(progress) {
                console.log('Processing: ' + progress.percent + '% done');
            })
            .pipe(res, {end: true});
    });
});


  



  On the receiving side I just have the following javascript in an empty html page:

  



  window.AudioContext = window.AudioContext || window.webkitAudioContext;
context = new AudioContext();

function process(Data) {
    source = context.createBufferSource(); // Create Sound Source
    context.decodeAudioData(Data, function(buffer){
        source.buffer = buffer;
        source.connect(context.destination);
        source.start(context.currentTime);
    });
};

function loadSound() {
    var request = new XMLHttpRequest();
    request.open("GET", "/stream/", true);
    request.responseType = "arraybuffer";

    request.onload = function() {
        var Data = request.response;
        process(Data);
    };

    request.send();
};

loadSound()


  



  =====================================

  



  The Answer

  



  The code above under the title 'updated again' will stream an mp4 file, from s3, via a Node.js server to a browser without using flash. It does require that the file be stored temporarily on the Node.js server so that the meta data in the file is moved from the end of the file to the front. In order to stream without storing the temporary file, you need to actual modify the file on S3 first and make this meta data change. If you have changed the file in this way on S3 then you can modify the code under the title 'updated again' so that the result from S3 is piped straight into the ffmpeg constructor, rather than into a file stream on the Node.js server, then providing that file location to ffmepg, as the code does now. You can change the final 'pipe' command to 'save(location)' to get a version of the mp4 file locally with the meta data moved to the front. You can then upload that new version of the file to S3 and try out the end to end streaming. Personally I'm now going to create a task that modifies the files in this way as they are uploaded to s3 in the first place. This allows me to record and stream in mp4 without transcoding or storing a temp file on the Node.js server.

  


• Playing With Emscripten and ASM.js

  1 March 2014, by Multimedia Mike — General

  The last 5 years or so have provided a tremendous amount of hype about the capabilities of JavaScript. I think it really kicked off when Google announced their Chrome web browser in September, 2008 along with its V8 JS engine. This seemed to spark an arms race in JS engine performance along with much hyperbole that eventually all software could, would, and/or should be written in straight JavaScript for maximum portability and future-proofing, perhaps aided by Emscripten, a tool which magically transforms C and C++ code into JS. The latest round of rhetoric comes courtesy of something called asm.js which purports to narrow the gap between JS and native code performance.

  I haven’t been a believer, to express it charitably. But I wanted to be certain, so I set out to devise my own experiment to test modern JS performance.

  Up Front Summary
  I was extremely surprised that my experiment demonstrated JS performance FAR beyond my expectations. There might be something to these claims of magnficent JS speed in numerical applications. Basically, here were my thoughts during the process:

  • There’s no way that JavaScript can come anywhere close to C performance for a numerically intensive operation; a simple experiment should demonstrate this.
  • Here’s a straightforward C program to perform a simple yet numerically intensive operation.
  • Let’s compile the C program on gcc and get some baseline performance numbers.
  • Let’s use Emscripten to convert the C program to JavaScript and run it under Chrome.
  • Ha! Pitiful JS performance, just as I expected!
  • Try the same program under Firefox, since Firefox is supposed to have some crazy optimization for asm.js code, allegedly emitted by Emscripten.
  • LOL! Firefox performs even worse than Chrome!
  • Wait a minute… the Emscripten documentation mentioned using optimization levels for generating higher performance JS, so try ‘-O1′.
  • Umm… wow: Chrome’s performance increased dramatically! What about Firefox? Not only is Firefox faster than Chrome, it’s faster than the gcc-generated code!
  • As my faith in C is suddenly shaken to its core, I remembered to compile the gcc version with an explicit optimization level. The native C version pulled ahead of Firefox again, but the Firefox code is still close.
  • Aha! This is just desktop– but what about mobile? One of the leading arguments for converting everything to pure JavaScript is that such programs will magically run perfectly in mobile browsers. So I wager that this is where the experiment will fall over.
  • I proceed to try the same converted program on a variety of mobile platforms.
  • The mobile platforms perform rather admirably as well.
  • I am surprised.

  The Experiment
  I wanted to run a simple yet numerically-intensive and relevant benchmark, and something I am familiar with. I settled on JPEG image decoding. Again, I wanted to keep this simple, ideally in a single file because I didn’t know how hard it might be to deal with Emscripten. I found NanoJPEG, which is a straightforward JPEG decoder contained in a single C file.
  

  I altered nanojpeg.c (to a new file called nanojpeg-static.c) such that the main() program would always load a 1920×1080 (a.k.a. 1080p) JPEG file (“bbb-1080p-title.jpg”, the Big Buck Bunny title), rather than requiring a command line argument. Then I used gettimeofday() to profile the core decoding function (njDecode()).

  Compiling with gcc and profiling execution:

  gcc -Wall nanojpeg-static.c -o nanojpeg-static
  ./nanojpeg-static
  

  Optimization levels such as -O0, -O3, or -Os can be applied to the compilation command.

  For JavaScript conversion, I installed Emscripten and converted using:

  /path/to/emscripten/emcc nanojpeg-static.c -o nanojpeg.html \
    —preload-file bbb-1080p-title.jpg -s TOTAL_MEMORY=32000000
  

  The ‘–preload-file’ option makes the file available to the program via standard C-style file I/O functions. The ‘-s TOTAL_MEMORY’ was necessary because the default of 16 MB wasn’t enough. Again, the -O optimization levels can be sent in.

  For running, the .html file is loaded (via webserver) in a web browser.

  Want To Try It Yourself?
  I put the files here: http://multimedia.cx/emscripten/. The .c file, the JPEG file, and the Emscripten-converted files using -O0, -O1, -O2, -O3, -Os, and no optimization switch.

  Results and Charts
  Here is the spreadsheet with the raw results.

  I ran this experiment using Ubuntu Linux 12.04 on an Intel Atom N450-based netbook. For this part, I was able to compare the Chrome and Firefox browser results against the C results:

  
  
  

  These are the results for a 2nd generation Android Nexus 7 using both Chrome and Firefox:

  
  
  

  Here is the result for an iPad 2 running iOS 7 and Safari– there is no Firefox for iOS and while there is a version of Chrome for iOS, it apparently isn’t able to leverage an optimized JS engine. Chrome takes so long to complete this experiment that there’s no reason to muddy the graph with the results:
  

  
  
  

  Interesting that -O1 tends to provide better optimization than levels 2 or 3, and that -Os (optimize for size) seems to be a good all-around choice.

  Don’t Get Too Smug
  JavaScript can indeed get amazing performance in this day and age. Please be advised, however, that this isn’t the best that a C decoder implementation can possibly do. This version doesn’t leverage any SIMD extensions. According to profiling (using gprof against the C code), sample saturation in color conversion dominates followed by inverse DCT functions, common cases for SIMD ASM or intrinsics. Allegedly, there will be some support for JS SIMD optimizations some day. We’ll see.

  Implications For Development
  I’m still not especially motivated to try porting the entire Native Client game music player codebase to JavaScript. I’m still wondering about the recommended development flow. How are you supposed to develop for Emscripten and asm.js? From what I can tell, Emscripten is not designed as a simple aide for porting C/C++ code to JS. No, it reduces the code into JS code you can’t possibly maintain. This seems to imply that the C/C++ code needs to be developed and debugged in its entirety and then converted to JS, which seems arduous.