Recherche avancée

Sur d’autres sites (5682)

• avcodec/nvdec : Round up odd width/height values

  24 novembre 2017, par Philip Langdale

  avcodec/nvdec : Round up odd width/height values
  nvdec will not produce odd width/height output, and while this is
  
  basically never an issue with most codecs, due to internal alignment
  
  requirements, you can get odd sized jpegs.
  If an odd-sized jpeg is encountered, nvdec will actually round down
  
  internally and produce output that is slightly smaller. This isn't
  
  the end of the world, as long as you know the output size doesn't
  
  match the original image resolution.
  However, with an hwaccel, we don't know. The decoder controls
  
  the reported output size and the hwaccel cannot change it. I was
  
  able to trigger an error in mpv where it tries to copy the output
  
  surface as part of rendering and triggers a cuda error because
  
  cuda knows the output frame is smaller than expected.
  To fix this, we can round up the configured width/height passed
  
  to nvdec so that the frames are always at least as large as the
  
  decoder's reported size, and data can be copied out safely.
  In this particular jpeg case, you end up with a blank (green) line
  
  at the bottom due to nvdec refusing to decode the last line, but
  
  the behaviour matches cuviddec, so it's as good as you're going to
  
  get.
  

  • [DH] libavcodec/nvdec.c

• x264 on Ubuntu video bad/corrupted

  6 septembre 2013, par Ryzone

  I am trying to use command line x264 to produce a blu-ray compatible file for use in Adobe Encore. For the source file I've tried both ProRes and mpeg2, both 1080p24. Both files import into Encore fine (no transcoding needed which is great) but the ProRes version is pink and grey "static" and the mpeg2 is just a bunch of green/black lines. The exact same files and the exact same commands on my Win7 PC come out fine. I'm only doing a 10 sec sample of the complete 90min movie. I'd love for it to work on Ubuntu cause it is running a new i7 haswell that encodes much quicker than my PC (many hours difference in encoding time)

  Ubuntu 13.04
  
  
  
  x264 0.135.2 f0c1c53<br />
  
  built on Jul 24 2013, gcc: 4.7.3<br />
  
  configuration: --bit-depth=8 --chroma-format=all<br />
  
  x264 license: GPL version 2 or later
  
  
  
  command:
  
      x264 --bitrate 30000 --preset veryslow --tune film --bluray-compat --fps 24000/1001 --force-cfr --bframes 3 --ref 4 --muxer raw --no-weightb --weightp 0 --b-pyramid none --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --profile high --keyint 24 --min-keyint 1 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1  -o output.264 --input-res 1920x1080 sample.mov

  (if it would work I'd be doing two pass encoding)

  I am able to encode the sample file with ffmpeg to h264 (if that helps).

• avcodec/omx : Fix handling of fragmented buffers

  17 janvier 2019, par Dave Stevenson

  avcodec/omx : Fix handling of fragmented buffers
  See https://trac.ffmpeg.org/ticket/7687
  If an encoded frame is returned split over two or more
  
  IL buffers due to the size, then there is a race between
  
  whether get_buffer will fail, return NULL, and a truncated
  
  frame is passed on, or IL will return the remaining part
  
  of the encoded frame.
  
  If get_buffer returns NULL, part of the frame is left behind
  
  in the codec, and will be collected on the next call. That
  
  then leaves a frame stuck in the codec. Repeat enough times
  
  and the codec FIFO is full, and the pipeline stalls.
  A performance improvement in the Raspberry Pi firmware means
  
  that the timing has changed, and now frequently drops into the
  
  case where get_buffer returns NULL.
  Add code such that should a buffer be received without
  
  OMX_BUFFERFLAG_ENDOFFRAME that get_buffer is called with wait
  
  set, so we wait for the remainder of the frame.
  
  This code has been made conditional on the Pi build in case
  
  other IL implementations don't handle ENDOFFRAME correctly.
  Signed-off-by : Dave Stevenson <dave.stevenson@raspberrypi.org>
  
  Signed-off-by : Aman Gupta <aman@tmm1.net>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/omx.c