Have to say, this issue has been a long grievance of mine. There is no
reason to delay frames when the decoder is set up to ignore B frames
as there is no reordering to be done; ideally this should be
zero-delay case (packet goes in, frame goes out) yet the most common
decoders delay frames
вс, 30 июл. 2023 г. в 16:04, Nicolas George :
> Kieran Kunhya (12023-07-28):
> > FFmpeg doesn't implement TCP in userspace, it doesn't implement the
> > WiFi protocol etc etc. Different layers are delegated to different
> > programs.
>
There is a good reason to have some part of TCP implemented
This looks like a (strange) hack to me.
First, you cannot just throw some pids out - that will make a non-standard
compliant stream. PMT will signal missing streams; PCR pid will be missing
also. So let's assume that your tool can also rewrite PMT.
Secondly, there is supposed to be one and only
cuvid decoder has one advantage over nvdec: it has a hardware deinterlacer
support. BTW not sure if this patch takes that into account. So cuvid is
the only way to get GPU-deinterlaced frames until someone makes CUDA-based
deinterlace filter.
2018-05-03 12:03 GMT+03:00 Timo Rothenpieler
NVENC side of things should be ok now that drivers are fixed and SEI is
reordered together with frames, but on CUVID side it is still pretty bad. I
find it funny that NVIDIA developer submits someone's hackish patch instead
of fixing cuvid parser API and implementing this properly. I mean,
I think first check (ascii case) should be explicit bit-test, or (if there
is some reason to use sign-bit approach) at least "c" should be signed char
instead of simply char.
2018-03-28 6:07 GMT+03:00 Philip Langdale :
> See the earlier fix for movtextdec for details. The
I've had a need for something similar a while back and the best solution I
could come up with was using stackful coroutines to invert code flow.
Basically the main program would fire up the the coroutine, the coroutine
would set up avformat context with custom AVIO (avio's read callback
transfers
I'd like to use this opportunity to remind of
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207513.html
2017-03-20 14:29 GMT+03:00 Michael Niedermayer :
> On Mon, Mar 20, 2017 at 10:14:21AM +0100, Hendrik Leppkes wrote:
> > On Mon, Mar 20, 2017 at 10:11 AM, Carl
av_malloc prefers posix_malloc over _aligned_alloc so realloc and free
functions must be used when posix_malloc is available. This fixes mingw32
builds when using custom allocators.
---
libavutil/mem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/mem.c
it would be good if someone with an access to later versions of the
standard could verify if these limits are still the same.
2016-09-27 6:24 GMT+03:00 Andrey Turkin <andrey.tur...@gmail.com>:
> ISO 18318 reserves PIDs 0x00-0x0F
> DVB also reserves PIDs 0x10-0x1F
> ARIB also reserves
ISO 18318 reserves PIDs 0x00-0x0F
DVB also reserves PIDs 0x10-0x1F
ARIB also reserves PIDs 0x20-0x2F
ATSC also reserves PID 0x1FFB
So, if there is going to be change to permitted PIDs assignment anyway, I
suggest to go with safest choice and use 0x0030-0x1FEF range
2016-09-27 4:41 GMT+03:00
AVFrame already has some support for embedded 608/708 subtitles in a form
of side data (AV_FRAME_DATA_A53_CC tag), and some decoders/encoders already
can handle that.
Main issue with this approach is that video frames can be modified, removed
or duplicated (mainly by video filters but also by
2016-06-07 1:08 GMT+03:00 Timo Rothenpieler :
> +if (ctx->cudecoder) {
> +av_log(avctx, AV_LOG_ERROR, "re-initializing decoder is not
> supported\n");
> +ctx->internal_error = AVERROR(EINVAL);
> +return 0;
> +}
> +
> +if
2016-06-05 21:58 GMT+03:00 Timo Rothenpieler :
> +/* check if the decoder supports CUVID and the output only goes to
> this stream */
> +if (ist->nb_filters || ist->hwaccel_id != HWACCEL_CUVID || !ist->dec
> || !ist->dec->pix_fmts)
> +goto cancel;
> +
2016-06-05 21:58 GMT+03:00 Timo Rothenpieler :
> +
> +avctx->width = format->coded_width;
> +avctx->height = format->coded_height;
> +
>
This patch seems to mix bitstream picture dimensions and output picture
dimensions in several places. Can you test if the
It mimics same options in libx264 and qsv_h264 encoders
---
libavcodec/nvenc.c | 28 ++--
libavcodec/nvenc.h | 1 +
libavcodec/nvenc_h264.c | 1 +
libavcodec/nvenc_hevc.c | 1 +
4 files changed, 29 insertions(+), 2 deletions(-)
diff --git
---
libavcodec/internal.h| 15 +
libavcodec/libx264.c | 49 ++---
libavcodec/qsvenc.c | 4 +--
libavcodec/qsvenc_h264.c | 82 +++-
libavcodec/utils.c | 43 +
5 files changed,
It mimics same options in libx264 and qsv_h264 encoders
---
libavcodec/internal.h| 15 +
libavcodec/libx264.c | 49 ++---
libavcodec/nvenc.c | 28 +++--
libavcodec/nvenc.h | 1 +
libavcodec/nvenc_h264.c | 1 +
ncl_internal.o
OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
@@ -162,7 +162,7 @@ OBJS += $(COMPAT_OBJS:%=../compat/%)
# Windows resource file
SLIBOBJS-$(HAVE_GNU_WINDRES)+= avutilres.o
-SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda.h
+SKIPHEADERS-$(CONFIG_
Yeah, I saw that patch series today. Still should be fixed until the
function goes away. I'll send patch to libav as well shortly.
2016-05-22 16:39 GMT+03:00 Mark Thompson :
> Looks fine; it does fix an immediate problem.
>
> Note that development around hwcontext is mainly
---
libavcodec/nvenc.c | 308 +++--
1 file changed, 251 insertions(+), 57 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index d3856a4..cad554c 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -33,16 +33,31 @@
There is no point in separate structures as they have 1:1 relationship,
they are always used together and they have same lifetime.
---
libavcodec/nvenc.c | 196 -
1 file changed, 105 insertions(+), 91 deletions(-)
diff --git
Functions names and scopes are from libav. This commit basically moves
code around without changing it; it shouldn't change any functionality
except some small leak fixes on error paths.
---
libavcodec/nvenc.c | 1083 ++--
1 file changed, 622
avcodec_copy_context didn't handle hw_frames_ctx references correctly which
could cause crashes.
---
Changes from v1: reverted changes to avcodec_free_context
libavcodec/options.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index
> No: this part of the patch does nothing because it's already unreffed in
the
> avcodec_close() called immediately above. Maybe the unref should
actually be in
> avcodec_free_context() only (if treating it like rc_override and those
fields),
> but it shouldn't be in both.
I missed that, thank
2016-05-13 10:35 GMT+03:00 wm4 <nfx...@googlemail.com>:
> On Thu, 12 May 2016 22:35:48 +0300
> Andrey Turkin <andrey.tur...@gmail.com> wrote:
>
> > Few functions didn't handle hw_frames_ctx references causing resources
> leaks and even crashes.
> >
Slicer is a part of the library and as such is under LGPL; in fact FFmpeg
already uses the library to decode DVB teletext.
2016-01-14 1:27 GMT+03:00 Carl Eugen Hoyos <ceho...@ag.or.at>:
> Andrey Turkin gmail.com> writes:
>
> > Why not use libzvbi's slicer? It should
2016-01-13 22:32 GMT+03:00 Michael Niedermayer :
> to calculate the phase
>
> the area that has alternating 0/1 values can be correlated with a
> sin() and a cos(), if you consider the 2 resulting values as x and y
> coordinates the angle they form from the origin is the
Why not use libzvbi's slicer? It should be pretty robust with
less-than-ideal signal.
Regarding your code - is there a need to calculate a frequency? I did
something similar a while back with VBI from TV signal and in my experience:
a) this kind of frequency/phase estimation doesn't work that
2016-01-08 20:25 GMT+03:00 Michael Niedermayer :
> Also slightly orthogonal but if you have 4 filters each written for a
> different hwaccel you can write a generic filter that passes its
> stuff to the appropriate one
> If theres not much shareale code between hw specific
2016-01-08 12:42 GMT+03:00 Carl Eugen Hoyos :
>
> I may have misunderstood myself but I believe the
> issue actually only happens on Windows XP;-)
>
>
I've encountered this issue a while back when trying to do about 20
simultaneous transcodings with some video filters. It was on
In my opinion this proliferation of various filters which do the same thing
in different way is a configuration headache. There's CPU filters: one for
scaling/format conversion, one for padding, one for cropping, like 5
different filters for deinterlacing. And now there would be nvresize for
ffer for
the padding. There's not; in fact there's no room in the buffer to hold the
view itself - so pad gives up and does another allocation and a copy. So,
basically this patch fixes that.
2016-01-06 0:59 GMT+03:00 Paul B Mahol <one...@gmail.com>:
> On 1/5/16, Andrey Turkin &l
One extra line must be allocated when adding left padding to make sure
that last line in every plane fits in the allocated buffer fully
---
libavfilter/vf_pad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c
index d94ced1..555b318
One extra line must be allocated when adding left padding to make sure
that last line in every plane fits in the allocated buffer fully
---
libavfilter/vf_pad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c
index d94ced1..555b318
35 matches
Mail list logo