Skip to content

F
ffmpeg.wasm-core
Switch branch/tag
  1. 09 Aug, 2019 2 commits
    • Olivier Maignial's avatar
      avformat/rtpdec_mpeg4: Fix integer parameters size check in SDP fmtp line · c29d81e7
      Olivier Maignial authored 
      === PROBLEM ===

I was trying to record h264 + aac streams from an RTSP server to mp4 file. using this command line:
    ffmpeg -v verbose -y -i "rtsp://<ip>/my_resources" -codec copy -bsf:a aac_adtstoasc test.mp4

FFmpeg then fail to record audio and output this logs:
    [rtsp @ 0xcda1f0] The profile-level-id field size is invalid (40)
    [rtsp @ 0xcda1f0] Error parsing AU headers
    ...
    [rtsp @ 0xcda1f0] Could not find codec parameters for stream 1 (Audio: aac, 48000 Hz, 1 channels): unspecified sample format

In SDP provided by my RTSP server I had this fmtp line:
    a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr; config=1188; sizeLength=13; indexLength=3; indexDeltaLength=3;

In FFmpeg code, I found a check introduced by commit 24130234. It disallows values greater than 32 for fmtp line parameters.
RFC-4566 (SDP: Session Description Protocol) do not give any limit of size on interger parameters given in an fmtp line.

However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual Streams) give examples of "profile-level-id" values for AAC, up to 55.

=== FIX ===

As each parameter may have its own min and max values
I propose to introduce a range for each parameter.
For this patch I used RFC-3640 and ISO/IEC 14496-1 as reference for validity ranges.

This patch fix my problem and I now can record my RTSP AAC stream to mp4.
It has passed the full fate tests suite sucessfully.
Signed-off-by: 's avatarOlivier Maignial <olivier.maignial@smile.fr>
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      c29d81e7
    • Andriy Gelman's avatar
      tools/zmqsend: Avoid mem copy past the end of input buffer · 90e965be
      Andriy Gelman authored 
      This patch avoids a read past the end of the input buffer in memcpy since the size
of the received zmq message is recv_buf_size - 1.
Reviewed-by: 's avatarPaul B Mahol <onemda@gmail.com>
Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      90e965be
  3. 08 Aug, 2019 6 commits
  5. 07 Aug, 2019 2 commits
    • Linjie Fu's avatar
      lavf/vf_vpp_qsv: add support for QSV transpose filter · af3ddd58
      Linjie Fu authored 
      Add transpose support for qsv_vpp with rotate and hflip:
    - rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
    - hflip:  [0, 1] support horizontal flip;

Configure with:
{"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","vflip"}

CMD:
ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
    -vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv output.h264

ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv -i input.h264
    -vf 'hwupload=extra_hw_frames=64,format=qsv,vpp_qsv=transpose=cclock_hflip'
                            -f rawvideo -pix_fmt nv12 ./transpose.yuv
Signed-off-by: 's avatarLinjie Fu <linjie.fu@intel.com>
Signed-off-by: 's avatarZhong Li <zhong.li@intel.com>
      af3ddd58
    • Ruiling Song's avatar
      avfilter/vf_convolution: add x86 SIMD for filter_3x3() · 98e419cb
      Ruiling Song authored 
      Tested using a simple command (apply edge enhance):
./ffmpeg_g -i ~/Downloads/bbb_sunflower_1080p_30fps_normal.mp4 \
 -vf convolution="0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:5:1:1:1:0:128:128:128" \
 -an -vframes 1000 -f null /dev/null

The fps increase from 151 to 270 on my local machine.
Signed-off-by: 's avatarRuiling Song <ruiling.song@intel.com>
      98e419cb
  7. 06 Aug, 2019 1 commit
  9. 05 Aug, 2019 26 commits
  11. 04 Aug, 2019 3 commits
    • Rodger Combs's avatar
      build: add support for building CUDA files with clang · 01994c93
      Rodger Combs authored 
      This avoids using the CUDA SDK at all; instead, we provide a minimal
reimplementation of the basic functionality that lavfi actually uses.
It generates very similar code to what NVCC produces.

The header contains no implementation code derived from the SDK.
The function and type declarations are derived from the SDK only to the
extent required to build a compatible implementation. This is generally
accepted to qualify as fair use.

Because this option does not require the proprietary SDK, it does not require
the "--enable-nonfree" flag in configure.
Signed-off-by: 's avatarTimo Rothenpieler <timo@rothenpieler.org>
      01994c93
    • Stefan Schoenefeld's avatar
      avcodec/h263dec: enable nvdec hwaccel · ad97be9f
      Stefan Schoenefeld authored 
      Signed-off-by: 's avatarTimo Rothenpieler <timo@rothenpieler.org>
      ad97be9f
    • Stefan Schoenefeld's avatar
      avcodec/h263dec: fix hwaccel decoding · 39a5c0ac
      Stefan Schoenefeld authored 
      Recently we encountered an issue when decoding a h.263 file:

FFmpeg will freeze when decoding h.263 video with NVDEC. Turns out this is not directly related to NVDEC but is a problem that shows with several other HW decoders like VDPAU, though the exact kind of error is different (either error messages or freezing[1]). The root cause is that ff_thread_finish_setup() is called twice per frame from ff_h263_decode_frame(). This is not supported by ff_thread_finish_setup() and specifically checked for and warned against in the functions code. The issue is also specific to hw accelerated decoding only as the second call to ff_thread_finish_setup() is only issued when hw acceleration is on. The fix is simple: add a check that the first call is only send when hw acceleration is off, and the second call only when hw acceleration is on (see attached patch). This works fine as far as I was able to test with vdpau and nvdec/nvcuvid hw decoding. The patch also adds NVDEC to the hw config list if available.

I also noticed a secondary issue when browsing through the code which is that, according to documentation, ff_thread_finish_setup() should only be called if the codec implements update_thread_context(), which h263dec does not. The patch does not address this and I'm not sure any action needs to be taken here at all.

[1] This is depending on whether or not the hw decoder sets the  HWACCEL_CAPS_ASYNC_SAFE flag
Signed-off-by: 's avatarTimo Rothenpieler <timo@rothenpieler.org>
      39a5c0ac