Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/dashenc: Remove muxer overhead from Bandwidth field in DASH manifest
On 9/4/18 1:45 PM, Karthick J wrote:
> From: Karthick Jeyapal
>
> Fixes bug id #7386
> Muxer overhead calculations was intented for HLS playlist as Apple's
> mediastreamvalidator tests were failing.
> But applying the same fix for DASH manifest proved counterproductive, as
> Bandwidth can be used for segment name templates.
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index c36ab12..2564b9e 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -611,7 +611,7 @@ static int write_adaptation_set(AVFormatContext *s,
> AVIOContext *out, int as_ind
>
> if (os->bit_rate > 0)
> snprintf(bandwidth_str, sizeof(bandwidth_str), "
> bandwidth=\"%d\"",
> - os->bit_rate + os->muxer_overhead);
> + os->bit_rate);
>
> if (as->media_type == AVMEDIA_TYPE_VIDEO) {
> AVStream *st = s->streams[i];
Pushed the patchset.
Regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavc: Add coded bitstream read/write support for AV1
On 9/9/2018 7:08 PM, Mark Thompson wrote:
> +static void cbs_av1_free_obu(void *unit, uint8_t *content)
> +{
> +AV1RawOBU *obu = (AV1RawOBU*)content;
> +
> +switch (obu->header.obu_type) {
> +case AV1_OBU_TILE_GROUP:
> +cbs_av1_free_tile_data(>tile_group.tile_data);
> +break;
> +case AV1_OBU_FRAME:
> +cbs_av1_free_tile_data(>frame.tile_group.tile_data);
> +break;
> +case AV1_OBU_TILE_LIST:
> +cbs_av1_free_tile_data(>tile_list.tile_data);
> +break;
> +case AV1_OBU_METADATA:
> +cbs_av1_free_metadata(>metadata);
> +break;
> +}
> +
> +av_freep();
Why adding a custom free function for all OBUs when only four types need
it? Sounds like unnecessary overhead for all cases.
IMO what cbs_h2645 does is better, using the default free function where
a custom one isn't needed, then calling a custom free function directly
for those that need one.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/5] Support for Decklink output of EIA-708 and AFD
On Mon, Sep 10, 2018 at 8:00 PM, Marton Balint wrote: > Yes, just put the same value to both line 12 (or whichever line the user > selects) and its pair line in the other field. Ok, will take care of this today. Thanks for reviewing. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat/tty: Remove .txt from the extensions as it more likely is not a multimedia related file
On Tue, Sep 11, 2018 at 11:31:23PM +0200, Carl Eugen Hoyos wrote: > 2018-05-12 18:33 GMT+02:00, Michael Niedermayer : > > Iam not sure if this is a good idea or not but it may make some > > attacks harder. So throwing this out for discussions ... > > I am definitely not objecting but I doubt that this patch can make > any attack harder. files ending with the .txt extension which are not multimedia files contain some other posibly sensitive data. If an attacker can control the input path for ffmpeg and nothing else then being able to read txt files allows leaking the content to the attacker generally. We had bugs that allowed the attacker to control the input path in some cases. So this pre-requesite has evidence for past occurance. We surely can leave txt in the list if people prefer. This is not a clear case of what is better. Its not a true "its buggy and this fixes it" case rather a "this is a steping stone an attacker might find useful in some case of unknown propability" > The main "advantage" of the patch imo is that it stops FFmpeg > from decoding txt files. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V7 0/3] enable multi-slices in vaapi_h264/265 encoder
On Wed, Aug 29, 2018 at 6:47 PM Jun Zhao wrote: > > V7: - Fix h264 first_mb_in_slice setting issue. (root cause by Mark) > - Refine the error handle > > V6: - Use rectangular slices and refine the code. > > V5: - In h265_vaapi encoder, when setting slice number > max slice number > supported by driver, report error and return. Same as h264_vaapi. > - Clean the logic when setting first_slice_segment_in_pic_flags. > > V4: - Change the array malloc function. > - Clean the pointless condition check when free the memory. > > V3: - Making pic->slices be VAAPIEncodeSlice* instead of VAAPIEncodeSlice**. > - Fix resource (vaBuffer) lead when realloc pic->param_buffers fail. > - Adjust max_slices location in VAAPIEncodeContext. > - Re-work distributing the macro-blocks for multi-slices function. > > V2: - Change the slice/parameter buffers to dynamic alloc and split the mutil-slice support for AVC/HEVC. > > Jun Zhao (3): > lavc/vaapi_encode: Add max slices number query. > lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder > lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder > > libavcodec/vaapi_encode.c |4 +++ > libavcodec/vaapi_encode.h |4 +++ > libavcodec/vaapi_encode_h264.c | 39 + > libavcodec/vaapi_encode_h265.c | 41 ++- > 4 files changed, 77 insertions(+), 11 deletions(-) > Ping, any comments for this patch-sets? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat/tty: Remove .txt from the extensions as it more likely is not a multimedia related file
2018-09-11 23:42 GMT+02:00, Paul B Mahol : > On 9/11/18, Carl Eugen Hoyos wrote: >> 2018-05-12 18:33 GMT+02:00, Michael Niedermayer : >>> Iam not sure if this is a good idea or not but it may make some >>> attacks harder. So throwing this out for discussions ... >> >> I am definitely not objecting but I doubt that this patch can make >> any attack harder. >> The main "advantage" of the patch imo is that it stops FFmpeg >> from decoding txt files. > > FFmpeg can still decode txt files, just not automatically. Sorry, I meant "by default". Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.
On Tue, Sep 11, 2018 at 1:48 PM Michael Niedermayer wrote: > > On Thu, Aug 30, 2018 at 08:43:25AM -0700, Jacob Trimble wrote: > > On Wed, Aug 29, 2018 at 4:37 PM Michael Niedermayer > > wrote: > > > > > > On Wed, Aug 29, 2018 at 03:30:39PM -0700, Jacob Trimble wrote: > > > > On Wed, Aug 29, 2018 at 3:20 PM James Almer wrote: > > > > > > > > > > On 8/29/2018 7:07 PM, Michael Niedermayer wrote: > > > > > > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote: > > > > > >> If a packet is full-sample encrypted, then packet data can't be > > > > > >> parsed > > > > > >> without decrypting it. So this skips the packet parsing for those > > > > > >> packets. If the packet has sub-sample encryption, it is assumed > > > > > >> that > > > > > >> the headers are in the clear and the parser will only need that > > > > > >> info. > > > > > >> > > > > > >> Signed-off-by: Jacob Trimble > > > > > >> --- > > > > > >> libavformat/utils.c | 21 - > > > > > >> 1 file changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > > > Hmm, please correct me if iam wrong but IIUC > > > > > > 1. The demuxer has set need_parsing, indicating that it _requires_ > > > > > > a parser > > > > > > > > There isn't a flag for "try parsing and ignore errors". So my choice > > > > (from an app) is to either require parsing or don't do parsing at all > > > > (which can result in incorrect timestamps). > > > > > > > > > > 2. Parsing cannot be done before decrypting > > > > > > > > > > > > If all this and the set values are correct, logically, the fix > > > > > > would be > > > > > > to decrypt the packet before the parser not to skip the parser. > > > > > > > > > > > There are cases where the packet can't be decrypted before getting to > > > > this point. > > > > > > Can you elaborate on these cases ? I dont think its obvious what these > > > cases are, at least its not obvious to me what exactly you are thinking > > > of here. And i think its not helpfull if i guess what you mean and then > > > argue/comment on that because maybe you meant something entirely > > > different ... > > > > Fair warning, I am working on a DRM solution. I know many of you may > > not agree with DRM, but it is a requirement imposed by content > > creators. FFmpeg doesn't have to support DRM itself, but you should > > still consider its usages. > > > > At that point in the code, the packet can only be decrypted by the > > demuxer. For example, in MP4 this can be done by passing the > > -decryption_key parameter. But that requires that FFmpeg handle the > > decryption. In my case, we are passing the packet to a CDM (content > > decryption module) to handle the decryption and that might be a > > hardware-secure decryptor. In most DRM situations, we can't get the > > raw key at all, all we can do is say "decrypt this block of memory". > > So the only way to have the packet decrypted before this point would > > be to introduce a callback to the app to decrypt the packet. > > 1. If the demuxer sets need_parsing it requires parsing > 2. If the demuxer requires parsing then parsing should be done > 3. If parsing cannot be done but is required thats a error and should produce >some warning or error message. It should not be part of some intended >design > So would a log be enough? That's what happens if the parser fails to be created or can't be found. > > > > > This is why I have been working on exposing the encryption info. My > > app (or more correctly the CDM) needs to handle the decryption and we > > can't just give the key to libavformat so the demuxer can decrypt the > > packet. > > > > > > > > > > > > This point is between the demuxer creating the packet and > > > > giving to the app. So the only way to decrypt the frame (as of now) > > > > is for the demuxer to do this. There is no way for the app to handle > > > > the decryption before this point. > > > > > > > > > > > From the app's perspective, I would expect the packet to remain > > > > encrypted for as long as possible. > > > > > > why ? > > > > Because the point of encryption is to ensure that nefarious parties > > you call your customers, "nefarious" ? I guess its none of my buisness > but i dont think this is a good mindset. > The people who bought the movie are our customers; the people trying to get the decrypted frames without paying, or trying to distribute the movie for free are the nefarious ones. > > > don't get access to the data. Even though the packet data is stored > > in memory, it could still be retrieved by a malicious user. Usually > > for protected media, the frames are only decrypted when needed and in > > some cases are decrypted in a secure CPU and isn't even accessible to > > the app. There are platforms that support what is called "direct > > render" where the app gives the platform the encrypted packets and a > > discrete hardware unit will decrypt the packet, decode it, and render > > it directly; this happens on some
[FFmpeg-devel] [PATCH 2/3] avcodec/bintext: Use ff_get_buffer instead of ff_reget_buffer and simplify
reget seems unneeded and it is slower
Signed-off-by: Michael Niedermayer
---
libavcodec/bintext.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/libavcodec/bintext.c b/libavcodec/bintext.c
index b14a2a9c29..d85f2c2dd4 100644
--- a/libavcodec/bintext.c
+++ b/libavcodec/bintext.c
@@ -96,11 +96,6 @@ static av_cold int decode_init(AVCodecContext *avctx)
if (avctx->width < FONT_WIDTH || avctx->height < s->font_height)
return AVERROR_INVALIDDATA;
-
-s->frame = av_frame_alloc();
-if (!s->frame)
-return AVERROR(ENOMEM);
-
return 0;
}
@@ -149,8 +144,9 @@ static int decode_frame(AVCodecContext *avctx,
if ((avctx->width / FONT_WIDTH) * (avctx->height / s->font_height) / 256 >
buf_size)
return AVERROR_INVALIDDATA;
+s->frame = data;
s->x = s->y = 0;
-if ((ret = ff_reget_buffer(avctx, s->frame)) < 0)
+if ((ret = ff_get_buffer(avctx, s->frame, 0)) < 0)
return ret;
s->frame->pict_type = AV_PICTURE_TYPE_I;
s->frame->palette_has_changed = 1;
@@ -208,21 +204,10 @@ static int decode_frame(AVCodecContext *avctx,
}
}
-if ((ret = av_frame_ref(data, s->frame)) < 0)
-return ret;
*got_frame = 1;
return buf_size;
}
-static av_cold int decode_end(AVCodecContext *avctx)
-{
-XbinContext *s = avctx->priv_data;
-
-av_frame_free(>frame);
-
-return 0;
-}
-
#if CONFIG_BINTEXT_DECODER
AVCodec ff_bintext_decoder = {
.name = "bintext",
@@ -231,7 +216,6 @@ AVCodec ff_bintext_decoder = {
.id = AV_CODEC_ID_BINTEXT,
.priv_data_size = sizeof(XbinContext),
.init = decode_init,
-.close = decode_end,
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
};
@@ -244,7 +228,6 @@ AVCodec ff_xbin_decoder = {
.id = AV_CODEC_ID_XBIN,
.priv_data_size = sizeof(XbinContext),
.init = decode_init,
-.close = decode_end,
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
};
@@ -257,7 +240,6 @@ AVCodec ff_idf_decoder = {
.id = AV_CODEC_ID_IDF,
.priv_data_size = sizeof(XbinContext),
.init = decode_init,
-.close = decode_end,
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
};
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/pictordec: Error out if more than one plane is unused
Fixes: Timeout
Fixes:
9797/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PICTOR_fuzzer-5664441659031552
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pictordec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/pictordec.c b/libavcodec/pictordec.c
index b29a484534..65d2d49060 100644
--- a/libavcodec/pictordec.c
+++ b/libavcodec/pictordec.c
@@ -236,6 +236,9 @@ static int decode_frame(AVCodecContext *avctx,
}
}
+if (s->nb_planes - plane > 1)
+return AVERROR_INVALIDDATA;
+
if (plane < s->nb_planes && x < avctx->width) {
int run = (y + 1) * avctx->width - x;
if (bits_per_plane == 8)
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/bintext: Check input size before allocating the input image
Fixes: Timeout Fixes: 9795/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_XBIN_fuzzer-5768631928487936 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/bintext.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/bintext.c b/libavcodec/bintext.c index d967317671..b14a2a9c29 100644 --- a/libavcodec/bintext.c +++ b/libavcodec/bintext.c @@ -146,6 +146,9 @@ static int decode_frame(AVCodecContext *avctx, const uint8_t *buf_end = buf+buf_size; int ret; +if ((avctx->width / FONT_WIDTH) * (avctx->height / s->font_height) / 256 > buf_size) +return AVERROR_INVALIDDATA; + s->x = s->y = 0; if ((ret = ff_reget_buffer(avctx, s->frame)) < 0) return ret; -- 2.18.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] frame: Simplify the video allocation
On 9/3/2018 6:03 AM, Maxym Dmytrychenko wrote: > On Mon, Sep 3, 2018 at 10:17 AM Michael Niedermayer > wrote: > >> On Sun, Sep 02, 2018 at 09:34:23PM -0300, James Almer wrote: >>> From: Luca Barbato >>> >>> Merged-by: James Almer >>> --- >>> This is the next merge in the queue. It's a critical part of the AVFrame >> API, >>> so even if FATE passes I'd rather have others look at it and test in case >>> something breaks. >>> >>> The only difference compared to the libav commit is the "32 - 1" padding >> per >>> plane when allocating the buffer, which was only in our tree. >> >> why is the STRIDE_ALIGN (which is a thing in units of bytes along the >> horizontal axis) added to padded_height which is vertical axis ? >> This is not done prior to the change >> >> Also if this changes how buffers are structured or sized it requires a more >> detailed commit message than "frame: Simplify the video allocation" >> >> > If can help: > Use of av_image_fill_pointers() helps to allocate planes continuously > instead of separate allocation for each plane, > which can end up in very different start locations of the allocated memory. > > Continuous allocation can be better for performance and/or functional sides > of the operations, > example of Intel's HW - QSV, > which is assuming Y/UV planes to be continuously allocated. I just merged this commit and the next, "qsv: enforcing continuous memory layout" of your authoring, where one line checks the distance between frame->data[1] and frame->data[0] to ensure the buffer is continuous. This check, with the padding in our av_frame_get_buffer() implementation, will probably always fail, but i can't test it. Can you look into it, if that's indeed the case? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.
On Thu, Aug 30, 2018 at 8:43 AM Jacob Trimble wrote: > > On Wed, Aug 29, 2018 at 4:37 PM Michael Niedermayer > wrote: > > > > On Wed, Aug 29, 2018 at 03:30:39PM -0700, Jacob Trimble wrote: > > > On Wed, Aug 29, 2018 at 3:20 PM James Almer wrote: > > > > > > > > On 8/29/2018 7:07 PM, Michael Niedermayer wrote: > > > > > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote: > > > > >> If a packet is full-sample encrypted, then packet data can't be > > > > >> parsed > > > > >> without decrypting it. So this skips the packet parsing for those > > > > >> packets. If the packet has sub-sample encryption, it is assumed that > > > > >> the headers are in the clear and the parser will only need that info. > > > > >> > > > > >> Signed-off-by: Jacob Trimble > > > > >> --- > > > > >> libavformat/utils.c | 21 - > > > > >> 1 file changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > Hmm, please correct me if iam wrong but IIUC > > > > > 1. The demuxer has set need_parsing, indicating that it _requires_ a > > > > > parser > > > > > > There isn't a flag for "try parsing and ignore errors". So my choice > > > (from an app) is to either require parsing or don't do parsing at all > > > (which can result in incorrect timestamps). > > > > > > > > 2. Parsing cannot be done before decrypting > > > > > > > > > > If all this and the set values are correct, logically, the fix would > > > > > be > > > > > to decrypt the packet before the parser not to skip the parser. > > > > > > > > There are cases where the packet can't be decrypted before getting to > > > this point. > > > > Can you elaborate on these cases ? I dont think its obvious what these > > cases are, at least its not obvious to me what exactly you are thinking > > of here. And i think its not helpfull if i guess what you mean and then > > argue/comment on that because maybe you meant something entirely different > > ... > > Fair warning, I am working on a DRM solution. I know many of you may > not agree with DRM, but it is a requirement imposed by content > creators. FFmpeg doesn't have to support DRM itself, but you should > still consider its usages. > > At that point in the code, the packet can only be decrypted by the > demuxer. For example, in MP4 this can be done by passing the > -decryption_key parameter. But that requires that FFmpeg handle the > decryption. In my case, we are passing the packet to a CDM (content > decryption module) to handle the decryption and that might be a > hardware-secure decryptor. In most DRM situations, we can't get the > raw key at all, all we can do is say "decrypt this block of memory". > So the only way to have the packet decrypted before this point would > be to introduce a callback to the app to decrypt the packet. > > This is why I have been working on exposing the encryption info. My > app (or more correctly the CDM) needs to handle the decryption and we > can't just give the key to libavformat so the demuxer can decrypt the > packet. > > > > > > > > This point is between the demuxer creating the packet and > > > giving to the app. So the only way to decrypt the frame (as of now) > > > is for the demuxer to do this. There is no way for the app to handle > > > the decryption before this point. > > > > > > > > From the app's perspective, I would expect the packet to remain > > > encrypted for as long as possible. > > > > why ? > > Because the point of encryption is to ensure that nefarious parties > don't get access to the data. Even though the packet data is stored > in memory, it could still be retrieved by a malicious user. Usually > for protected media, the frames are only decrypted when needed and in > some cases are decrypted in a secure CPU and isn't even accessible to > the app. There are platforms that support what is called "direct > render" where the app gives the platform the encrypted packets and a > discrete hardware unit will decrypt the packet, decode it, and render > it directly; this happens on some smart TVs. There are also cases > which require decrypt-decode where we give the platform an encrypted > packet and it will decrypt and decode the packet, ensuring the > decrypted packet data is never in main memory. So there are cases > where we can't even see the encoded packet and decoding is handled by > the platform. > > > > > > > > My app will store the packet for a > > > while, then decrypt it right before passing it to the decoder and > > > drawing the frame. So requiring the packet to be decrypted at this > > > point is not ideal. > > > > > > > > > > > And if that can't be done, then the demuxer could perhaps set > > > > st->need_parsing to 0 and skip parsing altogether? > > > > > > I would want to still have parsing if possible. For example, a lot of > > > content has a clear lead where the first few seconds are clear. So > > > they could be used to adjust the starting timestamps (and whatever > > > parsing needs) and the encrypted content
[FFmpeg-devel] adding file append option to file: protocol
The file protocol always creates new files. For mpeg1 and mpeg2, one can append directly. It would seem to be a small change to the file protocol to add a flag to support opening the file in append mode. Is there a good reason this is not already added?? For some standards, this would seem to be a better solution than writing a different file and using the concat protocol to join the two files into a third file. Thx, Duane P.S - code of interest seems to be ffpeg/libavformat/file.c file_open() .. would need to add branch in the decision tree which open file for write without using O_CREAT ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/vp8: Check bitstream input in vp7_fade_frame() before time consuming operation
On Sun, Jun 24, 2018 at 04:46:22AM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/vp8.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] frame: Simplify the video allocation
On Tue, Sep 11, 2018 at 6:43 PM James Almer wrote: > On 9/3/2018 6:03 AM, Maxym Dmytrychenko wrote: > > On Mon, Sep 3, 2018 at 10:17 AM Michael Niedermayer > > > wrote: > > > >> On Sun, Sep 02, 2018 at 09:34:23PM -0300, James Almer wrote: > >>> From: Luca Barbato > >>> > >>> Merged-by: James Almer > >>> --- > >>> This is the next merge in the queue. It's a critical part of the > AVFrame > >> API, > >>> so even if FATE passes I'd rather have others look at it and test in > case > >>> something breaks. > >>> > >>> The only difference compared to the libav commit is the "32 - 1" > padding > >> per > >>> plane when allocating the buffer, which was only in our tree. > >> > >> why is the STRIDE_ALIGN (which is a thing in units of bytes along the > >> horizontal axis) added to padded_height which is vertical axis ? > >> This is not done prior to the change > >> > >> Also if this changes how buffers are structured or sized it requires a > more > >> detailed commit message than "frame: Simplify the video allocation" > >> > >> > > If can help: > > Use of av_image_fill_pointers() helps to allocate planes continuously > > instead of separate allocation for each plane, > > which can end up in very different start locations of the allocated > memory. > > > > Continuous allocation can be better for performance and/or functional > sides > > of the operations, > > example of Intel's HW - QSV, > > which is assuming Y/UV planes to be continuously allocated. > > I just merged this commit and the next, "qsv: enforcing continuous > memory layout" of your authoring, where one line checks the distance > between frame->data[1] and frame->data[0] to ensure the buffer is > continuous. This check, with the padding in our av_frame_get_buffer() > implementation, will probably always fail, but i can't test it. > > Can you look into it, if that's indeed the case? > just finished my test cases and it seems to be just fine, fixes the original, non-deterministic problem. distance between frame->data[1] and frame->data[0] is not always non-continuous(and causes the problem) where now av_frame_get_buffer() fixes such corner case. thanks, James regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat/tty: Remove .txt from the extensions as it more likely is not a multimedia related file
On Sat, May 12, 2018 at 06:33:25PM +0200, Michael Niedermayer wrote: > Iam not sure if this is a good idea or not but it may make some > attacks harder. So throwing this out for discussions ... no comment or other suggestion from anyone, so i will apply this [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
When static linking programs using ffmpeg libraries, if linking against
libavutil, -ldrm is listed before -lavutil. This leads to linking failure
due to undefined reference of drmGetVersion() and drmFreeVersion().
This is why when pkg-config create libavutil.pc doesn't append -ldrm
after -lavutil.
Create LIBDRM=-ldrm in case libdrm is enabled and add $LIBDRM to
extralibs_avutil.
Signed-off-by: Giulio Benetti
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index ef97c6b500..28bc3481bc 100755
--- a/configure
+++ b/configure
@@ -6057,7 +6057,7 @@ enabled libcaca && require_pkg_config libcaca
caca caca.h caca_create_
enabled libcodec2 && require libcodec2 codec2/codec2.h codec2_create
-lcodec2
enabled libdavs2 && require_pkg_config libdavs2 "davs2 >= 1.5.115"
davs2.h davs2_decoder_open
enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
dc1394/dc1394.h dc1394_new
-enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h
drmGetVersion
+enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h
drmGetVersion && LIBDRM="-ldrm"
enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac
"fdk-aac/aacenc_lib.h" aacEncOpen ||
{ require libfdk_aac fdk-aac/aacenc_lib.h
aacEncOpen -lfdk-aac &&
warn "using libfdk without pkg-config"; } }
@@ -7347,7 +7347,7 @@ rpath=$(enabled rpath && echo "-Wl,-rpath,\${libdir}")
source_path=${source_path}
LIBPREF=${LIBPREF}
LIBSUF=${LIBSUF}
-extralibs_avutil="$avutil_extralibs"
+extralibs_avutil="$avutil_extralibs $LIBDRM"
extralibs_avcodec="$avcodec_extralibs"
extralibs_avformat="$avformat_extralibs"
extralibs_avdevice="$avdevice_extralibs"
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/pnm_parser: do not loose skipped parts in reporting of how much was consumed
On Tue, Sep 04, 2018 at 03:40:43PM +0200, Moritz Barsnick wrote: > On Tue, Sep 04, 2018 at 02:29:51 +0200, Michael Niedermayer wrote: > > Subject: [PATCH] libavcodec/pnm_parser: do not loose skipped parts in > > reporting of how much was consumed > Nit: ^ lose will apply with this fixed thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avfilter/vf_remap: add bilinear interpolation
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 13
libavfilter/vf_remap.c | 167 +
2 files changed, 166 insertions(+), 14 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 860d1eadca..3c5941d748 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13675,6 +13675,19 @@ Xmap and Ymap input video streams must be of same
dimensions. Output video strea
will have Xmap/Ymap video stream dimensions.
Xmap and Ymap input video streams are 16bit depth, single channel.
+@table @option
+@item interpolation
+
+Select interpolation mode.
+
+@table @samp
+@item nearest
+Use values from the nearest neighbor interpolation.
+@item bilinear
+Interpolate values using the bilinear interpolation.
+@end table
+@end table
+
@section removegrain
The removegrain filter is a spatial denoiser for progressive video.
diff --git a/libavfilter/vf_remap.c b/libavfilter/vf_remap.c
index 48ec38af7c..9dfb9ce0be 100644
--- a/libavfilter/vf_remap.c
+++ b/libavfilter/vf_remap.c
@@ -47,6 +47,7 @@
typedef struct RemapContext {
const AVClass *class;
+int interpolation;
int nb_planes;
int nb_components;
int step;
@@ -59,6 +60,9 @@ typedef struct RemapContext {
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
static const AVOption remap_options[] = {
+{ "interpolation", "select interpolation mode", OFFSET(interpolation),
AV_OPT_TYPE_INT , {.i64=0}, 0, 1, FLAGS, "interp" },
+{ "nearest", "use values from the nearest defined points", 0,
AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, FLAGS, "interp" },
+{ "bilinear", "use values from the linear interpolation", 0,
AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, FLAGS, "interp" },
{ NULL }
};
@@ -121,6 +125,138 @@ fail:
return ret;
}
+static av_always_inline float lerpf(float s, float e, float t)
+{
+return s + (e - s) * t;
+}
+
+static av_always_inline int blerp(int c00, int c10,
+ int c01, int c11,
+ float tx, float ty)
+{
+return lerpf(lerpf(c00, c10, tx), lerpf(c01, c11, tx), ty);
+}
+
+#define DEFINE_INTERP_NEAREST_PLANAR(bits)
\
+static av_always_inline int interp_nearest_planar##bits(const uint##bits##_t
*src, \
+ int slinesize,
\
+ const uint16_t *xmap, int
xlinesize, \
+ const uint16_t *ymap, int
ylinesize, \
+ int w, int h, int x, int y)
\
+{
\
+if (ymap[x] < h && xmap[x] < w) {
\
+return src[ymap[x] * slinesize + xmap[x]];
\
+}
\
+return 0;
\
+}
+
+#define DEFINE_INTERP_NEAREST_PACKED(bits)
\
+static av_always_inline int interp_nearest_packed##bits(const uint##bits##_t
*src, \
+ int slinesize,
\
+ const uint16_t *xmap, int
xlinesize, \
+ const uint16_t *ymap, int
ylinesize, \
+ int w, int h, int x, int y,
\
+ int step, int c)
\
+{
\
+if (ymap[x] < h && xmap[x] < w) {
\
+return src[ymap[x] * slinesize + xmap[x] * step + c];
\
+}
\
+return 0;
\
+}
+
+#define DEFINE_INTERP_BILINEAR_PLANAR(bits)
\
+static av_always_inline int interp_bilinear_planar##bits(const uint##bits##_t
*src, \
+ int slinesize,
\
+ const uint16_t *xmap, int
xlinesize, \
+ const uint16_t *ymap, int
ylinesize, \
+ int w, int h, int x, int y)
\
+{
\
+int c00, c10, c01, c11;
[FFmpeg-devel] [PATCH 1/2] avfilter/vf_remap: refactor code
Signed-off-by: Paul B Mahol
---
libavfilter/vf_remap.c | 242 ++---
1 file changed, 84 insertions(+), 158 deletions(-)
diff --git a/libavfilter/vf_remap.c b/libavfilter/vf_remap.c
index 4f8d57f229..48ec38af7c 100644
--- a/libavfilter/vf_remap.c
+++ b/libavfilter/vf_remap.c
@@ -126,85 +126,48 @@ fail:
* pixels are copied from source to target using :
* Target_frame[y][x] = Source_frame[ ymap[y][x] ][ [xmap[y][x] ];
*/
-static int remap_planar_slice(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs)
-{
-const ThreadData *td = (ThreadData*)arg;
-const AVFrame *in = td->in;
-const AVFrame *xin = td->xin;
-const AVFrame *yin = td->yin;
-const AVFrame *out = td->out;
-
-const int slice_start = (out->height * jobnr ) / nb_jobs;
-const int slice_end = (out->height * (jobnr+1)) / nb_jobs;
-
-const int xlinesize = xin->linesize[0] / 2;
-const int ylinesize = yin->linesize[0] / 2;
-int x , y, plane;
-
-for (plane = 0; plane < td->nb_planes ; plane++) {
-const int dlinesize = out->linesize[plane];
-const uint8_t *src = in->data[plane];
-uint8_t *dst = out->data[plane] + slice_start * dlinesize;
-const int slinesize = in->linesize[plane];
-const uint16_t *xmap = (const uint16_t *)xin->data[0] + slice_start *
xlinesize;
-const uint16_t *ymap = (const uint16_t *)yin->data[0] + slice_start *
ylinesize;
-
-for (y = slice_start; y < slice_end; y++) {
-for (x = 0; x < out->width; x++) {
-if (ymap[x] < in->height && xmap[x] < in->width) {
-dst[x] = src[ymap[x] * slinesize + xmap[x]];
-} else {
-dst[x] = 0;
-}
-}
-dst += dlinesize;
-xmap += xlinesize;
-ymap += ylinesize;
-}
-}
-
-return 0;
+#define DEFINE_REMAP_PLANAR_FUNC(name, bits, div)
\
+static int remap_planar##bits##_##name##_slice(AVFilterContext *ctx, void
*arg, \
+ int jobnr, int nb_jobs)
\
+{
\
+const ThreadData *td = (ThreadData*)arg;
\
+const AVFrame *in = td->in;
\
+const AVFrame *xin = td->xin;
\
+const AVFrame *yin = td->yin;
\
+const AVFrame *out = td->out;
\
+const int slice_start = (out->height * jobnr ) / nb_jobs;
\
+const int slice_end = (out->height * (jobnr+1)) / nb_jobs;
\
+const int xlinesize = xin->linesize[0] / 2;
\
+const int ylinesize = yin->linesize[0] / 2;
\
+int x , y, plane;
\
+
\
+for (plane = 0; plane < td->nb_planes ; plane++) {
\
+const int dlinesize = out->linesize[plane] / div;
\
+const uint##bits##_t *src = (const uint##bits##_t *)in->data[plane];
\
+uint##bits##_t *dst = (uint##bits##_t *)out->data[plane] + slice_start
* dlinesize; \
+const int slinesize = in->linesize[plane] / div;
\
+const uint16_t *xmap = (const uint16_t *)xin->data[0] + slice_start *
xlinesize;\
+const uint16_t *ymap = (const uint16_t *)yin->data[0] + slice_start *
ylinesize;\
+
\
+for (y = slice_start; y < slice_end; y++) {
\
+for (x = 0; x < out->width; x++) {
\
+if (ymap[x] < in->height && xmap[x] < in->width) {
\
+dst[x] = src[ymap[x] * slinesize + xmap[x]];
\
+} else {
\
+dst[x] = 0;
\
+}
\
+}
\
+dst += dlinesize;
Re: [FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.
On Thu, Aug 30, 2018 at 08:43:25AM -0700, Jacob Trimble wrote: > On Wed, Aug 29, 2018 at 4:37 PM Michael Niedermayer > wrote: > > > > On Wed, Aug 29, 2018 at 03:30:39PM -0700, Jacob Trimble wrote: > > > On Wed, Aug 29, 2018 at 3:20 PM James Almer wrote: > > > > > > > > On 8/29/2018 7:07 PM, Michael Niedermayer wrote: > > > > > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote: > > > > >> If a packet is full-sample encrypted, then packet data can't be > > > > >> parsed > > > > >> without decrypting it. So this skips the packet parsing for those > > > > >> packets. If the packet has sub-sample encryption, it is assumed that > > > > >> the headers are in the clear and the parser will only need that info. > > > > >> > > > > >> Signed-off-by: Jacob Trimble > > > > >> --- > > > > >> libavformat/utils.c | 21 - > > > > >> 1 file changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > Hmm, please correct me if iam wrong but IIUC > > > > > 1. The demuxer has set need_parsing, indicating that it _requires_ a > > > > > parser > > > > > > There isn't a flag for "try parsing and ignore errors". So my choice > > > (from an app) is to either require parsing or don't do parsing at all > > > (which can result in incorrect timestamps). > > > > > > > > 2. Parsing cannot be done before decrypting > > > > > > > > > > If all this and the set values are correct, logically, the fix would > > > > > be > > > > > to decrypt the packet before the parser not to skip the parser. > > > > > > > > There are cases where the packet can't be decrypted before getting to > > > this point. > > > > Can you elaborate on these cases ? I dont think its obvious what these > > cases are, at least its not obvious to me what exactly you are thinking > > of here. And i think its not helpfull if i guess what you mean and then > > argue/comment on that because maybe you meant something entirely different > > ... > > Fair warning, I am working on a DRM solution. I know many of you may > not agree with DRM, but it is a requirement imposed by content > creators. FFmpeg doesn't have to support DRM itself, but you should > still consider its usages. > > At that point in the code, the packet can only be decrypted by the > demuxer. For example, in MP4 this can be done by passing the > -decryption_key parameter. But that requires that FFmpeg handle the > decryption. In my case, we are passing the packet to a CDM (content > decryption module) to handle the decryption and that might be a > hardware-secure decryptor. In most DRM situations, we can't get the > raw key at all, all we can do is say "decrypt this block of memory". > So the only way to have the packet decrypted before this point would > be to introduce a callback to the app to decrypt the packet. 1. If the demuxer sets need_parsing it requires parsing 2. If the demuxer requires parsing then parsing should be done 3. If parsing cannot be done but is required thats a error and should produce some warning or error message. It should not be part of some intended design > > This is why I have been working on exposing the encryption info. My > app (or more correctly the CDM) needs to handle the decryption and we > can't just give the key to libavformat so the demuxer can decrypt the > packet. > > > > > > > > This point is between the demuxer creating the packet and > > > giving to the app. So the only way to decrypt the frame (as of now) > > > is for the demuxer to do this. There is no way for the app to handle > > > the decryption before this point. > > > > > > > > From the app's perspective, I would expect the packet to remain > > > encrypted for as long as possible. > > > > why ? > > Because the point of encryption is to ensure that nefarious parties you call your customers, "nefarious" ? I guess its none of my buisness but i dont think this is a good mindset. > don't get access to the data. Even though the packet data is stored > in memory, it could still be retrieved by a malicious user. Usually > for protected media, the frames are only decrypted when needed and in > some cases are decrypted in a secure CPU and isn't even accessible to > the app. There are platforms that support what is called "direct > render" where the app gives the platform the encrypted packets and a > discrete hardware unit will decrypt the packet, decode it, and render > it directly; this happens on some smart TVs. There are also cases > which require decrypt-decode where we give the platform an encrypted > packet and it will decrypt and decode the packet, ensuring the > decrypted packet data is never in main memory. So there are cases > where we can't even see the encoded packet and decoding is handled by > the platform. you arent yet using the cortex decryptor module with neuralink? seriously, i think without this your nefarious customers will still be able to easily record the data if they want. All this fancy stuff doesnt really provide any real
Re: [FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
On 9/11/2018 5:29 PM, Giulio Benetti wrote:
> When static linking programs using ffmpeg libraries, if linking against
> libavutil, -ldrm is listed before -lavutil. This leads to linking failure
> due to undefined reference of drmGetVersion() and drmFreeVersion().
> This is why when pkg-config create libavutil.pc doesn't append -ldrm
> after -lavutil.
>
> Create LIBDRM=-ldrm in case libdrm is enabled and add $LIBDRM to
> extralibs_avutil.
I'm not sure i understand. libdrm is already added to avutil extralibs,
seeing it's listed in the "avutil_suggest" line in configure. I see it's
also added to avdevice if kmsgrab_indev is enabled.
The -ldrm ldflag, assuming the libdrm pkg-config file is correct, should
be in $avutil_extralibs when configure dumps it into extralibs_avutil
for the purpose of creating libavutil.pc.
>
> Signed-off-by: Giulio Benetti
> ---
> configure | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index ef97c6b500..28bc3481bc 100755
> --- a/configure
> +++ b/configure
> @@ -6057,7 +6057,7 @@ enabled libcaca && require_pkg_config libcaca
> caca caca.h caca_create_
> enabled libcodec2 && require libcodec2 codec2/codec2.h codec2_create
> -lcodec2
> enabled libdavs2 && require_pkg_config libdavs2 "davs2 >= 1.5.115"
> davs2.h davs2_decoder_open
> enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
> dc1394/dc1394.h dc1394_new
> -enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h
> drmGetVersion
> +enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h
> drmGetVersion && LIBDRM="-ldrm"
> enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac
> "fdk-aac/aacenc_lib.h" aacEncOpen ||
> { require libfdk_aac fdk-aac/aacenc_lib.h
> aacEncOpen -lfdk-aac &&
> warn "using libfdk without pkg-config"; } }
> @@ -7347,7 +7347,7 @@ rpath=$(enabled rpath && echo "-Wl,-rpath,\${libdir}")
> source_path=${source_path}
> LIBPREF=${LIBPREF}
> LIBSUF=${LIBSUF}
> -extralibs_avutil="$avutil_extralibs"
> +extralibs_avutil="$avutil_extralibs $LIBDRM"
> extralibs_avcodec="$avcodec_extralibs"
> extralibs_avformat="$avformat_extralibs"
> extralibs_avdevice="$avdevice_extralibs"
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
Hello, Il 11/09/2018 22:49, James Almer ha scritto: On 9/11/2018 5:29 PM, Giulio Benetti wrote: When static linking programs using ffmpeg libraries, if linking against libavutil, -ldrm is listed before -lavutil. This leads to linking failure due to undefined reference of drmGetVersion() and drmFreeVersion(). This is why when pkg-config create libavutil.pc doesn't append -ldrm after -lavutil. Create LIBDRM=-ldrm in case libdrm is enabled and add $LIBDRM to extralibs_avutil. I'm not sure i understand. libdrm is already added to avutil extralibs, seeing it's listed in the "avutil_suggest" line in configure. I see it's also added to avdevice if kmsgrab_indev is enabled. The -ldrm ldflag, assuming the libdrm pkg-config file is correct, should be in $avutil_extralibs when configure dumps it into extralibs_avutil for the purpose of creating libavutil.pc. I point you a build failure, so it should be more clear. I did my best to explain on commit log, but it wasn't easy. http://autobuild.buildroot.net/results/515/5152dcca58944cf732d09fba6e6c9af8a9243c75/build-end.log In that case .configure file is different but the point is the same. At the end of the log you can see that -ldrm is yes present, but it comes too early respect to -lavutil. This situation is valid only in the case you link *statically*. For dynamic linking there's no problem at all. Thanks and Best regards Giulio Benetti ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
On 9/11/2018 5:59 PM, Giulio Benetti wrote: > Hello, > > Il 11/09/2018 22:49, James Almer ha scritto: >> On 9/11/2018 5:29 PM, Giulio Benetti wrote: >>> When static linking programs using ffmpeg libraries, if linking against >>> libavutil, -ldrm is listed before -lavutil. This leads to linking >>> failure >>> due to undefined reference of drmGetVersion() and drmFreeVersion(). >>> This is why when pkg-config create libavutil.pc doesn't append -ldrm >>> after -lavutil. >>> >>> Create LIBDRM=-ldrm in case libdrm is enabled and add $LIBDRM to >>> extralibs_avutil. >> >> I'm not sure i understand. libdrm is already added to avutil extralibs, >> seeing it's listed in the "avutil_suggest" line in configure. I see it's >> also added to avdevice if kmsgrab_indev is enabled. >> >> The -ldrm ldflag, assuming the libdrm pkg-config file is correct, should >> be in $avutil_extralibs when configure dumps it into extralibs_avutil >> for the purpose of creating libavutil.pc. >> > > I point you a build failure, so it should be more clear. > I did my best to explain on commit log, but it wasn't easy. > > http://autobuild.buildroot.net/results/515/5152dcca58944cf732d09fba6e6c9af8a9243c75/build-end.log > > > In that case .configure file is different but the point is the same. > > At the end of the log you can see that -ldrm is yes present, but it > comes too early respect to -lavutil. > This situation is valid only in the case you link *statically*. > For dynamic linking there's no problem at all. > > Thanks and > Best regards > Giulio Benetti > -lswscale -lavdevice -lavformat -lavcodec -lssl -lcrypto -lspeex -lmodplug > -lstdc++ -lfontconfig -lfreetype -lpng16 -lexpat -ldrm -lz -pthread -latomic > -lswresample -lavutil -lm What i'm seeing here is that -ldrm is apparently present in libavdevice.pc, but not in libavutill.pc, which shouldn't happen given that it's strictly listed in the avutil_suggest list. What version of ffmpeg is this script using? Latest git head, an old snapshot, or a release? Did this start failing recently? This patch is a hacky way to add the "-ldrm" ldflag to avutil_extralibs. It should be added organically by configure as part of the dependency checks, so this is definitely not an adequate fix. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v8 1/2] lavc, doc, configure: add libxavs2 video encoder wrapper
On 10/09/18 21:18, Mark Thompson wrote:
> On 10/09/18 04:59, hwren wrote:
>> Signed-off-by: hwren
>> ---
>> Changelog | 1 +
>> configure | 4 +
>> doc/encoders.texi | 49
>> doc/general.texi | 14 +++
>> libavcodec/Makefile| 1 +
>> libavcodec/allcodecs.c | 1 +
>> libavcodec/libxavs2.c | 300
>> +
>> libavcodec/version.h | 4 +-
>> 8 files changed, 372 insertions(+), 2 deletions(-)
>> create mode 100644 libavcodec/libxavs2.c
>>
>> ...> diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
>> new file mode 100644
>> index 000..a834f6e
>> --- /dev/null
>> +++ b/libavcodec/libxavs2.c
>> ...
>> +
>> +/* Rate control */
>> +if (avctx->bit_rate > 0) {
>> +xavs2_opt_set2("RateControl", "%d", 1);
>> +xavs2_opt_set2("initial_qp","%d", cae->qp);
>> +xavs2_opt_set2("TargetBitRate", "%"PRId64"", avctx->bit_rate);
>> +} else {
>> +xavs2_opt_set2("initial_qp","%d", cae->initial_qp);
>> +xavs2_opt_set2("max_qp","%d", cae->max_qp);
>> +xavs2_opt_set2("min_qp","%d", cae->min_qp);
>> +}
>
> The QP settings are the wrong way around - initial_qp, max_qp and min_qp
> should go with the rate control case.
>
>> ...
>
> Everything else LGTM now.
>
> Does anyone else have any comments on this? If not, I'll push it tomorrow
> with that fixed.
And applied :)
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
Hello, Il 11/09/2018 23:21, James Almer ha scritto: -lswscale -lavdevice -lavformat -lavcodec -lssl -lcrypto -lspeex -lmodplug -lstdc++ -lfontconfig -lfreetype -lpng16 -lexpat -ldrm -lz -pthread -latomic -lswresample -lavutil -lm What i'm seeing here is that -ldrm is apparently present in libavdevice.pc, but not in libavutill.pc, which shouldn't happen given that it's strictly listed in the avutil_suggest list. What version of ffmpeg is this script using? Latest git head, an old snapshot, or a release? Did this start failing recently? It happens on version 3.4.4 and I haven't foud fixes until master(maybe I've missed something, I'm quite new to this). This patch is a hacky way to add the "-ldrm" ldflag to avutil_extralibs. It should be added organically by configure as part of the dependency checks, so this is definitely not an adequate fix. Can you point me the right way to fix this? It was the only way I've found to have it working. Thanks in advance Giulio Benetti ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
Il 11/09/2018 23:34, James Almer ha scritto: On 9/11/2018 6:24 PM, Giulio Benetti wrote: Hello, Il 11/09/2018 23:21, James Almer ha scritto: -lswscale -lavdevice -lavformat -lavcodec -lssl -lcrypto -lspeex -lmodplug -lstdc++ -lfontconfig -lfreetype -lpng16 -lexpat -ldrm -lz -pthread -latomic -lswresample -lavutil -lm What i'm seeing here is that -ldrm is apparently present in libavdevice.pc, but not in libavutill.pc, which shouldn't happen given that it's strictly listed in the avutil_suggest list. What version of ffmpeg is this script using? Latest git head, an old snapshot, or a release? Did this start failing recently? It happens on version 3.4.4 and I haven't foud fixes until master(maybe I've missed something, I'm quite new to this). This patch does nothing on git master. This is a fix that needs to be applied to the 3.4 release branch, if anywhere. This patch is a hacky way to add the "-ldrm" ldflag to avutil_extralibs. It should be added organically by configure as part of the dependency checks, so this is definitely not an adequate fix. Can you point me the right way to fix this? It was the only way I've found to have it working. I guess it's acceptable in that case. The 3.4 branch had LIBRT and LIBM hacked into extralibs_avutil, so another one wont hurt. I've pushed it there. Oh well, thank it's good to know it's been useful to ffmpeg too. Best regards -- Giulio Benetti CTO MICRONOVA SRL Sede: Via A. Niedda 3 - 35010 Vigonza (PD) Tel. 049/8931563 - Fax 049/8931346 Cod.Fiscale - P.IVA 02663420285 Capitale Sociale € 26.000 i.v. Iscritta al Reg. Imprese di Padova N. 02663420285 Numero R.E.A. 258642 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
On 9/11/2018 6:24 PM, Giulio Benetti wrote: > Hello, > > Il 11/09/2018 23:21, James Almer ha scritto: >>> -lswscale -lavdevice -lavformat -lavcodec -lssl -lcrypto -lspeex >>> -lmodplug -lstdc++ -lfontconfig -lfreetype -lpng16 -lexpat -ldrm -lz >>> -pthread -latomic -lswresample -lavutil -lm >> >> What i'm seeing here is that -ldrm is apparently present in >> libavdevice.pc, but not in libavutill.pc, which shouldn't happen given >> that it's strictly listed in the avutil_suggest list. >> >> What version of ffmpeg is this script using? Latest git head, an old >> snapshot, or a release? Did this start failing recently? > > It happens on version 3.4.4 and I haven't foud fixes until master(maybe > I've missed something, I'm quite new to this). This patch does nothing on git master. This is a fix that needs to be applied to the 3.4 release branch, if anywhere. > >> This patch is a hacky way to add the "-ldrm" ldflag to avutil_extralibs. >> It should be added organically by configure as part of the dependency >> checks, so this is definitely not an adequate fix. > > Can you point me the right way to fix this? > It was the only way I've found to have it working. I guess it's acceptable in that case. The 3.4 branch had LIBRT and LIBM hacked into extralibs_avutil, so another one wont hurt. I've pushed it there. Thanks. > > Thanks in advance > Giulio Benetti ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
Il 11/09/2018 23:24, Giulio Benetti ha scritto: Hello, Il 11/09/2018 23:21, James Almer ha scritto: -lswscale -lavdevice -lavformat -lavcodec -lssl -lcrypto -lspeex -lmodplug -lstdc++ -lfontconfig -lfreetype -lpng16 -lexpat -ldrm -lz -pthread -latomic -lswresample -lavutil -lm What i'm seeing here is that -ldrm is apparently present in libavdevice.pc, but not in libavutill.pc, which shouldn't happen given that it's strictly listed in the avutil_suggest list. What version of ffmpeg is this script using? Latest git head, an old snapshot, or a release? Did this start failing recently? It happens on version 3.4.4 and I haven't foud fixes until master(maybe I've missed something, I'm quite new to this). Just tried with 4.0.2 and it builds ok. Sorry I didn't try it before. So it's only about Buildroot with version 3.4.4 Best regards Giulio Benetti ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat/tty: Remove .txt from the extensions as it more likely is not a multimedia related file
2018-05-12 18:33 GMT+02:00, Michael Niedermayer : > Iam not sure if this is a good idea or not but it may make some > attacks harder. So throwing this out for discussions ... I am definitely not objecting but I doubt that this patch can make any attack harder. The main "advantage" of the patch imo is that it stops FFmpeg from decoding txt files. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
Il 11/09/2018 23:38, Carl Eugen Hoyos ha scritto: 2018-09-11 23:34 GMT+02:00, Giulio Benetti : Il 11/09/2018 23:24, Giulio Benetti ha scritto: Hello, Il 11/09/2018 23:21, James Almer ha scritto: -lswscale -lavdevice -lavformat -lavcodec -lssl -lcrypto -lspeex -lmodplug -lstdc++ -lfontconfig -lfreetype -lpng16 -lexpat -ldrm -lz -pthread -latomic -lswresample -lavutil -lm What i'm seeing here is that -ldrm is apparently present in libavdevice.pc, but not in libavutill.pc, which shouldn't happen given that it's strictly listed in the avutil_suggest list. What version of ffmpeg is this script using? Latest git head, an old snapshot, or a release? Did this start failing recently? It happens on version 3.4.4 and I haven't foud fixes until master(maybe I've missed something, I'm quite new to this). Just tried with 4.0.2 and it builds ok. Could you also confirm that it works with current FFmpeg? Yes, it build correctly. This is the end-log: " Linking Motion... /home/giuliobenetti/Desktop/5152dcca58944cf732d09fba6e6c9af8a9243c75/output/host/bin/arm-linux-gcc -static -o motion motion.o logger.o conf.o draw.o jpegutils.o video_loopback.o video_v4l2.o video_common.o video_bktr.o netcam.o netcam_http.o netcam_ftp.o netcam_jpeg.o netcam_wget.o track.o alg.o event.o picture.o rotate.o webhttpd.o stream.o md5.o netcam_rtsp.o ffmpeg.o -lm -pthread -ljpeg -lsqlite3 -L/home/giuliobenetti/Desktop/5152dcca58944cf732d09fba6e6c9af8a9243c75/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib -L/home/giuliobenetti/Desktop/5152dcca58944cf732d09fba6e6c9af8a9243c75/output/host/bin/../arm-buildroot-linux-uclibcgnueabi/sysroot/usr//lib -lswscale -lavdevice -lavformat -lmodplug -lstdc++ -lssl -lcrypto -lavcodec -lz -lspeex -lswresample -lavutil -pthread -lm -ldrm Motion has been linked. " So now -ldrm is at the end as expected. Best regards -- Giulio Benetti CTO MICRONOVA SRL Sede: Via A. Niedda 3 - 35010 Vigonza (PD) Tel. 049/8931563 - Fax 049/8931346 Cod.Fiscale - P.IVA 02663420285 Capitale Sociale € 26.000 i.v. Iscritta al Reg. Imprese di Padova N. 02663420285 Numero R.E.A. 258642 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add LIBDRM to extralibs_avutil
2018-09-11 23:34 GMT+02:00, Giulio Benetti : > Il 11/09/2018 23:24, Giulio Benetti ha scritto: >> Hello, >> >> Il 11/09/2018 23:21, James Almer ha scritto: -lswscale -lavdevice -lavformat -lavcodec -lssl -lcrypto -lspeex -lmodplug -lstdc++ -lfontconfig -lfreetype -lpng16 -lexpat -ldrm -lz -pthread -latomic -lswresample -lavutil -lm >>> >>> What i'm seeing here is that -ldrm is apparently present in >>> libavdevice.pc, but not in libavutill.pc, which shouldn't happen given >>> that it's strictly listed in the avutil_suggest list. >>> >>> What version of ffmpeg is this script using? Latest git head, an old >>> snapshot, or a release? Did this start failing recently? >> >> It happens on version 3.4.4 and I haven't foud fixes until master(maybe >> I've missed something, I'm quite new to this). > > Just tried with 4.0.2 and it builds ok. Could you also confirm that it works with current FFmpeg? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat/tty: Remove .txt from the extensions as it more likely is not a multimedia related file
On 9/11/18, Carl Eugen Hoyos wrote: > 2018-05-12 18:33 GMT+02:00, Michael Niedermayer : >> Iam not sure if this is a good idea or not but it may make some >> attacks harder. So throwing this out for discussions ... > > I am definitely not objecting but I doubt that this patch can make > any attack harder. > The main "advantage" of the patch imo is that it stops FFmpeg > from decoding txt files. FFmpeg can still decode txt files, just not automatically. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
