Recherche avancée

Sur d’autres sites (7117)

• Encode Ogg/Opus with very specific structure

  28 septembre 2022, par sonovice

  I have an ogg/opus file with a pretty special structure that I would like to reproduce.

  


  opusinfo returns a few hints of how it was made :

  


  New logical stream (#1, serial: 59d24a85): type opus
Encoded with Lavf56.40.101
User comments section follows...
        encoder=Lavc56.60.100 libopus
        encoder_options=--quiet --bitrate 96 --vbr
        pad=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Opus stream 1:
        Pre-skip: 312
        Playback gain: 0 dB
        Channels: 2
        Original sample rate: 48000Hz
        Packet duration:   60.0ms (max),   56.6ms (avg),   20.0ms (min)
        Page duration:   1460.0ms (max),  323.6ms (avg),  120.0ms (min)
        Total data length: 38872802 bytes (overhead: 1.12%)
        Playback length: 51m:11.473s
        Average bitrate: 101.2 kb/s, w/o overhead: 100.1 kb/s
Logical stream 1 ended


  


  Lavf/Lavc suggests that it was made with FFMPEG, but I am not able to find suitable settings.

  


  Looking at the actual bytes, it starts with an 0x200 (512) byte long ogg page containing metadata, followed by an 0xE00 (3584) byte long ogg page with actual audio content. Both pages sum up exactly to 0x1000 (4096) bytes.


  


  After that, each page is exactly 0x1000 (4096) bytes long with potential zero padding, so that the pages start at offsets 0x1000, 0x2000, 0x3000 etc.


  


  Is there any known tool or library that can produce such ogg/opus files from PCM wave audio ?

  


  (Unfortunately I cannot share the file as it contains proprietary content.)

  


• multiple GPU encoding use FFMPEG under multiple threads environment

  8 septembre 2022, par shenuo

  Here is the application situation.
I want use 4 NV GPUs to carry out some calculation work (CUDA based), and encoding work (FFMPEG &NVEC), it works fine when they are in serial. But when I want them to be parallel. like this

  


  void encodingwork(){
            #pragma omp parallel for num_threads(4)
                for (int i = 0; i < 4; i++) {
                    cudaSetDevice(i);
                    encodingwork();
                }
        }

        int main(){
            thread thd;
            for (int k = 0; k < N; k++) {
#pragma omp parallel for num_threads(4)
                for (int i = 0; i < 4; i++) {
                    cudaSetDevice(i);
                    cudawork();
                }
                if (k != 0)
                    thd.join();
                thd = thread(encodingwork);
            }
            thd.join();
        }


  


  an error will be thrown out from ffmpeg. just like

  


  [AVHWDeviceContext @ 000002334959ac80] cu->cuMemFree((CUdeviceptr)data) failed -> CUDA_ERROR_ILLEGAL_ADDRESS: an illegal memory access was encountered

[hevc_nvenc @ 00000230c956b200] EncodePicture failed!: generic error (20):
Error sending a frame for encoding: -1313558101 (Unknown error occurred)


  


  can anybody tell me what's wrong with this ?

  


• How do I encode a video stream to multiple output formats in parallel with ffmpeg ?

  21 juillet 2022, par rgov

  I would like to use one FFmpeg process to receive video input and then pass that video to multiple separate encoder processes in order to efficiently make use of all available CPU cores.

  


  The FFmpeg wiki article on Creating multiple outputs has this note from @rogerdpack :

  


  


  Outputting and re encoding multiple times in the same FFmpeg process will typically slow down to the "slowest encoder" in your list. Some encoders (like libx264) perform their encoding "threaded and in the background" so they will effectively allow for parallel encodings, however audio encoding may be serial and become the bottleneck, etc. It seems that if you do have any encodings that are serial, it will be treated as "real serial" by FFmpeg and thus your FFmpeg may not use all available cores. One work around to this is to use multiple ffmpeg instances running in parallel, or possible piping from one ffmpeg to another to "do the second encoding" etc. Or if you can avoid the limiting encoder (ex : using a different faster one [ex : raw format] or just doing a raw stream copy) that might help.

  


  


  The article has an example of using a tee pseudo-muxer, but it uses "a single instance of FFmpeg. The example of piping from one instance of FFmpeg to another only allows one encoder process.

  


  A 10-year-old version of the same article mentions using the tee process but it was subsequently deleted :

  


  


  Another option is to output from FFmpeg to "-" then to pipe that to a "tee" command, which can send it to multiple other processes, for instance 2 different other ffmpeg processes for encoding (this may save time, as if you do different encodings, and do the encoding in 2 different simultaneous processes, it might do encoding more in parallel than elsewise). Un benchmarked, however.

  


  


  Along the same lines : Some of the example commands use the mpegts to encapsulate frames before passing them between processes. Is there any constraint that this applies to the codecs or types of metadata that can be sent to downstream processes ?