Recherche avancée

Sur d’autres sites (4584)

• Revision 8d3d2b76f3 : Tx size selection enhancements (1) Refines the modeling function and uses that

  22 juin 2013, par Deb Mukherjee

  Changed Paths :
   Modify /vp9/common/vp9_blockd.h

  
   Modify /vp9/encoder/vp9_encodeframe.c

  
   Modify /vp9/encoder/vp9_onyx_if.c

  
   Modify /vp9/encoder/vp9_onyx_int.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Tx size selection enhancements

  (1) Refines the modeling function and uses that to add some speed
  features. Specifically, intead of using a flag use_largest_txfm as
  a speed feature, an enum tx_size_search_method is used, of which
  two of the types are USE_FULL_RD and USE_LARGESTALL. Two other
  new types are added :
  USE_LARGESTINTRA (use largest only for intra)
  USE_LARGESTINTRA_MODELINTER (use largest for intra, and model for
  inter)

  (2) Another change is that the framework for deciding transform type
  is simplified to use a heuristic count based method rather than
  an rd based method using txfm_cache. In practice the new method
  is found to work just as well - with derf only -0.01 down.
  The new method is more compatible with the new framework where
  certain rd costs are based on full rd and certain others are
  based on modeled rd or are not computed. In this patch the existing
  rd based method is still kept for use in the USE_FULL_RD mode.
  In the other modes, the count based method is used.
  However the recommendation is to remove it eventually since the
  benefit is limited, and will remove a lot of complications in
  the code

  (3) Finally a bug is fixed with the existing use_largest_txfm speed feature
  that causes mismatches when the lossless mode and 4x4 WH transform is
  forced.

  Results on derf :
  USE_FULL_RD : +0.03% (due to change in the tables), 0% encode time reduction
  USE_LARGESTINTRA : -0.21%, 15% encode time reduction (this one is a
  pretty good compromise)
  USE_LARGESTINTRA_MODELINTER : -0.98%, 22% encode time reduction
  (currently the benefit of modeling is limited for txfm size selection,
  but keeping this enum as a placeholder) .
  USE_LARGESTALL : -1.05%, 27% encode-time reduction (same as existing
  use_largest_txfm speed feature).

  Change-Id : I4d60a5f9ce78fbc90cddf2f97ed91d8bc0d4f936

• Sending per frame metadata with H264 encoded frames

  21 septembre 2013, par user2459280

  We're looking for a way to send per frame metadata (for example an ID) with H264 encoded frames from a server to a client.

  We're currently developing a remote rendering application, where both client and server side are actively involved.
  The server renders a high quality image with all effects, lighting etc.
  The client also has model-informations and renders a diffuse image that is used when the bandwidth is too low or the images have to be warped in order to avoid stuttering .

  So far we're encoding the frames on the server side with ffmpeg and streaming them with live555 to the client, who receives an rtsp-stream and decodes the frames again using ffmpeg.

  For our application, we now need to send per frame metadata.
  We want the client to tell the server where the camera is right now.
  Ideally we'd be able to send the client's view matrix to the server, render the corresponding frame and send it back to the client together with its view matrix. So when the client receives a frame, we need to know exactly at what camera position the frame was rendered.

  Alternatively we could also tag each view matrix with an ID, send it to the server, render the frame and tag it with the same ID and send it back. In this case we'd have to assign the right matrix to the frame again on the client side.

  After several attempts to realize the above intent with ffmpeg we came to the conclusion that ffmpeg does not provide the required functionality. ffmpeg only provides a fix, predefined set of fields for metadata, that either cannot store a matrix or can only be set for every key frame, which is not frequently enough for our purpose.

  Now we're considering using live555. So far we have an on demand Server, witch gets a VideoSubsession with a H264VideoStreamDiscreteFramer to contain our own FramedSource class. In this class we load the encoded AVPacket (from ffmpeg) and send its data-buffer over the network. Now we need a way to send some kind of metadata with every frame to the client.

  Do you have any ideas how to solve this metadata problem with live555 oder another library ?

  Thanks for your help !

• Run Command/Process in Background but return the return code

  14 juin 2019, par techsavy

  I am Looking to run ffmpeg via subprocess, start the command in the background but return a return code so that further steps can be taken based on that return code. (stdout, stderr) = metadata.communicate is throwing all sorts of errors perhaps due to the process still being run.

  metadata = Popen(['/home/linuxbrew/.linuxbrew/bin/ffmpeg', '-i', '/mnt/sniops-ffmpeg/' + str(content.get('asset')), '-i', '/mnt/sniops-ffmpeg/' + str(content.get('asset')), '-lavfi', 'libvmaf=model_path=/opt/vmaf/model/vmaf_4k_v0.6.1.pkl:psnr=1:ssim=1:log_fmt=json:log_path=/mnt/sniops-ffmpeg/vmaf_scores/blackmonday_test1.json', '-t', '00:00:20.00', '-f', 'null', '-', '&'], stdout=PIPE, stderr=PIPE)