GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Wolf480pl (wolf480pl@mstdn.io)'s status on Tuesday, 27-Aug-2024 18:10:14 JST Wolf480pl Wolf480pl

    I have one opus file, 2 versions of ffmpeg.

    I use each ffmpeg to convert the file to s16le (which I'm assuming is raw PCM audio)

    The results differ.

    why?

    In conversation about 9 months ago from mstdn.io permalink
    • Embed this notice
      iced depresso (icedquinn@blob.cat)'s status on Tuesday, 27-Aug-2024 18:10:14 JST iced depresso iced depresso
      in reply to
      @wolf480pl floating point decoding isn't guaranteed to be bit identical maybe?
      In conversation about 9 months ago permalink
    • Embed this notice
      iced depresso (icedquinn@blob.cat)'s status on Tuesday, 27-Aug-2024 19:02:14 JST iced depresso iced depresso
      in reply to
      • Alexander Monakov
      @amonakov @wolf480pl packet recovery is for live situations, yes. when you are firing packets over UDP and there is no time to otherwise reassemble the data without it being woefully outdated
      In conversation about 9 months ago permalink
    • Embed this notice
      Alexander Monakov (amonakov@mastodon.gamedev.place)'s status on Tuesday, 27-Aug-2024 19:02:15 JST Alexander Monakov Alexander Monakov
      in reply to
      • iced depresso

      @wolf480pl @icedquinn again, on second^2 thought, in case of Youtube that wouldn't make sense, because they are streaming over TLS, which is not lossy. It is for use cases where the protocols are specifically built with dropouts in mind, like videoconferencing.

      In conversation about 9 months ago permalink
    • Embed this notice
      Alexander Monakov (amonakov@mastodon.gamedev.place)'s status on Tuesday, 27-Aug-2024 19:02:16 JST Alexander Monakov Alexander Monakov
      in reply to
      • iced depresso

      @wolf480pl @icedquinn possibly? from the sound of it, the encoder would have to opt-in for that, and I barely know what I'm talking about here.

      In conversation about 9 months ago permalink
    • Embed this notice
      Wolf480pl (wolf480pl@mstdn.io)'s status on Tuesday, 27-Aug-2024 19:02:17 JST Wolf480pl Wolf480pl
      in reply to
      • iced depresso
      • Alexander Monakov

      @amonakov @icedquinn
      streaming over networks?
      like youtube?

      So if you youtube-dl the opus audio from a youtube video without reencoding, it'd have that?

      In conversation about 9 months ago permalink
    • Embed this notice
      Alexander Monakov (amonakov@mastodon.gamedev.place)'s status on Tuesday, 27-Aug-2024 19:02:18 JST Alexander Monakov Alexander Monakov
      in reply to
      • iced depresso

      @wolf480pl @icedquinn hm, but on second thought, that is specifically for streaming over networks, and wouldn't be used in conventional encoding?

      In conversation about 9 months ago permalink
    • Embed this notice
      Alexander Monakov (amonakov@mastodon.gamedev.place)'s status on Tuesday, 27-Aug-2024 19:02:19 JST Alexander Monakov Alexander Monakov
      in reply to
      • iced depresso

      @wolf480pl @icedquinn but even without floating-point, you can get different decodes if your other version of ffmpeg doesn't know about the clever backward-compatible upgrade:

      In conversation about 9 months ago permalink

      Attachments


      1. https://cdn.masto.host/mastodongamedevplace/media_attachments/files/113/033/296/320/035/517/original/0d32dd60ff247a23.png
    • Embed this notice
      Wolf480pl (wolf480pl@mstdn.io)'s status on Tuesday, 27-Aug-2024 19:02:20 JST Wolf480pl Wolf480pl
      in reply to
      • iced depresso

      @icedquinn hmm... do you know if opus uses floats?

      In conversation about 9 months ago permalink
    • Embed this notice
      Alexander Monakov (amonakov@mastodon.gamedev.place)'s status on Tuesday, 27-Aug-2024 19:02:20 JST Alexander Monakov Alexander Monakov
      in reply to
      • iced depresso

      @wolf480pl @icedquinn I can confirm that, both the ffmpeg decoder and reference library use floats; the reference library can be configured to avoid floating-point arithmetic, but that's not the default.

      In conversation about 9 months ago permalink
    • Embed this notice
      iced depresso (icedquinn@blob.cat)'s status on Tuesday, 27-Aug-2024 19:03:23 JST iced depresso iced depresso
      in reply to
      • iced depresso
      • Alexander Monakov
      @amonakov @wolf480pl the secret to modern "low latency" protocols is just that they carry error recovery data. instead of having to renegotiate data they repair it locally. you can get this on just about anything with the right proxy servers (some chinese people were using that to play games around the firewall.)
      In conversation about 9 months ago permalink
    • Embed this notice
      iced depresso (icedquinn@blob.cat)'s status on Tuesday, 27-Aug-2024 19:11:28 JST iced depresso iced depresso
      in reply to
      • Alexander Monakov
      @wolf480pl @amonakov is this all an academic curiosity?

      its a lossy codec so bit identical decoding is a non-goal. you want flac or wavpack for that (lossless but bigger.)
      In conversation about 9 months ago permalink
    • Embed this notice
      Wolf480pl (wolf480pl@mstdn.io)'s status on Tuesday, 27-Aug-2024 19:11:29 JST Wolf480pl Wolf480pl
      in reply to
      • iced depresso
      • Alexander Monakov

      @icedquinn
      > some chinese people were using that to play games around the firewall

      not just chinese people

      also, when reading @amonakov 's screenshot for some reason I didn't notice that "lossy" referred to the network, not to the codec.

      But then, if the extra data is only some form of error-correcting code, why would it affect the decoded stream when I have the complete encoded stream with no holes in it?

      In conversation about 9 months ago permalink
    • Embed this notice
      iced depresso (icedquinn@blob.cat)'s status on Tuesday, 27-Aug-2024 19:12:35 JST iced depresso iced depresso
      in reply to
      • iced depresso
      • Alexander Monakov
      @wolf480pl @amonakov i remember one version of ffmpeg inserted unwanted resampling steps when making flacs. i'm not sure if its doing this to your opus files. but some versions did things like that. or used different dithering when converting bitrates.

      later versions fixed it and stopped resampling to flac but that's one way that non-identical outputs were happening.
      In conversation about 9 months ago permalink
    • Embed this notice
      iced depresso (icedquinn@blob.cat)'s status on Tuesday, 27-Aug-2024 19:27:40 JST iced depresso iced depresso
      in reply to
      • Alexander Monakov
      @wolf480pl @amonakov the lossless codecs are bit-perfect.

      the integer decoders *might* be but i haven't played with those.
      In conversation about 9 months ago permalink
    • Embed this notice
      Wolf480pl (wolf480pl@mstdn.io)'s status on Tuesday, 27-Aug-2024 19:27:41 JST Wolf480pl Wolf480pl
      in reply to
      • iced depresso
      • Alexander Monakov

      @amonakov @icedquinn
      I looked at the opus test vectors, and looks like they don't check it bit-by-bit, instead they use opus_compare, which seems to calculate per-band energy in a sliding window manner, and then compare those with some epsilon or sth...

      In conversation about 9 months ago permalink
    • Embed this notice
      Alexander Monakov (amonakov@mastodon.gamedev.place)'s status on Tuesday, 27-Aug-2024 19:27:43 JST Alexander Monakov Alexander Monakov
      in reply to
      • iced depresso

      @icedquinn @wolf480pl I don't think it's academic, checking decoded data is how you catch unintended bugs; floating-point decoding can be reproducible if you know what you're doing

      In conversation about 9 months ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.