Recherche avancée

Sur d’autres sites (9961)

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

• rtsp to rtmp using ffmpeg or any tool wrapper

  27 août 2017, par Chakri

  I have a requirement where I need to restream the RTSP stream from camera source to RTMP server. I know this may sound a repeated question but my exact scenario is I cannot do it manually over command line with ffmpeg command. I need a wrapper where I receive the rtsp and rtmp url from external source say through REST invocation. Then the code can trigger the ffmpeg restream.

  Basically flow is like this :

  1. Camera source application sends RTSP read event(could be basic HTTP(REST) request with RTSP url, metadata about camera info, serial no etc) to my streamer app

  Ex : /usr/bin/ffmpeg -i rtsp ://10.144.11.22:554/stream1 -f flv rtmp ://10.13.11.121:1935/stream1

  2. Streamer app computes the RTMP server url for corresponding camera and triggers a ffmpeg command to stream RTSP to RTMP

  3. Streamer app triggers above(2) in separate thread and keeps reading the logs for monitoring purpose. Also identifies the end of RTSP stream and sends an update(Example : RTSP END) event to UI

  Now at point(2) I need a suggestion. Here I need a stable wrapper/api which can help. I tried this through some Java wrappers but the process hangs or fails to read the output from ffmpeg. Also I need to handle streams from many cameras where spawning thread for each one could be exhaustive.

  So I am looking for some similar api/wrapper in C++ or Go Lang which might have more closer interaction in handling ffmpeg command.

  Please point if similar issue is addressed elsewhere

• Start of video is not labeled as "0" in QuickTime Video from GoPro

  26 mars 2020, par John Terragnoli

  I’m trying to combine four GoPro videos into a single video, and then rotate it 90 degrees. However, the time scales on the bottom of the videos are all wrong. The videos are 17 minutes and 42 second. But the beginning time is labeled as 5:15:20:32 and the ending time is 5:33:01:32. It just looks really weird and I’d like to fix it. After I use ffmpeg to rotate and concatenate the videos, the problem persists. Could it possibly be fixed with Exiftool ?

  ffmpeg -safe 0 -f concat -i list.txt -vcodec copy -acodec copy merged_videos.MP4

  ffmpeg -i input.mov -vf "transpose=1" output.mov

  Here is the exiftool information on one of the videos :

  File Name                       : GOPR3023.MP4
  
  Directory                       : .
  
  File Size                       : 3.7 GB
  
  File Modification Date/Time     : 2018:04:12 14:56:16-05:00
  
  File Access Date/Time           : 2020:03:25 12:17:18-05:00
  
  File Inode Change Date/Time     : 2020:03:25 17:57:04-05:00
  
  File Permissions                : rwxrwxrwx
  
  File Type                       : MP4
  
  File Type Extension             : mp4
  
  MIME Type                       : video/mp4
  
  Major Brand                     : MP4 v1 [ISO 14496-1:ch13]
  
  Minor Version                   : 2013.10.18
  
  Compatible Brands               : mp41
  
  Movie Data Size                 : 4001979951
  
  Movie Data Offset               : 28
  
  Movie Header Version            : 0
  
  Create Date                     : 2018:04:12 14:38:32
  
  Modify Date                     : 2018:04:12 14:38:32
  
  Time Scale                      : 60000
  
  Duration                        : 0:17:42
  
  Preferred Rate                  : 1
  
  Preferred Volume                : 100.00%
  
  Preview Time                    : 0 s
  
  Preview Duration                : 0 s
  
  Poster Time                     : 0 s
  
  Selection Time                  : 0 s
  
  Selection Duration              : 0 s
  
  Current Time                    : 0 s
  
  Next Track ID                   : 6
  
  Firmware Version                : HD5.03.02.51.00
  
  Lens Serial Number              : NAH6092300301117
  
  Camera Serial Number Hash       : 34676f2cdf49b86a1514817a93377bf7
  
  Track Header Version            : 0
  
  Track Create Date               : 2018:04:12 14:38:32
  
  Track Modify Date               : 2018:04:12 14:38:32
  
  Track ID                        : 1
  
  Track Duration                  : 0:17:42
  
  Track Layer                     : 0
  
  Track Volume                    : 0.00%
  
  Image Width                     : 1920
  
  Image Height                    : 1080
  
  Graphics Mode                   : srcCopy
  
  Op Color                        : 0 0 0
  
  Compressor ID                   : avc1
  
  Source Image Width              : 1920
  
  Source Image Height             : 1080
  
  X Resolution                    : 72
  
  Y Resolution                    : 72
  
  Compressor Name                 : GoPro AVC encoder
  
  Bit Depth                       : 24
  
  Color Representation            : nclx 1 1 1
  
  Video Frame Rate                : 59.94
  
  Time Code                       : 3
  
  Balance                         : 0
  
  Audio Format                    : mp4a
  
  Audio Channels                  : 2
  
  Audio Bits Per Sample           : 16
  
  Audio Sample Rate               : 48000
  
  Text Font                       : Unknown (21)
  
  Text Face                       : Plain
  
  Text Size                       : 10
  
  Text Color                      : 0 0 0
  
  Background Color                : 65535 65535 65535
  
  Font Name                       : Helvetica
  
  Other Format                    : tmcd
  
  Warning                         : [minor] The ExtractEmbedded option may find more tags in the movie data
  
  Matrix Structure                : 1 0 0 0 1 0 0 0 1
  
  Media Header Version            : 0
  
  Media Create Date               : 2018:04:12 14:38:32
  
  Media Modify Date               : 2018:04:12 14:38:32
  
  Media Time Scale                : 60000
  
  Media Duration                  : 0:17:42
  
  Handler Class                   : Media Handler
  
  Handler Type                    : NRT Metadata
  
  Handler Description             : GoPro SOS
  
  Gen Media Version               : 0
  
  Gen Flags                       : 0 0 0
  
  Gen Graphics Mode               : srcCopy
  
  Gen Op Color                    : 0 0 0
  
  Gen Balance                     : 0
  
  Meta Format                     : fdsc
  
  Image Size                      : 1920x1080
  
  Megapixels                      : 2.1
  
  Avg Bitrate                     : 30.1 Mbps
  
  Rotation                        : 0

  Part 2
  There is a pretty obvious "stutter" at the 17:42 mark where the two clips are combined. I’ve tried using ffmpeg and iMovie, but both give the same results. The GoPro broke up the event into multiple clips on it’s own so it seems weird that there would be any information missing. Is there any way to get rid of this stutter ?

  Thanks !