Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vlc-libhtsp-plugin #310

Closed
wants to merge 1,466 commits into from
Closed

vlc-libhtsp-plugin #310

wants to merge 1,466 commits into from

Conversation

@ghost
Copy link

@ghost ghost commented May 15, 2019

Hallo BtbN!
Ich weiß dass du deutsch sprichst. Du bist extremst schwer ausfindig zu machen für schriftlichen Kontakt. Daher schreibe ich dir hier!

Kannst du doch nochmal das im Betreff genannte Projekt aktualisieren? Denn seit VLC 3.x kann ich das Plugin nicht mehr mit "make" bauen. Bricht mit Fehlermeldungen ab. Wäre ich Programmierer würde ich das selber lösen. Aber ich bin, und wie alle anderen auch, die von programmieren keine Ahnung haben nu mal abhängig von deinen Künsten.

Danke dir im voraus!

richardpl and others added 30 commits Apr 7, 2019
Otherwise, AV1 encodes with FFmpeg trigger use-of-uninitialized-value
warnings under MemorySanitizer, and the output buffer potentially
changes from run to run.

Signed-off-by: James Almer <jamrial@gmail.com>
Fix memory leak after write trailer for #7827, only store a audio
packet whose buffer has size greater than zero in cur_audio_pkt.

Audio packets with size zero, but with side-data currently lead to
memleaks, in the Matroska muxer, because they are not properly freed:

They are currently put into an AVPacket in the MatroskaMuxContext to
ensure that the necessary audio is always available for a new cluster,
but are only written and freed when their size is > 0.

As the only use we have for such packets consists in updating the
CodecPrivate it makes no sense to store these packets at all and this
is how this commit solves the memleak.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The `opencl_get_plane_format` function was incorrectly determining the
value used to set the image channel order. This resulted in all RGB
pixel formats being set to the `CL_RGBA` pixel format, regardless of
whether or not they actually *were* RGBA.

This patch fixes the issue by using the `offset` and depth of components
rather than the loop index to determine the value of `order`.

Signed-off-by: Jarek Samic <cldfire3@gmail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
153372 UNITS in postfilter_c,   65536 runs,      0 skips
73164 UNITS in postfilter_neon,   65536 runs,      0 skips -> 2.1x speedup

80591 UNITS in deemphasis_c,  131072 runs,      0 skips
43969 UNITS in deemphasis_neon,  131072 runs,      0 skips -> 1.83x speedup

Total decoder speedup: ~15% on a Raspberry Pi 3 (from 28.1x to 33.5x realtime)

Deemphasis SIMD based on the following unrolling:
const float c1 = CELT_EMPH_COEFF, c2 = c1*c1, c3 = c2*c1, c4 = c3*c1;
float state = coeff;

for (int i = 0; i < len; i += 4) {
    y[0] = x[0] + c1*state;
    y[1] = x[1] + c2*state + c1*x[0];
    y[2] = x[2] + c3*state + c1*x[1] + c2*x[0];
    y[3] = x[3] + c4*state + c1*x[2] + c2*x[1] + c3*x[0];

    state = y[3];
    y += 4;
    x += 4;
}

Unlike the x86 version, duplication is used instead of pslldq so
the structure and tables are different.
Fixes: Timeout (8sec -> 0.1sec)
Fixes: 13864/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PAM_fuzzer-5737860621139968

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 -sws_flags fast_bilinear \
        -s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
        -cpuflags 0 -v error -

32-bit mul, power8 only.

~2x speedup:

rgb24
  24431 UNITS in yuv2packed2,   16384 runs,      0 skips
  13783 UNITS in yuv2packed2,   16383 runs,      1 skips
bgr24
  24396 UNITS in yuv2packed2,   16384 runs,      0 skips
  14059 UNITS in yuv2packed2,   16384 runs,      0 skips
rgba
  26815 UNITS in yuv2packed2,   16383 runs,      1 skips
  12797 UNITS in yuv2packed2,   16383 runs,      1 skips
bgra
  27060 UNITS in yuv2packed2,   16384 runs,      0 skips
  13138 UNITS in yuv2packed2,   16384 runs,      0 skips
argb
  26998 UNITS in yuv2packed2,   16384 runs,      0 skips
  12728 UNITS in yuv2packed2,   16381 runs,      3 skips
bgra
  26651 UNITS in yuv2packed2,   16384 runs,      0 skips
  13124 UNITS in yuv2packed2,   16384 runs,      0 skips

This is a low speedup, but the x86 mmx version also gets only ~2x. The mmx version
is also heavily inaccurate, while the vsx version has high accuracy.
Fixes: out of array access
Fixes: 14110/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5649184864075776

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will be needed by the eventual native AV1 decoder.

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Can be useful for API users as ffmpeg/libavformat can't properly support some
operational patterns.

Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: signed integer overflow: 255 + 2147483634 cannot be represented in type 'int'
Fixes: 13472/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5712444142387200

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fix ticket: 7831

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
…r size

Factor it out from cbs_av1_read_metadata_itut_t35()

Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Based on itut_t35 Matadata OBU parsing code.

Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
…ttern for metadata

This makes it more consistent with other metadata keys.

Signed-off-by: Marton Balint <cus@passwd.hu>
stimeout option is already used in tcp transport, since
http is based on tcp, pass the option to http for tunneling
case.

Reviewed-by: Steven Liu <lq@onvideo.cn>
Signed-off-by: Jun Li <junli1026@gmail.com>
richardpl and others added 28 commits May 5, 2019
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Apparently in the new SDK one cannot query if VANC output is supported, so we
will fall back to non-VANC output if enabling the video output with VANC fails.

Fixes ticket #7867.

Signed-off-by: Marton Balint <cus@passwd.hu>
…ngth is around the detection duration

Fixes ticket #7875.

Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes ticket #7859
Reported and tested by Steffen Ohrendorf, steffen d ohrendorf a gmx d de
New VdpYCbCr Formats VDP_YCBCR_FORMAT_Y_U_V_444 and,
VDP_YCBCR_FORMAT_Y_UV_444 have been added in VDPAU with libvdpau-1.2
to be used in get/putbits for YUV 4:4:4 surfaces. Earlier mapping of
AV_PIX_FMT_YUV444P to VDP_YCBCR_FORMAT_YV12 is not valid.

Hence this Change maps AV_PIX_FMT_YUV444P to VDP_YCBCR_FORMAT_Y_U_V_444
to access the YUV 4:4:4 surface via read-back API's of VDPAU.
Pass SPS, PPS range extensions to VDPAU layer via
VdpPictureInfoHEVC444. Added VdpPictureInfoHEVC444 struct to
VdpPictureInfo union to populate the range extension params. Mapped
FF_PROFILE_HEVC_REXT to VDP_DECODER_PROFILE_HEVC_MAIN_444.
The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. This change adds AV_PIX_FMT_VDPAU as a valid format
for HEVC 4:4:4 8 bit.
10 bytes (id3v2 header amount of bytes) were being read before any checks
were made on the bitstream. The result was that we were overreading into
the next frame if the current one was 8 or 9 bytes long.

Fixes tickets #7271 and #7869.

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Reference: Table 8: Interpretation of valid BITPIX value from FITS standard 4.0
Fixes: runtime error: division by zero
Fixes: 14581/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5652382425284608

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is helpful to know why some clips decoding failed.
Ticket#7330 is a good example, with this patch it is easily to
know bitstream codec level is out of support range.

Signed-off-by: Zhong Li <zhong.li@intel.com>
libmfx hevc level defination is same as h264, not level_idc of SPEC.

Signed-off-by: Zhong Li <zhong.li@intel.com>
Currently profile mapping is hard-coded, and not flexible to do extactly
map (E.g: libmfx treats H264 constrained baseline to be baseline profile).

vaapi profile mapping funtion provides a better soultion than current
qsv mapping.

Signed-off-by: Zhong Li <zhong.li@intel.com>
./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
    -s 2400x720 -f rawvideo -y -vframes 5 -pix_fmt yuv420p16le -nostats test.raw

2.26 speedup (x86 SSE2 is 2.32):
  23772 UNITS in hscale,    4096 runs,      0 skips
  53862 UNITS in hscale,    4096 runs,      0 skips
./ffmpeg -loop 1 -s 1200x1440 -i tux16.png \
    -s 2400x720 -f rawvideo -y -vframes 5 -pix_fmt yuv420p16le -nostats test.raw

./ffmpeg -loop 1 -s 1200x1440 -i tux16.png \
    -s 2400x720 -f rawvideo -y -vframes 5 -pix_fmt yuv420p -nostats test.raw

32-bit mul, power8 only

2x speedup for hScale8To19_vsx (x86 SSE2 is 2.37):
  30896 UNITS in hscale,    8192 runs,      0 skips
  63956 UNITS in hscale,    8192 runs,      0 skips

2.06 for hScale16To15_vsx:
  30531 UNITS in hscale,    8192 runs,      0 skips
  63161 UNITS in hscale,    8192 runs,      0 skips
Signed-off-by: James Almer <jamrial@gmail.com>
It's no longer needed.

Signed-off-by: James Almer <jamrial@gmail.com>
Instead of doing each column one by one, doing several columns
together gives about 30% better performance.

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
Cuvid supports clips with a limit on maximum number of macroblocks.
This check was missing after cuvidGetDecoderCaps API call allowing
unsupported clips to proceed.
Added the missing check, same as the one in hwaccel nvdec implementation.

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Adding the support to build FFMPEG with HW accelerated decode and encode on PPC64
little endian architecture.

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
@BtbN
Copy link
Member

@BtbN BtbN commented May 15, 2019

I'm not maintaining that project anymore. I archived the GitHub repository for a reason.
It's written against a really old VLC Version, so it not working anymore isn't very surprising.
I don't have tvheadend anymore, so I can't even reasonably test it, nor do I have time and interest.

Check for any forks of the project, maybe someone else already made it work.

@BtbN BtbN closed this May 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet