Skip to content

F
Ffmpeg

小白菜888 / Ffmpeg

通知 3
Star 0
Fork 0
F
Ffmpeg

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 27 4月, 2018 6 次提交
  3. 26 4月, 2018 3 次提交
  5. 25 4月, 2018 1 次提交
  7. 24 4月, 2018 1 次提交
  9. 22 4月, 2018 2 次提交
    • R
      lavf/qsv: clone the frame which may be managed by framework · d865783b
      由 Ruiling Song 提交于 
      For filters based on framesync, the input frame was managed
by framesync, so we should not directly keep and destroy it,
instead we make a clone of it here, or else double-free will occur.
But for other filters not based on framesync, we still need to
free the input frame inside filter_frame.
Signed-off-by: NRuiling Song <ruiling.song@intel.com>
      d865783b
    • R
      lavf: make overlay_qsv work based on framesync · f3341a04
      由 Ruiling Song 提交于 
      The existing version which was cherry-picked from Libav does not work
with FFmpeg framework, because ff_request_frame() was totally
different between Libav (recursive) and FFmpeg (non-recursive).
The existing overlay_qsv implementation depends on the recursive version
of ff_request_frame to trigger immediate call to request_frame() on input pad.
But this has been removed in FFmpeg since "lavfi: make request_frame() non-recursive."
Now that we have handy framesync support in FFmpeg, so I make it work
based on framesync. Some other fixing which is also needed to make
overlay_qsv work are put in a separate patch.
Signed-off-by: NRuiling Song <ruiling.song@intel.com>
      f3341a04
  11. 21 4月, 2018 1 次提交
  13. 19 4月, 2018 1 次提交
  15. 17 4月, 2018 3 次提交
  17. 16 4月, 2018 6 次提交
  19. 15 4月, 2018 3 次提交
  21. 14 4月, 2018 2 次提交
  23. 13 4月, 2018 1 次提交
  25. 10 4月, 2018 1 次提交
    • W
      w32pthreads: always use Vista+ API, drop XP support · c7ab6aff
      由 wm4 提交于 
      This removes the XP compatibility code, and switches entirely to SRW
locks, which are available starting at Windows Vista.

This removes CRITICAL_SECTION use, which allows us to add
PTHREAD_MUTEX_INITIALIZER, which will be useful later.

Windows XP is hereby not a supported build target anymore.
Signed-off-by: NDiego Biurrun <diego@biurrun.de>
      c7ab6aff
  27. 09 4月, 2018 2 次提交
    • M
      qsv: adding Multi Frame Encode support · cca5e4f0
      由 Maxym Dmytrychenko 提交于 
      Starting from API 1.25 helps to improve performance of the simultaneous
encode, 1:N scenario, like:

./avconv  -y -hwaccel qsv -c:v h264_qsv -r 30000/1001 -i
~/bbb_sunflower_1080p_60fps_normal.mp4  -vframes 600 -an \
    -filter_complex "split=2[s1][s2]; [s1]scale_qsv=1280:720[o1];
[s2]scale_qsv=960:540[o2]" \
    -map [o1] -c:v h264_qsv -b:v 3200k -minrate 3200k -maxrate 3200k -f
rawvideo /tmp/3200a.264 \
    -map [o2] -c:v h264_qsv -b:v 1750k -minrate 1750k -maxrate 1750k -f
rawvideo /tmp/1750a.264
Signed-off-by: NMaxym Dmytrychenko <maxim.d33@gmail.com>
      cca5e4f0
    • Z
      lavf/qsvvpp: bypass vpp if not needed. · 29a8ed76
      由 Zhong Li 提交于 
      Currently vpp pipeline is always created, even for the unnecessary
cases such as setting the option "vpp_qsv=w=1280:h=720" for an input
with native resolution 1280x720. Thus introduces unnecessary performance
dropping, so bypass vpp if not needed.
Signed-off-by: NZhong Li <zhong.li@intel.com>
Signed-off-by: NMaxym Dmytrychenko <maxim.d33@gmail.com>
      29a8ed76
  29. 06 4月, 2018 3 次提交
  31. 03 4月, 2018 1 次提交
    • W
      avutil/pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL · d6fc031c
      由 wm4 提交于 
      PSEUDOPAL pixel formats are not paletted, but carried a palette with the
intention of allowing code to treat unpaletted formats as paletted. The
palette simply mapped the byte values to the resulting RGB values,
making it some sort of LUT for RGB conversion.

It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
formats. The last one, GRAY8, is more common, but its treatment is
grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
from typical Y video planes was not mapped to the correct RGB values.
This cannot be fixed, because AVFrame.color_range can be freely changed
at runtime, and there is nothing to ensure the pseudo palette is
updated.

Also, nothing actually used the PSEUDOPAL palette data, except xwdenc
(trivially changed in the previous commit). All other code had to treat
it as a special case, just to ignore or to propagate palette data.

In conclusion, this was just a very strange old mechnaism that has no
real justification to exist anymore (although it may have been nice and
useful in the past). Now it's an artifact that makes the API harder to
use: API users who allocate their own pixel data have to be aware that
they need to allocate the palette, or FFmpeg will crash on them in
_some_ situations. On top of this, there was no API to allocate the
pseuo palette outside of av_frame_get_buffer().

This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
the pseudo palette optional. Nothing accesses it anymore, though if it's
set, it's propagated. It's still allocated and initialized for
compatibility with API users that rely on this feature. But new API
users do not need to allocate it. This was an explicit goal of this
patch.

Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.

Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
functions manually changed to not allocating a palette.
      d6fc031c
  33. 02 4月, 2018 3 次提交