April 2016 - MPlayer-dev-eng - lists.mplayerhq.hu

[PATCH] stream_ffmpeg: add -lavfstreamopts option.
by Reimar Döffinger 01 Nov '20

01 Nov '20

Allows specifying options to ffmpeg-based streams. --- DOCS/man/en/mplayer.1 | 4 ++++ cfg-common.h | 1 + stream/stream.h | 1 + stream/stream_ffmpeg.c | 19 ++++++++++++++++++- 4 files changed, 24 insertions(+), 1 deletion(-) diff --git a/DOCS/man/en/mplayer.1 b/DOCS/man/en/mplayer.1 index 2a143cb..d8e9b3b 100644 --- a/DOCS/man/en/mplayer.1 +++ b/DOCS/man/en/mplayer.1 @@ -1806,6 +1806,10 @@ Skip the proxy for IPv6 addresses. It will still be used for IPv4 connections. . .TP +.B \-lavfstreamopts <options> +Specify extra options for libavformat based streams. +. +.TP .B \-loadidx <index file> The file from which to read the video index data saved by \-saveidx. This index will be used for seeking, overriding any index data diff --git a/cfg-common.h b/cfg-common.h index 3a422cf..ca4e9c9 100644 --- a/cfg-common.h +++ b/cfg-common.h @@ -545,6 +545,7 @@ const m_option_t common_opts[] = { #ifdef CONFIG_FFMPEG {"lavdopts", lavc_decode_opts_conf, CONF_TYPE_SUBCONFIG, 0, 0, 0, NULL}, {"lavfdopts", lavfdopts_conf, CONF_TYPE_SUBCONFIG, CONF_GLOBAL, 0, 0, NULL}, + {"lavfstreamopts", &lavfstreamopts, CONF_TYPE_STRING, CONF_GLOBAL, 0, 0, NULL}, #endif #ifdef CONFIG_XVID4 {"xvidopts", xvid_dec_opts, CONF_TYPE_SUBCONFIG, 0, 0, 0, NULL}, diff --git a/stream/stream.h b/stream/stream.h index 615f579..388c353 100644 --- a/stream/stream.h +++ b/stream/stream.h @@ -392,6 +392,7 @@ extern char *dvd_device; extern const m_option_t dvbin_opts_conf[]; extern char *rtsp_destination; +extern char *lavfstreamopts; typedef struct { int id; // 0 - 31 mpeg; 128 - 159 ac3; 160 - 191 pcm diff --git a/stream/stream_ffmpeg.c b/stream/stream_ffmpeg.c index 57d45e4..1883af3 100644 --- a/stream/stream_ffmpeg.c +++ b/stream/stream_ffmpeg.c @@ -27,6 +27,8 @@ #include "av_helpers.h" #include "libmpdemux/demuxer.h" +char *lavfstreamopts; + static int fill_buffer(stream_t *s, char *buffer, int max_len) { int r = avio_read(s->priv, buffer, max_len); @@ -90,6 +92,7 @@ static int open_f(stream_t *stream, int mode, void *opts, int *file_format) { int flags = 0; const char *filename; + AVDictionary *avopts = NULL; AVIOContext *ctx = NULL; int res = STREAM_ERROR; int64_t size; @@ -125,9 +128,23 @@ static int open_f(stream_t *stream, int mode, void *opts, int *file_format) dummy = !strncmp(filename, "rtsp:", 5) || !strncmp(filename, "dummy:", 6); mp_msg(MSGT_OPEN, MSGL_V, "[ffmpeg] Opening %s\n", filename); - if (!dummy && avio_open(&ctx, filename, flags) < 0) + if (lavfstreamopts && av_dict_parse_string(&avopts, lavfstreamopts, "=", ",", 0) < 0) { + mp_msg(MSGT_HEADER,MSGL_ERR, "Your options /%s/ look like gibberish to me pal\n", lavfstreamopts); + goto out; + } + + if (!dummy && avio_open2(&ctx, filename, flags, NULL, &avopts) < 0) goto out; + if (!dummy && av_dict_count(avopts)) { + AVDictionaryEntry *e = NULL; + while ((e = av_dict_get(avopts, "", e, AV_DICT_IGNORE_SUFFIX))) { + mp_msg(MSGT_HEADER,MSGL_ERR,"Unknown option %s\n", e->key); + } + goto out; + } + av_dict_free(&avopts); + stream->priv = ctx; size = dummy ? 0 : avio_size(ctx); if (size >= 0) -- 2.7.0

1 1

Probable boolean logic bug
by Michael McConville 25 Jun '17

25 Jun '17

Hi, everyone. It seems that there's a nonsensical if condition in the IVTV code. It always evaluates to true because it tests the same variable against multiple different constants. The most probable explanation is that || was used when && was intended. I found this with Coccinelle. Thanks for your time, Michael --- libao2/ao_ivtv.c +++ /tmp/cocci-output-71047-6811f3-ao_ivtv.c @@ -84,7 +84,7 @@ init (int rate, int channels, int format freq = rate; /* check for supported audio rate */ - if (rate != 32000 || rate != 41000 || rate != 48000) + if (rate != 32000 && rate != 41000 && rate != 48000) { mp_msg (MSGT_AO, MSGL_ERR, MSGTR_AO_MPEGPES_UnsupSamplerate, rate); rate = 48000;

3 2

Relicensing MPlayer or parts of it to LGPL
by wm4 28 Sep '16

28 Sep '16

I'm maintainer of mpv, a MPlayer fork. One of the changes in mpv was turning the slave mode interface into a library (libmpv), which replaces the stdin/stdout parsing slave mode MPlayer uses. One problem with this is that it forces every client to be GPL. libmpv basically exhibits the slave mode interface as API, but since the application code actually links to it, and the player runs in the same address space, the GPL technically applies (in my interpretation). To avoid this, I'm thinking of relicensing mpv to LGPL 2.1 (with the "or later"). While many things have changed in mpv compared to MPlayer (and many parts have been rewritten or removed), much of its core is still based on MPlayer, and I need agreement from the original authors of the code. I'm thinking it would be beneficial for MPlayer as well to relicense parts to LGPL (or all of it, if enough contributors can be reached). Alternatively, I'd just ask for permission to relicense the affected source files in mpv. Would there be any welcoming or opposing to such a move from MPlayer developers?

8 20

[PATCH] Added support for arm64
by jpinto 24 May '16

24 May '16

Signed-off-by: Joao Pinto <jpinto(a)synopsys.com> Tested-by: Joao Pinto <jpinto(a)synopsys.com> --- configure | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/configure b/configure index 722b8a4..d17e61e 100755 --- a/configure +++ b/configure @@ -2493,6 +2493,11 @@ EOF arch='generic' ;; + aarch64) + arch='arm64' + iproc='arm64' + ;; + *) echo "The architecture of your CPU ($host_arch) is not supported by this configure script" echo "It seems nobody has ported MPlayer to your OS or CPU type yet." -- 1.8.1.5

3 3

Probable boolean logic bug
by Michael McConville 16 May '16

16 May '16

Hi, everyone. It seems that there's a nonsensical if condition in the IVTV code. It always evaluates to true because it tests the same variable against multiple different constants. The most probable explanation is that || was used when && was intended. I found this with Coccinelle. Thanks for your time, Michael --- libao2/ao_ivtv.c +++ /tmp/cocci-output-71047-6811f3-ao_ivtv.c @@ -84,7 +84,7 @@ init (int rate, int channels, int format freq = rate; /* check for supported audio rate */ - if (rate != 32000 || rate != 41000 || rate != 48000) + if (rate != 32000 && rate != 41000 && rate != 48000) { mp_msg (MSGT_AO, MSGL_ERR, MSGTR_AO_MPEGPES_UnsupSamplerate, rate); rate = 48000;

2 1

[RFC] Split out hwaccel code
by Roberto Togni 24 Apr '16

24 Apr '16

Hi, this is a proposed patch to split the hwaccel code out of vd_ffmpeg, and put it into its own driver (vd_ffhw, but better names are welcome). The main purpose of this is to be able to change vd_ffmpeg code without the risk of breaking hwaccel (difficult to test if you don't have the hardware); at the same time it allows to work on hwaccel in a small and clean decoder, without all the special cases needed for the many formats supported by vd_ffmpeg. This also permit to use hwaccel by passing only "-vfm ffhw -vo vdpau" on the commandline, without specifying the codec (now you have to use "-vo vdpau -vc xxxvdpau"). If you add -vfm ffhw and the codec is not supported by hwaccel, MPlayer will fall back to vd_ffmpeg. The current syntax with -vc is also supported, so backward compatibility is guaranteed. The code is tested only with h264 and vaapi over vdpau; xvmc and other vdpau formats are untested. Hopefully this should accelerate the addition of more hwaccel formats (eg. vaapi), and ease the work on buffer management in vd_ffmpeg (today dr1 mostly fails). Please comment. Ciao, Roberto

2 1

[PATCH] vf_expand: fix clearing of horizontal padding.
by Nicolas George 19 Apr '16

19 Apr '16

The current code clears full_w-w on the right of the input image, relying on the area overflowing to the left. Therefore, it does not clear properly the left of the first row, and probably the immediate left if the stride is larger than the full width. More importantly, the clear overflows from each plane on what whould be the left of the line after the last. It is visible with a command line like that: ./mplayer -vf-add expand=850:480 640x480.h264 A green line appears on the left of the first chroma lines. Instead, clear the left and right rectangles separately. --- libmpcodecs/vf_expand.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) A similar problem exists with the top/bottom clear just below, it can be observed with subtitles not disappearing on the padding. Unfortunately, for some reason, while full_w is really the full width, full_h seems not to be the full height. I am not familiar enough with the mp_image_t structure to understand what is going on. diff --git a/libmpcodecs/vf_expand.c b/libmpcodecs/vf_expand.c index 85fae06..f747374 100644 --- a/libmpcodecs/vf_expand.c +++ b/libmpcodecs/vf_expand.c @@ -416,8 +416,10 @@ static int put_image(struct vf_instance *vf, mp_image_t *mpi, double pts){ if(vf->priv->osd) draw_osd(vf,mpi->w,mpi->h); #endif // padding for use by decoder needs to be cleared - if (mpi->w < full_w) - vf_mpi_clear(mpi, mpi->w, 0, full_w - mpi->w, full_h); + if (mpi->w < full_w) { + vf_mpi_clear(mpi, -vf->priv->exp_x, 0, vf->priv->exp_x, full_h); + vf_mpi_clear(mpi, mpi->w, 0, full_w - mpi->w - vf->priv->exp_x, full_h); + } if (mpi->h < full_h) vf_mpi_clear(mpi, 0, mpi->h, full_w, full_h - mpi->h); // we've used DR, so we're ready... -- 2.8.0.rc3

1 0