Recherche avancée

Sur d’autres sites (3511)

• avformat/vobsub : fix several issues.

  29 septembre 2013, par Clément Bœsch

  avformat/vobsub : fix several issues.
  Here is an extract of fate-samples/sub/vobsub.idx, with an additional
  
  text at the end of each line to better identify each bitmap :
      timestamp : 00:04:55:445, filepos : 00001b000 Ace !
  
      timestamp : 00:05:00:049, filepos : 00001b800 Wake up, honey !
  
      timestamp : 00:05:02:018, filepos : 00001c800 I gotta go to work.
  
      timestamp : 00:05:02:035, filepos : 00001d000 < ???>
  
      timestamp : 00:05:04:203, filepos : 00001d800 Look after Clayton, okay ?
  
      timestamp : 00:05:05:947, filepos : 00001e800 I’ll be back tonight.
  
      timestamp : 00:05:07:957, filepos : 00001f800 Bye ! Love you.
  
      timestamp : 00:05:21:295, filepos : 000020800 Hey, Ace ! What’s up ?
  
      timestamp : 00:05:23:356, filepos : 000021800 Hey, how’s it going ?
  
      timestamp : 00:05:24:640, filepos : 000022800 Remember what today is ? The 3rd !
  
      timestamp : 00:05:27:193, filepos : 000023800 Look over there !
  
      timestamp : 00:05:28:369, filepos : 000024800 Where are they going ?
  
      timestamp : 00:05:28:361, filepos : 000025000 < ???>
  
      timestamp : 00:05:29:946, filepos : 000025800 Let’s go see.
  
      timestamp : 00:05:31:230, filepos : 000026000 I can’t, man. I got Clayton.
  Note the two "< ???>" : they are basically split subtitles (with the
  
  previous one), which the dvdsub decoder is now supposed to reconstruct
  
  with a previous commit. But also note that while the first chunk has
  
  increasing timestamps,
      timestamp : 00:05:02:018, filepos : 00001c800
  
      timestamp : 00:05:02:035, filepos : 00001d000
  ...it’s not the case of the second one (and this is not an exception in the
  
  original file) :
      timestamp : 00:05:28:369, filepos : 000024800
  
      timestamp : 00:05:28:361, filepos : 000025000
  For the dvdsub decoder, they need to be "filepos’ed" ordered, but the
  
  FFDemuxSubtitlesQueue is timestamps ordered, which is the reason of the
  
  introduction of a sub sort method in the context, to allow giving
  
  priority to the position, and then the timestamps. With that change, the
  
  dvdsub decoder get fed with ordered packets.
  Now the packet size estimation was also broken : the filepos differences
  
  in the vobsub index defines the full data read between two subtitles
  
  chunks, and it is necessary to take into account what is read by the
  
  mpegps_read_pes_header() function since the length returned by that
  
  function doesn’t count the size of the data it reads. This is fixed with
  
  the introduction of total_read, and old,new_pos. By doing this change,
  
  we can drop the unreliable len16 heuristic and simplify the whole loop.
  
  Note that mpegps_read_pes_header() often read more than one PES packet
  
  (typically in one call it can read 0x1ba and 0x1be chunk along with the
  
  relevant 0x1bd packet), which triggers the "total_read + pkt_size >
  
  psize" check. This is an expected behaviour, which could be avoided by
  
  having a more chunked version of mpegps_read_pes_header().
  The latest change is the extraction of each stream into its own
  
  subtitles queue. If we don’t do this, the maximum size for a subtitle
  
  chunk is broken, and the previous changes can not work. Having each
  
  stream in a different queue requires some little adjustments in the
  
  seek code of the demuxer.
  This commit is only meaningful as a whole change and can not be easily
  
  split. The FATE test changes because it uses the vobsub demuxer.
  

  • [DH] libavformat/mpeg.c
  • [DH] libavformat/subtitles.c
  • [DH] libavformat/subtitles.h
  • [DH] tests/ref/fate/sub2video

• ffmpeg GPU use cuvid with hwdownload will never finished, Appeared only recently

  28 mai 2020, par tags bt

  ffmpeg :

  



  ffmpeg version N-97331-g10a68cc Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)
  configuration: --pkg-config-flags=--static --prefix=/usr/local/ffmpeg --bindir=/usr/local/ffmpeg/bin --extra-cflags='-I /usr/local/ffmpeg/include -I /usr/local/cuda/include/' --extra-ldflags='-L /usr/local/ffmpeg/lib -L /usr/local/cuda/lib64/' --extra-libs=-lpthread --enable-cuda --enable-cuda-nvcc --enable-cuvid --enable-libnpp --enable-gpl --enable-libass --enable-libfdk-aac --enable-vaapi --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree --enable-libaom --enable-nvenc


  



  nvidia-msi

  



  +-----------------------------------------------------------------------------+
| NVIDIA-SMI 440.82       Driver Version: 440.82       CUDA Version: 10.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1080    Off  | 00000000:02:00.0 Off |                  N/A |
|  0%   51C    P8    13W / 200W |     18MiB /  8119MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0     23224      C   ffmpeg                                         8MiB |
+-----------------------------------------------------------------------------+



  



  if i use this command :

  



  ffmpeg -re -threads 0 -loglevel debug -hwaccel cuvid -hwaccel_output_format cuda -i 1.mp4 -c:v h264_nvenc -c:a aac -ac 2 -b:a 128k -strict -2 -filter_complex "[0:v]scale_npp=1280:-2" ouzz2t.mp4


  



  it will very fast.

  



  but if i use this command :

  



  ffmpeg -re -threads 0 -loglevel debug -vsync 0 -hwaccel cuvid -hwaccel_output_format cuda -hwaccel_device intel -i 1.mp4 -c:v h264_nvenc -c:a aac -ac 2 -b:a 128k -strict -2 -filter_complex "[0:v]scale_npp=1280:-2:format=yuv420p[tmp],[tmp]hwdownload,format=yuv420" ouzz2t.mp4


  



  it will never finished, one 40MB mp4 will transcode 44 minutes and not finished.

  



  as you see

  



  +-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0     23224      C   ffmpeg                                         8MiB |
+-----------------------------------------------------------------------------+


  



  it will only use GPU memory 8mib.

  



  and top will show :
enter image description here

  



  delug log :

  



  [AVHWDeviceContext @ 0x561cfaef92c0] Loaded lib: libcuda.so.1
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuInit
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDeviceGetCount
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDeviceGet
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDeviceGetAttribute
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDeviceGetName
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDeviceComputeCapability
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuCtxCreate_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuCtxSetLimit
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuCtxPushCurrent_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuCtxPopCurrent_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuCtxDestroy_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuMemAlloc_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuMemAllocPitch_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuMemsetD8Async
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuMemFree_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuMemcpy2D_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuMemcpy2DAsync_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuGetErrorName
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuGetErrorString
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuCtxGetDevice
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDevicePrimaryCtxRetain
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDevicePrimaryCtxRelease
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDevicePrimaryCtxSetFlags
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDevicePrimaryCtxGetState
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDevicePrimaryCtxReset
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuStreamCreate
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuStreamQuery
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuStreamSynchronize
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuStreamDestroy_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuStreamAddCallback
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuEventCreate
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuEventDestroy_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuEventSynchronize
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuEventQuery
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuEventRecord
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuLaunchKernel
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuModuleLoadData
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuModuleUnload
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuModuleGetFunction
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuTexObjectCreate
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuTexObjectDestroy
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuGLGetDevices_v2
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuGraphicsGLRegisterImage
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuGraphicsUnregisterResource
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuGraphicsMapResources
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuGraphicsUnmapResources
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuGraphicsSubResourceGetMappedArray
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDeviceGetUuid
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuImportExternalMemory
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDestroyExternalMemory
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuExternalMemoryGetMappedBuffer
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuExternalMemoryGetMappedMipmappedArray
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuMipmappedArrayGetLevel
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuMipmappedArrayDestroy
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuImportExternalSemaphore
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuDestroyExternalSemaphore
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuSignalExternalSemaphoresAsync
[AVHWDeviceContext @ 0x561cfaef92c0] Loaded sym: cuWaitExternalSemaphoresAsync



  



  Stop at Loaded sym : cuWaitExternalSemaphoresAsync, and ffmpeg will always 100% cpu and never finished.

  



  Appeared only recently, last week it work fine, but today it work worse.

  



  somebody know what happen to me ?

  


• Solving The XVD Puzzle

  15 avril 2012, par Multimedia Mike — General, multimedi archaeology, silicon valley, vg2, xvd, zygo

  I downloaded a multimedia file a long time ago (at least, I strongly suspected it was a multimedia file which is why I downloaded it). It went by the name of ‘lamborghini_850kbps.vg2′. I have had it in my collection for at least 7 years. I couldn’t remember where I found it. I downloaded it before it occurred to me to take notes about this sort of stuff.

  I found myself staring at the file again today and Googled the filename. This led me to a few Japanese sites which also contained working URLs for a few more .vg2 samples. Some other clues led me to a Russian language forum where someone had linked to a site that had Win32 codec modules that could process the files. The site was defunct but the Internet Archive Wayback Machine kept a copy for me, as well as copies of several more .vg2 samples from a defunct Japanese site previously involved with this codec.

  Sometimes this internet technology works really well. But I digress.

  Anyway, through all this, I finally found a clue : XVD. and wouldn’t you know, there is already a basic page on the MultimediaWiki describing the technology. In fact, while VG2 is a custom container, the MultimediaWiki states that the video component has a FourCC of VGMV, and there is already a file named VGMV.avi in the root V-codecs/ samples directory, something I vow to correct (that’s a big pet peeve of mine– putting samples in the root V-codecs/ or A-codecs/ directories).

  XVD… XVD… XVD… why does that sound so familiar ? Oh, of course ; there is a company named XVD and they have an office in the Bay Area which I have passed on numerous occasions, like this morning :

  
  <

  Someone originally connected with the multimedia technology in question operates a website which contains an unofficial history of the XVD tech. At first, I was wondering if the technology was completely defunct (and should therefore be open sourced). But if XVD’s solutions page (dated 2010) is to be believed, the technology is still in service, and purported to be better than H.264 and VC-1 : “The current generation of XVD video compression technology provides better video quality at any given data rate than standards-based codecs (H.264 or VC-1) with four times lower encoding complexity (when compared with H.264 Main Profile).”

  If they say so. For my part, I’m just happy that I have finally figured out what this lamborghini_850kbps.vg2 is so that I can properly catalog it on the samples site, which I have now done, along with other samples and various codecs modules.

  This episode reminds me that there’s a branch office of Zygo Corporation close to my home (though the headquarters are far, far away). The companies you see in Silicon Valley. Anyway, long-time open source multimedia hackers will no doubt recognize Zygo from the ZyGo FourCC & video codec transported in QuickTime files that was almost decode-able using an H.263 decoder.

  
  
  

  I may never learn what Zygo’s core competency actually is, but I will always remember their multimedia tech every time I run past their office.