Re: [FFmpeg-devel] [PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"
Le septidi 7 floréal, an CCXXIV, Andrey Utkin a écrit :
> Your patch breaks a particular usecase, however my patch handles it well.
> [h264 @ 0x1aa1000] no frame!
> Last message repeated 8 times
> [mpegts @ 0x1aa4180] H.264 bitstream malformed, no startcode found, use the
> video bitstream filter 'h264_mp4toannexb' to fix it ('-bsf:v
> h264_mp4toannexb' option with ffmpeg)
> av_interleaved_write_frame(): Invalid data found when processing input
I can not reproduce this with my patches. Or more precisely, I can reproduce
it with only the second patch applied. Are you sure you tested with both
patches applied?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: build fix for P5600 with mips code restructuring
On Tue, Apr 26, 2016 at 12:17:15PM +0530, shivraj.pa...@imgtec.com wrote: > From: Shivraj Patil > > Note:- backporting commit 15ef98afd10b3696d29fb6d19606ba03a9dd47ad from head > > Signed-off-by: Shivraj Patil > --- > configure | 252 > ++ > 1 file changed, 120 insertions(+), 132 deletions(-) patches applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope 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/3] configure: Do not create/install versioned DLLs on OS/2.
Dave Yeo wrote: > On 04/24/16 05:53 PM, Michael Niedermayer wrote: >> On Sun, Apr 24, 2016 at 11:55:06AM -0700, Dave Yeo wrote: >>> On 04/23/16 12:53 PM, Michael Niedermayer wrote: On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote: >> On 04/20/16 03:48 PM, Dmitriy Kuminov wrote: I do care about consistency, collaboration and prevention of artificial entropy growth. >> >> One option is to make ln_s a configure option, something like the >> attached, which is a work in progress as out of tree builds are >> broken when using cp -p. Almost seems a failure in the code that >> decides whether symlinks work. >> Dave >> this seems not working ./configure ./configure: 4790: ./configure: /tmp/dest_sJUY97zC: Permission denied rm: cannot remove `/tmp/name_cM7p9K1e': No such file or directory >>> >>> It's the correct output (I get similar even before this patch) when >>> $ln_s="cp -p" as it tries to touch a file in a symlinked directory >>> and correctly fails. >> >> there are no error messages before here, also the ln_s and ln_s_default >> are not connected i think >> set_default or similar is missing > > OK, thanks, that's what I missed. > >> >> >>> Did you run make && make install after configuring? >>> Here's the version I'll post later in a new thread, please test. >> >> this seems to apply only "in reverse" > > Strange, wonder how I did that. > New patch which I think along with Dmitriys could be applied if KOMH has > no objections Thanks, Dave. However, ln_s is always set to 'cp -f' on OS/2. Please remove ln_s overriding codes as well. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 03/12] lavc/videotoolboxenc: Require hardware encoding
Richard Kern gmail.com> writes:
> >> +#if !TARGET_OS_IPHONE
> >> +{ "allow_sw", "Allow software encoding", OFFSET(allow_sw),
> >
> > I have no strong opinion, but shouldn't the option
> > always exist (but only work in some cases)?
> iOS doesn’t support software encoding, and the dictionary keys to
> allow it aren’t part of the headers.
I understand this but I suspect the FFmpeg option "allow_sw"
should also exist on ios.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 01/12] lavc/videotoolboxenc: Use shared pixel buffer pool
Richard Kern gmail.com> writes:
> >> static const enum AVPixelFormat pix_fmts[] = {
> >> AV_PIX_FMT_NV12,
> >> -#if !TARGET_OS_IPHONE
> >> AV_PIX_FMT_YUV420P,
> >> -#endif
> >> AV_PIX_FMT_NONE
> >
> > Sorry: How is this related?
> Using a shared pixel buffer pool also sets up an internal
> color converter when needed.
And is this generally wanted?
(I assume so.)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avutil/log: added test case for av_log_format_line2
On Tue, Apr 26, 2016 at 08:31:06AM +0200, Andreas Weis wrote: > From: Andreas Weis > > --- > libavutil/log.c | 30 ++ > 1 file changed, 30 insertions(+) > > diff --git a/libavutil/log.c b/libavutil/log.c > index 0efba7a..6d192b6 100644 > --- a/libavutil/log.c > +++ b/libavutil/log.c > @@ -444,6 +444,17 @@ void avpriv_report_missing_feature(void *avc, const char > *msg, ...) > // LCOV_EXCL_START > #include > > +int call_log_format_line2(const char *fmt, char *buffer, int buffer_size, > ...) this should be static, otherwise it can break build as it has no prototype with some compiler options (like the ones we use) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Bug fixed: wrong ticks_per_frame. For H.264 stream ticks_per_frame should be 2
Hello All, Monday, April 25, 2016, 6:50:18 PM, you wrote: HL> On Mon, Apr 25, 2016 at 5:44 PM, Ivan Uskov wrote: >> Hello Derek, >> >> Monday, April 25, 2016, 4:50:28 PM, you wrote: >> >> DB> On 4/25/2016 2:14 PM, Ivan Uskov wrote: The attached patch does fixes the issue of frames duplication when elementary h.264 stream decodes by qsvdec. >> >> DB> Could you perhaps elaborate in the commit message, and a code comment, on >> DB> why it must be 2? Where does that value come from, etc. >> I do not see a necessity for additional comments because >> AVCodecContext::ticks_per_frame is public API and already enough documented: >> https://ffmpeg.org/doxygen/2.8/structAVCodecContext.html#a5c62b9c1528a272923ea2a4b86dea31a >> HL> Its not about what the field does, but why this is needed here. So HL> please explain why its set here, and only for this case. A have added brief comment to patch and to code, please review the attached patch. -- Best regards, Ivanmailto:ivan.us...@nablet.com 0001-Bug-fixed-wrong-ticks_per_frame.-For-H.264-stream-ti.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"
On Tue, Apr 26, 2016 at 10:44:06AM +0200, Nicolas George wrote: > I can not reproduce this with my patches. Or more precisely, I can reproduce > it with only the second patch applied. Are you sure you tested with both > patches applied? Sorry, I didn't notice that both of your patches must be applied. With both applied, it works. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.
Le septidi 7 floréal, an CCXXIV, Derek Buitenhuis a écrit : > I'm not opposed to it, as long as the API conversion is done in a reasonable > amount of time. Ok, both patches pushed after Andrey confirmed they work. And I start lookint more closely at the new API. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-26 11:51:28 +, KO Myung-Hun said: However, ln_s is always set to 'cp -f' on OS/2. Please remove ln_s overriding codes as well. Yes, but my initial patch already removes this override (check the first hunk) so just applying it + Dave's should get it all done. -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 01/12] lavc/videotoolboxenc: Use shared pixel buffer pool
> On Apr 26, 2016, at 8:14 AM, Carl Eugen Hoyos wrote:
>
> Richard Kern gmail.com> writes:
>
static const enum AVPixelFormat pix_fmts[] = {
AV_PIX_FMT_NV12,
-#if !TARGET_OS_IPHONE
AV_PIX_FMT_YUV420P,
-#endif
AV_PIX_FMT_NONE
>>>
>>> Sorry: How is this related?
>> Using a shared pixel buffer pool also sets up an internal
>> color converter when needed.
>
> And is this generally wanted?
> (I assume so.)
The pool? Probably. Using it reduces memcpy calls in the media server process.
I dug into this a little - yuv420p is supported natively (at least on some
devices), so it shouldn’t have been excluded in the first place.
>
> Carl Eugen
>
> ___
> 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] Bug fixed: wrong ticks_per_frame. For H.264 stream ticks_per_frame should be 2
On Tue, 26 Apr 2016 17:21:10 +0300
Ivan Uskov wrote:
> From 75d3a992e3c11edd39607cdc0109928db7905638 Mon Sep 17 00:00:00 2001
> From: Ivan Uskov
> Date: Tue, 26 Apr 2016 10:13:04 -0400
> Subject: [PATCH] Bug fixed: wrong ticks_per_frame. For H.264 stream
> ticks_per_frame should be 2
>
> ---
> libavcodec/qsvdec_h2645.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
> index a396f31..fda827c 100644
> --- a/libavcodec/qsvdec_h2645.c
> +++ b/libavcodec/qsvdec_h2645.c
> @@ -82,9 +82,11 @@ static av_cold int qsv_decode_init(AVCodecContext *avctx)
> }
> }
>
> -if (avctx->codec_id == AV_CODEC_ID_H264)
> +if (avctx->codec_id == AV_CODEC_ID_H264) {
> s->bsf = av_bitstream_filter_init("h264_mp4toannexb");
> -else
> +//regarding ticks_per_frame description, should be 2 for h.264:
> +avctx->ticks_per_frame = 2;
> +} else
I can see that this code is run only for h264, and I can see that you
set the field to 2. The added comment adds no new information and is
useless.
> s->bsf = av_bitstream_filter_init("hevc_mp4toannexb");
> if (!s->bsf) {
> ret = AVERROR(ENOMEM);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Bug fixed: wrong ticks_per_frame. For H.264 stream ticks_per_frame should be 2
On 4/26/2016 4:45 PM, wm4 wrote: > I can see that this code is run only for h264, and I can see that you > set the field to 2. The added comment adds no new information and is > useless. The ticks_per_frame docu literally says "should be 2 for h.264" or something. I only thought it should be in the commit message instead of something akin to "fix bug". - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vf_colorspace: add floyd-steinberg dithering option to full conversion.
---
doc/filters.texi | 13
libavfilter/colorspacedsp.c | 9 +++
libavfilter/colorspacedsp.h | 6 ++
libavfilter/colorspacedsp_template.c | 128 +++
libavfilter/vf_colorspace.c | 53 ++-
5 files changed, 207 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index b17b115..98a002b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5104,6 +5104,19 @@ YUV 4:4:4 planar 12-bits
Do a fast conversion, which skips gamma/primary correction. This will take
significantly less CPU, but will be mathematically incorrect. To get output
compatible with that produced by the colormatrix filter, use fast=1.
+
+@item dither
+Specify dithering mode.
+
+The accepted values are:
+@table @samp
+@item none
+No dithering
+
+@item fsb
+Floyd-Steinberg dithering
+@end table
+
@end table
The filter converts the transfer characteristics, color space and color
diff --git a/libavfilter/colorspacedsp.c b/libavfilter/colorspacedsp.c
index d4c43c3..d0dcd51 100644
--- a/libavfilter/colorspacedsp.c
+++ b/libavfilter/colorspacedsp.c
@@ -114,6 +114,15 @@ void ff_colorspacedsp_init(ColorSpaceDSPContext *dsp)
init_rgb2yuv_fn(1, 10);
init_rgb2yuv_fn(2, 12);
+#define init_rgb2yuv_fsb_fn(idx, bit) \
+dsp->rgb2yuv_fsb[idx][0] = rgb2yuv_fsb_444p##bit##_c; \
+dsp->rgb2yuv_fsb[idx][1] = rgb2yuv_fsb_422p##bit##_c; \
+dsp->rgb2yuv_fsb[idx][2] = rgb2yuv_fsb_420p##bit##_c
+
+init_rgb2yuv_fsb_fn(0, 8);
+init_rgb2yuv_fsb_fn(1, 10);
+init_rgb2yuv_fsb_fn(2, 12);
+
#define init_yuv2yuv_fn(idx1, idx2, bit1, bit2) \
dsp->yuv2yuv[idx1][idx2][0] = yuv2yuv_444p##bit1##to##bit2##_c; \
dsp->yuv2yuv[idx1][idx2][1] = yuv2yuv_422p##bit1##to##bit2##_c; \
diff --git a/libavfilter/colorspacedsp.h b/libavfilter/colorspacedsp.h
index 4e70c6c..2ca7b19 100644
--- a/libavfilter/colorspacedsp.h
+++ b/libavfilter/colorspacedsp.h
@@ -32,6 +32,11 @@ typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t
yuv_stride[3],
int16_t *rgb[3], ptrdiff_t rgb_stride,
int w, int h, const int16_t rgb2yuv_coeffs[3][3][8],
const int16_t yuv_offset[8]);
+typedef void (*rgb2yuv_fsb_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
+ int16_t *rgb[3], ptrdiff_t rgb_stride,
+ int w, int h, const int16_t
rgb2yuv_coeffs[3][3][8],
+ const int16_t yuv_offset[8],
+ int *rnd[3][2]);
typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t yuv_out_stride[3],
uint8_t *yuv_in[3], ptrdiff_t yuv_in_stride[3],
int w, int h, const int16_t yuv2yuv_coeffs[3][3][8],
@@ -40,6 +45,7 @@ typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t
yuv_out_stride[3],
typedef struct ColorSpaceDSPContext {
yuv2rgb_fn yuv2rgb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0: 444, 1:
422, 2: 420 */];
rgb2yuv_fn rgb2yuv[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0: 444, 1:
422, 2: 420 */];
+rgb2yuv_fsb_fn rgb2yuv_fsb[3 /* 0: 8bit, 1: 10bit, 2: 12bit */][3 /* 0:
444, 1: 422, 2: 420 */];
yuv2yuv_fn yuv2yuv[3 /* in_depth */][3 /* out_depth */][3 /* 0: 444, 1:
422, 2: 420 */];
void (*multiply3x3)(int16_t *data[3], ptrdiff_t stride,
diff --git a/libavfilter/colorspacedsp_template.c
b/libavfilter/colorspacedsp_template.c
index f225391..db4a8d2 100644
--- a/libavfilter/colorspacedsp_template.c
+++ b/libavfilter/colorspacedsp_template.c
@@ -199,6 +199,134 @@ static void fn(rgb2yuv)(uint8_t *_yuv[3], ptrdiff_t
yuv_stride[3],
}
}
+/* floyd-steinberg dithering - for any mid-top pixel A in a 3x2 block of
pixels:
+ *1 A 2
+ *3 4 5
+ * the rounding error is distributed over the neighbouring pixels:
+ *2: 7/16th, 3: 3/16th, 4: 5/16th and 5: 1/16th
+ */
+static void fn(rgb2yuv_fsb)(uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
+int16_t *rgb[3], ptrdiff_t s,
+int w, int h, const int16_t
rgb2yuv_coeffs[3][3][8],
+const int16_t yuv_offset[8],
+int *rnd_scratch[3][2])
+{
+pixel **yuv = (pixel **) _yuv;
+pixel *yuv0 = yuv[0], *yuv1 = yuv[1], *yuv2 = yuv[2];
+const int16_t *rgb0 = rgb[0], *rgb1 = rgb[1], *rgb2 = rgb[2];
+int y, x;
+const int sh = 29 - BIT_DEPTH;
+const int rnd = 1 << (sh - 1);
+int cry = rgb2yuv_coeffs[0][0][0];
+int cgy = rgb2yuv_coeffs[0][1][0];
+int cby = rgb2yuv_coeffs[0][2][0];
+int cru = rgb2yuv_coeffs[1][0][0];
+int cgu = rgb2yuv_coeffs[1][1][0];
+int cburv = rgb2yuv_coeffs[1][2][0];
+int cgv = rgb2yuv_coeffs[2][1][0];
+int cbv = rgb2yuv_coeffs[2][2][0];
+ptrdiff_t s0 = yuv_stride[0] / sizeof(pixel);
+const int uv_offset = 128 << (BIT_DEPTH - 8);
+unsigned mask =
[FFmpeg-devel] [RFC]lavc/adpcm: Support baby monitor adpcm_ms
Hi!
Attached patch fixes decoding a user-provided file here:
https://dropfile.to/x7hQfJt
I don't think there is a demuxer issue.
Please comment, Carl Eugen
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 5d8aa41..5a11faa 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -840,6 +840,8 @@ static int adpcm_decode_frame(AVCodecContext *avctx, void
*data,
{
int block_predictor;
+if (bytestream2_peek_le16(&gb) == 0x1ee1)
+bytestream2_skip(&gb, 2);
block_predictor = bytestream2_get_byteu(&gb);
if (block_predictor > 6) {
av_log(avctx, AV_LOG_ERROR, "ERROR: block_predictor[0] = %d\n",
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc
Timo Rothenpieler rothenpieler.org> writes: > As the nvEncodeApi.h header is now MIT licensed, this can be dropped. > The loaded CUDA and NVENC libraries are part of the nvidia driver, and > thus count as system libraries. If the explanation is correct, the patch is ok imo. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavc/adpcm: Support baby monitor adpcm_ms
Carl Eugen Hoyos ag.or.at> writes: > Attached patch fixes decoding a user-provided file here: > https://dropfile.to/x7hQfJt I added the following comment locally: // Levana Ovia Baby Monitor prepends each audio frame with these two bytes Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Refund request for FFmpeg at CLT 2016
Hi, On 21.03.2016 21:49, Thilo Borgmann wrote: Am 21.03.16 um 20:42 schrieb Michael Niedermayer: On Mon, Mar 21, 2016 at 12:14:40PM +0100, Thilo Borgmann wrote: Hi, last weekend, the Chemnitzer Linux Tage in Germany took place and we had quite a good experience and contacts to our end-users. Here is my refund request for gas taking Carl Eugen and myself to the venue. I'll send the invoice to Stefano. It is 64,43€. please provide some more details like the distance driven or from what city to which city We went from Berlin to Chemnitz on Friday, back from Chemnitz to Berlin on Sunday - overall around 550km. Also Hotel<->Venue transfer. Thomas made some pictures, he payed for the hotel around 160€. I think he'll request refunds for that, too. My expenses consist of: - 1 x hotel: 154 € - 1 x traveling: 147 € --- total: 301 € (The invoices will go to Stefano.) During the weekend we got many questions, some bug reports and ideas for the next CLT (and a possible presentation at OpenRheinRuhr in November 2016). The general feedback about FFmpeg was very positive. For some users, the usage complexity of the command line tools still seems to be a bit challenging. We explained the options and how the desired goals can be reached. My personal opinion is that such an event is good for the project to be visible to the outside and I support a sequel to this year's CLT. Pictures from the weekend can be found on our Facebook page: https://www.facebook.com/ffmpeg.org/ Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_colorspace: add floyd-steinberg dithering option to full conversion.
On 4/26/2016 5:41 PM, Ronald S. Bultje wrote: > --- > doc/filters.texi | 13 > libavfilter/colorspacedsp.c | 9 +++ > libavfilter/colorspacedsp.h | 6 ++ > libavfilter/colorspacedsp_template.c | 128 > +++ > libavfilter/vf_colorspace.c | 53 ++- > 5 files changed, 207 insertions(+), 2 deletions(-) This seems like a good enough place to ask this: [19:15] < Daemon404> wm4, can you perhaps enlighten me on what vf_colorspace is [19:15] < Daemon404> does it replace swscale, or colormatrix [19:15] < Daemon404> or both [19:16] < Daemon404> or parts of each but not totally [19:16] < Daemon404> or what [19:16] < wm4> that's a very good question I'm really not clear. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_colorspace: add floyd-steinberg dithering option to full conversion.
Hi, On Tue, Apr 26, 2016 at 2:17 PM, Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > On 4/26/2016 5:41 PM, Ronald S. Bultje wrote: > > --- > > doc/filters.texi | 13 > > libavfilter/colorspacedsp.c | 9 +++ > > libavfilter/colorspacedsp.h | 6 ++ > > libavfilter/colorspacedsp_template.c | 128 > +++ > > libavfilter/vf_colorspace.c | 53 ++- > > 5 files changed, 207 insertions(+), 2 deletions(-) > > This seems like a good enough place to ask this: > > [19:15] < Daemon404> wm4, can you perhaps enlighten me on what > vf_colorspace is > [19:15] < Daemon404> does it replace swscale, or colormatrix > [19:15] < Daemon404> or both > [19:16] < Daemon404> or parts of each but not totally > [19:16] < Daemon404> or what > [19:16] < wm4> that's a very good question > > I'm really not clear. It initially replaces colormatrix. Eventually, as some people have suggested, I'd really like if it could also do the full scaling (i.e. merge functionality with swscale's, similar to zscale or so). But that's quite far off. See the wiki. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] configure: Remove -Wredundant-decls on OS/2 to suppress noise.
On 2016-04-21 06:46:38 +, Reimar Döffinger said:
Have something that results in adding -I/usr/include to the compile
options or to C_INCLUDE_PATH? Probably your compiler is misconfigured
to not consider that a system include path.
Adding -isystem /usr/include should fix it.
I finally had some time to research. No, our compiler (at least the RPM
releases from BWW) is not misconfigured, /@unixroot/usr/include is the
system include path and a simple `gcc -Zomf -Wredundant-decls -c
hello.c` works well. However, when building FFmpeg stuff,
-I/@unxroot/usr/include indeed ends up in CFLAGS multiple times and all
these come from .pc files (namely, fontconfig.pc and vpx.pc). And from
what I see in the sources, -I${includedir} a very common thing which is
often used in Cflags: in .pc.in, including fontconfig.pc.in (and
{includedir} is normally /usr/include or such). So all other platforms
should be suffering from -Wredundant-decls as well (unless their libc
headers are very clean and don't contain duplicate decls).
So unless I miss something else, we should still apply this patch (as
fixing OS/2 libc headers won't happen any time soon).
--
Kind regards,
Dmitriy Kuminov
CPO of bww bitwise works GmbH
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavc/adpcm: Support baby monitor adpcm_ms
On 4/26/16, Carl Eugen Hoyos wrote: > Carl Eugen Hoyos ag.or.at> writes: > >> Attached patch fixes decoding a user-provided file here: >> https://dropfile.to/x7hQfJt > > I added the following comment locally: > // Levana Ovia Baby Monitor prepends each audio frame with these two bytes Sorry, life sucks. This patch is unacceptable. > > Carl Eugen > > ___ > 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] vf_colorspace: add floyd-steinberg dithering option to full conversion.
On Tue, Apr 26, 2016 at 12:41:02PM -0400, Ronald S. Bultje wrote:
> ---
> doc/filters.texi | 13
> libavfilter/colorspacedsp.c | 9 +++
> libavfilter/colorspacedsp.h | 6 ++
> libavfilter/colorspacedsp_template.c | 128
> +++
> libavfilter/vf_colorspace.c | 53 ++-
> 5 files changed, 207 insertions(+), 2 deletions(-)
[...]
> diff --git a/libavfilter/colorspacedsp_template.c
> b/libavfilter/colorspacedsp_template.c
> index f225391..db4a8d2 100644
> --- a/libavfilter/colorspacedsp_template.c
> +++ b/libavfilter/colorspacedsp_template.c
> @@ -199,6 +199,134 @@ static void fn(rgb2yuv)(uint8_t *_yuv[3], ptrdiff_t
> yuv_stride[3],
> }
> }
>
> +/* floyd-steinberg dithering - for any mid-top pixel A in a 3x2 block of
> pixels:
> + *1 A 2
> + *3 4 5
> + * the rounding error is distributed over the neighbouring pixels:
> + *2: 7/16th, 3: 3/16th, 4: 5/16th and 5: 1/16th
> + */
> +static void fn(rgb2yuv_fsb)(uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
> +int16_t *rgb[3], ptrdiff_t s,
> +int w, int h, const int16_t
> rgb2yuv_coeffs[3][3][8],
> +const int16_t yuv_offset[8],
> +int *rnd_scratch[3][2])
> +{
> +pixel **yuv = (pixel **) _yuv;
> +pixel *yuv0 = yuv[0], *yuv1 = yuv[1], *yuv2 = yuv[2];
> +const int16_t *rgb0 = rgb[0], *rgb1 = rgb[1], *rgb2 = rgb[2];
> +int y, x;
> +const int sh = 29 - BIT_DEPTH;
> +const int rnd = 1 << (sh - 1);
> +int cry = rgb2yuv_coeffs[0][0][0];
> +int cgy = rgb2yuv_coeffs[0][1][0];
> +int cby = rgb2yuv_coeffs[0][2][0];
> +int cru = rgb2yuv_coeffs[1][0][0];
> +int cgu = rgb2yuv_coeffs[1][1][0];
> +int cburv = rgb2yuv_coeffs[1][2][0];
> +int cgv = rgb2yuv_coeffs[2][1][0];
> +int cbv = rgb2yuv_coeffs[2][2][0];
> +ptrdiff_t s0 = yuv_stride[0] / sizeof(pixel);
> +const int uv_offset = 128 << (BIT_DEPTH - 8);
> +unsigned mask = (1 << sh) - 1;
> +
> +for (x = 0; x < w; x++) {
> +rnd_scratch[0][0][x] =
> +rnd_scratch[0][1][x] = rnd;
> +}
> +av_assert2(rgb2yuv_coeffs[1][2][0] == rgb2yuv_coeffs[2][0][0]);
> +w = AV_CEIL_RSHIFT(w, SS_W);
> +h = AV_CEIL_RSHIFT(h, SS_H);
> +for (x = 0; x < w; x++) {
> +rnd_scratch[1][0][x] =
> +rnd_scratch[1][1][x] =
> +rnd_scratch[2][0][x] =
> +rnd_scratch[2][1][x] = rnd;
> +}
> +for (y = 0; y < h; y++) {
> +for (x = 0; x < w; x++) {
> +int r00 = rgb0[x << SS_W], g00 = rgb1[x << SS_W], b00 = rgb2[x
> << SS_W];
> +int y00;
> +#if SS_W == 1
> +int r01 = rgb0[x * 2 + 1], g01 = rgb1[x * 2 + 1], b01 = rgb2[x *
> 2 + 1];
> +int y01;
> +#if SS_H == 1
SS_W/SS_H should be documented or named so they are self explanatory
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but never of holding my tongue.
-- Xenocrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/alsdec: Fix bitstream reading
According to the latest ISO specification pdf, the byte align should
be according to the patch.
Tested the change with all the sample ALS files. This doesn't produce any bug.
From 7af5076eabc28a441ed90f920bf1a6a1e0855c3f Mon Sep 17 00:00:00 2001
From: Umair Khan
Date: Wed, 27 Apr 2016 09:04:18 +0530
Subject: [PATCH] avcodec/alsdec: Fix bitstream reading
Signed-off-by: Umair Khan
---
libavcodec/alsdec.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index 1402b00..0967ea0 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec.c
@@ -867,9 +867,6 @@ static int read_var_block_data(ALSDecContext *ctx, ALSBlockData *bd)
*current_res++ = decode_rice(gb, s[sb]);
}
-if (!sconf->mc_coding || ctx->js_switch)
-align_get_bits(gb);
-
return 0;
}
@@ -989,6 +986,7 @@ static int read_block(ALSDecContext *ctx, ALSBlockData *bd)
{
int ret;
GetBitContext *gb= &ctx->gb;
+ALSSpecificConfig *sconf = &ctx->sconf;
*bd->shift_lsbs = 0;
// read block type flag and read the samples accordingly
@@ -998,6 +996,9 @@ static int read_block(ALSDecContext *ctx, ALSBlockData *bd)
ret = read_const_block_data(ctx, bd);
}
+if (!sconf->mc_coding || ctx->js_switch)
+align_get_bits(gb);
+
return ret;
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 57/57] support for matrox m703 mpeg-2
Signed-off-by: Aleksandr.Slobodeniuk
---
libavformat/riff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index cf5a2ff..7a1f3bc 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -168,6 +168,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
{ AV_CODEC_ID_MPEG2VIDEO, MKTAG('E', 'M', '2', 'V') },
/* Matrox MPEG-2 intra-only */
{ AV_CODEC_ID_MPEG2VIDEO, MKTAG('M', '7', '0', '1') },
+{ AV_CODEC_ID_MPEG2VIDEO, MKTAG('M', '7', '0', '3') },
{ AV_CODEC_ID_MPEG2VIDEO, MKTAG('M', '7', '0', '5') },
{ AV_CODEC_ID_MPEG2VIDEO, MKTAG('m', 'p', 'g', 'v') },
{ AV_CODEC_ID_MPEG1VIDEO, MKTAG('B', 'W', '1', '0') },
--
2.7.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 2/2] avutil/log: added test case for av_log_format_line2
From: Andreas Weis
Signed-off-by: Andreas Weis
---
libavutil/log.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libavutil/log.c b/libavutil/log.c
index 0efba7a..7e279ad 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -444,6 +444,17 @@ void avpriv_report_missing_feature(void *avc, const char
*msg, ...)
// LCOV_EXCL_START
#include
+static int call_log_format_line2(const char *fmt, char *buffer, int
buffer_size, ...)
+{
+va_list args;
+int ret;
+int print_prefix=1;
+va_start(args, buffer_size);
+ret = av_log_format_line2(NULL, AV_LOG_INFO, fmt, args, buffer,
buffer_size, &print_prefix);
+va_end(args);
+return ret;
+}
+
int main(int argc, char **argv)
{
int i;
@@ -458,6 +469,25 @@ int main(int argc, char **argv)
}
av_log(NULL, AV_LOG_PANIC, "\n");
}
+{
+int result;
+char buffer[4];
+result = call_log_format_line2("foo", NULL, 0);
+if(result != 3) {
+printf("Test NULL buffer failed.\n");
+return 1;
+}
+result = call_log_format_line2("foo", buffer, 2);
+if(result != 3 || strncmp(buffer, "f", 2)) {
+printf("Test buffer too small failed.\n");
+return 1;
+}
+result = call_log_format_line2("foo", buffer, 4);
+if(result != 3 || strncmp(buffer, "foo", 4)) {
+printf("Test buffer sufficiently big failed.\n");
+return 1;
+}
+}
return 0;
}
// LCOV_EXCL_STOP
--
2.5.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 1/2] avutil/log: added av_log_format_line2 which returns buffer length
From: Andreas Weis
The new function behaves the same as av_log_format_line, but also forwards
the return value from the underlying snprintf call. This will allow
callers to accurately determine the size requirements for the line buffer.
Signed-off-by: Andreas Weis
---
doc/APIchanges | 4
libavutil/log.c | 11 ++-
libavutil/log.h | 17 +
libavutil/version.h | 2 +-
4 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index de72807..032eb1c 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2015-08-28
API changes, most recent first:
+2016-04-26 - xxx - lavu 55.23.101 - log.h
+ Add a new function av_log_format_line2() which returns number of bytes
+ written to the target buffer.
+
2016-xx-xx - xxx - lavc 57.37.100 - avcodec.h
Add a new audio/video encoding and decoding API with decoupled input
and output -- avcodec_send_packet(), avcodec_receive_frame(),
diff --git a/libavutil/log.c b/libavutil/log.c
index 4583519..0efba7a 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -284,10 +284,19 @@ static void format_line(void *avcl, int level, const char
*fmt, va_list vl,
void av_log_format_line(void *ptr, int level, const char *fmt, va_list vl,
char *line, int line_size, int *print_prefix)
{
+av_log_format_line2(ptr, level, fmt, vl, line, line_size, print_prefix);
+}
+
+int av_log_format_line2(void *ptr, int level, const char *fmt, va_list vl,
+char *line, int line_size, int *print_prefix)
+{
AVBPrint part[4];
+int ret;
+
format_line(ptr, level, fmt, vl, part, print_prefix, NULL);
-snprintf(line, line_size, "%s%s%s%s", part[0].str, part[1].str,
part[2].str, part[3].str);
+ret = snprintf(line, line_size, "%s%s%s%s", part[0].str, part[1].str,
part[2].str, part[3].str);
av_bprint_finalize(part+3, NULL);
+return ret;
}
void av_log_default_callback(void* ptr, int level, const char* fmt, va_list vl)
diff --git a/libavutil/log.h b/libavutil/log.h
index 321748c..9b1d66f 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -317,6 +317,23 @@ AVClassCategory av_default_get_category(void *ptr);
void av_log_format_line(void *ptr, int level, const char *fmt, va_list vl,
char *line, int line_size, int *print_prefix);
+/**
+ * Format a line of log the same way as the default callback.
+ * @param line buffer to receive the formatted line;
+ * may be NULL if line_size is 0
+ * @param line_size size of the buffer; at most line_size-1 characters will
+ * be written to the buffer, plus one null terminator
+ * @param print_prefix used to store whether the prefix must be printed;
+ * must point to a persistent integer initially set to 1
+ * @return Returns a negative value if an error occured, otherwise returns
+ * the number of characters that would have been written for a
+ * sufficiently large buffer, not including the terminating null
+ * character. If the return value is not less than line_size, it means
+ * that the log message was truncated to fit the buffer.
+ */
+int av_log_format_line2(void *ptr, int level, const char *fmt, va_list vl,
+char *line, int line_size, int *print_prefix);
+
#if FF_API_DLOG
/**
* av_dlog macros
diff --git a/libavutil/version.h b/libavutil/version.h
index 24bd0d0..d862fb8 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -64,7 +64,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 55
-#define LIBAVUTIL_VERSION_MINOR 22
+#define LIBAVUTIL_VERSION_MINOR 23
#define LIBAVUTIL_VERSION_MICRO 101
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.5.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
