Sur d’autres sites (6516)

• ffmpeg hls video recording timing information is inaccurate

  28 juin 2018, par Haris

  I am recording the rtsp stream in HLS format which is working fine with below command.

  ~/bin/ffmpeg -i rtsp://10.0.7.39:554/media/live/1/1 -c:a aac -c:v copy -hls_list_size 65535 -hls_time 2 live.m3u8

  But when I check the duration of each ts file with live.m3u8 file content the value is not accurate.

  Here is the live.m3u8

  #EXTM3U
  
  #EXT-X-VERSION:3
  
  #EXT-X-TARGETDURATION:2
  
  #EXT-X-MEDIA-SEQUENCE:0
  
  #EXTINF:2.000000,
  
  live0.ts
  
  #EXTINF:2.000000,
  
  live1.ts
  
  #EXTINF:1.200000,
  
  live2.ts
  
  #EXTINF:2.500000,
  
  live3.ts
  
  #EXTINF:2.000000,
  
  live4.ts
  
  #EXTINF:2.600000,
  
  live5.ts
  
  #EXTINF:1.700000,
  
  live6.ts
  
  #EXT-X-ENDLIST

  And when I check the timing information of the ts file live2.ts using the command,

    ~/bin/ffprobe -i live2.ts -show_entries format=duration -v quiet -of csv="p=0"

  I am getting the value 2.136000 where as in m3u8 file it is 1.20000.

  I have build the latest FFMPEG based on official guild https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu.

  OS : Ubuntu 12.04

  ffmpeg Version

  $~/bin//ffmpeg -version
  
  
  
  
  
  ffmpeg version N-91369-g4ac88ba Copyright (c) 2000-2018 the FFmpeg developers
  
  built with gcc 4.8 (Ubuntu 4.8.1-2ubuntu1~12.04)
  
  configuration: --prefix=/home/haris/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/haris/ffmpeg_build/include --extra-ldflags=-L/home/haris/ffmpeg_build/lib --extra-libs='-lpthread -lm' --bindir=/home/haris/bin --enable-gpl --enable-libaom --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree
  
  libavutil      56. 18.102 / 56. 18.102
  
  libavcodec     58. 20.104 / 58. 20.104
  
  libavformat    58. 17.101 / 58. 17.101
  
  libavdevice    58.  4.101 / 58.  4.101
  
  libavfilter     7. 25.100 /  7. 25.100
  
  libswscale      5.  2.100 /  5.  2.100
  
  libswresample   3.  2.100 /  3.  2.100
  
  libpostproc    55.  2.100 / 55.  2.100

  Note

  If I tested the same command in Ubuntu 16.04 where ffmpeg installed with apt-get every thing works fine.

  Here is the ffmpeg details

  $ ~/bin/ffmpeg -version
  
  ffmpeg version 2.8.14-0ubuntu0.16.04.1 Copyright (c) 2000-2018 the FFmpeg developers
  
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 20160609
  
  configuration: --prefix=/usr --extra-version=0ubuntu0.16.04.1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv
  
  libavutil      54. 31.100 / 54. 31.100
  
  libavcodec     56. 60.100 / 56. 60.100
  
  libavformat    56. 40.101 / 56. 40.101
  
  libavdevice    56.  4.100 / 56.  4.100
  
  libavfilter     5. 40.101 /  5. 40.101
  
  libavresample   2.  1.  0 /  2.  1.  0
  
  libswscale      3.  1.101 /  3.  1.101
  
  libswresample   1.  2.101 /  1.  2.101
  
  libpostproc    53.  3.100 / 53.  3.100

  What could be the cause, any help will be appreciated.

• ffmpeg hls video recording timing inforamtion is inaccurate

  27 juin 2018, par Haris

  I am recording the rtsp stream in HLS format which is working fine with below command.

  ~/bin/ffmpeg -i rtsp://10.0.7.39:554/media/live/1/1 -c:a aac -c:v copy -hls_list_size 65535 -hls_time 2 live.m3u8

  But when I check the the duration of each ts file with live.m3u8 file content the value is not accurate.

  Here is the live.m3u8

  #EXTM3U
  
  #EXT-X-VERSION:3
  
  #EXT-X-TARGETDURATION:2
  
  #EXT-X-MEDIA-SEQUENCE:0
  
  #EXTINF:2.000000,
  
  live0.ts
  
  #EXTINF:2.000000,
  
  live1.ts
  
  #EXTINF:1.200000,
  
  live2.ts
  
  #EXTINF:2.500000,
  
  live3.ts
  
  #EXTINF:2.000000,
  
  live4.ts
  
  #EXTINF:2.600000,
  
  live5.ts
  
  #EXTINF:1.700000,
  
  live6.ts
  
  #EXT-X-ENDLIST

  And when I check the timing information of the ts file live2.ts using the command,

    ~/bin/ffprobe -i live2.ts -show_entries format=duration -v quiet -of csv="p=0"

  I am getting the value 2.136000 where as in m3u8 file it is 1.20000.

  I have build the latest FFMPEG based on official guild https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu.

  OS : Ubuntu 12.04

  ffmpeg Version

  $~/bin//ffmpeg -version
  
  
  
  
  
  ffmpeg version N-91369-g4ac88ba Copyright (c) 2000-2018 the FFmpeg developers
  
  built with gcc 4.8 (Ubuntu 4.8.1-2ubuntu1~12.04)
  
  configuration: --prefix=/home/haris/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/haris/ffmpeg_build/include --extra-ldflags=-L/home/haris/ffmpeg_build/lib --extra-libs='-lpthread -lm' --bindir=/home/haris/bin --enable-gpl --enable-libaom --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree
  
  libavutil      56. 18.102 / 56. 18.102
  
  libavcodec     58. 20.104 / 58. 20.104
  
  libavformat    58. 17.101 / 58. 17.101
  
  libavdevice    58.  4.101 / 58.  4.101
  
  libavfilter     7. 25.100 /  7. 25.100
  
  libswscale      5.  2.100 /  5.  2.100
  
  libswresample   3.  2.100 /  3.  2.100
  
  libpostproc    55.  2.100 / 55.  2.100

  Note

  If I tested the same command in Ubuntu 16.04 where ffmpeg installed with apt-get every thing works fine.

  Here is the ffmpeg details

  $ ~/bin/ffmpeg -version
  
  ffmpeg version 2.8.14-0ubuntu0.16.04.1 Copyright (c) 2000-2018 the FFmpeg developers
  
  built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 20160609
  
  configuration: --prefix=/usr --extra-version=0ubuntu0.16.04.1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv
  
  libavutil      54. 31.100 / 54. 31.100
  
  libavcodec     56. 60.100 / 56. 60.100
  
  libavformat    56. 40.101 / 56. 40.101
  
  libavdevice    56.  4.100 / 56.  4.100
  
  libavfilter     5. 40.101 /  5. 40.101
  
  libavresample   2.  1.  0 /  2.  1.  0
  
  libswscale      3.  1.101 /  3.  1.101
  
  libswresample   1.  2.101 /  1.  2.101
  
  libpostproc    53.  3.100 / 53.  3.100

  What could be the cause, any help will be appreciated.

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