Advanced search

On other websites (12665)

• "Unsupported huge granule pos -123480" when trying to convert from .opus extracted from Video to .wav using ffmpeg

  19 August 2021, by Scipio

  I have to convert a bunch of .opus files to .wav using ffmpeg. When calling

  



  ffmpeg -i input_file.opus -acodec pcm_s16le -ac 1 -ar 16000 output_file.wav

  



  I get

  



  Unsupported huge granule pos -123480

  



  This does not depend on the specific ffmpeg options. An example .opus file can be found here. The .opus file is a part of a soundstream extracted from a youtube video in .mkv container format with .opus as audio stream with the highest available quality. The corresponding ffmpeg call was

  



  ffmpeg -ss 00:15:00.00 -i input_file.mkv -to 00:15:00.00 -vn -acodec copy output_file.opus

  



  The line raising the original exception is

  



  if (os->granule > (1LL << 62)) 
     {av_log(avf, AV_LOG_ERROR, "Unsupported huge granule pos %"PRId64 "\n", os->granule);
     return AVERROR_INVALIDDATA;
    }

  



  It can be found in lines 121-124 of this file. granule is defined as an uint_64t here.

  



  So, what I figured so far is that a uint probably shouldn't be negative after all. I'm unsure whether the error is occuring during the extraction of the audio but remains unnoticed until trying to convert said audio or if the error is in the actual conversion. I also do not understand what "granule" is supposed to mean in this context, but probably I don't need to.

  


• How to seamlessly concatenate multiple Opus files together without popping sound?

  16 February, by Gurdie Derilus

  I have a large PCM file that I've split into N chunks (N being the # of threads), and I encode them in parallel into Opus files with FFmpeg.

  


  Note: All PCM files are 16-bit Little Endian, 2 channels, 48000 sample rate.

  


  I then concatenate the Opus files using FFmpeg's demuxer, but I can hear an audible pop sound between each segment.

  


  Opening this sample file in Audacity reveals the issue:
Notice the introduced pops in opus

  


  I created a simple and short Golang project on Github with a sample PCM file for easy testing. Note, not production code, so obviously not following any best practices here.

  


  #1, I suspected the pops might've been introduced while parallel encoding each PCM file to Opus files. This, however, wasn't the case.
Concatted Opus files vs Separate Opus files image.

  


  #2, using the concat filter works, however it reencodes the files, which is not doable in my case as it's too slow (these files can & do reach up to an hour). I know Opus files are chainable, so I can't imagine why they don't work flawlessly.

  


  #3, I heard that Opus has a 20ms frame size, so I split the file against that frame size, but this made no difference.

  


  chunkSize := largePcmFileStat.Size() / int64(runtime.GOMAXPROCS(0))
chunkSize = int64(roundUpToNearestMultiple(float64(chunkSize), 4))


  


  The entire sample looks like this:

  


  package main

import (
    "context"
    "fmt"
    "io"
    "log"
    "os"
)

func main() {
    // Grab large PCM file
    largePcmFile, err := os.Open("files/full_raw.pcm")
    if err != nil {
        log.Fatalln(err)
    }

    // Split into 2 chunks
    ByteRate := 2
    SampleRate := 48000
    Channels := 2
    Seconds := 20
    chunkSize := Seconds * Channels * SampleRate * ByteRate

    file1, err := encodePcmToOpus(context.TODO(), io.LimitReader(largePcmFile, int64(chunkSize)))
    if err != nil {
        log.Fatalln(err)
    }

    file2, err := encodePcmToOpus(context.TODO(), io.LimitReader(largePcmFile, int64(chunkSize)))
    if err != nil {
        log.Fatalln(err)
    }

    fmt.Println("Check if these play with no defects:", file1)
    fmt.Println("file1:", file1)
    fmt.Println("file2:", file2)
    fmt.Println()

    concatFile, err := concatOpusFiles(context.TODO(), []string{file1, file2})
    if err != nil {
        log.Fatalln(err)
    }

    fmt.Println("concatted file:", concatFile.Name())
}


  


• movenc: mark Opus encapsulation as stable

  23 March 2020, by Lynne

  movenc: mark Opus encapsulation as stable
  The specifications are de-facto frozen now as they've already been used in
  
  production for years, the author has indicated reluctance on IRC to change
  
  it further, and the only potential changes would, from what I understand,
  
  be forward-compatible.
  

  • [DH] libavformat/movenc.c