Re: [FFmpeg-devel] [PATCH v5 5/5] libavfilter: VAAPI surface scaler
On 1/30/16, Mark Thompson wrote: > On 30/01/16 22:22, Paul B Mahol wrote: >> On 1/30/16, Mark Thompson wrote: >>> >>> --- >>> configure| 3 + >>> libavfilter/Makefile | 1 + >>> libavfilter/allfilters.c | 1 + >>> libavfilter/vf_vaapi_scale.c | 709 >>> +++ >>> 4 files changed, 714 insertions(+) >>> create mode 100644 libavfilter/vf_vaapi_scale.c >>> >> >> missing documentation, how is this supposed to work? > > Documentation has not yet been written because the interface is not yet > finalised. (True of the whole series.) > > Can you clarify what "this" points to in that question? (The > documentation-writing, the filter itself, the submission process for this > patch series, the unclear hardware context setup, ... ?) > The filter itself. > > On 30/01/16 22:24, Paul B Mahol wrote: >> >> [...] >> >> Please use NULL like other filter do. >> > > Sure. Changed for next version. > > > - Mark > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On Sun, Jan 31, 2016 at 01:34:46AM +0100, Mats Peterson wrote: > On 01/30/2016 05:10 AM, Mats Peterson wrote: > >Now when both AVI and QuickTime use pal8 for 1 bpp video, there's no > >need to keep the monow stuff. > > > I should add that I'm only removing stuff that I've added myself > before, so don't worry. should this still be applied after 6ffac5d33d334f847150356293ecb6f9eaf69e15 ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hevc: set profile based on the profile compatibility flags if needed
On Sat, Jan 30, 2016 at 05:44:34PM +0100, Hendrik Leppkes wrote: > This fixes retrieving a valid profile for many of the FATE conformance > samples, > allowing them to be properly decoded by the HWAccel after adding a profile > check. > --- > libavcodec/hevc_ps.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes 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/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On 01/31/2016 11:31 AM, Michael Niedermayer wrote: On Sun, Jan 31, 2016 at 01:34:46AM +0100, Mats Peterson wrote: On 01/30/2016 05:10 AM, Mats Peterson wrote: Now when both AVI and QuickTime use pal8 for 1 bpp video, there's no need to keep the monow stuff. I should add that I'm only removing stuff that I've added myself before, so don't worry. should this still be applied after 6ffac5d33d334f847150356293ecb6f9eaf69e15 ? [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I've obviously missed that one, Michael, but I don't see the reason to switch to monow whatsoever. The space saving of using monow rather than pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage may vary, of course. And in order to be consequent, this would have to be done for 1 bpp QuickTime Animation (qtrle) as well. with your patch applied, this one should of course be ignored. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On 01/31/2016 12:25 PM, Mats Peterson wrote: On 01/31/2016 12:19 PM, Mats Peterson wrote: I've obviously missed that one, Michael, but I don't see the reason to switch to monow whatsoever. The space saving of using monow rather than pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage may vary, of course. And in order to be consequent, this would have to be done for 1 bpp QuickTime Animation (qtrle) as well. with your patch applied, this one should of course be ignored. Mats What's more, the palette side data is retrieved twice with your patch, at the beginning and at the end of raw_decode(). Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Do you mind reverting your patch? I don't see why monow would have to be used whatseover. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On 01/31/2016 12:27 PM, Mats Peterson wrote: On 01/31/2016 12:25 PM, Mats Peterson wrote: On 01/31/2016 12:19 PM, Mats Peterson wrote: I've obviously missed that one, Michael, but I don't see the reason to switch to monow whatsoever. The space saving of using monow rather than pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage may vary, of course. And in order to be consequent, this would have to be done for 1 bpp QuickTime Animation (qtrle) as well. with your patch applied, this one should of course be ignored. Mats What's more, the palette side data is retrieved twice with your patch, at the beginning and at the end of raw_decode(). Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Do you mind reverting your patch? I don't see why monow would have to be used whatseover. Mats whatsoever, not whatseover. -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On 01/31/2016 12:19 PM, Mats Peterson wrote: I've obviously missed that one, Michael, but I don't see the reason to switch to monow whatsoever. The space saving of using monow rather than pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage may vary, of course. And in order to be consequent, this would have to be done for 1 bpp QuickTime Animation (qtrle) as well. with your patch applied, this one should of course be ignored. Mats What's more, the palette side data is retrieved twice with your patch, at the beginning and at the end of raw_decode(). Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On 01/31/2016 12:31 PM, Mats Peterson wrote: On 01/31/2016 12:28 PM, Mats Peterson wrote: On 01/31/2016 12:27 PM, Mats Peterson wrote: On 01/31/2016 12:25 PM, Mats Peterson wrote: On 01/31/2016 12:19 PM, Mats Peterson wrote: I've obviously missed that one, Michael, but I don't see the reason to switch to monow whatsoever. The space saving of using monow rather than pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage may vary, of course. And in order to be consequent, this would have to be done for 1 bpp QuickTime Animation (qtrle) as well. with your patch applied, this one should of course be ignored. Mats What's more, the palette side data is retrieved twice with your patch, at the beginning and at the end of raw_decode(). Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Do you mind reverting your patch? I don't see why monow would have to be used whatseover. Mats whatsoever, not whatseover. I still have the old version of rawdec.c before your patch was applied here, so I can create a patch that restores it if you want. Mats I'll have to regenerate the FATE test files once again as well, obviously. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Speed up wtv index creation
On Fri, Jan 29, 2016 at 09:36:30PM +, popcorn mix wrote:
> The index creation is O(N^2) with number of entries (typically thousands).
> On a Raspberry Pi this can take more than 60 seconds to execute for a
> recording of a few hours.
>
> By replacing with an O(N) loop, this takes virtually zero time
>
> This patch has been in all Pi builds of Kodi for the last couple of years,
> so it is quite widely tested. No change in FATE output.
>
> From 4bad5dbd752e96a6dfcb7e46aff1d64996d08ed1 Mon Sep 17 00:00:00 2001
> From: popcornmix
> Date: Fri, 29 Jan 2016 20:27:00 +
> Subject: [PATCH] wtv: Speed up wtv index creation
>
> The index creation is O(N^2) with number of entries (typically thousands).
> On a Pi this can take more than 60 seconds to execute for a recording of a
> few hours.
>
> By replacing with an O(N) loop, this takes virtually zero time
> ---
> libavformat/wtvdec.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
> index e8f6196..b329b7c 100644
> --- a/libavformat/wtvdec.c
> +++ b/libavformat/wtvdec.c
> @@ -1028,21 +1028,23 @@ static int read_header(AVFormatContext *s)
> pb = wtvfile_open(s, root, root_size,
> ff_timeline_table_0_entries_Events_le16);
> if (pb) {
> int i;
> +AVIndexEntry *e = wtv->index_entries;
> +AVIndexEntry *e_end = wtv->index_entries +
> wtv->nb_index_entries - 1;
> +uint64_t last_position = 0;
> while (1) {
> uint64_t frame_nb = avio_rl64(pb);
> uint64_t position = avio_rl64(pb);
> +while (frame_nb > e->size && e <= e_end) {
> + e->pos = last_position;
> + e++;
^^^ this indent isn't aligned.
otherwise, great stuff. your implementation is solid.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
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/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On 01/31/2016 12:28 PM, Mats Peterson wrote: On 01/31/2016 12:27 PM, Mats Peterson wrote: On 01/31/2016 12:25 PM, Mats Peterson wrote: On 01/31/2016 12:19 PM, Mats Peterson wrote: I've obviously missed that one, Michael, but I don't see the reason to switch to monow whatsoever. The space saving of using monow rather than pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage may vary, of course. And in order to be consequent, this would have to be done for 1 bpp QuickTime Animation (qtrle) as well. with your patch applied, this one should of course be ignored. Mats What's more, the palette side data is retrieved twice with your patch, at the beginning and at the end of raw_decode(). Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Do you mind reverting your patch? I don't see why monow would have to be used whatseover. Mats whatsoever, not whatseover. I still have the old version of rawdec.c before your patch was applied here, so I can create a patch that restores it if you want. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On Sun, 31 Jan 2016 12:35:20 +0100 Mats Peterson wrote: > On 01/31/2016 12:31 PM, Mats Peterson wrote: > > On 01/31/2016 12:28 PM, Mats Peterson wrote: > >> On 01/31/2016 12:27 PM, Mats Peterson wrote: > >>> On 01/31/2016 12:25 PM, Mats Peterson wrote: > On 01/31/2016 12:19 PM, Mats Peterson wrote: > > I've obviously missed that one, Michael, but I don't see the reason to > > switch to monow whatsoever. The space saving of using monow rather > > than > > pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage may > > vary, of course. And in order to be consequent, this would have to be > > done for 1 bpp QuickTime Animation (qtrle) as well. > > > > with your patch applied, this one should of course be ignored. > > > > Mats > > > > What's more, the palette side data is retrieved twice with your patch, > at the beginning and at the end of raw_decode(). > > Mats > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >>> > >>> Do you mind reverting your patch? I don't see why monow would have to be > >>> used whatseover. > >>> > >>> Mats > >>> > >> > >> whatsoever, not whatseover. > >> > > > > I still have the old version of rawdec.c before your patch was applied > > here, so I can create a patch that restores it if you want. > > > > Mats > > > > I'll have to regenerate the FATE test files once again as well, obviously. "git revert" exists. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On 01/31/2016 01:10 PM, wm4 wrote: On Sun, 31 Jan 2016 12:35:20 +0100 Mats Peterson wrote: On 01/31/2016 12:31 PM, Mats Peterson wrote: On 01/31/2016 12:28 PM, Mats Peterson wrote: On 01/31/2016 12:27 PM, Mats Peterson wrote: On 01/31/2016 12:25 PM, Mats Peterson wrote: On 01/31/2016 12:19 PM, Mats Peterson wrote: I've obviously missed that one, Michael, but I don't see the reason to switch to monow whatsoever. The space saving of using monow rather than pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage may vary, of course. And in order to be consequent, this would have to be done for 1 bpp QuickTime Animation (qtrle) as well. with your patch applied, this one should of course be ignored. Mats What's more, the palette side data is retrieved twice with your patch, at the beginning and at the end of raw_decode(). Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Do you mind reverting your patch? I don't see why monow would have to be used whatseover. Mats whatsoever, not whatseover. I still have the old version of rawdec.c before your patch was applied here, so I can create a patch that restores it if you want. Mats I'll have to regenerate the FATE test files once again as well, obviously. "git revert" exists. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I'm creating a new patch here, anyway. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Error Message in Kodi ffmpeg - DVB subtitles with multiple languages
Kristian netvigator.com> writes: > I have uploaded a 10MB sample to the incoming folder of the ftp > server and an explanatory file. Uploaded to http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4469/ I don't know if one stream really contains more than one subtitle language. Thank you for the sample! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
I don't really appreciate that you're doing things behind my back,
Michael. There's nothing mentioned on the ffmpeg-devel mailing list
about your "monowhite switching patch". Furthermore, to me it's highly
unncecessary to use monowhite whatsoever. The space savings are quite
irrelevant nowadays, and the logic to detect whether a file is black &
white only creates more noise in the code. Here's a patch that restores
the old behaviour of only using pal8 for 1 bpp video, and removes
superfluous monowhite stuff.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 28c85e3bbda7eb957343f8b6c43cbffeb301a5c0 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 31 Jan 2016 13:22:39 +0100
Subject: [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
---
libavcodec/rawdec.c | 41 -
tests/ref/vsynth/vsynth1-bpp1 |4 ++--
tests/ref/vsynth/vsynth2-bpp1 |4 ++--
tests/ref/vsynth/vsynth3-bpp1 |4 ++--
tests/ref/vsynth/vsynth_lena-bpp1 |4 ++--
5 files changed, 16 insertions(+), 41 deletions(-)
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 93cbedf..7c59ed6 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -112,9 +112,6 @@ static av_cold int raw_init_decoder(AVCodecContext *avctx)
avctx->pix_fmt == AV_PIX_FMT_YUYV422)
context->is_yuv2 = 1;
-if (avctx->pix_fmt == AV_PIX_FMT_PAL8 && avctx->bits_per_coded_sample == 1)
-avctx->pix_fmt = AV_PIX_FMT_NONE;
-
return 0;
}
@@ -155,7 +152,7 @@ MKSCALE16(scale16le, AV_RL16, AV_WL16)
static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
AVPacket *avpkt)
{
-const AVPixFmtDescriptor *desc;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
RawVideoContext *context = avctx->priv_data;
const uint8_t *buf = avpkt->data;
int buf_size = avpkt->size;
@@ -176,35 +173,15 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
av_log(avctx, AV_LOG_ERROR, "Packet too small (%d) height (%d)\n", avpkt->size, avctx->height);
return AVERROR_INVALIDDATA;
}
-if (avctx->pix_fmt == AV_PIX_FMT_NONE &&
-avctx->bits_per_coded_sample == 1 &&
-avctx->frame_number == 0 &&
-context->palette &&
-AV_RB64(context->palette->data) == 0x
-) {
-const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE, NULL);
-if (!pal) {
-avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
-} else
-avctx->pix_fmt = AV_PIX_FMT_PAL8;
-}
-
-desc = av_pix_fmt_desc_get(avctx->pix_fmt);
if ((avctx->bits_per_coded_sample == 8 || avctx->bits_per_coded_sample == 4
|| avctx->bits_per_coded_sample == 2 || avctx->bits_per_coded_sample == 1) &&
(avctx->pix_fmt == AV_PIX_FMT_PAL8 || avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) &&
(!avctx->codec_tag || avctx->codec_tag == MKTAG('r','a','w',' '))) {
context->is_1_2_4_8_bpp = 1;
-if (avctx->bits_per_coded_sample == 1 && avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
-int row_bytes = avctx->width / 8 + (avctx->width & 7 ? 1 : 0);
-context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
- FFALIGN(row_bytes, 16) * 8,
- avctx->height, 1);
-} else
-context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
- FFALIGN(avctx->width, 16),
- avctx->height, 1);
+context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
+ FFALIGN(avctx->width, 16),
+ avctx->height, 1);
} else {
context->is_lt_16bpp = av_get_bits_per_pixel(desc) == 16 && avctx->bits_per_coded_sample && avctx->bits_per_coded_sample < 16;
context->frame_size = av_image_get_buffer_size(avctx->pix_fmt, avctx->width,
@@ -244,14 +221,12 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
if (context->is_1_2_4_8_bpp) {
int i, j, row_pix = 0;
uint8_t *dst = frame->buf[0]->data;
-buf_size = context->frame_size -
-(avctx->pix_fmt == AV_PIX_FMT_PAL8 ? AVPALETTE_SIZE : 0);
-if (avctx->bits_per_coded_sample == 8 || avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
-int pix_per_byte = avctx->pix_fmt == AV_PIX_FMT_MONOWHITE ? 8 : 1;
+buf_size = context->frame_size - AVPALETTE_SIZE;
+if (avctx->bits_per_coded_sample == 8) {
for (i = 0, j = 0; j < buf_size && isize; i++, j++) {
dst[j] = buf[i];
-row_pix
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, 31 Jan 2016 13:27:22 +0100 Mats Peterson wrote: > I don't really appreciate that you're doing things behind my back, > Michael. There's nothing mentioned on the ffmpeg-devel mailing list > about your "monowhite switching patch". Furthermore, to me it's highly > unncecessary to use monowhite whatsoever. The space savings are quite > irrelevant nowadays, and the logic to detect whether a file is black & > white only creates more noise in the code. Here's a patch that restores > the old behaviour of only using pal8 for 1 bpp video, and removes > superfluous monowhite stuff. Less complexity for such a corner case sounds indeed better. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 01:33 PM, wm4 wrote: On Sun, 31 Jan 2016 13:27:22 +0100 Mats Peterson wrote: I don't really appreciate that you're doing things behind my back, Michael. There's nothing mentioned on the ffmpeg-devel mailing list about your "monowhite switching patch". Furthermore, to me it's highly unncecessary to use monowhite whatsoever. The space savings are quite irrelevant nowadays, and the logic to detect whether a file is black & white only creates more noise in the code. Here's a patch that restores the old behaviour of only using pal8 for 1 bpp video, and removes superfluous monowhite stuff. Less complexity for such a corner case sounds indeed better Yes, and what a corner case it is... Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/v210dec: Accept odd width
Paul B Mahol gmail.com> writes: > > Patch applied. > > Did you just pushed patch that overreads or leaves > uninitialized data? How can I reproduce this? > That's big nono. Of course but valgrind shows no issues here. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
Minor fix.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From c8e99942495c797067be55fb115a21955e11b76b Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 31 Jan 2016 14:08:19 +0100
Subject: [PATCH v2] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
Minor fix.
---
libavcodec/rawdec.c | 43 -
tests/ref/vsynth/vsynth1-bpp1 |4 ++--
tests/ref/vsynth/vsynth2-bpp1 |4 ++--
tests/ref/vsynth/vsynth3-bpp1 |4 ++--
tests/ref/vsynth/vsynth_lena-bpp1 |4 ++--
5 files changed, 17 insertions(+), 42 deletions(-)
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 93cbedf..a60e9bf 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -112,9 +112,6 @@ static av_cold int raw_init_decoder(AVCodecContext *avctx)
avctx->pix_fmt == AV_PIX_FMT_YUYV422)
context->is_yuv2 = 1;
-if (avctx->pix_fmt == AV_PIX_FMT_PAL8 && avctx->bits_per_coded_sample == 1)
-avctx->pix_fmt = AV_PIX_FMT_NONE;
-
return 0;
}
@@ -155,7 +152,7 @@ MKSCALE16(scale16le, AV_RL16, AV_WL16)
static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
AVPacket *avpkt)
{
-const AVPixFmtDescriptor *desc;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
RawVideoContext *context = avctx->priv_data;
const uint8_t *buf = avpkt->data;
int buf_size = avpkt->size;
@@ -176,35 +173,15 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
av_log(avctx, AV_LOG_ERROR, "Packet too small (%d) height (%d)\n", avpkt->size, avctx->height);
return AVERROR_INVALIDDATA;
}
-if (avctx->pix_fmt == AV_PIX_FMT_NONE &&
-avctx->bits_per_coded_sample == 1 &&
-avctx->frame_number == 0 &&
-context->palette &&
-AV_RB64(context->palette->data) == 0x
-) {
-const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE, NULL);
-if (!pal) {
-avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
-} else
-avctx->pix_fmt = AV_PIX_FMT_PAL8;
-}
-
-desc = av_pix_fmt_desc_get(avctx->pix_fmt);
if ((avctx->bits_per_coded_sample == 8 || avctx->bits_per_coded_sample == 4
|| avctx->bits_per_coded_sample == 2 || avctx->bits_per_coded_sample == 1) &&
-(avctx->pix_fmt == AV_PIX_FMT_PAL8 || avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) &&
+avctx->pix_fmt == AV_PIX_FMT_PAL8 &&
(!avctx->codec_tag || avctx->codec_tag == MKTAG('r','a','w',' '))) {
context->is_1_2_4_8_bpp = 1;
-if (avctx->bits_per_coded_sample == 1 && avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
-int row_bytes = avctx->width / 8 + (avctx->width & 7 ? 1 : 0);
-context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
- FFALIGN(row_bytes, 16) * 8,
- avctx->height, 1);
-} else
-context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
- FFALIGN(avctx->width, 16),
- avctx->height, 1);
+context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
+ FFALIGN(avctx->width, 16),
+ avctx->height, 1);
} else {
context->is_lt_16bpp = av_get_bits_per_pixel(desc) == 16 && avctx->bits_per_coded_sample && avctx->bits_per_coded_sample < 16;
context->frame_size = av_image_get_buffer_size(avctx->pix_fmt, avctx->width,
@@ -244,14 +221,12 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
if (context->is_1_2_4_8_bpp) {
int i, j, row_pix = 0;
uint8_t *dst = frame->buf[0]->data;
-buf_size = context->frame_size -
-(avctx->pix_fmt == AV_PIX_FMT_PAL8 ? AVPALETTE_SIZE : 0);
-if (avctx->bits_per_coded_sample == 8 || avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
-int pix_per_byte = avctx->pix_fmt == AV_PIX_FMT_MONOWHITE ? 8 : 1;
+buf_size = context->frame_size - AVPALETTE_SIZE;
+if (avctx->bits_per_coded_sample == 8) {
for (i = 0, j = 0; j < buf_size && isize; i++, j++) {
dst[j] = buf[i];
-row_pix += pix_per_byte;
-if (row_pix >= avctx->width) {
+row_pix++;
+if (row_pix == avctx->width) {
i += avpkt_stride - (i % avpkt_stride) - 1;
j += 16 - (j % 16) - 1;
row_pix = 0;
diff --git a/tests/ref/vsynth/vsynth1-bpp1 b/tests/ref/vsynth/vsynth1-bpp1
index 32dab11..378f990 100644
--- a/tests/ref/vsynth/vsynth1-bpp1
+++ b/tests/ref/vsynth
[FFmpeg-devel] [PATCH 2/2] mpeg12dec: Export GOP timecodes as side data
The codec context field was rightly deprecated, and the data
may change per-frame.
Signed-off-by: Derek Buitenhuis
---
ffprobe.c | 8
libavcodec/mpeg12dec.c | 19 ---
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/ffprobe.c b/ffprobe.c
index c352b44..019863a 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2226,14 +2226,6 @@ static int show_stream(WriterContext *w, AVFormatContext
*fmt_ctx, int stream_id
print_str("chroma_location",
av_chroma_location_name(dec_ctx->chroma_sample_location));
else
print_str_opt("chroma_location",
av_chroma_location_name(dec_ctx->chroma_sample_location));
-
-if (dec_ctx->timecode_frame_start >= 0) {
-char tcbuf[AV_TIMECODE_STR_SIZE];
-av_timecode_make_mpeg_tc_string(tcbuf,
dec_ctx->timecode_frame_start);
-print_str("timecode", tcbuf);
-} else {
-print_str_opt("timecode", "N/A");
-}
print_int("refs", dec_ctx->refs);
break;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 23c77cd..56a87a4 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2413,17 +2413,25 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
-static void mpeg_decode_gop(AVCodecContext *avctx,
+static int mpeg_decode_gop(AVCodecContext *avctx,
const uint8_t *buf, int buf_size)
{
Mpeg1Context *s1 = avctx->priv_data;
MpegEncContext *s = &s1->mpeg_enc_ctx;
+AVFrameSideData *tcside;
int broken_link;
int64_t tc;
+tcside = av_frame_new_side_data(s->current_picture_ptr->f,
+AV_FRAME_DATA_GOP_TIMECODE,
sizeof(int64_t));
+if (!tcside)
+return AVERROR(ENOMEM);
+
init_get_bits(&s->gb, buf, buf_size * 8);
-tc = avctx->timecode_frame_start = get_bits(&s->gb, 25);
+tc = get_bits(&s->gb, 25);
+
+memcpy(tcside->data, &tc, sizeof(int64_t));
s->closed_gop = get_bits1(&s->gb);
/* broken_link indicate that after editing the
@@ -2438,6 +2446,8 @@ static void mpeg_decode_gop(AVCodecContext *avctx,
"GOP (%s) closed_gop=%d broken_link=%d\n",
tcbuf, s->closed_gop, broken_link);
}
+
+return 0;
}
static int decode_chunks(AVCodecContext *avctx, AVFrame *picture,
@@ -2604,8 +2614,11 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame
*picture,
break;
case GOP_START_CODE:
if (last_code == 0) {
+int gopret;
s2->first_field = 0;
-mpeg_decode_gop(avctx, buf_ptr, input_size);
+gopret = mpeg_decode_gop(avctx, buf_ptr, input_size);
+if (gopret < 0)
+return gopret;
s->sync = 1;
} else {
av_log(avctx, AV_LOG_ERROR,
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/2] Move MPEG1/2 GOP timecodes to side data
CC'd Clement, side he added it originally.; Derek Buitenhuis (2): avutil: Add GOP timecode frame side data mpeg12dec: Export GOP timecodes as side data ffprobe.c | 8 libavcodec/mpeg12dec.c | 19 --- libavutil/frame.h | 7 ++- libavutil/version.h| 4 ++-- 4 files changed, 24 insertions(+), 14 deletions(-) -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avutil: Add GOP timecode frame side data
Signed-off-by: Derek Buitenhuis
---
libavutil/frame.h | 7 ++-
libavutil/version.h | 4 ++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 406c8b5..e07922d 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -116,7 +116,12 @@ enum AVFrameSideDataType {
* an AVMasteringDisplayMetadata type and contains information about the
* mastering display color volume.
*/
-AV_FRAME_DATA_MASTERING_DISPLAY_METADATA
+AV_FRAME_DATA_MASTERING_DISPLAY_METADATA,
+/**
+ * The GOP timecode in 25 bit timecode format. Data format is 64-bit
integer.
+ * This is set on the first frame of a GOP.
+ */
+AV_FRAME_DATA_GOP_TIMECODE
};
enum AVActiveFormatDescription {
diff --git a/libavutil/version.h b/libavutil/version.h
index 8e1963c..5352f26 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -64,8 +64,8 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 55
-#define LIBAVUTIL_VERSION_MINOR 16
-#define LIBAVUTIL_VERSION_MICRO 101
+#define LIBAVUTIL_VERSION_MINOR 17
+#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] mpeg12dec: Export GOP timecodes as side data
On 1/31/2016 1:13 PM, Derek Buitenhuis wrote:
> -if (dec_ctx->timecode_frame_start >= 0) {
> -char tcbuf[AV_TIMECODE_STR_SIZE];
> -av_timecode_make_mpeg_tc_string(tcbuf,
> dec_ctx->timecode_frame_start);
> -print_str("timecode", tcbuf);
> -} else {
> -print_str_opt("timecode", "N/A");
> -}
This bit is going to be moved inside the deprecation defines.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On 01/31/2016 02:43 PM, Michael Niedermayer wrote: the space savings are significant, heres a 10second video to show this Of course they are significant (8 times less), but they are quite irrelevant nowadays with the amounts of memory we have today, as I have stated in the description of the new patch. And if you were to be consequent, you would have to change the logic for BMP files as well, which use pal8 for 1 bpp files. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove superfluous AV_PIX_FMT_MONOWHITE code
On Sun, Jan 31, 2016 at 12:19:21PM +0100, Mats Peterson wrote: > On 01/31/2016 11:31 AM, Michael Niedermayer wrote: > >On Sun, Jan 31, 2016 at 01:34:46AM +0100, Mats Peterson wrote: > >>On 01/30/2016 05:10 AM, Mats Peterson wrote: > >>>Now when both AVI and QuickTime use pal8 for 1 bpp video, there's no > >>>need to keep the monow stuff. > >>> > >>I should add that I'm only removing stuff that I've added myself > >>before, so don't worry. > > > >should this still be applied after > >6ffac5d33d334f847150356293ecb6f9eaf69e15 ? > > > >[...] > > > > > > > >___ > >ffmpeg-devel mailing list > >ffmpeg-devel@ffmpeg.org > >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > I've obviously missed that one, Michael, but I don't see the reason > to switch to monow whatsoever. The space saving of using monow > rather than pal8 for 1 bpp data is rather irrelevant nowadays. Your > mileage may vary, of course. And in order to be consequent, this > would have to be done for 1 bpp QuickTime Animation (qtrle) as well. it can be done for qtrle too, if one wants the space savings are significant, heres a 10second video to show this ./ffmpeg -pix_fmt monow -f rawvideo -s cif -i /dev/zero -t 10 -vcodec rawvideo test.avi ./ffmpeg -i test.avi -vcodec rawvideo out.avi ./ffmpeg-ref -i test.avi -vcodec rawvideo out-ref.avi -rw-r- 1 michael michael 25611686 Jan 31 14:34 out.avi -rw-r- 1 michael michael 3179686 Jan 31 14:34 out-ref.avi -rw-r- 1 michael michael 3179686 Jan 31 14:31 test.avi and since the table lists PAL8, muxing produces this warning: [avi @ 0x2d51940] monow rawvideo cannot be written to avi, output file will be unreadable the resulting file seems ok though [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB For every action, there is an equal and opposite reaction. -- Newton For every man jailed for a minor crime, theres one person more that will hate the government, some of them will become terrorists. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] docs: explain properly how -fs works
Umair Khan (1): docs: explain properly how -fs works doc/ffmpeg.texi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.5.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] docs: explain properly how -fs works
---
doc/ffmpeg.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7d3266a..07b7759 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -297,7 +297,8 @@ see @ref{time duration syntax,,the Time duration section in
the ffmpeg-utils(1)
-to and -t are mutually exclusive and -t has priority.
@item -fs @var{limit_size} (@emph{output})
-Set the file size limit, expressed in bytes.
+Set the file size limit, expressed in bytes. No more bytes are written
+after the limit is exceeded.
@item -ss @var{position} (@emph{input/output})
When used as an input option (before @code{-i}), seeks in this input file to
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 01:27:22PM +0100, Mats Peterson wrote: > I don't really appreciate that you're doing things behind my back, > Michael. There's nothing mentioned on the ffmpeg-devel mailing lis indeed, i should have clearly stated that i applied the pal8 patches with the plan to use pal8 only when neccessary. I had asked you to implement exactly that but it seemed you didnt know how to do that cleanly and simply so i thought "no problem, i know how to do that, ill do it" i had not expected this to be controversal > about your "monowhite switching patch". Furthermore, to me it's > highly unncecessary to use monowhite whatsoever. The space savings > are quite irrelevant nowadays, and the logic to detect whether a > file is black & white only creates more noise in the code. Here's a > patch that restores the old behaviour of only using pal8 for 1 bpp > video, and removes superfluous monowhite stuff. basically 100% of avis with monowhite are black&white, we do not have a single (no craftet) sample that contains paletted monochrome data in avi. IMHO its bizare to convert black and white 1 bpp data in the decoder to 8bit paletted data we reject colorspace/pixel format converting in the decoder normally unless its somehow a mess otherwise. and its a problem to for using the output because an encoder has to deal and encode 8bit paletted data from such avis even though they really are just black and white if pal8 is used [...] -- 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/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 01:33:02PM +0100, wm4 wrote: > On Sun, 31 Jan 2016 13:27:22 +0100 > Mats Peterson wrote: > > > I don't really appreciate that you're doing things behind my back, > > Michael. There's nothing mentioned on the ffmpeg-devel mailing list > > about your "monowhite switching patch". Furthermore, to me it's highly > > unncecessary to use monowhite whatsoever. The space savings are quite > > irrelevant nowadays, and the logic to detect whether a file is black & > > white only creates more noise in the code. Here's a patch that restores > > the old behaviour of only using pal8 for 1 bpp video, and removes > > superfluous monowhite stuff. > > Less complexity for such a corner case sounds indeed better. i dont mind reverting my patch if people prefer but converting from monochrome avis/nuts/others? to other formats would not store monochrome but paletted or RGB then heres an example with tiff: ./ffmpeg -i test.avi -vframes 1 test.tiff ./ffmpeg-ref -i test.avi -vframes 1 test-ref.tiff -rw-r- 1 michael michael 804 Jan 31 15:15 test-ref.tiff -rw-r- 1 michael michael 3592 Jan 31 15:15 test.tiff [...] -- 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] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 03:07 PM, Michael Niedermayer wrote: indeed, i should have clearly stated that i applied the pal8 patches with the plan to use pal8 only when neccessary. I had asked you to implement exactly that but it seemed you didnt know how to do that cleanly and simply so i thought "no problem, i know how to do that, ill do it" i had not expected this to be controversal Well, it would have been nice to know that you did it at least. I had no idea until you mentioned it. basically 100% of avis with monowhite are black&white, we do not have a single (no craftet) sample that contains paletted monochrome data in avi. IMHO its bizare to convert black and white 1 bpp data in the decoder to 8bit paletted data we reject colorspace/pixel format converting in the decoder normally unless its somehow a mess otherwise. and its a problem to for using the output because an encoder has to deal and encode 8bit paletted data from such avis even though they really are just black and white if pal8 is used It's not bizarre at all. Black & white is just a variant of palettized data in this context, it's not monochrome. And just because you don't have a non-b/w sample, it doesn't mean you should use monow. A 1 bpp AVI is not monochrome once again, it's palettized, even if it's only with black & white. The same semantics as with 1 bpp depth in QuickTime. And since you don't have a "pal2" or "pal4" format, it suddenly seems perfectly OK to convert this to pal8? THere's no logic in this. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 03:20 PM, Michael Niedermayer wrote: On Sun, Jan 31, 2016 at 01:33:02PM +0100, wm4 wrote: On Sun, 31 Jan 2016 13:27:22 +0100 Mats Peterson wrote: I don't really appreciate that you're doing things behind my back, Michael. There's nothing mentioned on the ffmpeg-devel mailing list about your "monowhite switching patch". Furthermore, to me it's highly unncecessary to use monowhite whatsoever. The space savings are quite irrelevant nowadays, and the logic to detect whether a file is black & white only creates more noise in the code. Here's a patch that restores the old behaviour of only using pal8 for 1 bpp video, and removes superfluous monowhite stuff. Less complexity for such a corner case sounds indeed better. i dont mind reverting my patch if people prefer No need to, just apply my latest patch, which restores the FATE test files as well, and includes the removal of superfluous monow stuff. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 5/5] libavfilter: VAAPI surface scaler
On 31/01/16 09:32, Paul B Mahol wrote:
> On 1/30/16, Mark Thompson wrote:
>> On 30/01/16 22:22, Paul B Mahol wrote:
>>> On 1/30/16, Mark Thompson wrote:
---
configure| 3 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_vaapi_scale.c | 709
+++
4 files changed, 714 insertions(+)
create mode 100644 libavfilter/vf_vaapi_scale.c
>>>
>>> missing documentation, how is this supposed to work?
>>
>> Documentation has not yet been written because the interface is not yet
>> finalised. (True of the whole series.)
>>
>> Can you clarify what "this" points to in that question? (The
>> documentation-writing, the filter itself, the submission process for this
>> patch series, the unclear hardware context setup, ... ?)
>>
>
> The filter itself.
>
See below.
It should probably look a bit more like vf_scale (at least with w/width and
h/height and default options), I'll look at this for the next iteration.
---
@section vaapi_scale
Scale the input video in hardware using the VAAPI video processing pipeline.
The input and output frames can either be a normal image format or an opaque
VAAPI surface. For the former case, the image data will be copied into/out of
VAAPI surfaces before/after being processed. For the latter case, the
@code{VASurfaceID} of the surface must be placed in @code{data[3]} of the
@code{AVFrame} input, and will appear in the same place in the output.
@subsection Options
@table @option
@item hardware_context
A pointer to the VAAPI hardware context to use. The type of this is
@code{AVVAAPIHardwareContext} (see @file{libavcodec/vaapi_support.h}), and must
be ready to use when the filter is initialised. This option must be set.
@item size
Set the output video size. For the syntax of this option, see the
@ref{video size syntax,,"Video size" section in the ffmpeg-utils
manual,ffmpeg-utils}.
@item force_vaapi_out
Make the filter declare that the only output format it supports is an opaque
VAAPI surface. This can help to push format negotiation into doing the right
thing when you are trying to avoid redundant copies from GPU memory and back.
@item force_vaapi_in
Like @var{force_vaapi_out}, for the input.
@end table
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 03:22 PM, Mats Peterson wrote: Yes it would, but just force -pix_fmt monow then. With the reservation that pal8 to monow is somewhat erratic, but I'll leave that to you guys to solve. I'm not able to. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 03:20 PM, Michael Niedermayer wrote: but converting from monochrome avis/nuts/others? to other formats would not store monochrome but paletted or RGB then heres an example with tiff: ./ffmpeg -i test.avi -vframes 1 test.tiff ./ffmpeg-ref -i test.avi -vframes 1 test-ref.tiff -rw-r- 1 michael michael 804 Jan 31 15:15 test-ref.tiff Yes it would, but just force -pix_fmt monow then. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 03:16:46PM +0100, Mats Peterson wrote: > On 01/31/2016 03:07 PM, Michael Niedermayer wrote: > >indeed, i should have clearly stated that i applied the pal8 > >patches with the plan to use pal8 only when neccessary. > >I had asked you to implement exactly that but it seemed you didnt > >know how to do that cleanly and simply so i thought "no problem, > >i know how to do that, ill do it" > >i had not expected this to be controversal > > > > Well, it would have been nice to know that you did it at least. I > had no idea until you mentioned it. > > >basically 100% of avis with monowhite are black&white, we do not have > >a single (no craftet) sample that contains paletted monochrome data > >in avi. > >IMHO its bizare to convert black and white 1 bpp data in the decoder > >to 8bit paletted data > >we reject colorspace/pixel format converting in the decoder normally > >unless its somehow a mess otherwise. > > > >and its a problem to for using the output because an encoder has to > >deal and encode 8bit paletted data from such avis even though they > >really are just black and white if pal8 is used > > > > It's not bizarre at all. Black & white is just a variant of > palettized data in this context, it's not monochrome. And just > because you don't have a non-b/w sample, it doesn't mean you should > use monow. A 1 bpp AVI is not monochrome once again, it's > palettized, even if it's only with black & white. The same semantics > as with 1 bpp depth in QuickTime. well, avi is a "old" format and ive worked with avis and maintained the avi demuxer for a long time. So if i dont remember a paletted 1bpp avi thats some indication that these would be rather rare if they exist at all > > And since you don't have a "pal2" or "pal4" format, it suddenly > seems perfectly OK to convert this to pal8? THere's no logic in > this. the problem is what happens with the data after the rawvideo decoder if its to be stored in a file the encoder will store 8bit paletted data (if it supports that) vs. 1bit monochrome data (if it supports that) making generated files potentially several times bigger [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein 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/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 03:22:57PM +0100, Mats Peterson wrote: > On 01/31/2016 03:20 PM, Michael Niedermayer wrote: > >but > >converting from monochrome avis/nuts/others? to other formats would > >not store monochrome but paletted or RGB then > > > >heres an example with tiff: > > > >./ffmpeg -i test.avi -vframes 1 test.tiff > >./ffmpeg-ref -i test.avi -vframes 1 test-ref.tiff > > > >-rw-r- 1 michael michael 804 Jan 31 15:15 test-ref.tiff > > Yes it would, but just force -pix_fmt monow then. less than one out of a hundread users would realize that also it does feel unclean to me to convert monochrome to pal8 in the decoder and then require the user to manually force convertion of paletted data back to monochrome [...] -- 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 v5 1/5] libavcodec: VAAPI support infrastructure
On 31/01/16 01:02, Timothy Gu wrote:
> On Sat, Jan 30, 2016 at 10:11:52PM +, Mark Thompson wrote:
>> +static AVClass vaapi_class = {
>
> static const
>
>> +.class_name = "vaapi",
>> +.item_name = av_default_item_name,
>> +.version= LIBAVUTIL_VERSION_INT,
>> +};
>> +static AVClass *vaapi_log = &vaapi_class;
>
> Ditto
>
> Timothy
Fixed; thanks.
On 30/01/16 22:11, Mark Thompson wrote:
> ...
> +#ifndef LIBAVUTIL_VAAPI_H_
> +#define LIBAVUTIL_VAAPI_H_
> ...
> +#endif /* LIBAVUTIL_VAAPI_H_ */
>
No longer in libavutil; fixed.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] docs: explain properly how -fs works
Umair Khan gmail.com> writes: > +Set the file size limit, expressed in bytes. No more bytes are written > +after the limit is exceeded. Does this explain that the file size is never smaller than the requested size (but usually higher)? Please mention ticket #5160 in the commit message. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3 v2] ffprobe: Deprecate stream timecode field and add frame side data timecode field
Signed-off-by: Derek Buitenhuis
---
ffprobe.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ffprobe.c b/ffprobe.c
index c352b44..f7b51ad 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -1917,6 +1917,10 @@ static void show_frame(WriterContext *w, AVFrame *frame,
AVStream *stream,
if (sd->type == AV_FRAME_DATA_DISPLAYMATRIX && sd->size >= 9*4) {
writer_print_integers(w, "displaymatrix", sd->data, 9, "
%11d", 3, 4, 1);
print_int("rotation", av_display_rotation_get((int32_t
*)sd->data));
+} else if (sd->type == AV_FRAME_DATA_GOP_TIMECODE && sd->size >=
8) {
+char tcbuf[AV_TIMECODE_STR_SIZE];
+av_timecode_make_mpeg_tc_string(tcbuf, *(int64_t *)(sd->data));
+print_str("timecode", tcbuf);
}
writer_print_section_footer(w);
}
@@ -2227,6 +2231,7 @@ static int show_stream(WriterContext *w, AVFormatContext
*fmt_ctx, int stream_id
else
print_str_opt("chroma_location",
av_chroma_location_name(dec_ctx->chroma_sample_location));
+#if FF_API_PRIVATE_OPT
if (dec_ctx->timecode_frame_start >= 0) {
char tcbuf[AV_TIMECODE_STR_SIZE];
av_timecode_make_mpeg_tc_string(tcbuf,
dec_ctx->timecode_frame_start);
@@ -2234,6 +2239,7 @@ static int show_stream(WriterContext *w, AVFormatContext
*fmt_ctx, int stream_id
} else {
print_str_opt("timecode", "N/A");
}
+#endif
print_int("refs", dec_ctx->refs);
break;
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 03:29 PM, Michael Niedermayer wrote: less than one out of a hundread users would realize that also it does feel unclean to me to convert monochrome to pal8 in the decoder and then require the user to manually force convertion of paletted data back to monochrome Since this is the way FFmpeg works, there is no way around it. Unfortunately. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 03:27 PM, Michael Niedermayer wrote: It's not bizarre at all. Black & white is just a variant of palettized data in this context, it's not monochrome. And just because you don't have a non-b/w sample, it doesn't mean you should use monow. A 1 bpp AVI is not monochrome once again, it's palettized, even if it's only with black & white. The same semantics as with 1 bpp depth in QuickTime. well, avi is a "old" format and ive worked with avis and maintained the avi demuxer for a long time. So if i dont remember a paletted 1bpp avi thats some indication that these would be rather rare if they exist at all They are rare, alright, but we should follow the specs, shouldn't we? And the specs tell us that 1 bpp AVI is not just black & white but palettized, albeit with only 2 colors. TIFF is a different story, it explicitly has a "bilevel" format which is black & white only. And since you don't have a "pal2" or "pal4" format, it suddenly seems perfectly OK to convert this to pal8? THere's no logic in this. the problem is what happens with the data after the rawvideo decoder if its to be stored in a file the encoder will store 8bit paletted data (if it supports that) vs. 1bit monochrome data (if it supports that) making generated files potentially several times bigger Not good enough as an argument for using monow. The space increase of using pal8 compared to monochrome is hardly an issue nowadays. It was in the early 90s, but that was then. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/3 v2] Move MPEG1/2 GOP timecodes to side data
Derek Buitenhuis (3): avutil: Add GOP timecode frame side data mpeg12dec: Export GOP timecodes as side data ffprobe: Deprecate stream timecode field and add frame side data timecode field doc/APIchanges | 3 +++ ffprobe.c | 6 ++ libavcodec/mpeg12dec.c | 22 -- libavutil/frame.c | 1 + libavutil/frame.h | 7 ++- libavutil/version.h| 4 ++-- 6 files changed, 38 insertions(+), 5 deletions(-) -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3 v2] mpeg12dec: Export GOP timecodes as side data
The codec context field was rightly deprecated, and the data
may change per-frame.
Signed-off-by: Derek Buitenhuis
---
I really don't liek dumping part of this at the end of mpeg_decode_frame,
but I have no idea where else to put it, so that the decoder delay and
reordering do not affect it.
Anyone who cares to help, please do!
---
libavcodec/mpeg12dec.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 23c77cd..b40a182 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2423,7 +2423,13 @@ static void mpeg_decode_gop(AVCodecContext *avctx,
init_get_bits(&s->gb, buf, buf_size * 8);
-tc = avctx->timecode_frame_start = get_bits(&s->gb, 25);
+tc = s-> timecode_frame_start = get_bits(&s->gb, 25);
+
+#if FF_API_PRIVATE_OPT
+FF_DISABLE_DEPRECATION_WARNINGS
+avctx->timecode_frame_start = tc;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
s->closed_gop = get_bits1(&s->gb);
/* broken_link indicate that after editing the
@@ -2831,9 +2837,21 @@ static int mpeg_decode_frame(AVCodecContext *avctx, void
*data,
}
ret = decode_chunks(avctx, picture, got_output, buf, buf_size);
-if (ret<0 || *got_output)
+if (ret<0 || *got_output) {
s2->current_picture_ptr = NULL;
+if (s2->timecode_frame_start != -1) {
+AVFrameSideData *tcside = av_frame_new_side_data(picture,
+
AV_FRAME_DATA_GOP_TIMECODE,
+ sizeof(int64_t));
+if (!tcside)
+return AVERROR(ENOMEM);
+memcpy(tcside->data, &s2->timecode_frame_start, sizeof(int64_t));
+
+s2->timecode_frame_start = -1;
+}
+}
+
return ret;
}
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3 v2] avutil: Add GOP timecode frame side data
Signed-off-by: Derek Buitenhuis
---
doc/APIchanges | 3 +++
libavutil/frame.c | 1 +
libavutil/frame.h | 7 ++-
libavutil/version.h | 4 ++--
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 15aefb5..45ccf13 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
API changes, most recent first:
+2016-01-31 - xxx - lavu 55.17.100
+ Add AV_FRAME_DATA_GOP_TIMECODE for exporting MPEG1/2 GOP timecodes.
+
2016-01-01 - xxx - lavc 57.21.100 / 57.12.0 - avcodec.h
Add AVCodecDescriptor.profiles and avcodec_profile_name().
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 9f9c720..c33e462 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -733,6 +733,7 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type)
case AV_FRAME_DATA_SKIP_SAMPLES:return "Skip samples";
case AV_FRAME_DATA_AUDIO_SERVICE_TYPE: return "Audio service
type";
case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA: return "Mastering display
metadata";
+case AV_FRAME_DATA_GOP_TIMECODE:return "GOP timecode";
}
return NULL;
}
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 406c8b5..e07922d 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -116,7 +116,12 @@ enum AVFrameSideDataType {
* an AVMasteringDisplayMetadata type and contains information about the
* mastering display color volume.
*/
-AV_FRAME_DATA_MASTERING_DISPLAY_METADATA
+AV_FRAME_DATA_MASTERING_DISPLAY_METADATA,
+/**
+ * The GOP timecode in 25 bit timecode format. Data format is 64-bit
integer.
+ * This is set on the first frame of a GOP.
+ */
+AV_FRAME_DATA_GOP_TIMECODE
};
enum AVActiveFormatDescription {
diff --git a/libavutil/version.h b/libavutil/version.h
index 8e1963c..5352f26 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -64,8 +64,8 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 55
-#define LIBAVUTIL_VERSION_MINOR 16
-#define LIBAVUTIL_VERSION_MICRO 101
+#define LIBAVUTIL_VERSION_MINOR 17
+#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 03:33 PM, Mats Peterson wrote: On 01/31/2016 03:29 PM, Michael Niedermayer wrote: less than one out of a hundread users would realize that also it does feel unclean to me to convert monochrome to pal8 in the decoder and then require the user to manually force convertion of paletted data back to monochrome Since this is the way FFmpeg works, there is no way around it. Unfortunately. It is just as unclean to convert a 4 bpp file to pal8 then. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 03:33:00PM +0100, Mats Peterson wrote: > On 01/31/2016 03:29 PM, Michael Niedermayer wrote: > >less than one out of a hundread users would realize that > >also it does feel unclean to me to convert monochrome to pal8 in > >the decoder and then require the user to manually force convertion > >of paletted data back to monochrome > > Since this is the way FFmpeg works, there is no way around it. > Unfortunately. ffmpeg source is not unchanegable, if you belive that pal8 should be used in place of monochrome you could certaily make the code act more reasonable with a 2 entry (black+white) PAL8 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data 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/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 03:59 PM, Michael Niedermayer wrote: ffmpeg source is not unchanegable, if you belive that pal8 should be used in place of monochrome you could certaily make the code act more reasonable with a 2 entry (black+white) PAL8 I don't believe. It's a fact. And it is used in other places (QuickTime, both raw and RLE, and BMP) for 1 bpp data, so why shouldn't it for AVI as well? Please, just apply my latest patch that restores the pal8-only behaviour. This is a lot more logical than switching to monow for the case of black & white, which has to detected with extraneous code, and which just complicates things in my book. The customer is always right, remember? Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 04:03 PM, Mats Peterson wrote: On 01/31/2016 03:59 PM, Michael Niedermayer wrote: ffmpeg source is not unchanegable, if you belive that pal8 should be used in place of monochrome you could certaily make the code act more reasonable with a 2 entry (black+white) PAL8 I don't believe. It's a fact. And it is used in other places (QuickTime, both raw and RLE, and BMP) for 1 bpp data, so why shouldn't it for AVI as well? Please, just apply my latest patch that restores the pal8-only behaviour. This is a lot more logical than switching to monow for the case of black & white, which has to detected with extraneous code, and which just complicates things in my book. The customer is always right, remember? I already initialize the palette in raw_init_decode() to black & white for AVIs that don't have a palette. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 04:05 PM, Mats Peterson wrote: I don't believe. It's a fact. And it is used in other places (QuickTime, both raw and RLE, and BMP) for 1 bpp data, so why shouldn't it for AVI as well? Please, just apply my latest patch that restores the pal8-only behaviour. This is a lot more logical than switching to monow for the case of black & white, which has to detected with extraneous code, and which just complicates things in my book. The customer is always right, remember? I already initialize the palette in raw_init_decode() to black & white for AVIs that don't have a palette. Mats People will have to get used to the video data being converted from 1 bpp to 8 bpp internally, just as they have become used to 2 and 4 bpp data being converted to 8 bpp. It shouldn't come as a shock, since this is perfectly logical behaviour, as long as we don't have "pal1", "pal2" or "pal4" pixel formats. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 04:19 PM, Mats Peterson wrote: People will have to get used to the video data being converted from 1 bpp to 8 bpp internally, just as they have become used to 2 and 4 bpp data being converted to 8 bpp. It shouldn't come as a shock, since this is perfectly logical behaviour, as long as we don't have "pal1", "pal2" or "pal4" pixel formats. Mats Once again, I would be hard pressed to find an application today that uses a 1-bit bitmap internally for the purpose of saving space. This was important in the past when memory was severely limited. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] docs: explain properly how -fs works
On Sun, Jan 31, 2016 at 8:04 PM, Carl Eugen Hoyos wrote: > Umair Khan gmail.com> writes: > >> +Set the file size limit, expressed in bytes. No more bytes are written >> +after the limit is exceeded. > > Does this explain that the file size is never smaller than > the requested size (but usually higher)? > > Please mention ticket #5160 in the commit message. Hi, Thanks for reply. I did a lot of searching but couldn't get what is the proper way to resend the patch with amended commit. Should I just do git send-email again ? And should I send it to this thread only ? If yes, how ? Umair ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 00/16] Replace native DCA decoder with libdcadec based one
On Sat, Jan 30, 2016 at 11:02 PM, James Almer wrote: > On 1/30/2016 6:45 PM, Hendrik Leppkes wrote: >> On Sat, Jan 30, 2016 at 10:41 PM, James Almer wrote: >>> On 1/30/2016 6:15 PM, Hendrik Leppkes wrote: On Sat, Jan 30, 2016 at 7:05 PM, Hendrik Leppkes wrote: > On Sat, Jan 30, 2016 at 1:43 AM, Andreas Cadhalpun > wrote: >> On 25.01.2016 23:47, Hendrik Leppkes wrote: >>> The decoder in itself looks fine to me, short of the regression michael >>> found. >>> If you could look at that, that would be great. >>> >>> I can squash and re-shuffle the commits appropriately for pushing and >>> make sure all intermediate steps still build, so don't worry about >>> that as much. >>> I would love to get this in soon, we can do further improvements and >>> more FATE coverage after. >> >> I agree that it's time to apply these patches. Resending this huge >> patch set for tiny improvements is just not practical. >> >>> There doesn't seem to be much agreement yet of the order of pushing. >>> I would argue that since we're replacing the decoder entirely anyway, >>> a tiny period in between where we don't actually have a dca decoder >>> wouldn't break any bisect flow, since it would probably end there >>> anyway. >>> So considering that, it feels cleaner to me to push the removal first, >>> and then the additions for the new decoder for "prettier" history. >> >> That seems fine to me, but I don't have a strong opinion about this. >> > > I have started to rebase, update and squash it appropriately, > including the patch for Michaels issue I posted earlier. > Once its all ready for pushing, I'll post my GitHub link for a final > review if anyone wants to, and otherwise push it in the next day or > two, so we finally get this done. > Here is the repository, rebased and partially squashed: https://github.com/Nevcairiel/FFmpeg/tree/dca All individual steps build and pass FATE, version bump and Changelog entry in the commit with the new decoder. >>> >>> It doesn't really need a minor bump. It's not a "new" decoder that wasn't >>> available before. Just bump micro because of the avoption changes. This >>> change is completely transparent from an API PoV otherwise. >> >> Suppose micro is fine as well. >> >>> - Hendrik >>> >>> IMO, merge "avcodec/dca: add math helpers and fixed point DCT" into the >>> last patch. It's no different than the dsp patch you already squashed. >>> >> >> The new synth filter functions depend on those (fixed point synth >> filter needs fixed point DCT), so its either squash those as well, or >> keep them split. >> >> - Hendrik > > Ah, i see. Ok, keep them split then. Thanks for merging and applying all > this. The decoder has been pushed now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/5] libavcodec: VAAPI support infrastructure
On Sat, 30 Jan 2016 22:11:52 +
Mark Thompson wrote:
> ---
> configure | 5 +
> libavcodec/Makefile| 1 +
> libavcodec/vaapi_support.c | 710
> +
> libavcodec/vaapi_support.h | 122
> 4 files changed, 838 insertions(+)
> create mode 100644 libavcodec/vaapi_support.c
> create mode 100644 libavcodec/vaapi_support.h
>
> diff --git a/configure b/configure
> index dba8180..e7f53af 100755
> --- a/configure
> +++ b/configure
> @@ -2037,6 +2037,7 @@ CONFIG_EXTRA="
> texturedsp
> texturedspenc
> tpeldsp
> +vaapi_recent
> videodsp
> vp3dsp
> vp56dsp
> @@ -5768,6 +5769,10 @@ enabled vaapi &&
> check_lib va/va.h vaInitialize -lva ||
> disable vaapi
>
> +enabled vaapi &&
> +check_code cc va/va.h "vaCreateSurfaces(0, 0, 0, 0, 0, 0, 0, 0)" &&
> +enable vaapi_recent
> +
> enabled vaapi && enabled xlib &&
> check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
> enable vaapi_x11
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index de957d8..045d118 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -719,6 +719,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER) += adpcmenc.o
> adpcm_data.o
> OBJS-$(CONFIG_D3D11VA)+= dxva2.o
> OBJS-$(CONFIG_DXVA2) += dxva2.o
> OBJS-$(CONFIG_VAAPI) += vaapi.o
> +OBJS-$(CONFIG_VAAPI_RECENT) += vaapi_support.o
> OBJS-$(CONFIG_VDA)+= vda.o videotoolbox.o
> OBJS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.o
> OBJS-$(CONFIG_VDPAU) += vdpau.o
> diff --git a/libavcodec/vaapi_support.c b/libavcodec/vaapi_support.c
> new file mode 100644
> index 000..2e22f98
> --- /dev/null
> +++ b/libavcodec/vaapi_support.c
> @@ -0,0 +1,710 @@
> +/*
> + * VAAPI helper functions.
> + *
> + * Copyright (C) 2016 Mark Thompson
> + *
> + * 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 "vaapi_support.h"
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/pixfmt.h"
> +
> +
> +static AVClass vaapi_class = {
> +.class_name = "vaapi",
> +.item_name = av_default_item_name,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +static AVClass *vaapi_log = &vaapi_class;
> +
I'll give a more thorough review tomorrow, but let me just point out
that this is not really the point of the log mechanism. It should be
bound to an actual instance, like the vaapi hw context or whatever. We
hope to get rid of the global log callback one day, and then all av_log
calls have to go to an instance of some sort (so that it can find the
log callback), even if this doesn't matter today yet.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] docs: explain properly how -fs works
On 2016-01-31 16:58, Umair Khan wrote: > Hi, > Thanks for reply. I did a lot of searching but couldn't get what is > the proper way to resend the patch with amended commit. > Should I just do git send-email again ? > And should I send it to this thread only ? If yes, how ? Yes. Run send-email again. Consider adding the --in-reply-to option and specify the message-id from your first one (or any other messge in this thread). Otherwise you can edit the email before sending with --annotate and make it [PATCH v2] (or similar). Sometimes it can be good to wait a little while before sending another patch to give others the chance to comment. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/5] libavcodec: VAAPI support infrastructure
On 31/01/16 16:13, wm4 wrote:
> On Sat, 30 Jan 2016 22:11:52 +
> Mark Thompson wrote:
>> +
>> +static AVClass vaapi_class = {
>> +.class_name = "vaapi",
>> +.item_name = av_default_item_name,
>> +.version= LIBAVUTIL_VERSION_INT,
>> +};
>> +static AVClass *vaapi_log = &vaapi_class;
>> +
>
> I'll give a more thorough review tomorrow, but let me just point out
> that this is not really the point of the log mechanism. It should be
> bound to an actual instance, like the vaapi hw context or whatever. We
> hope to get rid of the global log callback one day, and then all av_log
> calls have to go to an instance of some sort (so that it can find the
> log callback), even if this doesn't matter today yet.
>
I wanted to put an AVClass into the hardware context structure, but it doesn't
work without breaking the compatibility with struct vaapi_context (because it
has to be the first thing in the structure).
Without that, there is just nothing to bind it to in many of those functions.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/5] libavcodec: VAAPI support infrastructure
On 31/01/16 16:24, Mark Thompson wrote:
> On 31/01/16 16:13, wm4 wrote:
>> On Sat, 30 Jan 2016 22:11:52 +
>> Mark Thompson wrote:
>>> +
>>> +static AVClass vaapi_class = {
>>> +.class_name = "vaapi",
>>> +.item_name = av_default_item_name,
>>> +.version= LIBAVUTIL_VERSION_INT,
>>> +};
>>> +static AVClass *vaapi_log = &vaapi_class;
>>> +
>>
>> I'll give a more thorough review tomorrow, but let me just point out
>> that this is not really the point of the log mechanism. It should be
>> bound to an actual instance, like the vaapi hw context or whatever. We
>> hope to get rid of the global log callback one day, and then all av_log
>> calls have to go to an instance of some sort (so that it can find the
>> log callback), even if this doesn't matter today yet.
>>
>
> I wanted to put an AVClass into the hardware context structure, but it
> doesn't work without breaking the compatibility with struct vaapi_context
> (because it has to be the first thing in the structure).
>
> Without that, there is just nothing to bind it to in many of those functions.
>
> - Mark
>
And then I see the hackaround just after sending...
struct {
foo;
const AVClass *class;
} bar;
av_log(&bar->class, ...);
Nasty, but I can use that. (And not really worse than the existing "log"
static variable.)
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 00/16] Replace native DCA decoder with libdcadec based one
Hendrik Leppkes gmail.com> writes: > The decoder has been pushed now. It would be great if somebody writes a (short) news entry. Thank you! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avdevice/lavfi: replace deprecated function
Hi,
patch attached.
From 93a99efb889615d2f51f585d4cc49c2d6df70e28 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 31 Jan 2016 17:40:55 +0100
Subject: [PATCH] avdevice/lavfi: replace deprecated avpicture_layout
Signed-off-by: Paul B Mahol
---
libavdevice/lavfi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index 077879e..b7bc983 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -382,7 +382,6 @@ static int lavfi_read_packet(AVFormatContext *avctx, AVPacket *pkt)
double min_pts = DBL_MAX;
int stream_idx, min_pts_sink_idx = 0;
AVFrame *frame = lavfi->decoded_frame;
-AVPicture pict;
AVDictionary *frame_metadata;
int ret, i;
int size = 0;
@@ -435,11 +434,8 @@ static int lavfi_read_packet(AVFormatContext *avctx, AVPacket *pkt)
if ((ret = av_new_packet(pkt, size)) < 0)
return ret;
-memcpy(pict.data, frame->data, 4*sizeof(frame->data[0]));
-memcpy(pict.linesize, frame->linesize, 4*sizeof(frame->linesize[0]));
-
-avpicture_layout(&pict, frame->format, frame->width, frame->height,
- pkt->data, size);
+av_image_copy_to_buffer(pkt->data, size, (const uint8_t **)frame->data, frame->linesize,
+frame->format, frame->width, frame->height, 1);
} else if (av_frame_get_channels(frame) /* FIXME test audio */) {
size = frame->nb_samples * av_get_bytes_per_sample(frame->format) *
av_frame_get_channels(frame);
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 04:41:44PM +0100, Mats Peterson wrote: > On 01/31/2016 04:19 PM, Mats Peterson wrote: > >People will have to get used to the video data being converted from 1 > >bpp to 8 bpp internally, just as they have become used to 2 and 4 bpp > >data being converted to 8 bpp. It shouldn't come as a shock, since this > >is perfectly logical behaviour, as long as we don't have "pal1", "pal2" > >or "pal4" pixel formats. > > > >Mats > > Once again, I would be hard pressed to find an application today > that uses a 1-bit bitmap internally for the purpose of saving space. > This was important in the past when memory was severely limited. ffmpeg (the application) reads and writes multimedia files why should ffmpeg suddenly stop working well with monochrome ? (and require the user to per file convert to monochrome when the input already is monochrome) Also we talk about the raw video decoder here, i suspect this is used for more cases than just avi either way, as said iam happy to switch to using pal8 for monochrome avis if people want. I just dont know if people want that [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5 1/5] libavcodec: VAAPI support infrastructure
On Sun, 31 Jan 2016 16:32:24 +
Mark Thompson wrote:
> On 31/01/16 16:24, Mark Thompson wrote:
> > On 31/01/16 16:13, wm4 wrote:
> >> On Sat, 30 Jan 2016 22:11:52 +
> >> Mark Thompson wrote:
> >>> +
> >>> +static AVClass vaapi_class = {
> >>> +.class_name = "vaapi",
> >>> +.item_name = av_default_item_name,
> >>> +.version= LIBAVUTIL_VERSION_INT,
> >>> +};
> >>> +static AVClass *vaapi_log = &vaapi_class;
> >>> +
> >>
> >> I'll give a more thorough review tomorrow, but let me just point out
> >> that this is not really the point of the log mechanism. It should be
> >> bound to an actual instance, like the vaapi hw context or whatever. We
> >> hope to get rid of the global log callback one day, and then all av_log
> >> calls have to go to an instance of some sort (so that it can find the
> >> log callback), even if this doesn't matter today yet.
> >>
> >
> > I wanted to put an AVClass into the hardware context structure, but it
> > doesn't work without breaking the compatibility with struct vaapi_context
> > (because it has to be the first thing in the structure).
> >
> > Without that, there is just nothing to bind it to in many of those
> > functions.
> >
> > - Mark
> >
>
> And then I see the hackaround just after sending...
>
> struct {
> foo;
> const AVClass *class;
> } bar;
>
> av_log(&bar->class, ...);
>
> Nasty, but I can use that. (And not really worse than the existing "log"
> static variable.)
>
Why does AVClass have to be the first field in vaapi_context? Unless
you pass a vaapi_context pointer as argument to av_log, I don't see why
it would be needed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 04:03:36PM +0100, Mats Peterson wrote: > On 01/31/2016 03:59 PM, Michael Niedermayer wrote: > >ffmpeg source is not unchanegable, > >if you belive that pal8 should be used in place of monochrome you > >could certaily make the code act more reasonable with a 2 entry > >(black+white) PAL8 > > > > I don't believe. It's a fact. And it is used in other places > (QuickTime, both raw and RLE, and BMP) for 1 bpp data, so why > shouldn't it for AVI as well? Please, just apply my latest patch > that restores the pal8-only behaviour. This is a lot more logical > than switching to monow for the case of black & white, which has to > detected with extraneous code, and which just complicates things in > my book. there are many options support only black/white monochrome avis (this covers all real world samples we have) support only pal8 (this supports hypothetical paletted 1bpp but breaks converting to other monochrome formats without the user manually forcing monochrome, which he has no reason to really think that he would need to do that) support pal8+black/white monochrome avis, more complex code but supports both hypothetical paletted 1bpp and has correctly automatically working monochrome encoding support > The customer is always right, remember? yes but we have alot of "customers", i dont know what they prefer i dont even have a good approximation on what they prefer. but i suspect they probably prefer ffmpeg to "just work", most customers tend to want things to "just work" [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] mpeg12dec: Export GOP timecodes as side data
On Sun, Jan 31, 2016 at 01:13:42PM +, Derek Buitenhuis wrote: > The codec context field was rightly deprecated, and the data > may change per-frame. > > Signed-off-by: Derek Buitenhuis > --- > ffprobe.c | 8 > libavcodec/mpeg12dec.c | 19 --- > 2 files changed, 16 insertions(+), 11 deletions(-) this causes segfaults in fate TESTprobe-format-roundup1414 ./tests/fate-run.sh fate-probe-format-roundup1414 "fatesamples/fate/fate-suite/" "" "ffmpeg-git/ffmpeg" 'probefmt fatesamples/fate/fate-suite//probe-format/roundup1414' 'oneline' 'mpeg' '' '1' '' '' '' '' '' '' '' '' ffmpeg-git/ffmpeg/ffprobe -show_entries format=format_name -print_format default=nw=1:nk=1 -v 0 fatesamples/fate/fate-suite//probe-format/roundup1414 --- - 2016-01-31 18:48:21.493567697 +0100 +++ tests/data/fate/probe-format-roundup14142016-01-31 18:48:21.474836342 +0100 @@ -1 +0,0 @@ -mpeg Test probe-format-roundup1414 failed. Look at tests/data/fate/probe-format-roundup1414.err for details. Segmentation fault make: *** [fate-probe-format-roundup1414] Error 139 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] mpeg12dec: Export GOP timecodes as side data
On 1/31/2016 5:50 PM, Michael Niedermayer wrote: > this causes segfaults in fate Did you try v2? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 05:48 PM, Michael Niedermayer wrote: ffmpeg (the application) reads and writes multimedia files why should ffmpeg suddenly stop working well with monochrome ? (and require the user to per file convert to monochrome when the input already is monochrome) Also we talk about the raw video decoder here, i suspect this is used for more cases than just avi Why whould it "stop working well" with monochrome just because we use a different internal depth? And as I said, both QuickTime (raw and RLE) and BMP use pal8 exclusively for 1 bpp files. If you're willing to change the logic for these other formats as well, please go ahead. I won't do it. either way, as said iam happy to switch to using pal8 for monochrome avis if people want. I just dont know if people want that Why shouldn't we be consequent and do the same thing as for other file formats and other depths? It's over my head. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 07:04 PM, Mats Peterson wrote: either way, as said iam happy to switch to using pal8 for monochrome avis if people want. I just dont know if people want that Furthermore, there is no such thing as "monochrome AVIs". The semantics are that they are palettized, even if there are only two colors of black & white. Just like QuickTime. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/dca: add new decoder based on libdcadec
On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote: > ffmpeg | branch: master | foo86 | Sat Jan 16 11:54:38 > 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | committer: Hendrik > Leppkes > > avcodec/dca: add new decoder based on libdcadec > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ae5b2c52501d5009fe712334428138a9b758849b > --- > this breaks request_channel_layout example: ./ffmpeg -i dts/lotr_5.1_768.dts test.wav Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, 6.1, fltp, 768 kb/s vs. ./ffmpeg -request_channel_layout 3 -i dts/lotr_5.1_768.dts test-req3.wav Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s Stream #0:0: Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 768 kb/s vs. ./ffmpeg-ref -request_channel_layout 3 -i dts/lotr_5.1_768.dts test-ref-req3.wav Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, stereo, fltp, 768 kb/s previously it resulted in 2 channels now it produces 5.1 when requesting stereo [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/dca: add new decoder based on libdcadec
On 1/31/2016 3:51 PM, Michael Niedermayer wrote: > On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote: >> ffmpeg | branch: master | foo86 | Sat Jan 16 11:54:38 >> 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | committer: Hendrik >> Leppkes >> >> avcodec/dca: add new decoder based on libdcadec >> >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ae5b2c52501d5009fe712334428138a9b758849b >> --- >> > > > this breaks request_channel_layout > > example: > ./ffmpeg -i dts/lotr_5.1_768.dts test.wav > > Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': > Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s > Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, 6.1, fltp, 768 kb/s > > > vs. > ./ffmpeg -request_channel_layout 3 -i dts/lotr_5.1_768.dts test-req3.wav > > Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': > Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s > Stream #0:0: Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 768 kb/s > > vs. > ./ffmpeg-ref -request_channel_layout 3 -i dts/lotr_5.1_768.dts > test-ref-req3.wav > > Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': > Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s > Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, stereo, fltp, 768 kb/s > > > previously it resulted in 2 channels now it produces 5.1 when > requesting stereo libdcadec (and thus this new decoder) doesn't force stereo when downmix coefficients are not embedded in the stream, leaving the work to the resampler instead. Try the libdcadec wrapper and it will do the same. It's an intended change in behavior compared to the old dca decoder, so i guess it could documented. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/dca: add new decoder based on libdcadec
On Sun, Jan 31, 2016 at 7:57 PM, James Almer wrote: > On 1/31/2016 3:51 PM, Michael Niedermayer wrote: >> On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote: >>> ffmpeg | branch: master | foo86 | Sat Jan 16 11:54:38 >>> 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | committer: Hendrik >>> Leppkes >>> >>> avcodec/dca: add new decoder based on libdcadec >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ae5b2c52501d5009fe712334428138a9b758849b >>> --- >>> >> >> >> this breaks request_channel_layout >> >> example: >> ./ffmpeg -i dts/lotr_5.1_768.dts test.wav >> >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s >> Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, 6.1, fltp, 768 kb/s >> >> >> vs. >> ./ffmpeg -request_channel_layout 3 -i dts/lotr_5.1_768.dts test-req3.wav >> >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s >> Stream #0:0: Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 768 kb/s >> >> vs. >> ./ffmpeg-ref -request_channel_layout 3 -i dts/lotr_5.1_768.dts >> test-ref-req3.wav >> >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s >> Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, stereo, fltp, 768 kb/s >> >> >> previously it resulted in 2 channels now it produces 5.1 when >> requesting stereo > > libdcadec (and thus this new decoder) doesn't force stereo when downmix > coefficients are not embedded in the stream, leaving the work to the > resampler instead. Try the libdcadec wrapper and it will do the same. > > It's an intended change in behavior compared to the old dca decoder, so > i guess it could documented. Indeed, the decoder will only honor the request when the bitstream contains information to do so, instead of forcing a generic downmix like the old one. 5.1 is always possible for >5.1 streams, but stereo requires the bitstream to contain coefficients. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/dca: add new decoder based on libdcadec
On 1/31/2016 3:57 PM, James Almer wrote: > On 1/31/2016 3:51 PM, Michael Niedermayer wrote: >> On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote: >>> ffmpeg | branch: master | foo86 | Sat Jan 16 11:54:38 >>> 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | committer: Hendrik >>> Leppkes >>> >>> avcodec/dca: add new decoder based on libdcadec >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ae5b2c52501d5009fe712334428138a9b758849b >>> --- >>> >> >> >> this breaks request_channel_layout >> >> example: >> ./ffmpeg -i dts/lotr_5.1_768.dts test.wav >> >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s >> Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, 6.1, fltp, 768 kb/s >> >> >> vs. >> ./ffmpeg -request_channel_layout 3 -i dts/lotr_5.1_768.dts test-req3.wav >> >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s >> Stream #0:0: Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 768 kb/s >> >> vs. >> ./ffmpeg-ref -request_channel_layout 3 -i dts/lotr_5.1_768.dts >> test-ref-req3.wav >> >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s >> Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, stereo, fltp, 768 kb/s >> >> >> previously it resulted in 2 channels now it produces 5.1 when >> requesting stereo > > libdcadec (and thus this new decoder) doesn't force stereo when downmix > coefficients are not embedded in the stream, leaving the work to the > resampler instead. Try the libdcadec wrapper and it will do the same. > > It's an intended change in behavior compared to the old dca decoder, so > i guess it could documented. > To expand a bit based on what foo86 mentioned in a patch for the wrapper, with DTS-ES, DTS-HDMA and other extensions, if you request a stereo downmix and coefficients are not available it will not bother applying all the extensions to output 7 or 8 channels and instead output the core 5.1 stream as is, to simplify the work of the resampler. Trying to force a downmix using default coefficients may result in clipping. He can explain it much better than me, though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 00/16] Replace native DCA decoder with libdcadec based one
On Sun, Jan 31, 2016, at 07:33 AM, Carl Eugen Hoyos wrote: > > It would be great if somebody writes a (short) news entry. If someone provides the text I can add it to the site. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 07:04 PM, Mats Peterson wrote: Why whould it "stop working well" with monochrome just because we use a different internal depth? And as I said, both QuickTime (raw and RLE) Both 2 bpp and 4 bpp use pal8 internally, but nobody seems to complain about that fact. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/dca: add new decoder based on libdcadec
On Sun, Jan 31, 2016 at 04:04:41PM -0300, James Almer wrote: > On 1/31/2016 3:57 PM, James Almer wrote: > > On 1/31/2016 3:51 PM, Michael Niedermayer wrote: > >> On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote: > >>> ffmpeg | branch: master | foo86 | Sat Jan 16 > >>> 11:54:38 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | > >>> committer: Hendrik Leppkes > >>> > >>> avcodec/dca: add new decoder based on libdcadec > >>> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ae5b2c52501d5009fe712334428138a9b758849b > >>> --- > >>> > >> > >> > >> this breaks request_channel_layout > >> > >> example: > >> ./ffmpeg -i dts/lotr_5.1_768.dts test.wav > >> > >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': > >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s > >> Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, 6.1, fltp, 768 kb/s > >> > >> > >> vs. > >> ./ffmpeg -request_channel_layout 3 -i dts/lotr_5.1_768.dts test-req3.wav > >> > >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': > >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s > >> Stream #0:0: Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 768 kb/s > >> > >> vs. > >> ./ffmpeg-ref -request_channel_layout 3 -i dts/lotr_5.1_768.dts > >> test-ref-req3.wav > >> > >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': > >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s > >> Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, stereo, fltp, 768 kb/s > >> > >> > >> previously it resulted in 2 channels now it produces 5.1 when > >> requesting stereo > > > > libdcadec (and thus this new decoder) doesn't force stereo when downmix > > coefficients are not embedded in the stream, leaving the work to the > > resampler instead. Try the libdcadec wrapper and it will do the same. > > > > It's an intended change in behavior compared to the old dca decoder, so > > i guess it could documented. > > > > To expand a bit based on what foo86 mentioned in a patch for the wrapper, > with DTS-ES, DTS-HDMA and other extensions, if you request a stereo downmix > and coefficients are not available it will not bother applying all the > extensions to output 7 or 8 channels and instead output the core 5.1 stream > as is, to simplify the work of the resampler. > Trying to force a downmix using default coefficients may result in clipping. > > He can explain it much better than me, though. the output is float, that should not clip also how is downmixing after the decoder better, it too would apply some coefficients (either risking an increase in peak volume or a average loss of volume or inconsistet attenuation [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] docs: explain properly how -fs works
Signed-off-by: Umair Khan
---
doc/ffmpeg.texi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7d3266a..e02807c 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -297,7 +297,9 @@ see @ref{time duration syntax,,the Time duration section in
the ffmpeg-utils(1)
-to and -t are mutually exclusive and -t has priority.
@item -fs @var{limit_size} (@emph{output})
-Set the file size limit, expressed in bytes.
+Set the file size limit, expressed in bytes. No further chunk of bytes is
written
+after the limit is exceeded. The size of the output file is slightly more than
the
+requested file size.
@item -ss @var{position} (@emph{input/output})
When used as an input option (before @code{-i}), seeks in this input file to
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86: vc1dsp: Convert vc1_inv_trans_*_dc to NASM format
--- libavcodec/x86/vc1dsp.asm| 104 ++ libavcodec/x86/vc1dsp_init.c | 13 +++ libavcodec/x86/vc1dsp_mmx.c | 207 --- 3 files changed, 117 insertions(+), 207 deletions(-) diff --git a/libavcodec/x86/vc1dsp.asm b/libavcodec/x86/vc1dsp.asm index 6415a83..f922927 100644 --- a/libavcodec/x86/vc1dsp.asm +++ b/libavcodec/x86/vc1dsp.asm @@ -395,3 +395,107 @@ cglobal vc1_put_ver_16b_shift2, 4,7,0, dst, src, stride jnz .loop REP_RET %endif ; HAVE_MMX_INLINE + +%macro INV_TRANS_INIT 0 +movsxdifnidn linesizeq, linesized +movd m0, blockd +SPLATW m0, m0 +pxor m1, m1 +psubw m1, m0 +packuswb m0, m0 +packuswb m1, m1 +%endmacro + +%macro INV_TRANS_PROCESS 1 +mov%1 m2, [destq+linesizeq*0] +mov%1 m3, [destq+linesizeq*1] +mov%1 m4, [destq+linesizeq*2] +mov%1 m5, [destq+linesize3q] +paddusbm2, m0 +paddusbm3, m0 +paddusbm4, m0 +paddusbm5, m0 +psubusbm2, m1 +psubusbm3, m1 +psubusbm4, m1 +psubusbm5, m1 +mov%1 [linesizeq*0+destq], m2 +mov%1 [linesizeq*1+destq], m3 +mov%1 [linesizeq*2+destq], m4 +mov%1 [linesize3q +destq], m5 +%endmacro + +; ff_vc1_inv_trans_?x?_dc_mmxext(uint8_t *dest, int linesize, int16_t *block) +INIT_MMX mmxext +cglobal vc1_inv_trans_4x4_dc, 3,4,0, dest, linesize, block +movsx r3d, WORD [blockq] +movblockd, r3d ; dc +shlblockd, 4 ; 16 * dc +leablockd, [blockq+r3+4] ; 17 * dc + 4 +sarblockd, 3 ; >> 3 +mov r3d, blockd ; dc +shlblockd, 4 ; 16 * dc +leablockd, [blockq+r3+64] ; 17 * dc + 64 +sarblockd, 7 ; >> 7 + +INV_TRANS_INIT +%define linesize3q r2q +lealinesize3q, [linesizeq*3] + +INV_TRANS_PROCESS h +RET + +INIT_MMX mmxext +cglobal vc1_inv_trans_4x8_dc, 3,4,0, dest, linesize, block +movsx r3d, WORD [blockq] +movblockd, r3d ; dc +shlblockd, 4 ; 16 * dc +leablockd, [blockq+r3+4] ; 17 * dc + 4 +sarblockd, 3 ; >> 3 +shlblockd, 2 ; 4 * dc +leablockd, [blockq*3+64] ; 12 * dc + 64 +sarblockd, 7 ; >> 7 + +INV_TRANS_INIT +DECLARE_REG_TMP 2, 3 +%define linesize3q r2q +lealinesize3q, [linesizeq*3] + +INV_TRANS_PROCESS h +lea destq, [destq+linesizeq*4] +INV_TRANS_PROCESS h +RET + +INIT_MMX mmxext +cglobal vc1_inv_trans_8x4_dc, 3,4,0, dest, linesize, block +movsx blockd, WORD [blockq] ; dc +leablockd, [blockq*3+1]; 3 * dc + 1 +sarblockd, 1 ; >> 1 +mov r3d, blockd ; dc +shlblockd, 4 ; 16 * dc +leablockd, [blockq+r3+64] ; 17 * dc + 64 +sarblockd, 7 ; >> 7 + +INV_TRANS_INIT +%define linesize3q r2q +lealinesize3q, [linesizeq*3] + +INV_TRANS_PROCESS a +RET + +INIT_MMX mmxext +cglobal vc1_inv_trans_8x8_dc, 3,3,0, dest, linesize, block +movsx blockd, WORD [blockq] ; dc +leablockd, [blockq*3+1]; 3 * dc + 1 +sarblockd, 1 ; >> 1 +leablockd, [blockq*3+16] ; 3 * dc + 16 +sarblockd, 5 ; >> 5 + +INV_TRANS_INIT +%define linesize3q r2q +lealinesize3q, [linesizeq*3] + +INV_TRANS_PROCESS a +lea destq, [destq+linesizeq*4] +INV_TRANS_PROCESS a +RET diff --git a/libavcodec/x86/vc1dsp_init.c b/libavcodec/x86/vc1dsp_init.c index 1747305..c8943fa 100644 --- a/libavcodec/x86/vc1dsp_init.c +++ b/libavcodec/x86/vc1dsp_init.c @@ -92,6 +92,14 @@ void ff_put_vc1_chroma_mc8_nornd_ssse3(uint8_t *dst, uint8_t *src, int stride, int h, int x, int y); void ff_avg_vc1_chroma_mc8_nornd_ssse3(uint8_t *dst, uint8_t *src, int stride, int h, int x, int y); +void ff_vc1_inv_trans_4x4_dc_mmxext(uint8_t *dest, int linesize, +int16_t *block); +void ff_vc1_inv_trans_4x8_dc_mmxext(uint8_t *dest, int linesize, +int16_t *block); +void ff_vc1_inv_trans_8x4_dc_mmxext(uint8_t *dest, int linesize, +int16_t *block); +void ff_vc1_inv_trans_8x8_dc_mmxext(uint8_t *dest, int linesize, +int16_t *block); av_cold void ff_vc1dsp_init_x86(VC1DSPContext *dsp) @@ -130,6 +138,11 @@ av_cold void ff_vc1dsp_init_x86(VC1DSPContext *dsp) dsp->avg_vc1_mspel_pixels
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/dca: add new decoder based on libdcadec
On Sun, 31 Jan 2016 20:51:23 +0100 Michael Niedermayer wrote: > On Sun, Jan 31, 2016 at 04:04:41PM -0300, James Almer wrote: > > On 1/31/2016 3:57 PM, James Almer wrote: > > > On 1/31/2016 3:51 PM, Michael Niedermayer wrote: > > >> On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote: > > >>> ffmpeg | branch: master | foo86 | Sat Jan 16 > > >>> 11:54:38 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | > > >>> committer: Hendrik Leppkes > > >>> > > >>> avcodec/dca: add new decoder based on libdcadec > > >>> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ae5b2c52501d5009fe712334428138a9b758849b > > > > >>> --- > > >>> > > >> > > >> > > >> this breaks request_channel_layout > > >> > > >> example: > > >> ./ffmpeg -i dts/lotr_5.1_768.dts test.wav > > >> > > >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': > > >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s > > >> Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, 6.1, fltp, 768 kb/s > > >> > > >> > > >> vs. > > >> ./ffmpeg -request_channel_layout 3 -i dts/lotr_5.1_768.dts test-req3.wav > > >> > > >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': > > >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s > > >> Stream #0:0: Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 768 kb/s > > >> > > >> vs. > > >> ./ffmpeg-ref -request_channel_layout 3 -i dts/lotr_5.1_768.dts > > >> test-ref-req3.wav > > >> > > >> Input #0, dts, from '/home/michael/videos/dts/lotr_5.1_768.dts': > > >> Duration: 00:02:05.18, start: 0.00, bitrate: 768 kb/s > > >> Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, stereo, fltp, 768 kb/s > > >> > > >> > > >> previously it resulted in 2 channels now it produces 5.1 when > > >> requesting stereo > > > > > > libdcadec (and thus this new decoder) doesn't force stereo when downmix > > > coefficients are not embedded in the stream, leaving the work to the > > > resampler instead. Try the libdcadec wrapper and it will do the same. > > > > > > It's an intended change in behavior compared to the old dca decoder, so > > > i guess it could documented. > > > > > > > To expand a bit based on what foo86 mentioned in a patch for the wrapper, > > with DTS-ES, DTS-HDMA and other extensions, if you request a stereo downmix > > and coefficients are not available it will not bother applying all the > > extensions to output 7 or 8 channels and instead output the core 5.1 stream > > as is, to simplify the work of the resampler. > > Trying to force a downmix using default coefficients may result in clipping. > > > > He can explain it much better than me, though. > > the output is float, that should not clip > also how is downmixing after the decoder better, it too would apply > some coefficients (either risking an increase in peak volume or > a average loss of volume or inconsistet attenuation > At least you have control over it and can get consistent results with other decoders. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3 v2] avutil: Add GOP timecode frame side data
On Sun, Jan 31, 2016 at 02:36:18PM +, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> doc/APIchanges | 3 +++
> libavutil/frame.c | 1 +
> libavutil/frame.h | 7 ++-
> libavutil/version.h | 4 ++--
> 4 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 15aefb5..45ccf13 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2015-08-28
>
> API changes, most recent first:
>
> +2016-01-31 - xxx - lavu 55.17.100
> + Add AV_FRAME_DATA_GOP_TIMECODE for exporting MPEG1/2 GOP timecodes.
> +
> 2016-01-01 - xxx - lavc 57.21.100 / 57.12.0 - avcodec.h
>Add AVCodecDescriptor.profiles and avcodec_profile_name().
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 9f9c720..c33e462 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -733,6 +733,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
> case AV_FRAME_DATA_SKIP_SAMPLES:return "Skip samples";
> case AV_FRAME_DATA_AUDIO_SERVICE_TYPE: return "Audio service
> type";
> case AV_FRAME_DATA_MASTERING_DISPLAY_METADATA: return "Mastering
> display metadata";
> +case AV_FRAME_DATA_GOP_TIMECODE:return "GOP timecode";
> }
> return NULL;
> }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 406c8b5..e07922d 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -116,7 +116,12 @@ enum AVFrameSideDataType {
> * an AVMasteringDisplayMetadata type and contains information about the
> * mastering display color volume.
> */
> -AV_FRAME_DATA_MASTERING_DISPLAY_METADATA
> +AV_FRAME_DATA_MASTERING_DISPLAY_METADATA,
> +/**
> + * The GOP timecode in 25 bit timecode format. Data format is 64-bit
> integer.
> + * This is set on the first frame of a GOP.
whats the first frame of a gop ?
for example there may be B frames prior to an I frame in display
order
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] mpeg12dec: Export GOP timecodes as side data
On Sun, Jan 31, 2016 at 05:55:55PM +, Derek Buitenhuis wrote: > On 1/31/2016 5:50 PM, Michael Niedermayer wrote: > > this causes segfaults in fate > > Did you try v2? did now, v2 works [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- 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 1/3 v2] avutil: Add GOP timecode frame side data
On 1/31/2016 8:02 PM, Michael Niedermayer wrote: > whats the first frame of a gop ? > for example there may be B frames prior to an I frame in display > order In this case, it's the first frame output after decoding the GOP header. Do you think there is a better way to word it? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3 v2] avutil: Add GOP timecode frame side data
On Sun, Jan 31, 2016 at 08:17:04PM +, Derek Buitenhuis wrote: > On 1/31/2016 8:02 PM, Michael Niedermayer wrote: > > whats the first frame of a gop ? > > for example there may be B frames prior to an I frame in display > > order > > In this case, it's the first frame output after decoding the GOP header. > > Do you think there is a better way to word it? the spec says this: "The time code refers to the first picture after the group of pictures header that has a temporal_reference of zero." > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- 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] avcodec/dcadsp: replace intptr_t with ptrdiff_t
This is more consistent with the rest of the codebase
Signed-off-by: James Almer
---
libavcodec/dcadsp.c | 46 +++---
libavcodec/dcadsp.h | 34 +-
2 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/libavcodec/dcadsp.c b/libavcodec/dcadsp.c
index cee3d60..787d7b8 100644
--- a/libavcodec/dcadsp.c
+++ b/libavcodec/dcadsp.c
@@ -27,8 +27,8 @@ static void decode_hf_c(int32_t **dst,
const int32_t *vq_index,
const int8_t hf_vq[1024][32],
int32_t scale_factors[32][2],
-intptr_t sb_start, intptr_t sb_end,
-intptr_t ofs, intptr_t len)
+ptrdiff_t sb_start, ptrdiff_t sb_end,
+ptrdiff_t ofs, ptrdiff_t len)
{
int i, j;
@@ -42,8 +42,8 @@ static void decode_hf_c(int32_t **dst,
static void decode_joint_c(int32_t **dst, int32_t **src,
const int32_t *scale_factors,
- intptr_t sb_start, intptr_t sb_end,
- intptr_t ofs, intptr_t len)
+ ptrdiff_t sb_start, ptrdiff_t sb_end,
+ ptrdiff_t ofs, ptrdiff_t len)
{
int i, j;
@@ -55,7 +55,7 @@ static void decode_joint_c(int32_t **dst, int32_t **src,
}
static void lfe_fir_float_c(float *pcm_samples, int32_t *lfe_samples,
-const float *filter_coeff, intptr_t npcmblocks,
+const float *filter_coeff, ptrdiff_t npcmblocks,
int dec_select)
{
// Select decimation factor
@@ -85,19 +85,19 @@ static void lfe_fir_float_c(float *pcm_samples, int32_t
*lfe_samples,
}
static void lfe_fir1_float_c(float *pcm_samples, int32_t *lfe_samples,
- const float *filter_coeff, intptr_t npcmblocks)
+ const float *filter_coeff, ptrdiff_t npcmblocks)
{
lfe_fir_float_c(pcm_samples, lfe_samples, filter_coeff, npcmblocks, 0);
}
static void lfe_fir2_float_c(float *pcm_samples, int32_t *lfe_samples,
- const float *filter_coeff, intptr_t npcmblocks)
+ const float *filter_coeff, ptrdiff_t npcmblocks)
{
lfe_fir_float_c(pcm_samples, lfe_samples, filter_coeff, npcmblocks, 1);
}
static void lfe_x96_float_c(float *dst, const float *src,
-float *hist, intptr_t len)
+float *hist, ptrdiff_t len)
{
float prev = *hist;
int i;
@@ -119,7 +119,7 @@ static void sub_qmf32_float_c(SynthFilterContext *synth,
int32_t **subband_samples_lo,
int32_t **subband_samples_hi,
float *hist1, int *offset, float *hist2,
- const float *filter_coeff, intptr_t npcmblocks,
+ const float *filter_coeff, ptrdiff_t npcmblocks,
float scale)
{
LOCAL_ALIGNED(32, float, input, [32]);
@@ -148,7 +148,7 @@ static void sub_qmf64_float_c(SynthFilterContext *synth,
int32_t **subband_samples_lo,
int32_t **subband_samples_hi,
float *hist1, int *offset, float *hist2,
- const float *filter_coeff, intptr_t npcmblocks,
+ const float *filter_coeff, ptrdiff_t npcmblocks,
float scale)
{
LOCAL_ALIGNED(32, float, input, [64]);
@@ -192,7 +192,7 @@ static void sub_qmf64_float_c(SynthFilterContext *synth,
}
static void lfe_fir_fixed_c(int32_t *pcm_samples, int32_t *lfe_samples,
-const int32_t *filter_coeff, intptr_t npcmblocks)
+const int32_t *filter_coeff, ptrdiff_t npcmblocks)
{
// Select decimation factor
int nlfesamples = npcmblocks >> 1;
@@ -219,7 +219,7 @@ static void lfe_fir_fixed_c(int32_t *pcm_samples, int32_t
*lfe_samples,
}
static void lfe_x96_fixed_c(int32_t *dst, const int32_t *src,
-int32_t *hist, intptr_t len)
+int32_t *hist, ptrdiff_t len)
{
int32_t prev = *hist;
int i;
@@ -241,7 +241,7 @@ static void sub_qmf32_fixed_c(SynthFilterContext *synth,
int32_t **subband_samples_lo,
int32_t **subband_samples_hi,
int32_t *hist1, int *offset, int32_t *hist2,
- const int32_t *filter_coeff, intptr_t npcmblocks)
+ const int32_t *filter_coeff, ptrdiff_t
npcmblocks)
{
LOCAL_ALIGNED(32, int32_t, input, [32]);
int i, j;
@@ -265,7 +265,7 @@ static void sub_qmf64_fixed_c(SynthFilterContext *synth,
Re: [FFmpeg-devel] [PATCH] x86: vc1dsp: Convert vc1_inv_trans_*_dc to NASM format
Hi, On Sun, Jan 31, 2016 at 2:48 PM, Timothy Gu wrote: > +; ff_vc1_inv_trans_?x?_dc_mmxext(uint8_t *dest, int linesize, int16_t > *block) +INIT_MMX mmxext > +cglobal vc1_inv_trans_4x4_dc, 3,4,0, dest, linesize, block > [..] > +%define linesize3q r2q > DEFINE_ARGS dest, linesize, linesize3 Rest looks OK. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/dcadsp: replace intptr_t with ptrdiff_t
This is more consistent with the rest of the codebase
Signed-off-by: James Almer
---
libavcodec/dcadsp.c | 46 +++---
libavcodec/dcadsp.h | 34 +-
2 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/libavcodec/dcadsp.c b/libavcodec/dcadsp.c
index cee3d60..787d7b8 100644
--- a/libavcodec/dcadsp.c
+++ b/libavcodec/dcadsp.c
@@ -27,8 +27,8 @@ static void decode_hf_c(int32_t **dst,
const int32_t *vq_index,
const int8_t hf_vq[1024][32],
int32_t scale_factors[32][2],
-intptr_t sb_start, intptr_t sb_end,
-intptr_t ofs, intptr_t len)
+ptrdiff_t sb_start, ptrdiff_t sb_end,
+ptrdiff_t ofs, ptrdiff_t len)
{
int i, j;
@@ -42,8 +42,8 @@ static void decode_hf_c(int32_t **dst,
static void decode_joint_c(int32_t **dst, int32_t **src,
const int32_t *scale_factors,
- intptr_t sb_start, intptr_t sb_end,
- intptr_t ofs, intptr_t len)
+ ptrdiff_t sb_start, ptrdiff_t sb_end,
+ ptrdiff_t ofs, ptrdiff_t len)
{
int i, j;
@@ -55,7 +55,7 @@ static void decode_joint_c(int32_t **dst, int32_t **src,
}
static void lfe_fir_float_c(float *pcm_samples, int32_t *lfe_samples,
-const float *filter_coeff, intptr_t npcmblocks,
+const float *filter_coeff, ptrdiff_t npcmblocks,
int dec_select)
{
// Select decimation factor
@@ -85,19 +85,19 @@ static void lfe_fir_float_c(float *pcm_samples, int32_t
*lfe_samples,
}
static void lfe_fir1_float_c(float *pcm_samples, int32_t *lfe_samples,
- const float *filter_coeff, intptr_t npcmblocks)
+ const float *filter_coeff, ptrdiff_t npcmblocks)
{
lfe_fir_float_c(pcm_samples, lfe_samples, filter_coeff, npcmblocks, 0);
}
static void lfe_fir2_float_c(float *pcm_samples, int32_t *lfe_samples,
- const float *filter_coeff, intptr_t npcmblocks)
+ const float *filter_coeff, ptrdiff_t npcmblocks)
{
lfe_fir_float_c(pcm_samples, lfe_samples, filter_coeff, npcmblocks, 1);
}
static void lfe_x96_float_c(float *dst, const float *src,
-float *hist, intptr_t len)
+float *hist, ptrdiff_t len)
{
float prev = *hist;
int i;
@@ -119,7 +119,7 @@ static void sub_qmf32_float_c(SynthFilterContext *synth,
int32_t **subband_samples_lo,
int32_t **subband_samples_hi,
float *hist1, int *offset, float *hist2,
- const float *filter_coeff, intptr_t npcmblocks,
+ const float *filter_coeff, ptrdiff_t npcmblocks,
float scale)
{
LOCAL_ALIGNED(32, float, input, [32]);
@@ -148,7 +148,7 @@ static void sub_qmf64_float_c(SynthFilterContext *synth,
int32_t **subband_samples_lo,
int32_t **subband_samples_hi,
float *hist1, int *offset, float *hist2,
- const float *filter_coeff, intptr_t npcmblocks,
+ const float *filter_coeff, ptrdiff_t npcmblocks,
float scale)
{
LOCAL_ALIGNED(32, float, input, [64]);
@@ -192,7 +192,7 @@ static void sub_qmf64_float_c(SynthFilterContext *synth,
}
static void lfe_fir_fixed_c(int32_t *pcm_samples, int32_t *lfe_samples,
-const int32_t *filter_coeff, intptr_t npcmblocks)
+const int32_t *filter_coeff, ptrdiff_t npcmblocks)
{
// Select decimation factor
int nlfesamples = npcmblocks >> 1;
@@ -219,7 +219,7 @@ static void lfe_fir_fixed_c(int32_t *pcm_samples, int32_t
*lfe_samples,
}
static void lfe_x96_fixed_c(int32_t *dst, const int32_t *src,
-int32_t *hist, intptr_t len)
+int32_t *hist, ptrdiff_t len)
{
int32_t prev = *hist;
int i;
@@ -241,7 +241,7 @@ static void sub_qmf32_fixed_c(SynthFilterContext *synth,
int32_t **subband_samples_lo,
int32_t **subband_samples_hi,
int32_t *hist1, int *offset, int32_t *hist2,
- const int32_t *filter_coeff, intptr_t npcmblocks)
+ const int32_t *filter_coeff, ptrdiff_t
npcmblocks)
{
LOCAL_ALIGNED(32, int32_t, input, [32]);
int i, j;
@@ -265,7 +265,7 @@ static void sub_qmf64_fixed_c(SynthFilterContext *synth,
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 03:07 PM, Michael Niedermayer wrote:
On Sun, Jan 31, 2016 at 01:27:22PM +0100, Mats Peterson wrote:
I don't really appreciate that you're doing things behind my back,
Michael. There's nothing mentioned on the ffmpeg-devel mailing lis
indeed, i should have clearly stated that i applied the pal8
patches with the plan to use pal8 only when neccessary.
I had asked you to implement exactly that but it seemed you didnt
know how to do that cleanly and simply so i thought "no problem,
i know how to do that, ill do it"
i had not expected this to be controversal
Even if you stubbornly decide to keep your patch, it is incorrect
anyway. If a 1 bpp AVI contains a palette, black & white or not, pal8
will be used regardless. Look at the snippet below. Furthermore, the
palette side data packet will be retrieved twice, both here and at the
end of the raw_decode() function.
Don't you agree that it just creates a lot of unnecessary code noise to
have to do this "switching" uniformly for 1 bpp in all file formats? I
suggest you apply my patch, and we will get rid of stuff like this.
if (avctx->bits_per_coded_sample == 1 &&
avctx->frame_number == 0 &&
context->palette &&
AV_RB64(context->palette->data) == 0x
) {
const uint8_t *pal = av_packet_get_side_data(avpkt,
AV_PKT_DATA_PALETTE,
if (!pal) {
avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
} else
avctx->pix_fmt = AV_PIX_FMT_PAL8;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86: vc1dsp: Convert vc1_inv_trans_*_dc to NASM format
On 1/31/2016 4:48 PM, Timothy Gu wrote: > --- > libavcodec/x86/vc1dsp.asm| 104 ++ > libavcodec/x86/vc1dsp_init.c | 13 +++ > libavcodec/x86/vc1dsp_mmx.c | 207 > --- > 3 files changed, 117 insertions(+), 207 deletions(-) > > diff --git a/libavcodec/x86/vc1dsp.asm b/libavcodec/x86/vc1dsp.asm > index 6415a83..f922927 100644 > --- a/libavcodec/x86/vc1dsp.asm > +++ b/libavcodec/x86/vc1dsp.asm > @@ -395,3 +395,107 @@ cglobal vc1_put_ver_16b_shift2, 4,7,0, dst, src, stride > jnz .loop > REP_RET > %endif ; HAVE_MMX_INLINE > + > +%macro INV_TRANS_INIT 0 > +movsxdifnidn linesizeq, linesized Maybe change the prototype so linesize is ptrdiff_t? > +movd m0, blockd > +SPLATW m0, m0 > +pxor m1, m1 > +psubw m1, m0 > +packuswb m0, m0 > +packuswb m1, m1 > +%endmacro > + > +%macro INV_TRANS_PROCESS 1 > +mov%1 m2, [destq+linesizeq*0] > +mov%1 m3, [destq+linesizeq*1] > +mov%1 m4, [destq+linesizeq*2] > +mov%1 m5, [destq+linesize3q] > +paddusbm2, m0 > +paddusbm3, m0 > +paddusbm4, m0 > +paddusbm5, m0 > +psubusbm2, m1 > +psubusbm3, m1 > +psubusbm4, m1 > +psubusbm5, m1 > +mov%1 [linesizeq*0+destq], m2 > +mov%1 [linesizeq*1+destq], m3 > +mov%1 [linesizeq*2+destq], m4 > +mov%1 [linesize3q +destq], m5 > +%endmacro > + > +; ff_vc1_inv_trans_?x?_dc_mmxext(uint8_t *dest, int linesize, int16_t *block) > +INIT_MMX mmxext > +cglobal vc1_inv_trans_4x4_dc, 3,4,0, dest, linesize, block > +movsx r3d, WORD [blockq] Can this value be negative? Because you're using it as an argument for lea using native size after movsx sign extended the value to 32 bits, which means that on x86_64 the upper bits of the register will be zeroed. If it can you'll have to use blockq/r3q everywhere, and if it can't then use movzx and shr. > +movblockd, r3d ; dc > +shlblockd, 4 ; 16 * dc > +leablockd, [blockq+r3+4] ; 17 * dc + 4 > +sarblockd, 3 ; >> 3 > +mov r3d, blockd ; dc > +shlblockd, 4 ; 16 * dc > +leablockd, [blockq+r3+64] ; 17 * dc + 64 > +sarblockd, 7 ; >> 7 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3 v2] mpeg12dec: Export GOP timecodes as side data
On 1/31/2016 9:18 PM, Michael Niedermayer wrote: > is it intended to set this also when ret < 0 No, you're right, it should not be. Amended locally. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3 v2] mpeg12dec: Export GOP timecodes as side data
On Sun, Jan 31, 2016 at 02:36:19PM +, Derek Buitenhuis wrote:
> The codec context field was rightly deprecated, and the data
> may change per-frame.
>
> Signed-off-by: Derek Buitenhuis
> ---
> I really don't liek dumping part of this at the end of mpeg_decode_frame,
> but I have no idea where else to put it, so that the decoder delay and
> reordering do not affect it.
>
> Anyone who cares to help, please do!
> ---
> libavcodec/mpeg12dec.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index 23c77cd..b40a182 100644
> --- a/libavcodec/mpeg12dec.c
> +++ b/libavcodec/mpeg12dec.c
> @@ -2423,7 +2423,13 @@ static void mpeg_decode_gop(AVCodecContext *avctx,
>
> init_get_bits(&s->gb, buf, buf_size * 8);
>
> -tc = avctx->timecode_frame_start = get_bits(&s->gb, 25);
> +tc = s-> timecode_frame_start = get_bits(&s->gb, 25);
> +
> +#if FF_API_PRIVATE_OPT
> +FF_DISABLE_DEPRECATION_WARNINGS
> +avctx->timecode_frame_start = tc;
> +FF_ENABLE_DEPRECATION_WARNINGS
> +#endif
>
> s->closed_gop = get_bits1(&s->gb);
> /* broken_link indicate that after editing the
> @@ -2831,9 +2837,21 @@ static int mpeg_decode_frame(AVCodecContext *avctx,
> void *data,
> }
>
> ret = decode_chunks(avctx, picture, got_output, buf, buf_size);
> -if (ret<0 || *got_output)
> +if (ret<0 || *got_output) {
> s2->current_picture_ptr = NULL;
>
> +if (s2->timecode_frame_start != -1) {
> +AVFrameSideData *tcside = av_frame_new_side_data(picture,
> +
> AV_FRAME_DATA_GOP_TIMECODE,
> +
> sizeof(int64_t));
> +if (!tcside)
> +return AVERROR(ENOMEM);
> +memcpy(tcside->data, &s2->timecode_frame_start, sizeof(int64_t));
is it intended to set this also when ret < 0 ?
patch LGTM otherwise
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] msvc: Fix libx264 linking
On Thu, Jan 28, 2016 at 5:18 PM, Henrik Gramner wrote: > --- > configure | 1 + > 1 file changed, 1 insertion(+) No complaints and the same patch was OK:ed by Derek on libav-devel, so pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_yadif: make use of ctx pointer
Hi,
patch attached.
From a71c17e7a52ccc5ff4e7cf379cb87389bd60eff1 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 31 Jan 2016 22:23:07 +0100
Subject: [PATCH] avfilter/vf_yadif: make use of ctx pointer
Signed-off-by: Paul B Mahol
---
libavfilter/vf_yadif.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index d9668d0..8e6522c 100644
--- a/libavfilter/vf_yadif.c
+++ b/libavfilter/vf_yadif.c
@@ -389,7 +389,7 @@ static int request_frame(AVFilterLink *link)
if (yadif->eof)
return AVERROR_EOF;
-ret = ff_request_frame(link->src->inputs[0]);
+ret = ff_request_frame(ctx->inputs[0]);
if (ret == AVERROR_EOF && yadif->cur) {
AVFrame *next = av_frame_clone(yadif->next);
@@ -399,7 +399,7 @@ static int request_frame(AVFilterLink *link)
next->pts = yadif->next->pts * 2 - yadif->cur->pts;
-filter_frame(link->src->inputs[0], next);
+filter_frame(ctx->inputs[0], next);
yadif->eof = 1;
} else if (ret < 0) {
return ret;
@@ -469,15 +469,15 @@ static int query_formats(AVFilterContext *ctx)
static int config_props(AVFilterLink *link)
{
AVFilterContext *ctx = link->src;
-YADIFContext *s = link->src->priv;
+YADIFContext *s = ctx->priv;
-link->time_base.num = link->src->inputs[0]->time_base.num;
-link->time_base.den = link->src->inputs[0]->time_base.den * 2;
-link->w = link->src->inputs[0]->w;
-link->h = link->src->inputs[0]->h;
+link->time_base.num = ctx->inputs[0]->time_base.num;
+link->time_base.den = ctx->inputs[0]->time_base.den * 2;
+link->w = ctx->inputs[0]->w;
+link->h = ctx->inputs[0]->h;
if(s->mode & 1)
-link->frame_rate = av_mul_q(link->src->inputs[0]->frame_rate,
+link->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
(AVRational){2, 1});
if (link->w < 3 || link->h < 3) {
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 10:08 PM, Mats Peterson wrote: Even if you stubbornly decide to keep your patch, it is incorrect anyway. If a 1 bpp AVI contains a palette, black & white or not, pal8 will be used regardless. Look at the snippet below. Furthermore, the palette side data packet will be retrieved twice, both here and at the end of the raw_decode() function. Don't you agree that it just creates a lot of unnecessary code noise to have to do this "switching" uniformly for 1 bpp in all file formats? I suggest you apply my patch, and we will get rid of stuff like this. You'll have to look at the palette in the side data to decide if it's "mono" or not. And for qtrle one would have to add code for the special case of handling 1 bpp data. A lot of extra code for nothing. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86: vc1dsp: Convert vc1_inv_trans_*_dc to NASM format
On 1/31/2016 6:18 PM, James Almer wrote: > On 1/31/2016 4:48 PM, Timothy Gu wrote: >> +; ff_vc1_inv_trans_?x?_dc_mmxext(uint8_t *dest, int linesize, int16_t >> *block) >> +INIT_MMX mmxext >> +cglobal vc1_inv_trans_4x4_dc, 3,4,0, dest, linesize, block >> +movsx r3d, WORD [blockq] > > Can this value be negative? Because you're using it as an argument > for lea using native size after movsx sign extended the value to 32 > bits, which means that on x86_64 the upper bits of the register will > be zeroed. > > If it can you'll have to use blockq/r3q everywhere, and if it can't > then use movzx and shr. Or not... Seems to work as is and using movzx breaks it. > >> +movblockd, r3d ; dc >> +shlblockd, 4 ; 16 * dc >> +leablockd, [blockq+r3+4] ; 17 * dc + 4 >> +sarblockd, 3 ; >> 3 >> +mov r3d, blockd ; dc >> +shlblockd, 4 ; 16 * dc >> +leablockd, [blockq+r3+64] ; 17 * dc + 64 >> +sarblockd, 7 ; >> 7 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 10:08:41PM +0100, Mats Peterson wrote: > On 01/31/2016 03:07 PM, Michael Niedermayer wrote: > >On Sun, Jan 31, 2016 at 01:27:22PM +0100, Mats Peterson wrote: > >>I don't really appreciate that you're doing things behind my back, > >>Michael. There's nothing mentioned on the ffmpeg-devel mailing lis > > > >indeed, i should have clearly stated that i applied the pal8 > >patches with the plan to use pal8 only when neccessary. > >I had asked you to implement exactly that but it seemed you didnt > >know how to do that cleanly and simply so i thought "no problem, > >i know how to do that, ill do it" > >i had not expected this to be controversal > > > > > > Even if you stubbornly decide to keep your patch, it is incorrect > anyway. If a 1 bpp AVI contains a palette, black & white or not, If a AVI contains a palette one might argue its a paletted avi either way i dont know, i dont have such a file it would be needed to have real world files in that category to know if treating them as pal8 is better or not [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- 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] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 10:31 PM, Michael Niedermayer wrote: If a AVI contains a palette one might argue its a paletted avi either way i dont know, i dont have such a file it would be needed to have real world files in that category to know if treating them as pal8 is better or not So, will you apply my patch? Or are you willing to change to this funny logic for every file format that uses 1 bpp? As I said, both 2 and 4 bpp uses pal8 internally, and nobody seems to complain about that. I'm beginning to get rather tired of this. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 10:33 PM, Mats Peterson wrote: On 01/31/2016 10:31 PM, Michael Niedermayer wrote: If a AVI contains a palette one might argue its a paletted avi either way i dont know, i dont have such a file it would be needed to have real world files in that category to know if treating them as pal8 is better or not An 1- 2- 4- and 8-bit AVI is palettized no matter if it contains a palette or not. Of course it has to contain palette in order to display it correctly, but in the case of 1 bpp I have set a default black & white palette in raw_init_decoder() to avoid sudden surprises when switching from using monow. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 10:49 PM, Michael Niedermayer wrote: So, will you apply my patch? Or are you willing to change to this funny logic for every file format that uses 1 bpp? As I said, both 2 and 4 bpp uses pal8 internally, and nobody seems to complain about that. I'm beginning to get rather tired of this. this decission should be made by other developers, who where not involved in this disagreement, that should result in a outcome that represents the preferrances of the community better. wm4 is already on my side, as far as I understand. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 10:33:33PM +0100, Mats Peterson wrote: > On 01/31/2016 10:31 PM, Michael Niedermayer wrote: > > > >If a AVI contains a palette one might argue its a paletted avi > >either way i dont know, i dont have such a file > >it would be needed to have real world files in that category > >to know if treating them as pal8 is better or not > > > > > > So, will you apply my patch? Or are you willing to change to this > funny logic for every file format that uses 1 bpp? As I said, both 2 > and 4 bpp uses pal8 internally, and nobody seems to complain about > that. I'm beginning to get rather tired of this. this decission should be made by other developers, who where not involved in this disagreement, that should result in a outcome that represents the preferrances of the community better. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 10:49 PM, Mats Peterson wrote: this decission should be made by other developers, who where not involved in this disagreement, that should result in a outcome that represents the preferrances of the community better. wm4 is already on my side, as far as I understand. Just because we have monow and monob pixel formats, it doesn't mean they should be used wherever 1 bpp data is involved. And once again, the semantics according to Microsoft are that 1 bpp AVI is NEVER monochrome, it is ALWAYS palettized, regardless of the number of colors, or whether they are black & white or not. And implementing "mono switches" for 1 bpp depth for every file format involves writing a lot of superfluous code just for this, and in the case of qtrle, creating a whole new loop for the 1 bpp case. Overkill. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86: vc1dsp: Convert vc1_inv_trans_*_dc to NASM format
On Sun, Jan 31, 2016 at 10:18 PM, James Almer wrote: > On 1/31/2016 4:48 PM, Timothy Gu wrote: >> +; ff_vc1_inv_trans_?x?_dc_mmxext(uint8_t *dest, int linesize, int16_t >> *block) >> +INIT_MMX mmxext >> +cglobal vc1_inv_trans_4x4_dc, 3,4,0, dest, linesize, block >> +movsx r3d, WORD [blockq] > > Can this value be negative? Because you're using it as an argument > for lea using native size after movsx sign extended the value to 32 > bits, which means that on x86_64 the upper bits of the register will > be zeroed. > > If it can you'll have to use blockq/r3q everywhere, and if it can't > then use movzx and shr. The destination of those lea instructions are 32-bit, so the upper half is discarded anyway. Fun fact: you _can_ use the 32-bit register form inside the lea brackets, but doing so would just require a REX prefix without affecting the output, so you don't really want to do that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On Sun, Jan 31, 2016 at 10:53:35PM +0100, Mats Peterson wrote: > On 01/31/2016 10:49 PM, Mats Peterson wrote: > >>this decission should be made by other developers, who where not > >>involved in this disagreement, that should result in a outcome that > >>represents the preferrances of the community better. > >> > > > >wm4 is already on my side, as far as I understand. > > > > Just because we have monow and monob pixel formats, it doesn't mean > they should be used wherever 1 bpp data is involved. And once again, > the semantics according to Microsoft are that 1 bpp AVI is NEVER > monochrome, it is ALWAYS palettized, regardless of the number of > colors, or whether they are black & white or not. And implementing > "mono switches" for 1 bpp depth for every file format involves > writing a lot of superfluous code just for this, and in the case of > qtrle, creating a whole new loop for the 1 bpp case. Overkill. i did not suggest that. my suggestion is just about the raw video decoder, that is if a AVPacket contains monochrome 1bpp black/white data without a palette that this is passed through and not converted to pal8 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill hundred thousands of innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. 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/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 10:53 PM, Mats Peterson wrote: Just because we have monow and monob pixel formats, it doesn't mean they should be used wherever 1 bpp data is involved. And once again, the semantics according to Microsoft are that 1 bpp AVI is NEVER monochrome, it is ALWAYS palettized, regardless of the number of colors, or whether they are black & white or not. And implementing "mono switches" for 1 bpp depth for every file format involves writing a lot of superfluous code just for this, and in the case of qtrle, creating a whole new loop for the 1 bpp case. Overkill. Mats You don't seem to realize the simplicity of having a uniform way of converting 1, 2, 4, and 8 bpp palettized video data. Why should using monow even be considered? Less space? Not a valid argument nowadays. There are no reasons to use it really, except for the case of TIFF with its bilevel mode, which only uses black & white. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 11:08 PM, Michael Niedermayer wrote: On Sun, Jan 31, 2016 at 10:53:35PM +0100, Mats Peterson wrote: On 01/31/2016 10:49 PM, Mats Peterson wrote: this decission should be made by other developers, who where not involved in this disagreement, that should result in a outcome that represents the preferrances of the community better. wm4 is already on my side, as far as I understand. Just because we have monow and monob pixel formats, it doesn't mean they should be used wherever 1 bpp data is involved. And once again, the semantics according to Microsoft are that 1 bpp AVI is NEVER monochrome, it is ALWAYS palettized, regardless of the number of colors, or whether they are black & white or not. And implementing "mono switches" for 1 bpp depth for every file format involves writing a lot of superfluous code just for this, and in the case of qtrle, creating a whole new loop for the 1 bpp case. Overkill. i did not suggest that. my suggestion is just about the raw video decoder, that is if a AVPacket contains monochrome 1bpp black/white data without a palette that this is passed through and not converted to pal8 I thought you did, since you once said "this can be done for qtrle as well". And using monow for the single case of a 1 bpp AVI without a palette is a bit far fetched to me, since AVIs are never monochrome. That's why i initialize a default palette in raw_init_decoder() once again. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
On 01/31/2016 11:08 PM, Michael Niedermayer wrote: my suggestion is just about the raw video decoder, that is if a AVPacket contains monochrome 1bpp black/white data without a palette that this is passed through and not converted to pal8 * If you want to pass it through, just use "-c:v copy". Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
