Recherche avancée

Sur d’autres sites (14493)

• Compressing videos from a smartphone

  21 septembre 2019, par fejesjoco

  I have a Nexus 6p with the stock camera. It’s set to record at 1080p, 30fps. Here’s a 5 second sample (11 MB).

  Videos from this phone come out at about 17 Mbps on average. I tried to compress it with ffmpeg with -c:v libx264 -crf 23 -preset veryslow, the result comes out at about 5.5 MB, which is about 9 Mbps.

  I think this bitrate is a bit too much. When I look at torrent file listings, I can see high quality videos at 3 GB in size on average, and if such a movie is 90 minutes long on average, that is about 4-5 Mbps which sounds okay.

  I’m wondering, why the big difference ? I can notice that my video is noisy/grainy (which is expected from a phone), and that might reduce compressibility. I tried a few ffmpeg filters, like hqdn3d and atadenoise, but the noise mostly remained (maybe I didn’t play with it enough). Then I figured, the video is also shaky (which is also expected), and that might reduce compressibility too (and even makes temporal noise filtering less effective). I tried to stabilize it with the deshake filter, but that didn’t help either.

  I know I could just limit the bandwidth to whatever I like, but there must be a reason why ffmpeg thinks it needs a high bandwidth to maintain a certain quality, and a lower bandwidth would just decrease the quality.

  Why do these videos have such a high bitrate ? What’s the best way to compress them more while keeping or even increasing their quality ?

• Revision 7eca086707 : Add segmentation map array for current and last frame segmentation. The origina

  17 juillet 2014, par hkuang

  Changed Paths :
   Modify /vp9/common/vp9_alloccommon.c

  
   Modify /vp9/common/vp9_alloccommon.h

  
   Modify /vp9/common/vp9_entropymode.c

  
   Modify /vp9/common/vp9_onyxc_int.h

  
   Modify /vp9/decoder/vp9_decodemv.c

  
   Modify /vp9/decoder/vp9_decoder.c

  
  
  Add segmentation map array for current and last frame segmentation.

  The original implementation only allocates one segmentation map and this
  works fine for serial decode. But for frame parallel decode, each thread
  need to have its own segmentation map and the last frame segmentation map
  should be provided from last frame decoding thread.

  After finishing decoding a frame, thread need to serve the old segmentation
  map that associate with the previous decoded frame. The thread also need to
  use another segmentation map for decoding the current frame.

  Change-Id : I442ddff36b5de9cb8a7eb59e225744c78f4492d8

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