Recherche avancée

Sur d’autres sites (11577)

• Use deck.js as a remote presentation tool

  8 janvier 2014, par silvia

  deck.js is one of the new HTML5-based presentation tools. It’s simple to use, in particular for your basic, every-day presentation needs. You can also create more complex slides with animations etc. if you know your HTML and CSS.

  Yesterday at linux.conf.au (LCA), I gave a presentation using deck.js. But I didn’t give it from the lectern in the room in Perth where LCA is being held – instead I gave it from the comfort of my home office at the other end of the country.

  I used my laptop with in-built webcam and my Chrome browser to give this presentation. Beforehand, I had uploaded the presentation to a Web server and shared the link with the organiser of my speaker track, who was on site in Perth and had set up his laptop in the same fashion as myself. His screen was projecting the Chrome tab in which my slides were loaded and he had hooked up the audio output of his laptop to the room speaker system. His camera was pointed at the audience so I could see their reaction.

  I loaded a slide master URL :
  http://html5videoguide.net/presentations/lca_2014_webrtc/?master
  and the room loaded the URL without query string :
  http://html5videoguide.net/presentations/lca_2014_webrtc/.

  Then I gave my talk exactly as I would if I was in the same room. Yes, it felt exactly as though I was there, including nervousness and audience feedback.

  How did we do that ? WebRTC (Web Real-time Communication) to the rescue, of course !

  We used one of the modules of the rtc.io project called rtc-glue to add the video conferencing functionality and the slide navigation to deck.js. It was actually really really simple !

  Here are the few things we added to deck.js to make it work :

  • Code added to index.html to make the video connection work :

    <meta name="rtc-signalhost" content="http://rtc.io/switchboard/">
    
    <meta name="rtc-room" content="lca2014">
    
    ...
    
    <video id="localV" rtc-capture="camera" muted></video>
    
    <video id="peerV" rtc-peer rtc-stream="localV"></video>
    
    ...
    
    <script src="glue.js"></script>
    
    <script>
    
    glue.config.iceServers = [{ url: 'stun:stun.l.google.com:19302' }];
    
    </script>

    The iceServers config is required to punch through firewalls – you may also need a TURN server. Note that you need a signalling server – in our case we used http://rtc.io/switchboard/, which runs the code from rtc-switchboard.

  • Added glue.js library to deck.js :

    Downloaded from https://raw.github.com/rtc-io/rtc-glue/master/dist/glue.js into the source directory of deck.js.

  • Code added to index.html to synchronize slide navigation :

    glue.events.once('connected', function(signaller) {
    
      if (location.search.slice(1) !== '') {
    
        $(document).bind('deck.change', function(evt, from, to) {
    
          signaller.send('/slide', {
    
            idx: to,
    
            sender: signaller.id
    
          });
    
        });
    
      }
    
      signaller.on('slide', function(data) {
    
        console.log('received notification to change to slide: ', data.idx);
    
        $.deck('go', data.idx);
    
      });
    
    });

    This simply registers a callback on the slide master end to send a slide position message to the room end, and a callback on the room end that initiates the slide navigation.

  And that’s it !

  You can find my slide deck on GitHub.

  Feel free to write your own slides in this manner – I would love to have more users of this approach. It should also be fairly simple to extend this to share pointer positions, so you can actually use the mouse pointer to point to things on your slides remotely. Would love to hear your experiences !

  Note that the slides are actually a talk about the rtc.io project, so if you want to find out more about these modules and what other things you can do, read the slide deck or watch the talk when it has been published by LCA.

  Many thanks to Damon Oehlman for his help in getting this working.

  BTW : somebody should really fix that print style sheet for deck.js – I’m only ever getting the one slide that is currently showing.

• ffmpeg-normalize exits with OSError : [WinError 193] %1 is not a valid Win32 application

  1er septembre 2021, par Moldy1

  I have a large number of files I want to normalize the volume with a simple method using a basic loop.

  


  When trying to use ffmpeg-normalize the application exits with the error. I searched the error on-line but I can't find any issue similar to mine. I thought it may be a 'path' or file type association problem but they look ok.

  


  Can anyone give me an explanation for this error and a possible fix for it please ?

  


  D:\Test>ffmpeg-normalize.exe in.mkv -o out.mkv&#xA;Traceback (most recent call last):&#xA;  File "c:\users\les\appdata\local\programs\python\python39\lib\runpy.py", line 197, in _run_module_as_main&#xA;    return _run_code(code, main_globals, None,&#xA;  File "c:\users\les\appdata\local\programs\python\python39\lib\runpy.py", line 87, in _run_code&#xA;    exec(code, run_globals)&#xA;  File "C:\Users\Les\AppData\Local\Programs\Python\Python39\Scripts\ffmpeg-normalize.exe\__main__.py", line 7, in <module>&#xA;  File "c:\users\les\appdata\local\programs\python\python39\lib\site-packages\ffmpeg_normalize\__main__.py", line 409, in main&#xA;    ffmpeg_normalize = FFmpegNormalize(&#xA;  File "c:\users\les\appdata\local\programs\python\python39\lib\site-packages\ffmpeg_normalize\_ffmpeg_normalize.py", line 68, in __init__&#xA;    self.has_loudnorm_capabilities = ffmpeg_has_loudnorm()&#xA;  File "c:\users\les\appdata\local\programs\python\python39\lib\site-packages\ffmpeg_normalize\_cmd_utils.py", line 185, in ffmpeg_has_loudnorm&#xA;    cmd_runner.run_command()&#xA;  File "c:\users\les\appdata\local\programs\python\python39\lib\site-packages\ffmpeg_normalize\_cmd_utils.py", line 101, in run_command&#xA;    p = subprocess.Popen(&#xA;  File "c:\users\les\appdata\local\programs\python\python39\lib\subprocess.py", line 947, in __init__&#xA;    self._execute_child(args, executable, preexec_fn, close_fds,&#xA;  File "c:\users\les\appdata\local\programs\python\python39\lib\subprocess.py", line 1416, in _execute_child&#xA;    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,&#xA;OSError: [WinError 193] %1 is not a valid Win32 application&#xA;&#xA;D:\Test>path&#xA;PATH=C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Calibre2\;C:\Program Files (x86)\Calibre2\;C:\Users\Les\AppData\Local\Programs\Python\Python39\Scripts\;C:\Users\Les\AppData\Local\Programs\Python\Python39\;C:\Users\Les\AppData\Local\Microsoft\WindowsApps;D:\MABS\local64\bin-video;C:\Program Files (x86)\sox-14-4-2&#xA;&#xA;D:\Test>ftype python.file&#xA;python.file="C:\Users\Les\AppData\Local\Programs\Python\Python39\python.exe" "%1"&#xA;&#xA;D:\Test>python.exe&#xA;Python 3.9.1 (tags/v3.9.1:1e5d33e, Dec  7 2020, 17:08:21) [MSC v.1927 64 bit (AMD64)] on win32&#xA;&#xA;ffmpeg -version&#xA;ffmpeg version N-100483-g728b83a7c4-gd67c6c7f6f&#x2B;4 Copyright (c) 2000-2020 the FFmpeg developers&#xA;built with gcc 10.2.0 (Rev6, Built by MSYS2 project)&#xA;&#xA;&#xA;&#xA; D:\Test>ffmpeg-normalize --version&#xA;        ffmpeg-normalize v1.22.1&#xA;</module>

  


• strange artifacts in image - where does a frame start ?

  26 mai 2017, par user3387542

  We are live broadcasting a webcam stream. No audio, video only. The current command that works great :

  # Direct replay works well:
  
  ffmpeg -f video4linux2 -r 10 -s 1280x720 -i /dev/video0 -c:v rawvideo -f rawvideo -pix_fmt yuv420p - | \
  
   ffplay -f rawvideo -pixel_format yuv420p -video_size 1280x720 -framerate 10 -

  but as soon as we try to send this data over the network (udp broadcast / gigabit lan) we are getting strange artefacts into the image.

  # server command:
  
  ffmpeg -f video4linux2 -r 10 -s 1280x720 -i /dev/video0 -c:v rawvideo -f rawvideo -pix_fmt yuv420p - | \
  
  socat - UDP-DATAGRAM:10.0.0.255:12345,broadcast
  
  
  
  # client command:
  
  socat -u udp-recv:12345,reuseaddr - | \
  
  ffplay -f rawvideo -pixel_format yuv420p -video_size 1280x720 -framerate 10 -

  Where do these artifacts come from and how to get rid of them ? Does this has something to do with the client not knowing where a certain video frame starts ?

  We have chosen to stream raw video to reduce latency. The final goal would be to apply opencv tools to the video and react live depending on the situation. Which works great, as long as the camera is plugged in directly into this computer. But we need to set it apart and need multiple clients.

  

  The camera used is a Microsoft® LifeCam Studio(TM).

  $ v4l2-ctl -d 0 --list-formats
  
  ioctl: VIDIOC_ENUM_FMT
  
  Index       : 0
  
  Type        : Video Capture
  
  Pixel Format: 'YUYV'
  
  Name        : YUYV 4:2:2
  
  
  
  Index       : 1
  
  Type        : Video Capture
  
  Pixel Format: 'MJPG' (compressed)
  
  Name        : Motion-JPEG
  
  
  
  Index       : 2
  
  Type        : Video Capture
  
  Pixel Format: 'M420'
  
  Name        : YUV 4:2:0 (M420)

  Update

  To narrow down the issue, I tried to split it up into different tasks :

  1.0. Writing the stream to a file :

  ffmpeg -f video4linux2 -r 10 -s 1280x720 -i /dev/video0 -c:v rawvideo -f rawvideo -pix_fmt yuv420p - > ~/deltemp/rawout

  1.1. Reading the file : The result looks great, no artefacts :

  cat ~/deltemp/rawout | ffplay -f rawvideo -pixel_format yuv420p -video_size 1280x720 -framerate 10 -

  2.0 Starting the stream and broadcasting the stream as mentioned in the server command above

  2.1 Writing the UDP stream to a file. And watching the file (artifacts are back again)

  socat -u udp-recv:12345,reuseaddr - > ~/deltemp/rawout
  
  cat ~/deltemp/rawout | ffplay -f rawvideo -pixel_format yuv420p -video_size 1280x720 -framerate 10 -

  As test 1 showed no artifacts and test 2 did, it must be something with udp packet loss.

  Test 3 : Reducing quality to 640x480 did not help either.