Re: [FFmpeg-devel] Bug in YUV decoder

2019-03-15 Thread Ben Hutchinson
So what you are saying is that "-pix_fmt yuv420p -color_range 2" should produce the same output as "-pix_fmt yuvj420p" (both producing YUV video with full range 0 to 255)? Unfortunately I tried that, and it doesn't work. I saved the FFMPEG outputs to "-f rawvideo" and then looked at the individual

Re: [FFmpeg-devel] Bug in YUV decoder

2019-03-15 Thread Ben Hutchinson
What is top posting? I'll try to avoid it if I know what it is. On Fri, Mar 15, 2019 at 5:21 PM Hendrik Leppkes wrote: > On Fri, Mar 15, 2019 at 10:13 PM Ben Hutchinson wrote: > > > > Also, on another note, why don't we have yuvj410p as a video format? Each > > chroma-subsampled versionof yuv

[FFmpeg-devel] [PATCH] avcodec/libdav1d: reset pool size on allocation failure

2019-03-15 Thread James Almer
Signed-off-by: James Almer --- No testcase for this, just the theoretical scenario where a library user could flush the decoder after ENOMEM was signaled here, then pass new data where a frame with the same size as the last successfully allocated one is the first in line. libavcodec/libdav1d.c

Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

2019-03-15 Thread Rogozhkin, Dmitry V
On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote: > > -Original Message- > > From: Rogozhkin, Dmitry V > > Sent: Saturday, March 9, 2019 8:48 AM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Li, Zhong > > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace > > current > > parser

Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

2019-03-15 Thread Rogozhkin, Dmitry V
On Thu, 2019-03-14 at 19:03 +0800, Li, Zhong wrote: > > From: Rogozhkin, Dmitry V > > Sent: Tuesday, March 12, 2019 7:37 AM > > To: Li, Zhong ; ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace > > current > > parser with MFXVideoDECODE_DecodeHeader() > >

Re: [FFmpeg-devel] [PATCH v4] avformat/smoothstreamingenc:add bitrate calculate

2019-03-15 Thread Jun Li
On Fri, Mar 15, 2019 at 5:34 PM Moritz Barsnick wrote: > On Fri, Mar 15, 2019 at 17:21:19 -0700, Jun Li wrote: > > -av_log(s, AV_LOG_ERROR, "No bit rate set for stream %d\n", > i); > > -ret = AVERROR(EINVAL); > > -goto fail; > > +av_log(s,

[FFmpeg-devel] [PATCH v5] avformat/smoothstreamingenc:add bitrate calculate

2019-03-15 Thread Jun Li
Calculate bitrate based on fragment size, only applied when bitrate is not set, for example rtsp source. Signed-off-by: Jun Li --- libavformat/smoothstreamingenc.c | 32 +++- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git

Re: [FFmpeg-devel] [PATCH v4] avformat/smoothstreamingenc:add bitrate calculate

2019-03-15 Thread Moritz Barsnick
On Fri, Mar 15, 2019 at 17:21:19 -0700, Jun Li wrote: > -av_log(s, AV_LOG_ERROR, "No bit rate set for stream %d\n", i); > -ret = AVERROR(EINVAL); > -goto fail; > +av_log(s, AV_LOG_WARNING, "No bit rate set for stream > %"PRId32"\n", i); i is

Re: [FFmpeg-devel] [PATCH v3] avformat/smoothstreamingenc:add bitrate calculate

2019-03-15 Thread Jun Li
On Fri, Mar 15, 2019 at 4:15 PM Michael Niedermayer wrote: > On Thu, Mar 14, 2019 at 11:21:58AM -0700, Jun Li wrote: > > Calculate bitrate based on fragment size, only applied when > > bitrate is not set, for example rtsp source. > > > > Signed-off-by: Jun Li > > --- > >

Re: [FFmpeg-devel] Bug in YUV decoder

2019-03-15 Thread Hendrik Leppkes
On Fri, Mar 15, 2019 at 10:13 PM Ben Hutchinson wrote: > > Also, on another note, why don't we have yuvj410p as a video format? Each > chroma-subsampled versionof yuv (partial range YUV) format should have an > equivalent chroma-subsampled version of yuvj (full range yuv). This would > allow

[FFmpeg-devel] [PATCH v4] avformat/smoothstreamingenc:add bitrate calculate

2019-03-15 Thread Jun Li
Calculate bitrate based on fragment size, only applied when bitrate is not set, for example rtsp source. Signed-off-by: Jun Li --- libavformat/smoothstreamingenc.c | 32 +++- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git

Re: [FFmpeg-devel] [PATCH v3] avformat/smoothstreamingenc:add bitrate calculate

2019-03-15 Thread Michael Niedermayer
On Thu, Mar 14, 2019 at 11:21:58AM -0700, Jun Li wrote: > Calculate bitrate based on fragment size, only applied when > bitrate is not set, for example rtsp source. > > Signed-off-by: Jun Li > --- > libavformat/smoothstreamingenc.c | 32 +++- > 1 file changed, 27

Re: [FFmpeg-devel] [PATCH]lavf/sdp: Change configuration pointer from char* to uint8_t*.

2019-03-15 Thread Michael Niedermayer
On Fri, Mar 15, 2019 at 12:56:05AM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch silences three warnings with clang and makes the > pointer type equal to what the function called with the pointer > expects. > > Please comment, Carl Eugen > sdp.c |3 ++- > 1 file changed, 2

Re: [FFmpeg-devel] [PATCH v7] mpeg12enc: Use Closed Captions if available

2019-03-15 Thread Michael Niedermayer
On Thu, Mar 14, 2019 at 09:29:49PM +0100, Mathieu Duponchelle wrote: > Hello, is there anything preventing from merging this patch? no will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. --

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

2019-03-15 Thread Michael Niedermayer
On Thu, Mar 14, 2019 at 05:55:41PM +, Yufei He wrote: > Hi > > Here is the patch for a new H.264 codec with Matrox m264 card. > > Please review. > > Thanks. > > Yufei. > > > Changelog |1 > configure |2 > libavcodec/Makefile |2 >

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

2019-03-15 Thread Marton Balint
On Fri, 15 Mar 2019, Ronald S. Bultje wrote: Hi guys, On Thu, Mar 14, 2019 at 1:55 PM Yufei He wrote: Hi Here is the patch for a new H.264 codec with Matrox m264 card. I want to bring up again that this library is closed-source. I don't think FFmpeg should link to closed-source

Re: [FFmpeg-devel] Bug in YUV decoder

2019-03-15 Thread Ben Hutchinson
Also, on another note, why don't we have yuvj410p as a video format? Each chroma-subsampled versionof yuv (partial range YUV) format should have an equivalent chroma-subsampled version of yuvj (full range yuv). This would allow various experimental setups to be tested. On Fri, Mar 15, 2019 at

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

2019-03-15 Thread Michael Niedermayer
On Fri, Mar 15, 2019 at 01:08:33AM +0100, Ulf Zibis wrote: [...] > static void fixed_borders16(FillBordersContext *s, AVFrame *frame) > { > -int p, y, x; > - > -for (p = 0; p < s->nb_planes; p++) { > +for (int p = 0; p < s->nb_planes; p++) { > uint16_t *data = (uint16_t

Re: [FFmpeg-devel] Bug in YUV decoder

2019-03-15 Thread Ben Hutchinson
Doesn't SDL support YUV444 as a YUV format? Or does it only support YUV420? Also, thanks for the tip about -vf format=bgra On Fri, Mar 15, 2019 at 1:00 AM Gyan wrote: > > > On 15-03-2019 12:05 PM, Ben Hutchinson wrote: > > Note that it does not matter what pixel format the encoder uses (j or >

Re: [FFmpeg-devel] [PATCH v3] avformat/smoothstreamingenc:add bitrate calculate

2019-03-15 Thread Jun Li
On Thu, Mar 14, 2019 at 11:22 AM Jun Li wrote: > Calculate bitrate based on fragment size, only applied when > bitrate is not set, for example rtsp source. > > Signed-off-by: Jun Li > --- > libavformat/smoothstreamingenc.c | 32 +++- > 1 file changed, 27

Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()

2019-03-15 Thread Rogozhkin, Dmitry V
On Thu, 2019-03-14 at 19:16 +0800, Li, Zhong wrote: > > From: Rogozhkin, Dmitry V > > Sent: Tuesday, March 12, 2019 8:04 AM > > To: Li, Zhong ; ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace > > current > > parser with MFXVideoDECODE_DecodeHeader() > >

Re: [FFmpeg-devel] [PATCHv3] avcodec/nvenc: Reconfigure resolution on-the-fly

2019-03-15 Thread Timo Rothenpieler
So what's the final verdict here, can this be pushed or not? Timo - did you manage to test it over last weekend? I haven't found the time, sorry. I'm generally not opposed to this. It does not disrupt normal use, and spinning up nvenc does have a surprisingly hefty overhead, so it makes

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

2019-03-15 Thread Ronald S. Bultje
Hi, On Fri, Mar 15, 2019 at 2:19 PM BIGLER Don (Framatome) < don.big...@framatome.com> wrote: > >Yufei He (12019-03-15): > >> I did not find a better way to make this work. > > >It exists: make your client libraries GPL-compatible. > > Or alternatively creating open-source headers that allow the

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

2019-03-15 Thread BIGLER Don (Framatome)
>Yufei He (12019-03-15): >> I did not find a better way to make this work. >It exists: make your client libraries GPL-compatible. Or alternatively creating open-source headers that allow the m264 drivers to be used similar to NVidia's Video Codec SDK: https://github.com/FFmpeg/nv-codec-headers

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

2019-03-15 Thread Nicolas George
Yufei He (12019-03-15): > I did not find a better way to make this work. It exists: make your client libraries GPL-compatible. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

2019-03-15 Thread Yufei He
Hi Jean-Baptiste Sorry for the complexity and confusion to so many people involved on this new patch. We have been working on this for 4 months because some of our big customers on internet business have been asking Matrox to make our M264 card to support FFmpeg on h.264 transcoding, esp on

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: added support for the write_data_type callback

2019-03-15 Thread Oliver Collyer
> > This patch makes it possible to do stuff like write a custom in-memory TS > segmenter, which was what I needed it for. > >> Hi >> >> I needed to be able to use the write_data_type callback when reading data >> from the mpegts muxer, to make my application aware of key frames in the >>

Re: [FFmpeg-devel] [PATCHv3] avcodec/nvenc: Reconfigure resolution on-the-fly

2019-03-15 Thread Oliver Collyer
> >>> >>> >>> Can you explain the actual intended use-case for this? >>> >>> The current way to handle resolution changes (or any other stream change of >>> similar magnitude, like a pixel format change) is to flush the existing >>> encoder and then make a new one with the new parameters.

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

2019-03-15 Thread Jean-Baptiste Kempf
On Fri, 15 Mar 2019, at 15:02, Tomas Härdin wrote: > > +#ifdef _WIN32 > > +lib_handle = dlopen("mvM264Ffmpeg.dll", RTLD_LAZY); > > +#else    > > +lib_handle = dlopen("libmvM264Ffmpeg.so", RTLD_LAZY); > > +#endif > > Still dlopen() I see. You should link to these libraries

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

2019-03-15 Thread Ronald S. Bultje
Hi guys, On Thu, Mar 14, 2019 at 1:55 PM Yufei He wrote: > Hi > > Here is the patch for a new H.264 codec with Matrox m264 card. > I want to bring up again that this library is closed-source. I don't think FFmpeg should link to closed-source software in its public mainline version. Matrox is

Re: [FFmpeg-devel] patch for a new H.264 codec with Matrox m264 card.

2019-03-15 Thread Tomas Härdin
tor 2019-03-14 klockan 17:55 + skrev Yufei He: > Hi > > Here is the patch for a new H.264 codec with Matrox m264 card. > > Please review. > --- a/libavcodec/codec_desc.c > +++ b/libavcodec/codec_desc.c > @@ -1705,7 +1705,6 @@ static const AVCodecDescriptor > codec_descriptors[] = { >    

Re: [FFmpeg-devel] 32bit transcoding app running out of memory

2019-03-15 Thread Simone Donadini
Hi Ronald, yes, we are using our own codec wrapped inside FFmpeg. Thank you for your suggestion, i will try with limiting the number of threads launched by FFmpeg. Simone. From: ffmpeg-devel [ffmpeg-devel-boun...@ffmpeg.org] on behalf of Ronald S. Bultje

Re: [FFmpeg-devel] 32bit transcoding app running out of memory

2019-03-15 Thread Ronald S. Bultje
Hi, On Thu, Mar 14, 2019 at 7:52 AM Simone Donadini < simone.donad...@avolites.com> wrote: > > 2019-03-14 11:28 GMT+01:00, Simone Donadini < > simone.donad...@avolites.com>: > > > While transcoding video files with larger resolution (8K) the app, > > > which is 32bit, will run out of memory

Re: [FFmpeg-devel] 32bit transcoding app running out of memory

2019-03-15 Thread Simone Donadini
Hi Carl, Thanks for your reply. The main issue we are seeing is the huge memory footprint, directly allocated by FFMPEG. I'm no expert in FFMPEG, but it looks like it is doing this to encode multiple frames at the same time. Is this correct and expected behaviour? If this is correct, is there

[FFmpeg-devel] [PATCH 2/2] lavf/qsvvpp: allocate continuous memory across Y and UV

2019-03-15 Thread Linjie Fu
Mediasdk calls CMRT to copy from video to system memory and requires memory to be continuously allocated across Y and UV. Add a new path to allocate continuous memory when using system out Fix the segmentation fault when enabling QSV mirror through video memory -> system memory. [#1223 in

[FFmpeg-devel] [PATCH 1/2] lavf/vf_vpp_qsv: add transpose support for QSV VPP

2019-03-15 Thread Linjie Fu
Add transpose support for qsv_vpp: - rotation: [0, 3] support clockwise rotation of 0, 90, 180, 270; - mirror: [0, 1] support horizontal mirroring; ffmpeg -hwaccel qsv -v verbose -c:v h264_qsv -i input.h264 -vf 'format=qsv,vpp_qsv=rotation=1' -c:v h264_qsv output.h264 ffmpeg

Re: [FFmpeg-devel] Bug in YUV decoder

2019-03-15 Thread Gyan
On 15-03-2019 12:05 PM, Ben Hutchinson wrote: Note that it does not matter what pixel format the encoder uses (j or non-j). This bug is only present in the decoder, and only when I select the non-j version of a yuv pixel format. This bug is present in the ffplay decoder (possibly also in the

[FFmpeg-devel] Bug in YUV decoder

2019-03-15 Thread Ben Hutchinson
When I decode rawvideo yuv444p in ffplay that was encoded in ffmpeg (using the test source called "testsrc"), I notice there is blurring between adjacent colors (both horizontally and vertically), which would typically be present in yuv420p. I can avoid this by switching the decoder to use a pixel