From komh78 at gmail.com Mon Mar 1 13:39:40 2021 From: komh78 at gmail.com (KO Myung-Hun) Date: Mon, 1 Mar 2021 20:39:40 +0900 Subject: [MPlayer-dev-eng] [PATCH] kva: support -geometry option Message-ID: <20210301113940.37141-1-komh@chollian.net> --- libvo/vo_kva.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/libvo/vo_kva.c b/libvo/vo_kva.c index 04333c64f..42b273dd7 100644 --- a/libvo/vo_kva.c +++ b/libvo/vo_kva.c @@ -812,12 +812,21 @@ static int config(uint32_t width, uint32_t height, d_height++; } - m_int.rclDst.xLeft = ((LONG)vo_screenwidth - (LONG)d_width) / 2; - m_int.rclDst.yBottom = ((LONG)vo_screenheight - (LONG)d_height) / 2; + vo_dx = (vo_screenwidth - d_width) / 2; + vo_dy = (vo_screenheight - d_height ) / 2; + geometry(&vo_dx, &vo_dy, &d_width, &d_height, + vo_screenwidth, vo_screenheight); + + m_int.rclDst.xLeft = vo_dx; + // invert Y + m_int.rclDst.yBottom = vo_screenheight - (vo_dy + d_height); m_int.rclDst.xRight = m_int.rclDst.xLeft + d_width; m_int.rclDst.yTop = m_int.rclDst.yBottom + d_height; if (vo_fs) { + vo_dx = 0; + vo_dy = 0; + d_width = vo_screenwidth; d_height = vo_screenheight; @@ -831,10 +840,11 @@ static int config(uint32_t width, uint32_t height, setAspectRatio(KVAR_FORCEANY); } - rcl.xLeft = ((LONG)vo_screenwidth - (LONG)d_width) / 2; - rcl.yBottom = ((LONG)vo_screenheight - (LONG)d_height) /2 ; - rcl.xRight = rcl.xLeft + d_width; - rcl.yTop = rcl.yBottom + d_height; + rcl.xLeft = vo_dx; + // invert Y + rcl.yBottom = vo_screenheight - (vo_dy + d_height); + rcl.xRight = rcl.xLeft + d_width; + rcl.yTop = rcl.yBottom + d_height; } else { vo_fs = 0; -- 2.30.0 From ib at wupperonline.de Sun Mar 7 12:17:35 2021 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Sun, 07 Mar 2021 11:17:35 +0100 Subject: [MPlayer-dev-eng] Preparing MPlayer 1.5 Release In-Reply-To: <20200901194127.GA2552@akuma.local> Message-ID: <6044a850.617afcf8.bm000@wupperonline.de> Alexander Strasser wrote on Tue, 1 Sep 2020 21:41:27 +0200: > I intent to do an MPlayer release in the next weeks. It would probably be too late for the Debian bullseye release, but where are we on that? Ingo From komh78 at gmail.com Wed Mar 10 13:28:01 2021 From: komh78 at gmail.com (KO Myung-Hun) Date: Wed, 10 Mar 2021 20:28:01 +0900 Subject: [MPlayer-dev-eng] [PATCH] kva: support -geometry option In-Reply-To: <20210301113940.37141-1-komh@chollian.net> References: <20210301113940.37141-1-komh@chollian.net> Message-ID: <6048AD41.1050607@chollian.net> Hi/2. If no objections, I'll commit soon. KO Myung-Hun wrote: > --- > libvo/vo_kva.c | 22 ++++++++++++++++------ > 1 file changed, 16 insertions(+), 6 deletions(-) > > diff --git a/libvo/vo_kva.c b/libvo/vo_kva.c > index 04333c64f..42b273dd7 100644 > --- a/libvo/vo_kva.c > +++ b/libvo/vo_kva.c > @@ -812,12 +812,21 @@ static int config(uint32_t width, uint32_t height, > d_height++; > } > > - m_int.rclDst.xLeft = ((LONG)vo_screenwidth - (LONG)d_width) / 2; > - m_int.rclDst.yBottom = ((LONG)vo_screenheight - (LONG)d_height) / 2; > + vo_dx = (vo_screenwidth - d_width) / 2; > + vo_dy = (vo_screenheight - d_height ) / 2; > + geometry(&vo_dx, &vo_dy, &d_width, &d_height, > + vo_screenwidth, vo_screenheight); > + > + m_int.rclDst.xLeft = vo_dx; > + // invert Y > + m_int.rclDst.yBottom = vo_screenheight - (vo_dy + d_height); > m_int.rclDst.xRight = m_int.rclDst.xLeft + d_width; > m_int.rclDst.yTop = m_int.rclDst.yBottom + d_height; > > if (vo_fs) { > + vo_dx = 0; > + vo_dy = 0; > + > d_width = vo_screenwidth; > d_height = vo_screenheight; > > @@ -831,10 +840,11 @@ static int config(uint32_t width, uint32_t height, > setAspectRatio(KVAR_FORCEANY); > } > > - rcl.xLeft = ((LONG)vo_screenwidth - (LONG)d_width) / 2; > - rcl.yBottom = ((LONG)vo_screenheight - (LONG)d_height) /2 ; > - rcl.xRight = rcl.xLeft + d_width; > - rcl.yTop = rcl.yBottom + d_height; > + rcl.xLeft = vo_dx; > + // invert Y > + rcl.yBottom = vo_screenheight - (vo_dy + d_height); > + rcl.xRight = rcl.xLeft + d_width; > + rcl.yTop = rcl.yBottom + d_height; > } else { > vo_fs = 0; > -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.10 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.os2.kr/ From Reimar.Doeffinger at gmx.de Wed Mar 10 20:35:26 2021 From: Reimar.Doeffinger at gmx.de (=?ISO-8859-1?Q?Reimar_D=F6ffinger?=) Date: Wed, 10 Mar 2021 19:35:26 +0100 Subject: [MPlayer-dev-eng] [PATCH] kva: support -geometry option In-Reply-To: <6048AD41.1050607@chollian.net> References: <20210301113940.37141-1-komh@chollian.net> <6048AD41.1050607@chollian.net> Message-ID: <1A3E847C-314C-4051-AF19-7EA88541E493@gmx.de> On 10 March 2021 12:28:01 CET, KO Myung-Hun wrote: >Hi/2. > >If no objections, I'll commit soon. No, no objections. You are really the only one in a position to really say if it works and is good for kva stuff. The only thing I'm not entirely sure about is if setting vo_dx and vo_dy manually (e.g. in the vo_fs case) should be necessary or if it indicates some bug that you have to do that. It seems a bit suspicious to me, but as long as it works it's fine. From Reimar.Doeffinger at gmx.de Wed Mar 10 20:37:59 2021 From: Reimar.Doeffinger at gmx.de (=?ISO-8859-1?Q?Reimar_D=F6ffinger?=) Date: Wed, 10 Mar 2021 19:37:59 +0100 Subject: [MPlayer-dev-eng] Preparing MPlayer 1.5 Release In-Reply-To: <6044a850.617afcf8.bm000@wupperonline.de> References: <6044a850.617afcf8.bm000@wupperonline.de> Message-ID: <1790D3F8-2CE1-4D0D-B610-4295A8E6A3B4@gmx.de> On 7 March 2021 11:17:35 CET, "Ingo Brückl" wrote: >Alexander Strasser wrote on Tue, 1 Sep 2020 21:41:27 +0200: > >> I intent to do an MPlayer release in the next weeks. > >It would probably be too late for the Debian bullseye release, >but where are we on that? Probably things got too busy. I may have contributed to the delay by asking if you should try to get rid of the other deprecated FFmpeg functions we are still using before. Actually the best approach would be to see if everything compiles and works when manually bumping all FFmpeg major versions... Though in principle we can release without that. From komh78 at gmail.com Mon Mar 15 11:34:19 2021 From: komh78 at gmail.com (KO Myung-Hun) Date: Mon, 15 Mar 2021 18:34:19 +0900 Subject: [MPlayer-dev-eng] [PATCH] kva: support -geometry option In-Reply-To: <1A3E847C-314C-4051-AF19-7EA88541E493@gmx.de> References: <20210301113940.37141-1-komh@chollian.net> <6048AD41.1050607@chollian.net> <1A3E847C-314C-4051-AF19-7EA88541E493@gmx.de> Message-ID: <604F2A1B.10100@chollian.net> Hi/2. Reimar Döffinger wrote: > On 10 March 2021 12:28:01 CET, KO Myung-Hun wrote: >> Hi/2. >> >> If no objections, I'll commit soon. > > No, no objections. > You are really the only one in a position to really say if it works and is good for kva stuff. Good, but I want to check my correct using of MPlayer APIs. > The only thing I'm not entirely sure about is if setting vo_dx and vo_dy manually (e.g. in the vo_fs case) should be necessary or if it indicates some bug that you have to do that. > It seems a bit suspicious to me, but as long as it works it's fine. Because I'm not sure vo_dx, vo_dy, d_width and d_height are set to 0, 0, vo_screenwidth and vo_screenheight respectively on full screen mode. Anyway, it works fine. I'll commit. Thanks! -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.1.10 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.os2.kr/ From eclipse7 at gmx.net Sun Mar 28 00:13:55 2021 From: eclipse7 at gmx.net (Alexander Strasser) Date: Sat, 27 Mar 2021 23:13:55 +0100 Subject: [MPlayer-dev-eng] [PATCH 1/6] vo_png: switch to new FFmpeg API. In-Reply-To: References: <20201220175034.26414-1-Reimar.Doeffinger@gmx.de> <20210109000021.GA1379@xklotz.local> Message-ID: <20210327221355.GA761@xklotz.local> On 2021-01-09 16:27 +0100, Reimar Döffinger wrote: > On Sat, Jan 09, 2021 at 01:00:21AM +0100, Alexander Strasser wrote: > > On 2020-12-20 18:50 +0100, Reimar Döffinger wrote: > > > --- > > > libvo/vo_png.c | 27 ++++++++++++--------------- > > > 1 file changed, 12 insertions(+), 15 deletions(-) > > > > > > diff --git a/libvo/vo_png.c b/libvo/vo_png.c > > > index 5696a1f3e..7523dca74 100644 > > > --- a/libvo/vo_png.c > > > +++ b/libvo/vo_png.c > > > @@ -150,8 +150,7 @@ config(uint32_t width, uint32_t height, uint32_t d_width, uint32_t d_height, uin > > > > > > static uint32_t draw_image(mp_image_t* mpi){ > > > AVFrame *pic; > > > - int buffersize; > > > - int res, got_pkt; > > > + int res; > > > char buf[100]; > > > FILE *outfile; > > > AVPacket pkt; > > > @@ -174,26 +173,25 @@ static uint32_t draw_image(mp_image_t* mpi){ > > > pic->format = imgfmt2pixfmt(png_format); > > > pic->data[0] = mpi->planes[0]; > > > pic->linesize[0] = mpi->stride[0]; > > > - buffersize = mpi->w * mpi->h * 8; > > > - if (outbuffer_size < buffersize) { > > > - av_freep(&outbuffer); > > > - outbuffer = av_malloc(buffersize); > > > - outbuffer_size = buffersize; > > > - } > > > av_init_packet(&pkt); > > > - pkt.data = outbuffer; > > > - pkt.size = outbuffer_size; > > > > > - res = avcodec_encode_video2(avctx, &pkt, pic, &got_pkt); > > > + res = avcodec_send_frame(avctx, pic); > > > + if (res >= 0) { > > > + res = avcodec_receive_packet(avctx, &pkt); > > > + if (res == AVERROR(EAGAIN)) { > > > + avcodec_send_frame(avctx, NULL); > > > + res = avcodec_receive_packet(avctx, &pkt); > > > + } > > > + } > > > > I don't like how this gets harder to read after the patch. > > > > Did you try it like this? > > > > 1, avcodec_send_frame(avctx, pic) > > 2. avcodec_send_frame(avctx, NULL) > > 3. avcodec_receive_packet(avctx, &pkt) > > > > This is related to the decoder side. > I have not re-tested since to make sure, and it > certainly would be nice it worked that way, but what > I have seen for PNG codec is: > - once you do send_frame(NULL) the receive_packet will always return an > error. > - the codec is then also stuck in this error state, so you cannot > re-use the encoder even if you send in more real frames. > There are some reset functions that I thought were for this > use-case but I just got a warning that the encoder does not > support it. > - for this use-case, that means you would never get any frame out. > - however, API-wise you are supposed to do the send_frame(NULL) per > my understanding, so I added it in case FFmpeg changes/fixes it. > > Now I could try to investigate and fix it in FFmpeg, but that comes > with the dual issue of me not having time, plus usually "make the > API less painful to use" type of patches usually encounter resistance > of the "you just shouldn't use it that way" type. Seems it didn't (and probably still doesn't) work like we expected. I'm fine with your patch as it was tested that way. Alexander From eclipse7 at gmx.net Sun Mar 28 00:20:25 2021 From: eclipse7 at gmx.net (Alexander Strasser) Date: Sat, 27 Mar 2021 23:20:25 +0100 Subject: [MPlayer-dev-eng] Preparing MPlayer 1.5 Release In-Reply-To: <1790D3F8-2CE1-4D0D-B610-4295A8E6A3B4@gmx.de> References: <6044a850.617afcf8.bm000@wupperonline.de> <1790D3F8-2CE1-4D0D-B610-4295A8E6A3B4@gmx.de> Message-ID: <20210327222025.GB761@xklotz.local> On 2021-03-10 19:37 +0100, Reimar Döffinger wrote: > On 7 March 2021 11:17:35 CET, "Ingo Brückl" wrote: > >Alexander Strasser wrote on Tue, 1 Sep 2020 21:41:27 +0200: > > > >> I intent to do an MPlayer release in the next weeks. > > > >It would probably be too late for the Debian bullseye release, > >but where are we on that? > > Probably things got too busy. > I may have contributed to the delay by asking if you should try to get rid of the other deprecated FFmpeg functions we are still using before. > Actually the best approach would be to see if everything compiles and works when manually bumping all FFmpeg major versions... > Though in principle we can release without that. Sorry, for not getting the release done. Too many things started to drain my time and I just couldn't get it done. After a while I started testing the FFmpeg API patches. Found some other problem I couldn't track down and got stuck again. I am all ears for plans to go forward. I should also have some time in the coming weeks. Would be great if we could get a release done. Best regards, Alexander From eclipse7 at gmx.net Sun Mar 28 21:48:24 2021 From: eclipse7 at gmx.net (Alexander Strasser) Date: Sun, 28 Mar 2021 20:48:24 +0200 Subject: [MPlayer-dev-eng] [PATCH] tests/faterun: Use single-threaded decoding for mov/empty_edit_5s.mp4 Message-ID: <20210328184752.GA9351@akuma.local> This sample resulted in changing checksums when decoding with 4 threads. I couldn't find anything wrong about testing this sample with valgrind, thus I concluded it is because of using multi-threaded decoding when error concealing happens. --- tests/faterun.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tests/faterun.sh b/tests/faterun.sh index 7df8ade67..acba45aa2 100755 --- a/tests/faterun.sh +++ b/tests/faterun.sh @@ -7,11 +7,17 @@ fi sample="$1" md5out="tests/res/$sample.md5" ref_file="tests/ref/$sample.md5" -options="-noconfig all -lavdopts threads=4:bitexact:idct=2 -really-quiet -noconsolecontrols -nosound -benchmark" +options="-noconfig all -really-quiet -noconsolecontrols -nosound -benchmark" if [ -z ${sample##h264-conformance/*} ] ; then # these files generally only work when a fps is given explicitly options="$options -fps 25" fi +if [ -z ${sample##mov/empty_edit_5s.mp4} ] ; then + # these do error concealing and yield non-deterministic results with threads + options="$options -lavdopts threads=1:bitexact:idct=2" +else + options="$options -lavdopts threads=4:bitexact:idct=2" +fi echo "testing $sample" # create necessary files and run --