Recherche avancée

Sur d’autres sites (18427)

• Revision e0a257868b54b1706bea837651542cd6406c00cb : corrige un bug dans les liens de la forme {{{[->ur’l]}}} (camille) + un ...

  10 août 2010, par Fil — Log

  corrige un bug dans les liens de la forme (camille) + un entites_html() inutile puisque s’appliquant uniquement sur des chiffres (expression \d+ dans la regexp) git-svn-id : svn ://trac.rezo.net/spip/branches/spip-2.1@15912 caf5f3e8-d4fe-0310-bb3e-c32d5e47d55d

• Inside WebM Technology : The VP8 Alternate Reference Frame

  15 juin 2010, par noreply@blogger.com (John Luther) — inside webm, vp8

  Since the WebM project was open-sourced just a week ago, we’ve seen blog posts and articles about its capabilities. As an open project, we welcome technical scrutiny and contributions that improve the codec. We know from our extensive testing that VP8 can match or exceed other leading codecs, but to get the best results, it helps to understand more about how the codec works. In this first of a series of blog posts, I’ll explain some of the fundamental techniques in VP8, along with examples and metrics.

  The alternative reference frame is one of the most exciting quality innovations in VP8. Let’s delve into how VP8 uses these frames to improve prediction and thereby overall video quality.

  Alternate Reference Frames in VP8

  VP8 uses three types of reference frames for inter prediction : the last frame, a "golden" frame (one frame worth of decompressed data from the arbitrarily distant past) and an alternate reference frame. Overall, this design has a much smaller memory footprint on both encoders and decoders than designs with many more reference frames. In video compression, it is very rare for more than three reference frames to provide significant quality benefit, but the undesirable increase in memory footprint from the extra frames is substantial.

  Unlike other types of reference frames used in video compression, which are displayed to the user by the decoder, the VP8 alternate reference frame is decoded normally but is never shown to the user. It is used solely as a reference to improve inter prediction for other coded frames. Because alternate reference frames are not displayed, VP8 encoders can use them to transmit any data that are helpful to compression. For example, a VP8 encoder can construct one alternate reference frame from multiple source frames, or it can create an alternate reference frame using different macroblocks from hundreds of different video frames.

  The current VP8 implementation enables two different types of usage for the alternate reference frame : noise-reduced prediction and past/future directional prediction.

  Noise-Reduced Prediction

  The alternate reference frame is transmitted and decoded similar to other frames, hence its usage does not add extra computation in decoding. The VP8 encoder however is free to use more sophisticated processing to create them in off-line encoding. One application of the alternate reference frame is for noise-reduced prediction. In this application, the VP8 encoder uses multiple input source frames to construct one reference frame through temporal or spatial noise filtering. This "noise-free" alternate reference frame is then used to improve prediction for encoding subsequent frames.

  You can make use of this feature by setting ARNR parameters in VP8 encoding, where ARNR stands for "Alternate Reference Noise Reduction." A sample two-pass encoding setting with the parameters :

  --arnr-maxframes=5 --arnr-strength=3

  enables the encoder to use "5" consecutive input source frames to produce one alternate reference frame using a filtering strength of "3". Here is an example showing the quality benefit of using this experimental "ARNR" feature on the standard test clip "Hall Monitor." (Each line on the graph represents the quality of an encoded stream on a given clip at multiple datarates. The higher points on the Y axis (PSNR) indicates the stream with the better quality.)

  
  

  The only difference between the two curves in the graph is that VP8_ARNR was produced by encodings with ARNR parameters and VP8_NO_ARNR was not. As we can see from the graph, noise reduced prediction is very helpful to compression quality when encoding noisy sources. We’ve just started to explore this idea but have already seen strong improvements on noisy input clips similar to this "Hall Monitor." We feel there’s a lot more we can do in this area.

  Improving Prediction without B Frames

  The lack of B frames in VP8 has sparked some discussion about its ability to achieve competitive compression efficiency. VP8 encoders, however, can make intelligent use of the golden reference and the alternate reference frames to compensate for this. The VP8 encoder can choose to transmit an alternate reference frame similar to a "future" frame, and encoding of subsequent frames can make use of information from the past (last frame and golden frame) and from the future (alternate reference frame). Effectively, this helps the encoder to achieve results similar to bidirectional (B frame) prediction without requiring frame reordering in the decoder. Running in two-pass encoding mode, compression can be improved in the VP8 encoder by using encoding parameters that enable lagged encoding and automatic placement of alternate reference frames :

  --auto-alt-ref=1 --lag-in-frames=16

  Used this way, the VP8 encoder can achieve improved prediction and compression efficiency without increasing the decoder’s complexity :

  
  

  In the video compression community, "Mobile and calendar" is known as a clip that benefits significantly from the usage of B frames. The graph above illustrates that the use of alternate reference frame benefits VP8 significantly without using B frames.

  Keep an eye on this blog for more posts about VP8 encoding. You can find more information on above encoding parameters or other detailed instructions to use with our VP8 encoders on our site, or join our discussion list.

  Yaowu Xu, Ph.D. is a codec engineer at Google.

  

• ffmpeg not reading string correctly in Swift MacOS app

  21 octobre 2019, par NCrusher

  I’m so close to having a working app that does a simple audio conversion calling ffmpeg but I’m stuck on what appears to be the silliest error.

  in the Console, ffmpeg prints the following error when I try to run the conversion :

  "Unrecognized option ’c copy’. Error splitting the argument list :
  Option not found"

  Which is strange because that’s not the argument I’m giving it. My method for producing the string it’s getting its argument from is as follows :

  func conversionSelection() {
  
      if inputFileUrl != nil {
  
          let conversionChoice = conversionOptionsPopup.indexOfSelectedItem
  
          switch conversionChoice {
  
              case 1 :
  
                  outputExtension = ".mp3"
  
                  ffmpegFilters = "-c:a libmp3lame -ac 1 -ar 22050 -q:a 9"
  
              case 2 :
  
                  outputExtension = ".mp3"
  
                  ffmpegFilters = "-c:a libmp3lame -ac 2 -ar 44100 -q:a 5"
  
              case 3 :
  
                  outputExtension = ".mp3"
  
                  ffmpegFilters = "-c:a libmp3lame -ac 1 -ar 22050 -b:a 32k"
  
              case 4:
  
                  outputExtension = ".flac"
  
                  ffmpegFilters = "-c:a flac"
  
              default :
  
                  outputExtension = ".m4b"
  
                  ffmpegFilters = "-c copy"
  
          }
  
      }
  
  }

  Then the code I use to launch ffmpeg is as follows :

  func ffmpegConvert(inputPath: String, filters: String, outputPath: String) {
  
      guard let launchPath = Bundle.main.path(forResource: "ffmpeg", ofType: "") else { return }
  
      do {
  
          let compressTask: Process = Process()
  
          compressTask.launchPath = launchPath
  
          compressTask.arguments = [
  
              "-y",
  
              "-i", inputPath,
  
              filters,
  
              outputPath
  
          ]
  
          compressTask.standardInput = FileHandle.nullDevice
  
          compressTask.launch()
  
          compressTask.waitUntilExit()
  
  
  
      }
  
  }

  Which I call when my "Start Conversion" button is clicked :

  @IBAction func startConversionClicked(_ sender: Any) {
  
      ffmpegConvert(inputPath: inputFilePath, filters: ffmpegFilters, outputPath: outputFilePath)
  
  }

  (inputFilePath and outputFilePath are strings obviously generated by other methods which appear to be working fine.)

  So it appears the only obstacle to my having a working app here is that for some reason, I’m losing that hyphen at the start of the ffmpegFilters string.

  How is that happening and what do I need to do to fix it ?

  EDIT : Having tried the basic script I’m trying to create in XCode from the Terminal, I realized I’d forgotten to take into account the fact that paths with spaces in them need to have the spaces converted to "\ ". So that may actually be the cause and the error is misleading ? Which is strange because ffmpeg gives me the exact error in Terminal so maybe not ?

  FURTHER EDIT : Upon further experimentation, I discovered it would recognize the hyphen at the beginning of the argument string as long as I used two hyphens—which I should have realized sooner because duh, mathematical operator, just like && and ==.

  But it’s still telling me Unrecognized option '-c copy' which really makes no sense, because "-c copy" is definitely a valid ffmpeg argument.

  I tried converting the file paths with the .addingPercentEncoding option, and it was still giving me the error about the argument rather than saying the file/directory being invalid, so either XCode was already passing a perfectly formatted file path string to ffmpeg, or ffmpeg is too busy complaining about the invalid argument to get around to telling me I have an invalid path.

  AND A STILL FURTHER EDIT : I’m still battering my head against this issue, because I’m convinced it’s going to be something stupid and minor. I’m just throwing things at the wall and seeing what sticks.

  I put a whitespace at the beginning of the arguments string inside my quotes for the filters argument (so it reads " -c copy" instead of "-c copy") and that seemed to make a little headway. It actually read the metadata of my input file before telling me :

  Unable to find a suitable output format for ’ -c copy’
  -c copy : Invalid argument

  Which suggests to me that the issue is that the method for stringing together all the strings might not be either putting (or not putting ?) whitespace between the adjacent strings where appropriate ?

  Because of course a whitespace needs to go between the inputFilePath string and the ffmpegFilters string. A whitespace also needs to go between the ffmpegFilters string and the outputFilePath string, but NOT between the individual components comprising the output string.

  If that’s the issue, it’s actually going to a little tough to troubleshoot at my current level of understanding, because the output path is composed of different components derived from different methods.

  This is the method I use to pull it all together, which yields a string that gets displayed in a text field, and also provides the outputFilePath I use in the ffmpegConvert process.

  func updateOutputText(outputString: String, outputField: NSTextField) {
  
      if inputFileUrl != nil && outputDirectoryUrl == nil {
  
          // derive output path and filename from input and tack on a new extension if a different output format is chosen
  
          let outputFileUrl = inputFileUrl!.deletingPathExtension()
  
          let outputPath = outputFileUrl.path
  
          outputFilePath = outputPath + "\(outputExtension)"
  
      } else if   inputFileUrl != nil && outputDirectoryUrl != nil {
  
          // derive output directory from outputBrowseButton action, derive filename from input file, and derive output extension from conversion format selection
  
          let outputFile = inputFileUrl!.deletingPathExtension()
  
          let outputFilename = outputFile.lastPathComponent
  
          let outputDirectory = outputDirectoryPath
  
          outputFilePath = outputDirectory + "/" + outputFilename + "\(outputExtension)"
  
      }
  
      outputTextDisplay.stringValue = outputFilePath
  
  }

  From the error ffmpeg kicked back this time, either there’s NOT a space between the ffmpegFilters string and the outputFilePath string, or there IS an unwanted space between the outputFilename and "\(outputExtension)" components of the outputFilePath string.

  And it’s such a strangely put together string that I’m not sure what to do if that’s the case.