[FFmpeg-devel] [PATCH]lavf/mov: Only copy extradata if it exists.
Hi!
Attached patch fixes an ubsan warning like the following here:
libavformat/mov.c:2332:13: runtime error: null pointer passed as argument 2,
which is declared to never be null
Please comment, Carl Eugen
From b117fdd2adf3271fcaf8f9388866aaf115284f74 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 18 Apr 2017 10:56:31 +0200
Subject: [PATCH] lavf/mov: Only copy extradata if it exists.
Avoids undefined call of memcpy(ptr, NULL, 0);
---
libavformat/mov.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2995a00..03fd90e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2321,7 +2321,7 @@ int ff_mov_read_stsd_entries(MOVContext *c, AVIOContext
*pb, int entries)
} else if (a.size > 0)
avio_skip(pb, a.size);
-if (sc->extradata) {
+if (sc->extradata && st->codecpar->extradata) {
int extra_size = st->codecpar->extradata_size;
/* Move the current stream extradata to the stream context one. */
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/motion_est: Fix undefined negative left shifts
Hi! Attached patch fixes the following ubsan errors: libavcodec/motion_est.c:959:42: runtime error: left shift of negative value -16 libavcodec/motion_est.c:960:42: runtime error: left shift of negative value -16 I do not have a testcase for lines 961f. Please comment, Carl Eugen From 4dd1b8d61c5dd2e77b7c855a1d2acf7d90277daf Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Tue, 18 Apr 2017 11:02:30 +0200 Subject: [PATCH] lavc/motion_est: Fix undefined negative left shifts. --- libavcodec/motion_est.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c index 25b606f..316d16a 100644 --- a/libavcodec/motion_est.c +++ b/libavcodec/motion_est.c @@ -956,10 +956,10 @@ void ff_estimate_p_frame_motion(MpegEncContext * s, P_TOPRIGHT[1] = s->current_picture.motion_val[0][mot_xy - mot_stride + 2][1]; if (P_TOP[1] > (c->ymax << shift)) P_TOP[1] = c->ymax << shift; -if (P_TOPRIGHT[0] < (c->xmin << shift)) -P_TOPRIGHT[0] = c->xmin << shift; -if (P_TOPRIGHT[1] > (c->ymax << shift)) -P_TOPRIGHT[1] = c->ymax << shift; +if (P_TOPRIGHT[0] < (c->xmin * (1 << shift))) +P_TOPRIGHT[0] = c->xmin * (1 << shift); +if (P_TOPRIGHT[1] > (c->ymax * (1 << shift))) +P_TOPRIGHT[1] = c->ymax * (1 << shift); P_MEDIAN[0] = mid_pred(P_LEFT[0], P_TOP[0], P_TOPRIGHT[0]); P_MEDIAN[1] = mid_pred(P_LEFT[1], P_TOP[1], P_TOPRIGHT[1]); -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg; check return code of avcodec_send_frame when flushing encoders
On Tue, Apr 18, 2017 at 07:09:30AM +0200, Nicolas George wrote:
> Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit :
> > > +while ((ret = avcodec_receive_packet(enc, &pkt)) ==
> > > AVERROR(EAGAIN)) {
> > > +ret = avcodec_send_frame(enc, NULL);
>
> The doc says:
>
> # The functions will not return AVERROR(EAGAIN), unless you forgot to
> # enter draining mode.
The full paragraph in the docs which you qoted from says this:
* - Call avcodec_receive_frame() (decoding) or avcodec_receive_packet()
* (encoding) in a loop until AVERROR_EOF is returned. The functions will
* not return AVERROR(EAGAIN), unless you forgot to enter draining mode.
the patch adds a check to avcodec_send_frame()
>
> > can the code be changed to not require this ?
>
> I would say the code does not require this as is.
For decoding theres an explicit
"Sending the first flush packet will return success."
I cannot find similar for encoding, which is the case the patch changes
and what i think should be fixed if possible as it would be simpler,
making the patch unneeded.
Its quite possible iam missing something that makes it uneeded though
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
Signed-off-by: Michael Niedermayer --- libavcodec/avcodec.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h index ee133712b5..2ac1523a36 100644 --- a/libavcodec/avcodec.h +++ b/libavcodec/avcodec.h @@ -4960,7 +4960,7 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, AVSubtitle *sub, * Unlike with older APIs, the packet is always fully consumed, * and if it contains multiple frames (e.g. some audio codecs), * will require you to call avcodec_receive_frame() multiple - * times afterwards before you can send a new packet. + * times afterwards. * It can be NULL (or an AVPacket with data set to NULL and * size set to 0); in this case, it is considered a flush * packet, which signals the end of the stream. Sending the -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
Hi, On Tue, Apr 18, 2017 at 6:31 AM, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/avcodec.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > index ee133712b5..2ac1523a36 100644 > --- a/libavcodec/avcodec.h > +++ b/libavcodec/avcodec.h > @@ -4960,7 +4960,7 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, > AVSubtitle *sub, > * Unlike with older APIs, the packet is always fully > consumed, > * and if it contains multiple frames (e.g. some audio > codecs), > * will require you to call avcodec_receive_frame() > multiple > - * times afterwards before you can send a new packet. > + * times afterwards. Does/did this imply single-threaded decoding? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
On Tue, 18 Apr 2017 12:31:25 +0200 Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/avcodec.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > index ee133712b5..2ac1523a36 100644 > --- a/libavcodec/avcodec.h > +++ b/libavcodec/avcodec.h > @@ -4960,7 +4960,7 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, > AVSubtitle *sub, > * Unlike with older APIs, the packet is always fully > consumed, > * and if it contains multiple frames (e.g. some audio > codecs), > * will require you to call avcodec_receive_frame() multiple > - * times afterwards before you can send a new packet. > + * times afterwards. > * It can be NULL (or an AVPacket with data set to NULL and > * size set to 0); in this case, it is considered a flush > * packet, which signals the end of the stream. Sending the How did the old text imply that, and how does the new text remove this implication? Because I can't see either. This removes the important fact that you can't just call receive at "any time", but that it must happen before you call send again. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
On Tue, Apr 18, 2017 at 06:43:07AM -0400, Ronald S. Bultje wrote: > Hi, > > On Tue, Apr 18, 2017 at 6:31 AM, Michael Niedermayer > wrote: > > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/avcodec.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > > index ee133712b5..2ac1523a36 100644 > > --- a/libavcodec/avcodec.h > > +++ b/libavcodec/avcodec.h > > @@ -4960,7 +4960,7 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, > > AVSubtitle *sub, > > * Unlike with older APIs, the packet is always fully > > consumed, > > * and if it contains multiple frames (e.g. some audio > > codecs), > > * will require you to call avcodec_receive_frame() > > multiple > > - * times afterwards before you can send a new packet. > > + * times afterwards. > > > Does/did this imply single-threaded decoding? if you cannot send a new packet before you received the output of the previous then the decoder has only one packet at a time and cannot decode multiple in parallel. ill add above to the commit message [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
On Tue, 18 Apr 2017 13:30:43 +0200 Michael Niedermayer wrote: > On Tue, Apr 18, 2017 at 06:43:07AM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Tue, Apr 18, 2017 at 6:31 AM, Michael Niedermayer > > > > wrote: > > > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavcodec/avcodec.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > > > index ee133712b5..2ac1523a36 100644 > > > --- a/libavcodec/avcodec.h > > > +++ b/libavcodec/avcodec.h > > > @@ -4960,7 +4960,7 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, > > > AVSubtitle *sub, > > > * Unlike with older APIs, the packet is always fully > > > consumed, > > > * and if it contains multiple frames (e.g. some audio > > > codecs), > > > * will require you to call avcodec_receive_frame() > > > multiple > > > - * times afterwards before you can send a new packet. > > > + * times afterwards. > > > > > > Does/did this imply single-threaded decoding? > > if you cannot send a new packet before you received the output of > the previous then the decoder has only one packet at a time and cannot > decode multiple in parallel. > > ill add above to the commit message That's not how it works. I'm against the patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
On Tue, Apr 18, 2017 at 02:14:47PM +0200, wm4 wrote: > On Tue, 18 Apr 2017 13:30:43 +0200 > Michael Niedermayer wrote: > > > On Tue, Apr 18, 2017 at 06:43:07AM -0400, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Tue, Apr 18, 2017 at 6:31 AM, Michael Niedermayer > > > > > > wrote: > > > > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > libavcodec/avcodec.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > > > > index ee133712b5..2ac1523a36 100644 > > > > --- a/libavcodec/avcodec.h > > > > +++ b/libavcodec/avcodec.h > > > > @@ -4960,7 +4960,7 @@ int avcodec_decode_subtitle2(AVCodecContext > > > > *avctx, > > > > AVSubtitle *sub, > > > > * Unlike with older APIs, the packet is always fully > > > > consumed, > > > > * and if it contains multiple frames (e.g. some audio > > > > codecs), > > > > * will require you to call avcodec_receive_frame() > > > > multiple > > > > - * times afterwards before you can send a new packet. > > > > + * times afterwards. > > > > > > > > > Does/did this imply single-threaded decoding? > > > > if you cannot send a new packet before you received the output of > > the previous then the decoder has only one packet at a time and cannot > > decode multiple in parallel. > > > > ill add above to the commit message > > That's not how it works. I'm against the patch. Thats not how patch review works. If you have objections, you have to explain the issue so it can be resolved/clarified. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit : > if you cannot send a new packet before you received the output of > the previous You have to TRY TO receive the output before you send a new packet. A threaded decoder will just start the work and return EAGAIN. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
On Tue, Apr 18, 2017 at 03:23:14PM +0200, Nicolas George wrote: > Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit : > > if you cannot send a new packet before you received the output of > > the previous > > You have to TRY TO receive the output before you send a new packet. A This contradicts the documentation: (and would be rather rigid design) * Using the API as outlined above is highly recommended. But it is also * possible to call functions outside of this rigid schema. For example, you can * call avcodec_send_packet() repeatedly without calling * avcodec_receive_frame(). In this case, avcodec_send_packet() will succeed * until the codec's internal buffer has been filled up (which is typically of * size 1 per output frame, after initial input), and then reject input with * AVERROR(EAGAIN). Once it starts rejecting input, you have no choice but to * read at least some output. > threaded decoder will just start the work and return EAGAIN. Thats true but this is not permitted by the text prior to my patch The requiement to call avcodec_receive_frame() multiple times implies it does not return EAGAIN because you would not call it again if it did. (one might "mathematically" work around this but the result still wont make sense) For reference: @@ -4960,7 +4960,7 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, AVSubtitle *sub, * Unlike with older APIs, the packet is always fully consumed, * and if it contains multiple frames (e.g. some audio codecs), * will require you to call avcodec_receive_frame() multiple - * times afterwards before you can send a new packet. + * times afterwards. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit : > This contradicts the documentation: (and would be rather rigid design) Possible. But it has nothing to do with threading. > > threaded decoder will just start the work and return EAGAIN. > Thats true but this is not permitted by the text prior to my patch Yes it is. > The requiement to call avcodec_receive_frame() multiple times implies > it does not return EAGAIN because you would not call it again if it > did. No, you would not call it again, you would first have to feed it another packet. Still no problem at this level. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
On Tue, Apr 18, 2017 at 03:47:29PM +0200, Nicolas George wrote: > Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit : > > This contradicts the documentation: (and would be rather rigid design) > > Possible. But it has nothing to do with threading. > > > > threaded decoder will just start the work and return EAGAIN. > > Thats true but this is not permitted by the text prior to my patch > > Yes it is. > > > The requiement to call avcodec_receive_frame() multiple times implies > > it does not return EAGAIN because you would not call it again if it > > did. > > No, you would not call it again, you would first have to feed it another > packet. Still no problem at this level. Iam not sure you did read the text the patch changes "... require you to call avcodec_receive_frame() multiple times afterwards before you can send a new packet" this just isnt true if a decoder returns EAGAIN you would not call it multiple times Heres the whole again for reference: * Unlike with older APIs, the packet is always fully consumed, * and if it contains multiple frames (e.g. some audio codecs), * will require you to call avcodec_receive_frame() multiple - * times afterwards before you can send a new packet. + * times afterwards. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit : > Iam not sure you did read the text the patch changes I am replying to the issue about threading. If you find the documentation inconsistent, your commit message must be changed. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
On Tue, Apr 18, 2017 at 04:08:43PM +0200, Nicolas George wrote: > Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit : > > Iam not sure you did read the text the patch changes > > I am replying to the issue about threading. ok, iam trying to stay with the topic of this thread which was fixing the documentation touched by the patch. > > If you find the documentation inconsistent, your commit message must be > changed. Sure, what commit message would you suggest ? Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/motion_est: Fix undefined negative left shifts
On Tue, Apr 18, 2017 at 11:04:34AM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes the following ubsan errors: > libavcodec/motion_est.c:959:42: runtime error: left shift of negative > value -16 > libavcodec/motion_est.c:960:42: runtime error: left shift of negative > value -16 > > I do not have a testcase for lines 961f. > > Please comment, Carl Eugen > motion_est.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > 835e20f48e7c0b1df3bdba09f3723e21a4cfd155 > 0001-lavc-motion_est-Fix-undefined-negative-left-shifts.patch > From 4dd1b8d61c5dd2e77b7c855a1d2acf7d90277daf Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Tue, 18 Apr 2017 11:02:30 +0200 > Subject: [PATCH] lavc/motion_est: Fix undefined negative left shifts. LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] movenc/isom: update vpcC box to the latest draft specification
This brings our generation of the vpcC box up to date to the latest
draft version of the VP Codec ISO Media File Format Binding.
Specifically, color/transfer properties are now written with values
based on ISO/IEC 23001-8, which is the same reference specification the
AVColor* enumerations are based on.
---
libavformat/vpcc.c | 53 -
1 file changed, 4 insertions(+), 49 deletions(-)
diff --git a/libavformat/vpcc.c b/libavformat/vpcc.c
index 2390e1711c..d20ca9edc2 100644
--- a/libavformat/vpcc.c
+++ b/libavformat/vpcc.c
@@ -23,44 +23,6 @@
#include "libavutil/pixfmt.h"
#include "vpcc.h"
-enum VpxColorSpace
-{
-VPX_COLOR_SPACE_UNSPECIFIED = 0,
-VPX_COLOR_SPACE_BT601 = 1,
-VPX_COLOR_SPACE_BT709 = 2,
-VPX_COLOR_SPACE_SMPTE_170 = 3,
-VPX_COLOR_SPACE_SMPTE_240 = 4,
-VPX_COLOR_SPACE_BT2020_NCL = 5,
-VPX_COLOR_SPACE_BT2020_CL = 6,
-VPX_COLOR_SPACE_RGB = 7,
-};
-
-static int get_vpx_color_space(AVFormatContext *s,
- enum AVColorSpace color_space)
-{
-switch (color_space) {
-case AVCOL_SPC_RGB:
-return VPX_COLOR_SPACE_RGB;
-case AVCOL_SPC_BT709:
-return VPX_COLOR_SPACE_BT709;
-case AVCOL_SPC_UNSPECIFIED:
-return VPX_COLOR_SPACE_UNSPECIFIED;
-case AVCOL_SPC_BT470BG:
-return VPX_COLOR_SPACE_BT601;
-case AVCOL_SPC_SMPTE170M:
-return VPX_COLOR_SPACE_SMPTE_170;
-case AVCOL_SPC_SMPTE240M:
-return VPX_COLOR_SPACE_SMPTE_240;
-case AVCOL_SPC_BT2020_NCL:
-return VPX_COLOR_SPACE_BT2020_NCL;
-case AVCOL_SPC_BT2020_CL:
-return VPX_COLOR_SPACE_BT2020_CL;
-default:
-av_log(s, AV_LOG_ERROR, "Unsupported color space (%d)\n", color_space);
-return -1;
-}
-}
-
enum VPX_CHROMA_SUBSAMPLING
{
VPX_SUBSAMPLING_420_VERTICAL = 0,
@@ -100,12 +62,6 @@ static int get_bit_depth(AVFormatContext *s, enum
AVPixelFormat pixel_format)
return desc->comp[0].depth;
}
-static int get_vpx_transfer_function(
-enum AVColorTransferCharacteristic transfer)
-{
-return transfer == AVCOL_TRC_SMPTEST2084;
-}
-
static int get_vpx_video_full_range_flag(enum AVColorRange color_range)
{
return color_range == AVCOL_RANGE_JPEG;
@@ -117,10 +73,8 @@ int ff_isom_write_vpcc(AVFormatContext *s, AVIOContext *pb,
int profile = par->profile;
int level = par->level == FF_LEVEL_UNKNOWN ? 0 : par->level;
int bit_depth = get_bit_depth(s, par->format);
-int vpx_color_space = get_vpx_color_space(s, par->color_space);
int vpx_chroma_subsampling =
get_vpx_chroma_subsampling(s, par->format, par->chroma_location);
-int vpx_transfer_function = get_vpx_transfer_function(par->color_trc);
int vpx_video_full_range_flag =
get_vpx_video_full_range_flag(par->color_range);
@@ -138,9 +92,10 @@ int ff_isom_write_vpcc(AVFormatContext *s, AVIOContext *pb,
avio_w8(pb, profile);
avio_w8(pb, level);
-avio_w8(pb, (bit_depth << 4) | vpx_color_space);
-avio_w8(pb, (vpx_chroma_subsampling << 4) | (vpx_transfer_function << 1) |
-vpx_video_full_range_flag);
+avio_w8(pb, (bit_depth << 4) | (vpx_chroma_subsampling << 1) |
vpx_video_full_range_flag);
+avio_w8(pb, par->color_primaries);
+avio_w8(pb, par->color_trc);
+avio_w8(pb, par->color_space);
// vp9 does not have codec initialization data.
avio_wb16(pb, 0);
--
2.12.2.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mov: Only copy extradata if it exists.
On Tue, Apr 18, 2017 at 10:59:31AM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes an ubsan warning like the following here: > libavformat/mov.c:2332:13: runtime error: null pointer passed as argument 2, > which is declared to never be null > > Please comment, Carl Eugen > mov.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 6e412b49316b5c6529c476233d54723c24b1d740 > 0001-lavf-mov-Only-copy-extradata-if-it-exists.patch > From b117fdd2adf3271fcaf8f9388866aaf115284f74 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Tue, 18 Apr 2017 10:56:31 +0200 > Subject: [PATCH] lavf/mov: Only copy extradata if it exists. > > Avoids undefined call of memcpy(ptr, NULL, 0); > --- > libavformat/mov.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc/isom: update vpcC box to the latest draft specification
Hi, On Tue, Apr 18, 2017 at 10:30 AM, Hendrik Leppkes wrote: > This brings our generation of the vpcC box up to date to the latest > draft version of the VP Codec ISO Media File Format Binding. > > Specifically, color/transfer properties are now written with values > based on ISO/IEC 23001-8, which is the same reference specification the > AVColor* enumerations are based on. > --- > libavformat/vpcc.c | 53 -- > --- > 1 file changed, 4 insertions(+), 49 deletions(-) Cool! Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc/isom: update vpcC box to the latest draft specification
On Tue, Apr 18, 2017 at 04:30:12PM +0200, Hendrik Leppkes wrote: > This brings our generation of the vpcC box up to date to the latest > draft version of the VP Codec ISO Media File Format Binding. > > Specifically, color/transfer properties are now written with values > based on ISO/IEC 23001-8, which is the same reference specification the > AVColor* enumerations are based on. > --- > libavformat/vpcc.c | 53 - > 1 file changed, 4 insertions(+), 49 deletions(-) fails to build here: libavformat/vpcc.c: In function ‘ff_isom_write_vpcc’: libavformat/vpcc.c:81:26: error: ‘vpx_color_space’ undeclared (first use in this function) libavformat/vpcc.c:81:26: note: each undeclared identifier is reported only once for each function it appears in i assume iam missing some change ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] movenc/isom: update vpcC box to the latest draft specification
This brings our generation of the vpcC box up to date to the latest
draft version of the VP Codec ISO Media File Format Binding.
Specifically, color/transfer properties are now written with values
based on ISO/IEC 23001-8, which is the same reference specification the
AVColor* enumerations are based on.
---
libavformat/vpcc.c | 55 +-
1 file changed, 5 insertions(+), 50 deletions(-)
diff --git a/libavformat/vpcc.c b/libavformat/vpcc.c
index 2390e1711c..df08de59a6 100644
--- a/libavformat/vpcc.c
+++ b/libavformat/vpcc.c
@@ -23,44 +23,6 @@
#include "libavutil/pixfmt.h"
#include "vpcc.h"
-enum VpxColorSpace
-{
-VPX_COLOR_SPACE_UNSPECIFIED = 0,
-VPX_COLOR_SPACE_BT601 = 1,
-VPX_COLOR_SPACE_BT709 = 2,
-VPX_COLOR_SPACE_SMPTE_170 = 3,
-VPX_COLOR_SPACE_SMPTE_240 = 4,
-VPX_COLOR_SPACE_BT2020_NCL = 5,
-VPX_COLOR_SPACE_BT2020_CL = 6,
-VPX_COLOR_SPACE_RGB = 7,
-};
-
-static int get_vpx_color_space(AVFormatContext *s,
- enum AVColorSpace color_space)
-{
-switch (color_space) {
-case AVCOL_SPC_RGB:
-return VPX_COLOR_SPACE_RGB;
-case AVCOL_SPC_BT709:
-return VPX_COLOR_SPACE_BT709;
-case AVCOL_SPC_UNSPECIFIED:
-return VPX_COLOR_SPACE_UNSPECIFIED;
-case AVCOL_SPC_BT470BG:
-return VPX_COLOR_SPACE_BT601;
-case AVCOL_SPC_SMPTE170M:
-return VPX_COLOR_SPACE_SMPTE_170;
-case AVCOL_SPC_SMPTE240M:
-return VPX_COLOR_SPACE_SMPTE_240;
-case AVCOL_SPC_BT2020_NCL:
-return VPX_COLOR_SPACE_BT2020_NCL;
-case AVCOL_SPC_BT2020_CL:
-return VPX_COLOR_SPACE_BT2020_CL;
-default:
-av_log(s, AV_LOG_ERROR, "Unsupported color space (%d)\n", color_space);
-return -1;
-}
-}
-
enum VPX_CHROMA_SUBSAMPLING
{
VPX_SUBSAMPLING_420_VERTICAL = 0,
@@ -100,12 +62,6 @@ static int get_bit_depth(AVFormatContext *s, enum
AVPixelFormat pixel_format)
return desc->comp[0].depth;
}
-static int get_vpx_transfer_function(
-enum AVColorTransferCharacteristic transfer)
-{
-return transfer == AVCOL_TRC_SMPTEST2084;
-}
-
static int get_vpx_video_full_range_flag(enum AVColorRange color_range)
{
return color_range == AVCOL_RANGE_JPEG;
@@ -117,14 +73,12 @@ int ff_isom_write_vpcc(AVFormatContext *s, AVIOContext *pb,
int profile = par->profile;
int level = par->level == FF_LEVEL_UNKNOWN ? 0 : par->level;
int bit_depth = get_bit_depth(s, par->format);
-int vpx_color_space = get_vpx_color_space(s, par->color_space);
int vpx_chroma_subsampling =
get_vpx_chroma_subsampling(s, par->format, par->chroma_location);
-int vpx_transfer_function = get_vpx_transfer_function(par->color_trc);
int vpx_video_full_range_flag =
get_vpx_video_full_range_flag(par->color_range);
-if (bit_depth < 0 || vpx_color_space < 0 || vpx_chroma_subsampling < 0)
+if (bit_depth < 0 || vpx_chroma_subsampling < 0)
return AVERROR_INVALIDDATA;
if (profile == FF_PROFILE_UNKNOWN) {
@@ -138,9 +92,10 @@ int ff_isom_write_vpcc(AVFormatContext *s, AVIOContext *pb,
avio_w8(pb, profile);
avio_w8(pb, level);
-avio_w8(pb, (bit_depth << 4) | vpx_color_space);
-avio_w8(pb, (vpx_chroma_subsampling << 4) | (vpx_transfer_function << 1) |
-vpx_video_full_range_flag);
+avio_w8(pb, (bit_depth << 4) | (vpx_chroma_subsampling << 1) |
vpx_video_full_range_flag);
+avio_w8(pb, par->color_primaries);
+avio_w8(pb, par->color_trc);
+avio_w8(pb, par->color_space);
// vp9 does not have codec initialization data.
avio_wb16(pb, 0);
--
2.12.2.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] movenc/isom: update vpcC box to the latest draft specification
On Tue, Apr 18, 2017 at 4:47 PM, Michael Niedermayer wrote: > On Tue, Apr 18, 2017 at 04:30:12PM +0200, Hendrik Leppkes wrote: >> This brings our generation of the vpcC box up to date to the latest >> draft version of the VP Codec ISO Media File Format Binding. >> >> Specifically, color/transfer properties are now written with values >> based on ISO/IEC 23001-8, which is the same reference specification the >> AVColor* enumerations are based on. >> --- >> libavformat/vpcc.c | 53 >> - >> 1 file changed, 4 insertions(+), 49 deletions(-) > > fails to build here: > > libavformat/vpcc.c: In function ‘ff_isom_write_vpcc’: > libavformat/vpcc.c:81:26: error: ‘vpx_color_space’ undeclared (first use in > this function) > libavformat/vpcc.c:81:26: note: each undeclared identifier is reported only > once for each function it appears in > > i assume iam missing some change ? > I failed to add a hunk to the patch, new one coming up. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for CUDA Scale Filter
On Mon, Apr 17, 2017 at 2:51 PM, Timo Rothenpieler wrote: >>> I'm generally in favor of adding CUDA based filtering, there's a lot of >>> nice stuff that could be done that way. >>> >>> But there is one big issue with this approach: >>> >>> Having to run a .bat file prior to building isn't really nice, and not >>> something I and some other people on IRC would like to see in ffmpeg. >>> >>> Instead, it would be nice if configure/make would learn how to handle >>> .cu files, converting them straight to an object-file. >>> My idea for this would be to teach the Makefiles about .cu files, and >>> using a shell script as their compiler. >>> That script can then call nvcc and include the ptx2c functionality, and >>> additionally also calls the designated C compiler, so for the build >>> system it converts .cu to .o. >>> >>> Also, due to these kind of filters having to include cuda.h, they need >>> to be put behind --enable-nonfree in configure. >>> >>> That's what I have in mind so far. I didn't have time for a full review >>> of the code yet, so can't say much about the filter itself. >> >> >> I'm against. Building the "script" seems pretty terribly complicated, >> and adding generated code is usually not what we do in this project. >> This is probably done better with a d3d11 video scale filter, although >> I'm not sure about the tradeoffs yet. > > > That's exactly what I said though? Making configure/make generate the code > at build time, so the generated code is not in the repo, only the actual .cu > file. > > One problem with that is, that nvcc require cl.exe on Windows, it doesn't > work with gcc. So that would limit it to MSVC builds on Windows, which is > fine with me. > FWIW there are non-nvcc cuda compilers that run on Windows, like clang. http://llvm.org/docs/CompileCudaWithLLVM.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] HLS, add option to skip down streams
option to skip down streams in HLS
>From 14eb94c48fddf92d63d7d7030689a625a4228740 Mon Sep 17 00:00:00 2001
From: amine kabab
Date: Tue, 18 Apr 2017 15:12:38 +
Subject: [PATCH] HLS, add option to skip down streams
---
libavformat/hls.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4..d962956 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -194,6 +194,7 @@ typedef struct HLSContext {
int cur_seq_no;
int live_start_index;
+int skip_down_streams;
int first_packet;
int64_t first_timestamp;
int64_t cur_timestamp;
@@ -1652,11 +1653,20 @@ static int hls_read_header(AVFormatContext *s)
/* If the playlist only contained playlists (Master Playlist),
* parse each individual playlist. */
if (c->n_playlists > 1 || c->playlists[0]->n_segments == 0) {
+int all_failed = 1;
for (i = 0; i < c->n_playlists; i++) {
struct playlist *pls = c->playlists[i];
-if ((ret = parse_playlist(c, pls->url, pls, NULL)) < 0)
+av_log(NULL, AV_LOG_WARNING, "Trying %s\n", pls->url);
+ret = parse_playlist(c, pls->url, pls, NULL);
+if (c->skip_down_streams && ret < 0) {
+all_failed = 0;
+} else if(ret < 0) {
goto fail;
+}
}
+
+if (all_failed)
+goto fail;
}
if (c->variants[0]->playlists[0]->n_segments == 0) {
@@ -2126,6 +2136,8 @@ static int hls_probe(AVProbeData *p)
static const AVOption hls_options[] = {
{"live_start_index", "segment index to start live streams at (negative
values are from the end)",
OFFSET(live_start_index), AV_OPT_TYPE_INT, {.i64 = -3}, INT_MIN,
INT_MAX, FLAGS},
+{"skip_down_streams", "continue playback of HLS when one of the variant
streams are down",
+OFFSET(skip_down_streams), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS},
{NULL}
};
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for CUDA Scale Filter
FWIW there are non-nvcc cuda compilers that run on Windows, like clang. http://llvm.org/docs/CompileCudaWithLLVM.html As this needs nonfree anyway, it might as well use NVRTC and compile the code at runtime, same way OpenCL does it. That's probably even easier than fiddling with integrating nvcc into the build process, and also allows for it to work on Windows with MinGW builds. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add deflicker filter
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_deflicker.c | 327 +
3 files changed, 329 insertions(+)
create mode 100644 libavfilter/vf_deflicker.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index d6daa7a..6de7cc0 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -155,6 +155,7 @@ OBJS-$(CONFIG_DCTDNOIZ_FILTER) +=
vf_dctdnoiz.o
OBJS-$(CONFIG_DEBAND_FILTER) += vf_deband.o
OBJS-$(CONFIG_DECIMATE_FILTER) += vf_decimate.o
OBJS-$(CONFIG_DEFLATE_FILTER)+= vf_neighbor.o
+OBJS-$(CONFIG_DEFLICKER_FILTER) += vf_deflicker.o
OBJS-$(CONFIG_DEINTERLACE_QSV_FILTER)+= vf_deinterlace_qsv.o
OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER) += vf_deinterlace_vaapi.o
OBJS-$(CONFIG_DEJUDDER_FILTER) += vf_dejudder.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ec6ec04..0e69f99 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -166,6 +166,7 @@ static void register_all(void)
REGISTER_FILTER(DEBAND, deband, vf);
REGISTER_FILTER(DECIMATE, decimate, vf);
REGISTER_FILTER(DEFLATE,deflate,vf);
+REGISTER_FILTER(DEFLICKER, deflicker, vf);
REGISTER_FILTER(DEINTERLACE_QSV,deinterlace_qsv,vf);
REGISTER_FILTER(DEINTERLACE_VAAPI, deinterlace_vaapi, vf);
REGISTER_FILTER(DEJUDDER, dejudder, vf);
diff --git a/libavfilter/vf_deflicker.c b/libavfilter/vf_deflicker.c
new file mode 100644
index 000..5e9d957
--- /dev/null
+++ b/libavfilter/vf_deflicker.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+
+#define FF_BUFQUEUE_SIZE 129
+#include "bufferqueue.h"
+
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+#define SIZE FF_BUFQUEUE_SIZE
+
+typedef struct DeflickerContext {
+const AVClass *class;
+
+int eof;
+int depth;
+int nb_planes;
+int planewidth[4];
+int planeheight[4];
+
+uint64_t *histogram;
+float luminance[SIZE];
+
+struct FFBufQueue q;
+int size;
+int available;
+
+float (*calc_avgy)(AVFilterContext *ctx, AVFrame *in);
+int (*deflicker)(AVFilterContext *ctx, AVFrame *in, AVFrame *out);
+} DeflickerContext;
+
+#define OFFSET(x) offsetof(DeflickerContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption deflicker_options[] = {
+{ "s", "set how many frames to use",OFFSET(size),
AV_OPT_TYPE_INT, {.i64=5}, 2, SIZE, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(deflicker);
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pixel_fmts[] = {
+AV_PIX_FMT_GRAY8,
+AV_PIX_FMT_GRAY10,
+AV_PIX_FMT_GRAY12,
+AV_PIX_FMT_GRAY16,
+AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P,
+AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P,
+AV_PIX_FMT_YUVJ440P, AV_PIX_FMT_YUVJ444P,
+AV_PIX_FMT_YUVJ411P,
+AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV444P9,
+AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV440P10,
+AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12,
+AV_PIX_FMT_YUV440P12,
+AV_PIX_FMT_YUV444P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV420P14,
+AV_PIX_FMT_YUV420P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_NONE
+};
+AVFilterFormats *formats = ff_make_format_list(pixel_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+return ff_set_common_formats(ctx, formats);
+}
+
+static int deflicker8(AVFilterContext *ctx, AVFrame *in, AVFrame *out)
+{
+DeflickerContext *s = ctx->priv;
+const int h = s->planeheight[0];
+const int w = s->planewidth[0];
+const uint8_t *src = in->data[0];
+uint8_t *dst =
Re: [FFmpeg-devel] [PATCH]lavc/pnmdec: Do not fail by default for truncated pbm files
On Tue, Oct 11, 2016 at 11:16:48AM +0200, Michael Niedermayer wrote: > On Tue, Oct 11, 2016 at 10:06:54AM +0200, Carl Eugen Hoyos wrote: > > 2016-09-05 11:12 GMT+02:00 Carl Eugen Hoyos : > > > 2016-09-05 10:26 GMT+02:00 Paul B Mahol : > > >> On 9/5/16, Carl Eugen Hoyos wrote: > > > > > >>> New patch attached. > > >> > > >> It seems this patch disables check for all cases when experimental is > > >> enabled, > > >> but check for overflow in only one case. > > > > > > I am not sure I understand: > > > Do you mean I missed a case where an overflow is now (after the patch) > > > possible (but wasn't before) or do you mean there are formats after the > > > patch that allow truncation and formats that do not allow it? > > > > Ping. > > i didnt look at the code but from the diff it seems what was > meant was that bytestream + n could point outside the array > that is indeed (suprising to many) undefined, you dont need to do > bytestream[n] i just stumbled across this again the correct way to check for the end (overflow wise) is if (n > s->bytestream_end - s->bytestream) ... also ptr[] should be memset (probably to 0) when there is no more input [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj
On Fri, Sep 09, 2016 at 11:15:32AM +0300, Ligverd Haer wrote: > > > missing commit mesage / not a proper git patch > ... > > this looks unrelated, unrelated changes need to be in separate patches > > > > please explain in the commit messages of the patch(es) what each > > patch does, why it does it and if you have at hand any reference to > > specs feel free to include them > > > > floats make the binary output code platform dependant, theres no > > need to use floats here > > Thanks for the positive comments Michael. > > 0001-libavformat-dashenc.c-fix-validation-manifest.mpd.patch > 1. If the MPD is dynamic the Period element shall have an id. > 2. Attribute ‘bandwidth’ must appear on element ‘Representation’ > 3. Attribute > [profiles,width,height,sar,frameRate,audioSamplingRate,mimeType,segmentProfiles,codecs,maximumSAPPeriod,startWithSAP,maxPlayoutRate,codingDependency,scanType] >Common attributes for AdaptationSet and Representation shall either be in > one of the elements but not in both. > the tests were conducted on http://www-itec.uni-klu.ac.at/dash/?page_id=605 > > 0002-libavformat-dashenc.c-calculation-bandwidth-for-mani.patch > When stream encoding is not counted bandwidth which makes it impossible to > properly switch to the desired stream. > Use float I removed. Now the calculation accuracy decreased to kilobits. > Is it possible to supply test division by 0 ? > > 0003-libavformat-dashenc.c-change-moveflags-works-better.patch > Replaced flags movflags. These flags input rtsp stream looked better. Sorry for the late reply, i was hoping someone who knows dash well would look at this and then i forgot patch1 still applies cleanly patches2 and 3 dont patch1 removes the storage of the framerate this leaves several unused variables. Most likely the framerate should be stored differently instead of not storing it anymore but certainly no unused variables should remain thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg; check return code of avcodec_send_frame when flushing encoders
On Tue, 18 Apr 2017, Michael Niedermayer wrote:
On Tue, Apr 18, 2017 at 07:09:30AM +0200, Nicolas George wrote:
Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit :
+while ((ret = avcodec_receive_packet(enc, &pkt)) ==
AVERROR(EAGAIN)) {
+ret = avcodec_send_frame(enc, NULL);
The doc says:
# The functions will not return AVERROR(EAGAIN), unless you forgot to
# enter draining mode.
The full paragraph in the docs which you qoted from says this:
* - Call avcodec_receive_frame() (decoding) or avcodec_receive_packet()
* (encoding) in a loop until AVERROR_EOF is returned. The functions will
* not return AVERROR(EAGAIN), unless you forgot to enter draining mode.
the patch adds a check to avcodec_send_frame()
can the code be changed to not require this ?
I would say the code does not require this as is.
For decoding theres an explicit
"Sending the first flush packet will return success."
As far as I see this sentence is only true if there was no decoding error
in the legacy API during a flush. So this should probably be changed to
something like "The first flush packet will not return AVERROR_EOF, if it
returns success then any subsequent flush packets will return
AVERROR_EOF." By the way we also guarantee this at libavcodec level, so
it is harder to write a codec with the new API which violates this.
I cannot find similar for encoding, which is the case the patch changes
and what i think should be fixed if possible as it would be simpler,
making the patch unneeded.
Its quite possible iam missing something that makes it uneeded though
The same is true for send_frame, based on the code involving the legacy
API.
We can of course decide to change the code involving the legacy API and
enforce that flushing always succeed, but I'd rather keep it as is, even
if that means a bit more error checking. It would be ugly API-wise that
you sometimes have to check the return value of a function, sometimes you
don't.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg; check return code of avcodec_send_frame when flushing encoders
On Tue, Apr 18, 2017 at 08:46:24PM +0200, Marton Balint wrote:
>
>
> On Tue, 18 Apr 2017, Michael Niedermayer wrote:
>
> >On Tue, Apr 18, 2017 at 07:09:30AM +0200, Nicolas George wrote:
> >>Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit :
> +while ((ret = avcodec_receive_packet(enc, &pkt)) ==
> AVERROR(EAGAIN)) {
> +ret = avcodec_send_frame(enc, NULL);
> >>
> >>The doc says:
> >>
> >># The functions will not return AVERROR(EAGAIN), unless you forgot to
> >># enter draining mode.
> >
> >The full paragraph in the docs which you qoted from says this:
> >* - Call avcodec_receive_frame() (decoding) or avcodec_receive_packet()
> >* (encoding) in a loop until AVERROR_EOF is returned. The functions will
> >* not return AVERROR(EAGAIN), unless you forgot to enter draining mode.
> >
> >the patch adds a check to avcodec_send_frame()
> >
> >
> >>
> >>>can the code be changed to not require this ?
> >>
> >>I would say the code does not require this as is.
> >
> >For decoding theres an explicit
> >"Sending the first flush packet will return success."
>
> As far as I see this sentence is only true if there was no decoding
> error in the legacy API during a flush. So this should probably be
> changed to something like "The first flush packet will not return
> AVERROR_EOF, if it returns success then any subsequent flush packets
> will return AVERROR_EOF." By the way we also guarantee this at
> libavcodec level, so it is harder to write a codec with the new API
> which violates this.
>
> >I cannot find similar for encoding, which is the case the patch changes
> >and what i think should be fixed if possible as it would be simpler,
> >making the patch unneeded.
> >Its quite possible iam missing something that makes it uneeded though
>
> The same is true for send_frame, based on the code involving the
> legacy API.
>
> We can of course decide to change the code involving the legacy API
> and enforce that flushing always succeed, but I'd rather keep it as
> is, even if that means a bit more error checking. It would be ugly
> API-wise that you sometimes have to check the return value of a
> function, sometimes you don't.
iam happy with any solution or the patch as is
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Development Services Inquiry
Hello, I am looking for a software development that allows me to stream synchronously multiple tracks of video and audio recorded in matroska format to ios and android devices. Please contact me at amang...@gmail.com. Thank you very much, Andres Manguel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/movenc: Explicitly address potential division by zero.
find_fps attempts to infer framerate from AVCodec's timebase. When this
results in a frame rate that isn't explicitly marked as supported in
av_timecode_check_frame_rate, find_fps returns the AVStream's
avg_frame_rate, which, per avformat.h, _may_ be set (or not).
mov_get_mpeg2_xdcam_codec_tag, mov_get_h264_codec_tag and
find_compressor attempt to call av_q2d on the return value of find_fps,
which in the above case, may result in division by zero.
---
libavformat/movenc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e6e2313c53..0e337d5258 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1326,7 +1326,10 @@ static int mov_get_mpeg2_xdcam_codec_tag(AVFormatContext
*s, MOVTrack *track)
int tag = track->par->codec_tag;
int interlaced = track->par->field_order > AV_FIELD_PROGRESSIVE;
AVStream *st = track->st;
-int rate = av_q2d(find_fps(s, st));
+AVRational rational_framerate = find_fps(s, st);
+int rate = 0;
+if (rational_framerate.den != 0)
+ rate = av_q2d(rational_framerate);
if (!tag)
tag = MKTAG('m', '2', 'v', '1'); //fallback tag
@@ -1388,7 +1391,10 @@ static int mov_get_h264_codec_tag(AVFormatContext *s,
MOVTrack *track)
int tag = track->par->codec_tag;
int interlaced = track->par->field_order > AV_FIELD_PROGRESSIVE;
AVStream *st = track->st;
-int rate = av_q2d(find_fps(s, st));
+AVRational rational_framerate = find_fps(s, st);
+int rate = 0;
+if (rational_framerate.den != 0)
+ rate = av_q2d(rational_framerate);
if (!tag)
tag = MKTAG('a', 'v', 'c', 'i'); //fallback tag
@@ -1850,7 +1856,10 @@ static void find_compressor(char * compressor_name, int
len, MOVTrack *track)
} else if (track->par->codec_id == AV_CODEC_ID_MPEG2VIDEO && xdcam_res) {
int interlaced = track->par->field_order > AV_FIELD_PROGRESSIVE;
AVStream *st = track->st;
-int rate = av_q2d(find_fps(NULL, st));
+AVRational rational_framerate = find_fps(NULL, st);
+int rate = 0;
+if (rational_framerate.den != 0)
+ rate = av_q2d(rational_framerate);
av_strlcatf(compressor_name, len, "XDCAM");
if (track->par->format == AV_PIX_FMT_YUV422P) {
av_strlcatf(compressor_name, len, " HD422");
--
2.12.2.816.g281164-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: Explicitly address potential division by zero.
On Wed, Apr 19, 2017 at 12:34 AM, Lucas Cooper wrote: > find_fps attempts to infer framerate from AVCodec's timebase. When this > results in a frame rate that isn't explicitly marked as supported in > av_timecode_check_frame_rate, find_fps returns the AVStream's > avg_frame_rate, which, per avformat.h, _may_ be set (or not). > > mov_get_mpeg2_xdcam_codec_tag, mov_get_h264_codec_tag and > find_compressor attempt to call av_q2d on the return value of find_fps, > which in the above case, may result in division by zero. Floating point division by zero is not an error (as av_q2d performs), and in these cases the wrong return value is likely harmless. What is the actual error you are trying to fix? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
On Tue, 18 Apr 2017 16:01:48 +0200 Michael Niedermayer wrote: > On Tue, Apr 18, 2017 at 03:47:29PM +0200, Nicolas George wrote: > > Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit : > > > This contradicts the documentation: (and would be rather rigid design) > > > > Possible. But it has nothing to do with threading. > > > > > > threaded decoder will just start the work and return EAGAIN. > > > Thats true but this is not permitted by the text prior to my patch > > > > Yes it is. > > > > > > The requiement to call avcodec_receive_frame() multiple times implies > > > it does not return EAGAIN because you would not call it again if it > > > did. > > > > No, you would not call it again, you would first have to feed it another > > packet. Still no problem at this level. > > Iam not sure you did read the text the patch changes > > "... require you to call avcodec_receive_frame() multiple > times afterwards before you can send a new packet" > > this just isnt true > if a decoder returns EAGAIN you would not call it multiple times > The decoder is free to do whatever it pleases. It _could_ force the API user to "receive" multiple frames immediately, or it could buffer multiple packets/frames internally and make the user "receive" them at a later point. The whole point of the API is to make this data flow more flexible. The whole point about the sentence your patch changes is that you do not somehow feed parts of the previous packet to new "send" invocations, like the old audio decode API did. Feel free to improve the docs (they surely are not perfect), but I don't think your patch does. It seems to sort of miss the point. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Development Services Inquiry
Hello, I am looking for a software development that allows me to stream synchronously multiple tracks of video and audio recorded in matroska format to ios and android devices. Please contact me at amang...@gmail.com. Thank you very much, Andres Manguel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: [PATCH] added expr evaluation to drawtext - fontsize
On Mon, Apr 17, 2017 at 5:48 PM, Michael Niedermayer wrote:
> On Sun, Apr 16, 2017 at 10:01:01PM -0700, Brett Harrison wrote:
> > Any comments on this patch?
> >
> > -- Forwarded message --
> > From: Brett Harrison
> > Date: Tue, Apr 11, 2017 at 1:37 PM
> > Subject: Re: [FFmpeg-devel] [PATCH] added expr evaluation to drawtext -
> > fontsize
> > To: FFmpeg development discussions and patches
> >
> >
> > Pinging for comments / review...
> >
> > On Tue, Apr 4, 2017 at 3:45 PM, Brett Harrison <
> brett.harri...@zyamusic.com>
> > wrote:
> >
> > > Resurrecting this patch.
> > >
> > > On Thu, Sep 15, 2016 at 3:20 AM, Michael Niedermayer <
> > > mich...@niedermayer.cc> wrote:
> > >
> > >> On Fri, Sep 09, 2016 at 05:26:03PM -0700, Brett Harrison wrote:
> > >> > Here are the changes requested
> > >> [...]
> > >> > +static av_cold int parse_fontsize(AVFilterContext *ctx)
> > >> > +{
> > >> > +DrawTextContext *s = ctx->priv;
> > >> > +int err;
> > >> > +
> > >> > +if (s->fontsize_expr == NULL)
> > >> > +return AVERROR(EINVAL);
> > >> > +
> > >> > +av_expr_free(s->fontsize_pexpr);
> > >> > +s->fontsize_pexpr = NULL;
> > >> > +
> > >> > +if ((err = av_expr_parse(&s->fontsize_pexpr, s->fontsize_expr,
> > >> var_names,
> > >> > + NULL, NULL, fun2_names, fun2, 0,
> ctx)) <
> > >> 0)
> > >> > +return err;
> > >> > +
> > >> > +return 0;
> > >> > +}
> > >>
> > >> why is av_expr_parse() not executed where the other av_expr_parse()
> > >> are ?
> > >>
> > >
> > > I needed to perform av_expr_parse() during init() to resolve the
> default
> > > fontsize. init() is called before config_input() where the other
> > > av_expr_parse() calls are.
> > >
> > >
>
> > vf_drawtext.c | 125 ++
>
> > 1 file changed, 108 insertions(+), 17 deletions(-)
> > 085506596906b7f89f46edf6d21d34374e92d994 0001-added-expr-evaluation-to-
> drawtext-fontsize.patch
> > From 8647e01f8ac2cd622e0ff5c1257773cfffa01ed9 Mon Sep 17 00:00:00 2001
> > From: Brett Harrison
> > Date: Tue, 4 Apr 2017 15:39:06 -0700
> > Subject: [PATCH] added expr evaluation to drawtext - fontsize
> >
> > ---
> > libavfilter/vf_drawtext.c | 125 ++
> +---
> > 1 file changed, 108 insertions(+), 17 deletions(-)
> >
> > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> > index 8b24f50..77209f3 100644
> > --- a/libavfilter/vf_drawtext.c
> > +++ b/libavfilter/vf_drawtext.c
> > @@ -156,7 +156,10 @@ typedef struct DrawTextContext {
> > int max_glyph_h;///< max glyph height
> > int shadowx, shadowy;
> > int borderw;///< border width
> > +char *fontsize_expr;///< expression for fontsize
> > +AVExpr *fontsize_pexpr; ///< parsed expressions for fontsize
> > unsigned int fontsize; ///< font size to use
> > +unsigned int default_fontsize; ///< default font size to use
> >
> > int line_spacing; ///< lines spacing in pixels
> > short int draw_box; ///< draw box around text - true or
> false
> > @@ -211,7 +214,7 @@ static const AVOption drawtext_options[]= {
> > {"box", "set box", OFFSET(draw_box),
> AV_OPT_TYPE_BOOL, {.i64=0}, 0,1 , FLAGS},
> > {"boxborderw", "set box border width", OFFSET(boxborderw),
> AV_OPT_TYPE_INT,{.i64=0}, INT_MIN, INT_MAX , FLAGS},
> > {"line_spacing", "set line spacing in pixels",
> OFFSET(line_spacing), AV_OPT_TYPE_INT,{.i64=0}, INT_MIN,
> INT_MAX,FLAGS},
> > -{"fontsize","set font size",OFFSET(fontsize),
> AV_OPT_TYPE_INT,{.i64=0}, 0,INT_MAX , FLAGS},
> > +{"fontsize","set font size",OFFSET(fontsize_expr),
> AV_OPT_TYPE_STRING, {.str=NULL}, CHAR_MIN, CHAR_MAX , FLAGS},
> > {"x", "set x expression", OFFSET(x_expr),
> AV_OPT_TYPE_STRING, {.str="0"}, CHAR_MIN, CHAR_MAX, FLAGS},
> > {"y", "set y expression", OFFSET(y_expr),
> AV_OPT_TYPE_STRING, {.str="0"}, CHAR_MIN, CHAR_MAX, FLAGS},
> > {"shadowx", "set shadow x offset", OFFSET(shadowx),
> AV_OPT_TYPE_INT,{.i64=0}, INT_MIN, INT_MAX , FLAGS},
> > @@ -281,6 +284,7 @@ typedef struct Glyph {
> > FT_Glyph glyph;
> > FT_Glyph border_glyph;
> > uint32_t code;
> > +unsigned int fontsize;
> > FT_Bitmap bitmap; ///< array holding bitmaps of font
> > FT_Bitmap border_bitmap; ///< array holding bitmaps of font border
> > FT_BBox bbox;
> > @@ -293,7 +297,11 @@ static int glyph_cmp(const void *key, const void *b)
> > {
> > const Glyph *a = key, *bb = b;
> > int64_t diff = (int64_t)a->code - (int64_t)bb->code;
> > -return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> > +
> > +if (diff != 0)
> > + return diff > 0 ? 1 : -1;
> > +else
> > + return FFDI
Re: [FFmpeg-devel] Development Services Inquiry
On Tue, 18 Apr 2017 22:19:45 -0300 Andres Manguel wrote: > Hello, > I am looking for a software development that allows me to stream > synchronously multiple tracks of video and audio recorded in matroska format > to ios and android devices. > > Please contact me at amang...@gmail.com. Your first mail already made it to the list, now it's here twice: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/210342.html http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/210346.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/mov: strip com.apple.quicktime prefix in meta; parse creation date
On Mon, Sep 12, 2016 at 08:24:44PM -0500, Rodger Combs wrote:
>
> > On Sep 10, 2016, at 05:55, Michael Niedermayer
> > wrote:
> >
> > On Fri, Sep 09, 2016 at 08:06:40PM -0500, Rodger Combs wrote:
> >> ---
> >> libavformat/mov.c | 16
> >> 1 file changed, 16 insertions(+)
> >>
> >> diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> index 54530e3..b75acd2 100644
> >> --- a/libavformat/mov.c
> >> +++ b/libavformat/mov.c
> >> @@ -42,6 +42,7 @@
> >> #include "libavutil/aes_ctr.h"
> >> #include "libavutil/sha.h"
> >> #include "libavutil/timecode.h"
> >> +#include "libavutil/parseutils.h"
> >> #include "libavcodec/ac3tab.h"
> >> #include "libavcodec/mpegaudiodecheader.h"
> >> #include "avformat.h"
> >> @@ -476,6 +477,21 @@ retry:
> >> return ret;
> >> }
> >> str[str_size] = 0;
> >> +if (!strcmp(key, "com.apple.quicktime.creationdate")) {
> >> +struct tm *ptm, tmbuf;
> >> +int64_t timeval;
> >> +if (av_parse_time(&timeval, str, 0) >= 0) {
> >> +time_t timet = timeval / 100;
> >> +if (ptm = gmtime_r(&timet, &tmbuf)) {
> >> +strftime(str, str_size, "%Y-%m-%d %H:%M:%S", ptm);
> >> +key = "creation_time";
> >> +}
> >> +}
> >> +} else if (!strcmp(key,
> >> "com.apple.quicktime.location.ISO6709")) {
> >> +key = "location";
> >> +} else if (!strncmp(key, "com.apple.quicktime.", 20)) {
> >> +key += 20;
> >> +}
> >> }
> >
> > this causes language specific entries no longer to be listed together
> > with their "parent" entries:
>
> Huh; interesting. Not sure why this happens, but also not sure if it matters?
doesnt matter
btw this patch seems to have been forgotten
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
