Recherche avancée

Sur d’autres sites (6066)

• vsync flag usage in ffmpeg while filtering

  13 octobre 2022, par antortjim

  I am trying to apply a threshold to an input video with ffmpeg, but I observe the following warning emitted for every processed frame

  


  [mp4 @ 0x56360181a200] Non-monotonous DTS in output stream 0:0; previous: 182272, current: 182272; changing to 182273. This may result in incorrect timestamps in the output file.


  


  where the previous and current are always 1 less than the value to which the DTS (Decoding Time Stamp) is changed

  


  I have noticed this warning is emitted only if I set -vsync passthrough (which I changed from the original -vsync 0 which is seen in many online examples).

  


  # input.mp4 has resolution 790x790
ffmpeg -vsync passthrough  -i input.mp4  -f lavfi -i color=808080:s=790x790 -f lavfi -i color=black:s=790x790 -f lavfi -i color=white:s=790x790 -filter_complex '[0:v][1:v][2:v][3:v]threshold' -an -c:v h264_nvenc threshold.mp4


  


  Shall I leave the vsync flag set to the default (auto or -1), or is -vsync passthrough essential to guarantee the frames are displayed in the right order ? In that case, how do I handle this warning ? Some other online examples I found of users experiencing this warning are different from mine, because in their case they are concatenating videos (see 1, 2

  


  From the documentation on the -vsync flag, at the end, I see :

  


  


  With -map you can select from which stream the timestamps should be taken. You can leave either video or audio unchanged and sync the remaining stream(s) to the unchanged one

  


  


  Maybe this warning should be handled with -map ? But I don't know how.

  


  Sidenote, I keep getting the deprecation warning asserting me to change -vsync for -fps_mode, however doing so breaks the command.

  


  FFPEG Version :

  


  commit 28ac2279adb860ea8b90d3073603912bf3eb6a83 from ffmpeg master branch

  


  ffmpeg version N-108625-g28ac2279ad Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
configuration: --enable-nonfree --enable-cuda-nvcc --enable-libnpp --enable-gpl --extra-cflags=-I/usr/local/cuda/include --extra-ldflags=-L/usr/local/cuda/lib64 --disable-static --enable-shared
libavutil      57. 39.101 / 57. 39.101
libavcodec     59. 50.100 / 59. 50.100
libavformat    59. 34.101 / 59. 34.101
libavdevice    59.  8.101 / 59.  8.101
libavfilter     8. 49.101 /  8. 49.101
libswscale      6.  8.112 /  6.  8.112
libswresample   4.  9.100 /  4.  9.100
libpostproc    56.  7.100 / 56.  7.100


  


  OS

  


  Ubuntu 20.04.4 LTS

  


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

• ffprobe : IGMP membership packet doesn't include source when localaddr is set to the non-default GW interface [closed]

  28 août 2023, par Chu N

  On a Ubuntu 18.04.6 LTS box with 2 interfaces e.g. eno1 (10.1.1.1/24), eno2 (10.2.2.2/24). The default route goes out eno1, however I need to send SSM membership reports via eno2 to join a multicast S,G stream on 232.0.0.5 sourced from 10.5.5.5.

  


  ffprobe version 3.4.11-0ubuntu0.1

  


  When I input the command :
ffprobe udp ://232.0.0.5:8000 ?localaddr=10.2.2.2&sources=10.5.5.5

  


  The outgoing IGMPv3 packet leaves via eno2 but it does NOT include the Source Address in the membership report group record field as observed on Wireshark.

  


  When I input the command to go out via eno1 :
ffprobe udp ://232.0.0.5:8000 ?sources=10.5.5.5
or
ffprobe udp ://232.0.0.5:8000 ?localaddr=10.1.1.1&sources=10.5.5.5

  


  The outgoing IGMPv3 packet leaves via the default GW eno1 and includes the Source Address in the IGMPv3 membership report group record field as observed on Wireshark.

  


  How do I make ffprobe include the Source Address in the IGMPv3 packet when using an interface that's not the default gateway ?

  


  I tried different formats of the UDP URL.
When I put the sources before localaddr(10.2.2.2), the IGMPv3 packet goes out via the default gateway (10.1.1.1).
I tried using a routing-policy on netplan to do some source routing under the eno2 stanza but it didn't work.