Recherche avancée

Sur d’autres sites (7995)

• How to host a react.js ssr on vercel ?

  2 janvier 2024, par UltimateSheepConfusedAtCode

  I want to host a react.js server side rendering because of ffmpeg killing me with SharedArrayBuffer is not defined

  


  I've tried so many hosting service provider like firebase but now I want to host it to Vercel but I don't know how to make it works with react ssr. Can anyone help me ?

  


  When I run 'ssr' command in my machine it's work and ffmpeg is not throwing 'bad memory' or 'SharedArrayBuffer is not defined' but when I run it in vercel build command it stucks but the index.js/server.js is running I know because the main script is running and won't stop so the build is stuck but any solution ? I've search the problem but I guess nobody haven't asked this yet

  


  

  


  and this a code of package.json

  


  {
  "name": "ultimatesheep-vidreverse",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@babel/preset-env": "^7.18.10",
    "@babel/preset-react": "^7.18.6",
    "@babel/register": "^7.18.9",
    "@ffmpeg/core": "^0.11.0",
    "@ffmpeg/ffmpeg": "^0.11.0",
    "@testing-library/jest-dom": "^5.16.5",
    "@testing-library/react": "^13.3.0",
    "@testing-library/user-event": "^13.5.0",
    "bootstrap": "^5.2.0",
    "cors": "^2.8.5",
    "ignore-styles": "^5.0.1",
    "react": "^18.2.0",
    "react-bootstrap": "^2.5.0",
    "react-dom": "^18.2.0",
    "react-scripts": "5.0.1",
    "uuid": "^8.3.2",
    "web-vitals": "^2.1.4"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "ssr": "npm run build && node backend/index.js",
    "deploy": "npm run build && firebase deploy",
    "git" : "git add . && git commit -m 'ahawdaw' && git push -u origin main"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
  "externals": {
    "react": "React"
  },
  "description": "This project was bootstrapped with [Create React App](https://github.com/facebook/create-react-app).",
  "main": "backend/index.js",
  "keywords": [],
  "author": "",
  "license": "ISC"
}


  


  

  


• Dreamcast Archival

  24 mai 2011, par Multimedia Mike — Sega Dreamcast

  Console homebrew communities have always had a precarious relationship with console pirates. The same knowledge and skills useful for creating homebrew programs can usually be parlayed into ripping games and cajoling a console into honoring ripped copies. For this reason, the Dreamcast homebrew community tried hard to distance itself from pirates, rippers, and other unsavory characters.

  
  
  

  Funny how times change. While I toed the same line while I was marginally a part of the community back in the day, now I think I’m performing a service for video game archivists and historians by openly publishing the same information. I know of at least one solution already. But I think it’s possible to do much better.

  Pre-existing Art
  Famed Japanese game hacker BERO (FFmpeg contributors should recognize his name from a number of Dreamcast-related multimedia contributions including CRI ADX and SH-4 optimizations) crafted a program called dreamrip based on KOS’s precursor called libdream. This is the program I used to extract 4XM multimedia files from Alone in the Dark : The New Nightmare.

  Fun facts : The Sega Dreamcast used special optical discs called GD-ROMs. The GD stands for ‘GigaDisc’ which implied that they could hold roughly a gigabyte of data. How long do you think it takes to transfer that much data over a serial cable operating at 115,200 bits/second (on the order of 11 Kbytes/sec) ? I seem to recall entire discs requiring on the order of 27-28 hours to archive.

  If only I possessed some expertise in data compression which might expedite this process.

  KallistiOS’ Unwitting Help
  The KallistiOS (KOS) console-oriented RTOS provides all the software infrastructure necessary for archiving (that’s what we’ll call it in this post) Dreamcast games. KOS exposes the optical disc’s filesystem via the /cd mount point on the VFS. From there, KOS provides functions for communicating with a host computer via ethernet (broadband adapter) or serial line (DC coder’s cable). To this end, KOS exposes another mount point on the VFS named /pc which allows direct access to the host PC’s filesystem.

  Thus, it’s pretty straightforward to use KOS to access the files (or raw sectors) of the Dreamcast disc and then send them over the communication line to the host PC. Simple.

  Compressing Before Transfer
  Right away, I wonder about compiling 3 different compression libraries : libz, libbz2, and liblzma. The latter 2 are exceptionally CPU-intensive to compress. Then again, it doesn’t really matter how long the compressor takes to do its job as long as it can average better than 11 Kbytes/sec on a 200MHz Hitachi SH-4 CPU. KOS can be set up in a preemptive threading mode which means it should be possible to read sectors and compress them while keeping the UART operating at full tilt.

  A 4th compression algorithm should be in play here as well : FLAC. Since some of these discs contain red book CD audio tracks that need archival, lossless audio compression should be useful.

  This post serves as a rough overview for possible future experiments. Readers might have further brainstorms.

• ffmpeg : -copyts makes -t stop at timestamps, not duration

  30 juillet 2017, par arielCo

  From

  -t duration (input/output)

  When used as an input option (before -i), limit the duration of data read from the input file.

  When used as an output option (before an output url), stop writing the output after its duration reaches duration.

  So this should yield a 1-minute file with timestamps starting at 1:49, right ?

  ffmpeg -y -copyts -ss 1:49 -i ~/Videos/input.mkv -c copy -t 1:00 timing-1m49s.mkv 
  
  ffmpeg version 3.3.2 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 7 (SUSE Linux)
  
    configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdir=/usr/include/ffmpeg --extra-cflags='-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -g' --optflags='-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -g' --disable-htmlpages --enable-pic --disable-stripping --enable-shared --disable-static --enable-gpl --disable-openssl --enable-avresample --enable-libcdio --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libcelt --enable-libcdio --enable-libdc1394 --enable-libfreetype --enable-libgsm --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libwebp --enable-netcdf --enable-vaapi --enable-vdpau --enable-libfdk_aac --enable-nonfree --enable-libmp3lame --enable-libtwolame --enable-libx264 --enable-libx265 --enable-libxvid
  
    libavutil      55. 58.100 / 55. 58.100
  
    libavcodec     57. 89.100 / 57. 89.100
  
    libavformat    57. 71.100 / 57. 71.100
  
    libavdevice    57.  6.100 / 57.  6.100
  
    libavfilter     6. 82.100 /  6. 82.100
  
    libavresample   3.  5.  0 /  3.  5.  0
  
    libswscale      4.  6.100 /  4.  6.100
  
    libswresample   2.  7.100 /  2.  7.100
  
    libpostproc    54.  5.100 / 54.  5.100
  
  Input #0, matroska,webm, from '/home/ariel/Videos/input.mkv':
  
    Metadata:
  
      encoder         : libebml v0.7.7 + libmatroska v0.8.0
  
      creation_time   : 2006-07-20T03:07:03.000000Z
  
    Duration: 00:23:57.06, start: 0.000000, bitrate: 1983 kb/s
  
      Stream #0:0: Video: h264 (High), yuv420p(progressive), 720x480, SAR 37:30 DAR 37:20, 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)
  
      Stream #0:1(eng): Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s (default)
  
      Stream #0:2(jpn): Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
  
      Stream #0:3(eng): Subtitle: dvd_subtitle, 720x480 (default)
  
      Metadata:
  
        title           : English Audio
  
      Stream #0:4(eng): Subtitle: dvd_subtitle, 720x480
  
      Metadata:
  
        title           : Japanese Audio
  
  Output #0, matroska, to 'timing-1m49s.mkv':
  
    Metadata:
  
      encoder         : Lavf57.71.100
  
      Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p(progressive), 720x480 [SAR 37:30 DAR 37:20], q=2-31, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
  
      Stream #0:1(eng): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo, fltp, 192 kb/s (default)
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (copy)
  
    Stream #0:1 -> #0:1 (copy)
  
  Press [q] to stop, [?] for help
  
  frame=    0 fps=0.0 q=-1.0 Lsize=       1kB time=00:00:00.00 bitrate=N/A speed=   0x    
  
  video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

  Wrong. It outputs a file with no frames :

  -rwxrwx--- 1 root users 805 Jul 30 01:36 timing-1m49s.mkv

  I have to specify -t 1:49 or more, and e.g. -t 1:55 produces a 6-second file that starts at 0:00 and according to the metadata should last 1:55.

  I arrived at this point trying to extract a clip and add subtitles in the same command, but this minimal case looks to me contrary to the documentation.