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 ff
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 -hwaccel
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 MediaSD
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
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 (>4GB
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
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[] = {
>
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 ob
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 prope
>
>>>
>>>
>>> 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. Ev
>
> 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
>> dat
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 4k
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
ffmpeg-devel@ffmpeg.or
>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
h
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
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
sense
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()
> >
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 insertions(+
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
> >
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 *)fra
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 1:00
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 softwar
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
> libavcod
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. -- A
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 inserti
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 inse
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 a/libavformat/smoothstreamingenc
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 vario
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
> > ---
> > libavformat/smoothstrea
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 declare
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 a/libavformat/smoothstreamingenc
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, AV_LOG_WA
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()
> >
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 wi
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 |
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 (
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
Ben Hutchinson wrote:
>What is top posting? I'll try to avoid it if I know what it is.
Then please "google" it. Thanks!
https://ffmpeg.org/contact.html#MailingLists
https://en.wikipedia.org/wiki/Posting_style#Top-posting
___
ffmpeg-devel mailing list
38 matches
Mail list logo
