Recherche avancée

Sur d’autres sites (6646)

• aacenc_pred : rework the way prediction is done

  29 août 2015, par Rostislav Pehlivanov

  aacenc_pred : rework the way prediction is done
  This commit completely alters the algorithm of prediction.
  
  The original commit which introduced prediction was completely
  
  incorrect to even remotely care about what the actual coefficients
  
  contain or whether any options were enabled. Not my actual fault.
  This commit treats prediction the way the decoder does and expects
  
  to do : like lossy encryption. Everything related to prediction now
  
  happens at the very end but just before quantization and encoding
  
  of coefficients. On the decoder side, prediction happens before
  
  anything has had a chance to even access the coefficients.
  Also the original implementation had problems because it actually
  
  touched the band_type of special bands which already had their
  
  scalefactor indices marked and it’s a wonder the asserion wasn’t
  
  triggered when transmitting those.
  Overall, this now drastically increases audio quality and you should
  
  think about enabling it if you don’t plan on playing anything encoded
  
  on really old low power ultra-embedded devices since they might not
  
  support decoding of prediction or AAC-Main. Though the specifications
  
  were written ages ago and as times change so do the FLOPS.
  Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  

  • [DH] libavcodec/aac.h
  • [DH] libavcodec/aaccoder.c
  • [DH] libavcodec/aacenc.c
  • [DH] libavcodec/aacenc.h
  • [DH] libavcodec/aacenc_pred.c
  • [DH] libavcodec/aacenc_pred.h

• avconv / ffmpeg webcam capture while using minimum CPU processing

  10 septembre 2015, par user3585723

  I have a question about avconv (or ffmpeg) usage.

  My goal is to capture video from a webcam and saving it to a file.
  Also, I don’t want to use too much CPU processing. (I don’t want avconv to scale or re-encode the stream)

  So, I was thinking to use the compressed mjpeg video stream from the webcam and directly saving it to a file.

  My webcam is a Microsoft LifeCam HD 3000 and its capabilities are :

  ffmpeg -f v4l2 -list_formats all -i /dev/video0
  
  
  
  Raw: yuyv422 : YUV 4:2:2 (YUYV) : 640x480 1280x720 960x544 800x448 640x360 424x240 352x288 320x240 800x600 176x144 160x120 1280x800
  
  
  
  Compressed: mjpeg : MJPEG : 640x480 1280x720 960x544 800x448 640x360 800x600 416x240 352x288 176x144 320x240 160x120

  What would be the avconv command to save the Compressed stream directly without having avconv doing scaling or re-encoding.

  For now, I am using this command :

  avconv -f video4linux2 -r 30 -s 320x240 -i /dev/video0 test.avi

  I’m not sure that this command is CPU efficient since I don’t tell anywhere to use the mjpeg Compressed capability of the webcam.

  Is avconv taking care of the configuration of the webcam setting before starting to record the file ? Is it always working of raw stream and doing scaling and enconding on the raw stream ?

  Thanks for your answer

• Registration free (sxs) COM DirectShow filter

  21 septembre 2015, par caesay

  There are questions asking on how to get Registration free COM working, and this is not one of those. I have a DirectShow video source filter (catagory 860BB310-5D01-11d0-BD3B-00A0C911CE86) implemented in .Net with the help of an edited version of the code available here : Pure .Net DirectShow Filters by Maxim Kartavenkov.

  I need to get ffmpeg to recognize my .Net DirectShow filter as a video source using Registration Free COM (Side by Side / sxs). Built into the .Net framework is support for COM component servers, so theoretically as long as the manifests are correct, ffmpeg should detect the filters.

  Here is a snippet of the relevant sections of my manifest files currently.

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  
  <assembly manifestversion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  
  <assemblyidentity version="1.0.0.0" type="win32" processorarchitecture="*"></assemblyidentity>
  
  <dependency>
  
   <dependentassembly>
  
    <assemblyidentity version="1.0.0.0" publickeytoken="26A05D7C90FBA3E8"></assemblyidentity>
  
   </dependentassembly>
  
  </dependency>
  
  </assembly>

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  
  <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestversion="1.0">
  
     <assemblyidentity version="1.0.0.0" publickeytoken="26A05D7C90FBA3E8"></assemblyidentity>
  
     <clrclass clsid="{65722BE6-3449-4628-ABD3-74B6864F9739}" progid="DShowVideoFilter.VideoCaptureFilter" threadingmodel="Both" runtimeversion="v2.0.50727"></clrclass>
  
     <file>
  
     </file>
  
     <file>
  
       <typelib tlbid="{B618E67B-64C8-48E9-9F94-F13214B76808}" version="1.0" helpdir="" flags="hasdiskimage"></typelib>
  
     </file>
  
  </assembly>

  So, I get no errors when running ffmpeg (like you would if there was a manifest error) - and I am confident that everything that is configured correctly (related to traditional sxs com loading), the problem I think (unconfirmed) is that ffmpeg loads DShow filters via DirectShow’s intelligent connect system, which requires the filter and pins to be registered. Here are some documents that talk about how filters need to be registered that I’ve found :

  • #1 Registering DirectShow Filters
  • #2 Implementing DllRegisterServer

  Now, in Maxim Kartavenkov’s DShow base classes, he takes care of #2 automatically. Here is a significantly shortened version of the method that registers the filters implementing BaseFilter.

  [ComRegisterFunction]
  
  public static void RegisterFunction(Type _type)
  
  {
  
      AMovieSetup _setup = (AMovieSetup)Attribute.GetCustomAttribute(_type, typeof(AMovieSetup));
  
      BaseFilter _filter = (BaseFilter)Activator.CreateInstance(_type);
  
      string _name = _filter.Name;
  
      DsGuid _category = new DsGuid(_setup.Category);
  
      IFilterMapper2 _mapper2 = (IFilterMapper2)new FilterMapper2();
  
  
  
      RegFilter2 _reg2 = new RegFilter2();
  
      _reg2.dwVersion = (int)_setup.Version;
  
      _reg2.dwMerit = _setup.FilterMerit;
  
      _reg2.rgPins = IntPtr.Zero;
  
      _reg2.cPins = 0;
  
  
  
      IntPtr _register = Marshal.AllocCoTaskMem(Marshal.SizeOf(_reg2));
  
      Marshal.StructureToPtr(_reg2, _register, true);
  
  
  
      hr = _mapper2.RegisterFilter(_type.GUID, _name, IntPtr.Zero, _category, _instance, _register);
  
  
  
      Marshal.FreeCoTaskMem(_register);
  
  }

  That is the method (particularly mapper2.RegisterFilter) that allows ffmpeg to find the DShow filter when it is registered traditionally (with RegAsm) into the registry, which creates registry keys for the filter and pins as described by #2 link.

  tldr ;
  So the question is, how to emulate the function of RegisterFilter or the intelligent connect registry entries this within a manifest file as to allow the sxs context to find my DirectShow filter when ffmpeg searches for it.