Re: [FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation
On Wed, Jul 06, 2016 at 03:51:12PM +0700, nablet developer wrote: > > > On 06 Jul 2016, at 15:48, Hendrik Leppkes wrote: > > > > On Wed, Jul 6, 2016 at 9:08 AM, nablet developer wrote: > >> add hwcontext_qsv (Intel QuickSync Video) implementation > >> basically it's adapted patch from libav > >> (https://lists.libav.org/pipermail/libav-devel/2016-May/077126.html) > > > > If you take a patch from libav, you need to maintain proper authorship > > information. > > how is it usually done? commit message, comment block or something else? git has a author field if more detals are needed, they can additionally be put in the commit message > > > Also please outline what has changed from the original, if anything. > > We try to keep all the hwcontext things as close to libav as possible > > to make future enhancements easier. > > patch is identical except copyright headers of hwcontext_qsv.c / > hwcontext_qsv.h (first 17 lines) which are changed to the typical ffmpeg > copyright. > > > > > - Hendrik > > ___ > > 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 -- 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] libavcodec/webp : fix return code check in lossy decoding
On Sun, Jun 26, 2016 at 10:45:33PM +0200, Martin Vignali wrote: > Hello, > > in attach patch to fix ret code check in webp lossy decoding (when files > have alpha) > > before this patch, if an error occured during rgb decoding > the return code was ignored. And a useless ret test was made > after alpha decoding. > > after this patch, the return code of rgb is test before > trying to decode alpha. > > > Comments welcome > > Martin > Jokyo Images > webp.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > 494399734be14a906e03a1b976dbca27c442cdac > 0001-libavcodec-webp-fix-return-code-check-in-lossy-decod.patch > From 4b7a1b3c03ec1a9062d3100d79668d905f6226fe Mon Sep 17 00:00:00 2001 > From: Martin Vignali > Date: Sun, 26 Jun 2016 22:36:23 +0200 > Subject: [PATCH] libavcodec/webp : fix return code check in lossy decoding > > before this patch, if an error occured during rgb decoding > the return code was ignored. And an useless ret test was made > after alpha decoding. > > after this patch, the return code of rgb is test before > trying to decode alpha. should not both be attempted to be decoded and in case both fail an error be returned? One could be correctly decoded and that should not be discarded but maybe iam missing something [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Support QT b64a ARGB64 rawvideo
On Sun, Jul 03, 2016 at 11:08:15PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patches fix ticket #5657.
>
> Please comment, Carl Eugen
> libavcodec/raw.c |1 +
> libavcodec/rawdec.c |9 +
> libavcodec/version.h |2 +-
> libavformat/isom.c |1 +
> 4 files changed, 12 insertions(+), 1 deletion(-)
> cd699fd29642c445ed3d785f64f96b94f6b4e027
> 0001-lavc-rawdec-Support-QuickTime-b64a-ARGB64-rawvideo.patch
> From 1bba7103c093951cab1bb9aa7b5eaf07b44d2781 Mon Sep 17 00:00:00 2001
> From: v0lt
> Date: Sun, 3 Jul 2016 23:04:08 +0200
> Subject: [PATCH 1/2] lavc/rawdec: Support QuickTime b64a ARGB64 rawvideo.
>
> Fixes ticket #5657.
> ---
> libavcodec/raw.c |1 +
> libavcodec/rawdec.c |9 +
> libavcodec/version.h |2 +-
> libavformat/isom.c |1 +
> 4 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/raw.c b/libavcodec/raw.c
> index bfa2537..35dfbab 100644
> --- a/libavcodec/raw.c
> +++ b/libavcodec/raw.c
> @@ -224,6 +224,7 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
> { AV_PIX_FMT_ABGR,MKTAG('A', 'B', 'G', 'R') },
> { AV_PIX_FMT_GRAY16BE,MKTAG('b', '1', '6', 'g') },
> { AV_PIX_FMT_RGB48BE, MKTAG('b', '4', '8', 'r') },
> +{ AV_PIX_FMT_RGBA64BE,MKTAG('b', '6', '4', 'a') },
>
> /* vlc */
> { AV_PIX_FMT_YUV410P, MKTAG('I', '4', '1', '0') },
> diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
> index 765e567..8085ffa 100644
> --- a/libavcodec/rawdec.c
> +++ b/libavcodec/rawdec.c
> @@ -444,6 +444,15 @@ static int raw_decode(AVCodecContext *avctx, void *data,
> int *got_frame,
> }
> }
>
> +if (avctx->codec_tag == MKTAG('b', '6', '4', 'a') &&
> +avctx->pix_fmt == AV_PIX_FMT_RGBA64BE) {
> +uint64_t *pixel = frame->data[0];
> +int i, n = avctx->width * avctx->height;
> +for (i = 0; i < n; i++) {
> +*pixel++ = *pixel << 48 | *pixel >> 16;
> +}
> +}
does this work on big endian ?
also a fate test would be useful
[...]
thx
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/webp : fix return code check in lossy decoding
On Sat, Jul 9, 2016 at 11:13 AM, Michael Niedermayer wrote: > On Sun, Jun 26, 2016 at 10:45:33PM +0200, Martin Vignali wrote: >> Hello, >> >> in attach patch to fix ret code check in webp lossy decoding (when files >> have alpha) >> >> before this patch, if an error occured during rgb decoding >> the return code was ignored. And a useless ret test was made >> after alpha decoding. >> >> after this patch, the return code of rgb is test before >> trying to decode alpha. >> >> >> Comments welcome >> >> Martin >> Jokyo Images > >> webp.c |4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> 494399734be14a906e03a1b976dbca27c442cdac >> 0001-libavcodec-webp-fix-return-code-check-in-lossy-decod.patch >> From 4b7a1b3c03ec1a9062d3100d79668d905f6226fe Mon Sep 17 00:00:00 2001 >> From: Martin Vignali >> Date: Sun, 26 Jun 2016 22:36:23 +0200 >> Subject: [PATCH] libavcodec/webp : fix return code check in lossy decoding >> >> before this patch, if an error occured during rgb decoding >> the return code was ignored. And an useless ret test was made >> after alpha decoding. >> >> after this patch, the return code of rgb is test before >> trying to decode alpha. > > should not both be attempted to be decoded and in case both fail an > error be returned? > > One could be correctly decoded and that should not be discarded > but maybe iam missing something > Decoding the alpha plane when the RGB plane failed seems rather useless, doesn't it. One may argue that decoding and returning the RGB and ignoring failure in alpha may be useful. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/webp : fix return code check in lossy decoding
On Sat, Jul 09, 2016 at 11:53:04AM +0200, Hendrik Leppkes wrote: > On Sat, Jul 9, 2016 at 11:13 AM, Michael Niedermayer > wrote: > > On Sun, Jun 26, 2016 at 10:45:33PM +0200, Martin Vignali wrote: > >> Hello, > >> > >> in attach patch to fix ret code check in webp lossy decoding (when files > >> have alpha) > >> > >> before this patch, if an error occured during rgb decoding > >> the return code was ignored. And a useless ret test was made > >> after alpha decoding. > >> > >> after this patch, the return code of rgb is test before > >> trying to decode alpha. > >> > >> > >> Comments welcome > >> > >> Martin > >> Jokyo Images > > > >> webp.c |4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> 494399734be14a906e03a1b976dbca27c442cdac > >> 0001-libavcodec-webp-fix-return-code-check-in-lossy-decod.patch > >> From 4b7a1b3c03ec1a9062d3100d79668d905f6226fe Mon Sep 17 00:00:00 2001 > >> From: Martin Vignali > >> Date: Sun, 26 Jun 2016 22:36:23 +0200 > >> Subject: [PATCH] libavcodec/webp : fix return code check in lossy decoding > >> > >> before this patch, if an error occured during rgb decoding > >> the return code was ignored. And an useless ret test was made > >> after alpha decoding. > >> > >> after this patch, the return code of rgb is test before > >> trying to decode alpha. > > > > should not both be attempted to be decoded and in case both fail an > > error be returned? > > > > One could be correctly decoded and that should not be discarded > > but maybe iam missing something > > > > Decoding the alpha plane when the RGB plane failed seems rather > useless, doesn't it. I dont know to me having an alpha plane seems better than having nothing With slices we generally also return what we can even if its just one macroblock we could decode also with videos and slices previous frames would be used to fill in missing areas ... > One may argue that decoding and returning the RGB and ignoring failure > in alpha may be useful. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] lavf/segment: copy stream dispositions in output
On Mon, Jul 04, 2016 at 10:33:19AM -0700, Rodger Combs wrote: > --- > libavformat/segment.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/segment.c b/libavformat/segment.c > index 9c766a5..5aec018 100644 > --- a/libavformat/segment.c > +++ b/libavformat/segment.c > @@ -184,6 +184,7 @@ static int segment_mux_init(AVFormatContext *s) > } > st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio; > st->time_base = s->streams[i]->time_base; > +st->disposition = s->streams[i]->disposition; > av_dict_copy(&st->metadata, s->streams[i]->metadata, 0); LGTM please apply (no need to wait for the other patches i think) Thnaks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavf/segment: write attached pictures to all segments by default
On Mon, Jul 04, 2016 at 10:33:20AM -0700, Rodger Combs wrote: > --- > doc/muxers.texi | 4 > libavformat/segment.c | 33 + > libavformat/version.h | 2 +- > 3 files changed, 38 insertions(+), 1 deletion(-) probably ok a fate test for this would be cool too either way thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv4] lavf: add libopenmpt demuxer
On 07/08/2016 10:17 PM, Nicolas George wrote:
Le primidi 21 messidor, an CCXXIV, Jörn Heusipp a écrit :
Regarding AVProbeData:
Looking at AVProbeData, I can see no (optional) field describing the file
size:
typedef struct AVProbeData {
const char *filename;
unsigned char *buf; /**< Buffer must have AVPROBE_PADDING_SIZE of extra
allocated bytes filled with zero. */
int buf_size; /**< Size of buf except extra allocated bytes */
const char *mime_type; /**< mime_type, when known. */
} AVProbeData;
Sadly, that makes it rather useless for probing module formats: There are
module formats which have no magic bytes at all, or very bad ones which
require verifying other simple parts of the header in order to determine any
meaningful probing result, some even require seeking through the file and
verifying other later parts, some even have a footer that may need to be
verified.
Because of this situation, the libopenmpt I/O layer absolutely needs to know
the file size in order to do anything useful. In our adaption layer for
streams (like stdin or HTTP without length information), we lazily pre-cache
the whole file until hitting EOF as soon as the size is required or the code
wants to seek to the end. As any kind of streaming does not apply to module
formats, this was (and is) a sane design choice for libopenmpt.
The probing infrastructure can not provide the file size, for all we know it
could be an infinite stream coming from a live capture device.
Well, I think it could optionally provide it if it knows, as an
additional hint to probe functions. I do understand however, that
supporting probing for such non-streamable formats is probably not a
primary design goal of ffmpeg. I'm not arguing for changing ffmpeg
internals here.
Naively, I would suggest to assume that AVProbeData contains the whole file
and try probing that. That would be like trying to play a file that was
truncated on disk for some reason. If the probing fails, libavformat will
read some more and try again until it reaches the probe size limit.
I was not aware of that strategy used by ffmpeg. Skimming through the
ffmpeg code, you seem to be referring to av_probe_input_buffer2().
I think your suggestion can work.
For an obscure format (I mean it without any disrespect, only as a fact with
regard to FFMpeg's usual use), false negatives on the probing are not that
big a problem: it will fall back to using the extension, and if even that
fails the user can still specify "-f libopenmpt" or the equivalent in their
application.
These formats are obscure, but they exist, are old, and are not going to
change, thus we are stuck with this mess (no disrespect taken ;).
If false-negatives are acceptable for ffmpeg, using your suggestion of
just pretending AVProbeData contained the whole file will work for
almost all cases. I do not think that we (libopenmpt) can guarantee that
this will not also introduce false-positives, though they should be
really rare (I cannot think of such a case right now, but I also do not
think that we want to make the promise made by our API more specific for
the truncated data case).
I also was not aware of the fallback to file extension, which totally
makes sense.
Specifying libopenmpt explicitly would of course be easy for users of
the ffmpeg program itself, but maybe not so much for users who use
libavformat through some other library/framework/player.
I did a really quick, non-exhaustive check on some files, and libopenmpt
currently gives pretty reliable positive probing results for files
truncated to 4096 bytes. 1024 is not sufficient as standard ProTracker
MOD files have the magic bytes "M.K." at offset 1080.
Starting calling openmpt_could_open_propability() only after more than
4096 are available would be a trade-off between on the one hand
performance (not calling into libopenmpt at all if other ffmpeg demuxers
were able to probe successfully with fewer data) and maybe reduced
false-positives, and on the other hand reduced false-negatives (there
are perfectly valid and usable module files smaller than 4096 bytes,
even smaller than 1024 bytes is possible for some formats).
Regarding probing performance:
A thing to consider when discussing probing performance: the most important
is the speed of the obviously negative answers. A Matroska file or a MP3
file does not look at all like a tracker file, and libopenmpt should be able
to figure it out very quickly. Only when the file actually looks like a
tracker file should it make extra checks to be sure.
If that condition is met, then probing performance is probably not an issue:
users playing non-tracker file will not suffer from it.
I wish we could have this kind of early-reject in our probing function,
but module formats without any file magic bytes at all prohibit such an
implementation.
For formats which have magic bytes, we of course check these first and
continue with the next format if they
Re: [FFmpeg-devel] [PATCHv4] lavf: add libopenmpt demuxer
On 06/30/2016 02:49 AM, Josh de Kock wrote:
Fixes ticket #5623
TODO: bump lavf minor
---
I looked more thoroughly at your patch again.
I'm commenting from libopenmpt perspective of course.
+openmpt->module = openmpt_module_create_from_memory(buf, size,
openmpt_logfunc, s, NULL);
+av_freep(&buf);
+if (!openmpt->module)
+return AVERROR(ENOMEM);
Libopenmpt C API sadly does not allow to determine the reason for a
failing openmpt_module_create. This was an oversight when designing the
API. It will be improved with the 1.0 API which is currently in
development. We will continue to support the API (and ABI) of 0.2 just
fine even after 1.0.
As to the specific error code: ENOMEM is of course a possible reason why
openmpt_module_create_from_memory could fail, but a very unlikely one.
The more common case would be an invalid/corrupt/unsupported module file.
I think, replacing AVERROR(ENOMEM) with something resembling that would
be better.
+#define add_meta(s, name, meta)\
+do { \
+const char *value = meta; \
+if (value && value[0]) \
+av_dict_set(&s->metadata, name, value, 0); \
+} while(0)
+
+static int read_header_openmpt(AVFormatContext *s)
+{
> [...]
+add_meta(s, "artist", openmpt_module_get_metadata(openmpt->module,
"artist"));
+add_meta(s, "title", openmpt_module_get_metadata(openmpt->module,
"title"));
+add_meta(s, "encoder", openmpt_module_get_metadata(openmpt->module,
"tracker"));
+add_meta(s, "comment", openmpt_module_get_metadata(openmpt->module,
"message"));
This will leak memory.
All strings returned by libopenmpt are dynamically allocated and need to
be freed with openmpt_free_string() after use.
See https://lib.openmpt.org/doc/libopenmpt_c_overview.html and
https://lib.openmpt.org/doc/group__libopenmpt__c.html#ga0fb70a57725fc29499c557974f16a873
.
Looking at the av_dict_set API, I can see one might be tempted to just
pass AV_DICT_DONT_STRDUP_VAL in order to resolve this. Please don't, as
this will break on Windows if libavformat links dynamically to
libopenmpt which may itself be linked statically against the MSVC
runtime or dynamically against a different instance of the runtime as
ffmpeg is using. I do not know whether ffmpeg wants to support this use
case, but libopenmpt (C API only) is intended to be usable this way,
which is why one must use openmpt_free_string() which will call the
appropriate free() function internally.
i.e. something like:
#define add_meta_and_free(s, name, meta) \
do { \
const char *value = meta; \
if (value && value[0]) \
av_dict_set(&s->metadata, name, value, 0); \
openmpt_free_string(value);\
} while(0)
Regards,
Jörn (manx on htts://bugs.openmpt.org/)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: update to openh264 1.6
On 23 May 2016 at 20:11, Michael Niedermayer wrote: > > it would be great to have support for both 1.6 and older versions > There's a patch by Martin Störjo in libav-devel that seems to allow support for both releases and git master. Tested just now in MinGW with git master and it worked. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] latest ffmpeg git master build is broken on osx powerpc
Hi,
PowerPC build on OSX 10.5 (Leopard) is broken:
$ gcc --version
powerpc-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/nfs/scratch/Developer/ffmpeg-git-src/configure --prefix=/Developer/ppc
--disable-debug --disable-shared --enable-static --enable-swscale
--enable-avfilter --enable-libmp3lame --enable-libvorbis
--enable-libopus --enable-libtheora --enable-libschroedinger
--enable-libopenjpeg --enable-libmodplug --enable-libvpx
--enable-libspeex --enable-pthreads --enable-gpl --enable-version3
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-postproc
--enable-libx264 --enable-libxvid --enable-libass --enable-gnutls
--enable-runtime-cpudetect --extra-cflags=-I/opt/local/include
--extra-ldflags='-headerpad_max_install_names -L/opt/local/lib'
--disable-audiotoolbox --disable-videotoolbox --disable-sdl
--disable-filter=coreimagesrc --disable-filter=coreimage
$ make
ASlibavcodec/ppc/fft_altivec.o
{standard input}:257:Parameter syntax error (parameter 3)
{standard input}:264:Parameter syntax error (parameter 3)
{standard input}:265:Parameter syntax error (parameter 3)
{standard input}:271:Parameter syntax error (parameter 3)
{standard input}:278:Parameter syntax error (parameter 3)
{standard input}:279:Parameter syntax error (parameter 3)
{standard input}:285:Parameter syntax error (parameter 3)
{standard input}:292:Parameter syntax error (parameter 3)
{standard input}:293:Parameter syntax error (parameter 3)
{standard input}:299:Parameter syntax error (parameter 3)
{standard input}:306:Parameter syntax error (parameter 3)
{standard input}:307:Parameter syntax error (parameter 3)
{standard input}:313:Parameter syntax error (parameter 3)
{standard input}:320:Parameter syntax error (parameter 3)
{standard input}:321:Parameter syntax error (parameter 3)
{standard input}:327:Parameter syntax error (parameter 3)
{standard input}:334:Parameter syntax error (parameter 3)
{standard input}:335:Parameter syntax error (parameter 3)
{standard input}:341:Parameter syntax error (parameter 3)
{standard input}:348:Parameter syntax error (parameter 3)
{standard input}:349:Parameter syntax error (parameter 3)
{standard input}:355:Parameter syntax error (parameter 3)
{standard input}:362:Parameter syntax error (parameter 3)
{standard input}:363:Parameter syntax error (parameter 3)
{standard input}:369:Parameter syntax error (parameter 3)
{standard input}:378:Parameter syntax error (parameter 3)
{standard input}:379:Parameter syntax error (parameter 3)
{standard input}:385:Parameter syntax error (parameter 3)
{standard input}:394:Parameter syntax error (parameter 3)
{standard input}:395:Parameter syntax error (parameter 3)
{standard input}:401:Parameter syntax error (parameter 3)
{standard input}:408:Parameter syntax error (parameter 3)
{standard input}:409:Parameter syntax error (parameter 3)
{standard input}:415:Parameter syntax error (parameter 3)
{standard input}:422:Parameter syntax error (parameter 3)
{standard input}:423:Parameter syntax error (parameter 3)
{standard input}:433:Parameter syntax error (parameter 3)
{standard input}:434:Parameter syntax error (parameter 3)
{standard input}:464:Parameter syntax error (parameter 3)
{standard input}:465:Parameter syntax error (parameter 2)
{standard input}:521:Parameter syntax error (parameter 3)
{standard input}:550:Parameter syntax error (parameter 3)
{standard input}:552:Parameter syntax error (parameter 3)
{standard input}:553:Parameter syntax error (parameter 3)
{standard input}:799:Parameter syntax error (parameter 3)
{standard input}:806:Parameter syntax error (parameter 3)
{standard input}:807:Parameter syntax error (parameter 3)
{standard input}:813:Parameter syntax error (parameter 3)
{standard input}:820:Parameter syntax error (parameter 3)
{standard input}:821:Parameter syntax error (parameter 3)
{standard input}:827:Parameter syntax error (parameter 3)
{standard input}:834:Parameter syntax error (parameter 3)
{standard input}:835:Parameter syntax error (parameter 3)
{standard input}:841:Parameter syntax error (parameter 3)
{standard input}:848:Parameter syntax error (parameter 3)
{standard input}:849:Parameter syntax error (parameter 3)
{standard input}:855:Parameter syntax error (parameter 3)
{standard input}:862:Parameter syntax error (parameter 3)
{standard input}:863:Parameter syntax error (parameter 3)
{standard input}:869:Parameter syntax error (parameter 3)
{standard input}:876:Parameter syntax error (parameter 3)
{standard input}:877:Parameter syntax error (parameter 3)
{standard input}:883:Parameter syntax error (parameter 3)
{standard input}:890:Parameter syntax error (parameter 3)
{standard input}:891:Parameter syntax error (parameter 3)
{standard input}:897:Parameter syntax error (parameter 3)
{standard inpu
Re: [FFmpeg-devel] [PATCH] vp9: add 16x16 idct avx2 (8-bit).
On 7/8/2016 6:59 PM, Ronald S. Bultje wrote: > +%if ARCH_X86_64 > +INIT_YMM avx2 Add an %if HAVE_AVX2_EXTERNAL check here, because yasm 1.1.0 and older don't support avx2. lgtm aside from that. > +cglobal vp9_idct_idct_16x16_add, 4, 4, 16, dst, stride, block, eob ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] libavcodec : add psd image file decoder
Hello,
In attach patch to add decoding of .psd file (Photoshop file).
PSD file can contain merge layers data at the end of the file (Image Data
Section)
This patch add support for this kind of files, using uncompress data Image
Data Section
Support Gray/A, and RGB/A with 8b or 16 bits by channel.
Samples can be found here :
https://we.tl/GK6yQhUV8j
Comments welcome
Martin
From a4b9c1373cc62d1bb38997704a924ecfe78ee4b4 Mon Sep 17 00:00:00 2001
From: Martin Vignali
Date: Sat, 9 Jul 2016 15:59:41 +0200
Subject: [PATCH] libavcodec : add decoder for .psd image file. Decode the
Image Data Section (who contain merge picture) Support RGB/A and Grayscale/A
in 8bits and 16 bits by channel. Only support now, uncompress Image Data
Section.
---
Changelog| 2 +-
doc/general.texi | 2 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h | 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/psd.c | 310 +++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/img2.c | 1 +
libavformat/img2dec.c| 10 ++
libavformat/isom.c | 1 +
12 files changed, 337 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/psd.c
diff --git a/Changelog b/Changelog
index 99cdb80..c7b9908 100644
--- a/Changelog
+++ b/Changelog
@@ -2,7 +2,7 @@ Entries are sorted chronologically from oldest to youngest within each release,
releases are sorted from youngest to oldest.
version :
-
+- Psd Decoder
version 3.1:
- DXVA2-accelerated HEVC Main10 decoding
diff --git a/doc/general.texi b/doc/general.texi
index 4db209f..06775f4 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -577,6 +577,8 @@ following image formats are supported:
@item PNG @tab X @tab X
@item PPM @tab X @tab X
@tab Portable PixelMap image
+@item PSD @tab @tab X
+@tab Photoshop
@item PTX @tab @tab X
@tab V.Flash PTX format
@item SGI @tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fd0d1f0..913b4a8 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -456,6 +456,7 @@ OBJS-$(CONFIG_PRORES_LGPL_DECODER) += proresdec_lgpl.o proresdsp.o proresdat
OBJS-$(CONFIG_PRORES_ENCODER) += proresenc_anatoliy.o
OBJS-$(CONFIG_PRORES_AW_ENCODER) += proresenc_anatoliy.o
OBJS-$(CONFIG_PRORES_KS_ENCODER) += proresenc_kostya.o proresdata.o
+OBJS-$(CONFIG_PSD_DECODER) += psd.o
OBJS-$(CONFIG_PTX_DECODER) += ptx.o
OBJS-$(CONFIG_QCELP_DECODER) += qcelpdec.o \
celp_filters.o acelp_vectors.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 54efaad..458f603 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -278,6 +278,7 @@ void avcodec_register_all(void)
REGISTER_ENCODER(PRORES_AW, prores_aw);
REGISTER_ENCODER(PRORES_KS, prores_ks);
REGISTER_DECODER(PRORES_LGPL, prores_lgpl);
+REGISTER_DECODER(PSD, psd);
REGISTER_DECODER(PTX, ptx);
REGISTER_DECODER(QDRAW, qdraw);
REGISTER_DECODER(QPEG, qpeg);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 39713ed..75a9970 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -409,6 +409,7 @@ enum AVCodecID {
AV_CODEC_ID_MAGICYUV,
AV_CODEC_ID_SHEERVIDEO,
AV_CODEC_ID_YLC,
+AV_CODEC_ID_PSD,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9d94b72..427553c 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1425,6 +1425,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
},
{
+.id= AV_CODEC_ID_PSD,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "psd",
+.long_name = NULL_IF_CONFIG_SMALL("Photoshop file"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
+{
.id= AV_CODEC_ID_PTX,
.type = AVMEDIA_TYPE_VIDEO,
.name = "ptx",
diff --git a/libavcodec/psd.c b/libavcodec/psd.c
new file mode 100644
index 000..da9036f
--- /dev/null
+++ b/libavcodec/psd.c
@@ -0,0 +1,310 @@
+/*
+ * Photoshop (.psd) image decoder
+ * Copyright (c) 2016 Jokyo Images
+ *
+ * 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,
Re: [FFmpeg-devel] libavcodec/webp : fix return code check in lossy decoding
2016-07-09 12:18 GMT+02:00 Michael Niedermayer :
> On Sat, Jul 09, 2016 at 11:53:04AM +0200, Hendrik Leppkes wrote:
> > On Sat, Jul 9, 2016 at 11:13 AM, Michael Niedermayer
> > wrote:
> > > On Sun, Jun 26, 2016 at 10:45:33PM +0200, Martin Vignali wrote:
> > >> Hello,
> > >>
> > >> in attach patch to fix ret code check in webp lossy decoding (when
> files
> > >> have alpha)
> > >>
> > >> before this patch, if an error occured during rgb decoding
> > >> the return code was ignored. And a useless ret test was made
> > >> after alpha decoding.
> > >>
> > >> after this patch, the return code of rgb is test before
> > >> trying to decode alpha.
> > >>
> > >>
> > >> Comments welcome
> > >>
> > >> Martin
> > >> Jokyo Images
> > >
> > >> webp.c |4 ++--
> > >> 1 file changed, 2 insertions(+), 2 deletions(-)
> > >> 494399734be14a906e03a1b976dbca27c442cdac
> 0001-libavcodec-webp-fix-return-code-check-in-lossy-decod.patch
> > >> From 4b7a1b3c03ec1a9062d3100d79668d905f6226fe Mon Sep 17 00:00:00 2001
> > >> From: Martin Vignali
> > >> Date: Sun, 26 Jun 2016 22:36:23 +0200
> > >> Subject: [PATCH] libavcodec/webp : fix return code check in lossy
> decoding
> > >>
> > >> before this patch, if an error occured during rgb decoding
> > >> the return code was ignored. And an useless ret test was made
> > >> after alpha decoding.
> > >>
> > >> after this patch, the return code of rgb is test before
> > >> trying to decode alpha.
> > >
> > > should not both be attempted to be decoded and in case both fail an
> > > error be returned?
> > >
> > > One could be correctly decoded and that should not be discarded
> > > but maybe iam missing something
> > >
> >
> > Decoding the alpha plane when the RGB plane failed seems rather
> > useless, doesn't it.
>
> I dont know
> to me having an alpha plane seems better than having nothing
>
> With slices we generally also return what we can even if its just
> one macroblock we could decode
> also with videos and slices previous frames would be used to fill in
> missing areas ...
>
In attach a new patch.
for rgba lossy file :
if rgb decoding failed, an error is log, but alpha is decode
if alpha decoding failed, an error is log
if both failed, return invalid data.
Comments welcome
Martin
From ba52bd0377303e56e322079e71a4d83b95cb5f80 Mon Sep 17 00:00:00 2001
From: Martin Vignali
Date: Sat, 9 Jul 2016 17:32:04 +0200
Subject: [PATCH] libavcodec/webp : check return code of rgb and alpha.
---
libavcodec/webp.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 45abfdc..890cbba 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1322,7 +1322,7 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx, AVFrame *p,
{
WebPContext *s = avctx->priv_data;
AVPacket pkt;
-int ret;
+int ret, aret;
if (!s->initialized) {
ff_vp8_decode_init(avctx);
@@ -1343,10 +1343,16 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx, AVFrame *p,
ret = ff_vp8_decode_frame(avctx, p, got_frame, &pkt);
if (s->has_alpha) {
-ret = vp8_lossy_decode_alpha(avctx, p, s->alpha_data,
- s->alpha_data_size);
if (ret < 0)
-return ret;
+av_log(avctx, AV_LOG_ERROR, "Failed to decode rgb\n");
+
+aret = vp8_lossy_decode_alpha(avctx, p, s->alpha_data,
+ s->alpha_data_size);
+if (aret < 0)
+av_log(avctx, AV_LOG_ERROR, "Failed to decode alpha\n");
+
+if ((ret < 0)&&(aret < 0))
+return AVERROR_INVALIDDATA;
}
return ret;
}
--
1.9.3 (Apple Git-50)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec : add psd image file decoder
On 7/9/2016 12:29 PM, Martin Vignali wrote:
> Hello,
>
> In attach patch to add decoding of .psd file (Photoshop file).
>
> PSD file can contain merge layers data at the end of the file (Image Data
> Section)
>
> This patch add support for this kind of files, using uncompress data Image
> Data Section
>
> Support Gray/A, and RGB/A with 8b or 16 bits by channel.
>
>
> Samples can be found here :
>
> https://we.tl/GK6yQhUV8j
>
>
> Comments welcome
>
> Martin
>
>
> 0001-libavcodec-add-decoder-for-.psd-image-file.patch
>
>
> From a4b9c1373cc62d1bb38997704a924ecfe78ee4b4 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sat, 9 Jul 2016 15:59:41 +0200
> Subject: [PATCH] libavcodec : add decoder for .psd image file. Decode the
> Image Data Section (who contain merge picture) Support RGB/A and Grayscale/A
> in 8bits and 16 bits by channel. Only support now, uncompress Image Data
> Section.
>
> ---
> Changelog| 2 +-
> doc/general.texi | 2 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h | 1 +
> libavcodec/codec_desc.c | 7 ++
> libavcodec/psd.c | 310
> +++
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/img2.c | 1 +
> libavformat/img2dec.c| 10 ++
> libavformat/isom.c | 1 +
> 12 files changed, 337 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/psd.c
>
[...]
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index 9d6796f..a6a2148 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -821,6 +821,15 @@ static int png_probe(AVProbeData *p)
> return 0;
> }
>
> +static int psd_probe(AVProbeData *p)
> +{
> +const uint8_t *b = p->buf;
> +
> +if (AV_RL32(b) == 1397768760)
if (AV_RL32(b) == MKTAG('S','P','B','8'))
> +return AVPROBE_SCORE_EXTENSION + 1;
> +return 0;
> +}
> +
> static int sgi_probe(AVProbeData *p)
> {
> const uint8_t *b = p->buf;
> @@ -946,6 +955,7 @@ IMAGEAUTO_DEMUXER(pgmyuv, AV_CODEC_ID_PGMYUV)
> IMAGEAUTO_DEMUXER(pictor, AV_CODEC_ID_PICTOR)
> IMAGEAUTO_DEMUXER(png, AV_CODEC_ID_PNG)
> IMAGEAUTO_DEMUXER(ppm, AV_CODEC_ID_PPM)
> +IMAGEAUTO_DEMUXER(psd, AV_CODEC_ID_PSD)
> IMAGEAUTO_DEMUXER(qdraw, AV_CODEC_ID_QDRAW)
> IMAGEAUTO_DEMUXER(sgi, AV_CODEC_ID_SGI)
> IMAGEAUTO_DEMUXER(sunrast, AV_CODEC_ID_SUNRAST)
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index d412f06..75fbf2f 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -254,6 +254,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
> { AV_CODEC_ID_SGI, MKTAG('s', 'g', 'i', ' ') }, /* SGI */
> { AV_CODEC_ID_DPX, MKTAG('d', 'p', 'x', ' ') }, /* DPX */
> { AV_CODEC_ID_EXR, MKTAG('e', 'x', 'r', ' ') }, /* OpenEXR */
> +{ AV_CODEC_ID_EXR, MKTAG('p', 's', 'd', ' ') }, /* Psd */
You probably meant to use AV_CODEC_ID_PSD here.
>
> { AV_CODEC_ID_PRORES, MKTAG('a', 'p', 'c', 'h') }, /* Apple ProRes 422
> High Quality */
> { AV_CODEC_ID_PRORES, MKTAG('a', 'p', 'c', 'n') }, /* Apple ProRes 422
> Standard Definition */
> -- 1.9.3 (Apple Git-50)
>
Wait for a real review before resending the patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv4] lavf: add libopenmpt demuxer
Josh de Kock itanimul.li> writes: > On Thu, Jul 7, 2016, at 10:47 AM, Carl Eugen Hoyos wrote: > > Josh de Kock itanimul.li> writes: > > > > > +ret = openmpt_could_open_propability( > > > > I don't know anything about openmpt but what was > > wrong with the original probe function sent by you? > > It probed one format, and not very well, compared to a lot > more formats probed by openmpt's. Could you for the time being send a patch without a probe function? (Only file extension probing.) That would still allow to apply the patch and to choose the demuxer explicitely at runtime. Would that be a solution to consider how to allow probing? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec : add psd image file decoder
Martin Vignali gmail.com> writes:
> psd_probe()
Please also test for version (and color mode) and increase
the probe score / if easily possible, don't detect things
that are immediately rejected by the decoder.
And don't remove the empty line from Changelog...
> +{ AV_CODEC_ID_EXR, MKTAG('p', 's', 'd', ' ') }, /* Psd */
What produces such files?
Thank you!
Please wait for a real review, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec : add psd image file decoder
On 7/9/2016 1:09 PM, James Almer wrote:
> On 7/9/2016 12:29 PM, Martin Vignali wrote:
>> +static int psd_probe(AVProbeData *p)
>> +{
>> +const uint8_t *b = p->buf;
>> +
>> +if (AV_RL32(b) == 1397768760)
>
> if (AV_RL32(b) == MKTAG('S','P','B','8'))
>
MKTAG('8','B','P','S'), sorry.
Also, this is mostly cosmetic, so if you prefer consistency write the
value in hex like in the other probe functions instead of using this
macro.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec : add psd image file decoder
On 7/9/16, Martin Vignali wrote: > Hello, > > In attach patch to add decoding of .psd file (Photoshop file). > > PSD file can contain merge layers data at the end of the file (Image Data > Section) > > This patch add support for this kind of files, using uncompress data Image > Data Section > > Support Gray/A, and RGB/A with 8b or 16 bits by channel. > > > Samples can be found here : > > https://we.tl/GK6yQhUV8j > > > Comments welcome > > Martin > Switch cases should be aligned with switch, like in rest of ffmpeg codebase. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec : add psd image file decoder
On 9 July 2016 at 16:29, Martin Vignali wrote: > Hello, > > In attach patch to add decoding of .psd file (Photoshop file). > > PSD file can contain merge layers data at the end of the file (Image Data > Section) > > This patch add support for this kind of files, using uncompress data Image > Data Section > > Support Gray/A, and RGB/A with 8b or 16 bits by channel. > > > Samples can be found here : > > https://we.tl/GK6yQhUV8j > > > Comments welcome > > Martin > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > This has the potential to turn into the shittiest thing in libavcodec. PSD is a notoriously horrible format and I believe code needed to read and render it belongs outside of libavcodec. Not to mention that close to 90% of the features it has are unsupported by the framework, be it vectors, the colorspaces, layers, etc. The decoder's also pretty raw and only supports uncompressed images, with every other mode currently unsupported, giving the deceptive idea it's a simple decoder for a simple format. A decoder which can open a very small part of all psd files floating around isn't a very useful one. There is simply no simple way to expose all the quirks of the format in a nice way to libavcodec, given that this decoder can be potentially as complex and bad as photoshop. Please make this a separate library or a program, you don't even need any framework features since it's a simple bytestream. In case you need the testament of someone who's done the work already take a read at this: https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m#L108-L136 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec : add psd image file decoder
On 7/9/16, Rostislav Pehlivanov wrote: > On 9 July 2016 at 16:29, Martin Vignali wrote: > >> Hello, >> >> In attach patch to add decoding of .psd file (Photoshop file). >> >> PSD file can contain merge layers data at the end of the file (Image Data >> Section) >> >> This patch add support for this kind of files, using uncompress data Image >> Data Section >> >> Support Gray/A, and RGB/A with 8b or 16 bits by channel. >> >> >> Samples can be found here : >> >> https://we.tl/GK6yQhUV8j >> >> >> Comments welcome >> >> Martin >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > This has the potential to turn into the shittiest thing in libavcodec. PSD > is a notoriously horrible format and I believe code needed to read and > render it belongs outside of libavcodec. Not to mention that close to 90% > of the features it has are unsupported by the framework, be it vectors, the > colorspaces, layers, etc. The decoder's also pretty raw and only supports > uncompressed images, with every other mode currently unsupported, giving > the deceptive idea it's a simple decoder for a simple format. A decoder > which can open a very small part of all psd files floating around isn't a > very useful one. Why? Neither exr decoder was good, at beginning it supported only raw. > There is simply no simple way to expose all the quirks of the format in a > nice way to libavcodec, given that this decoder can be potentially as > complex and bad as photoshop. Please make this a separate library or a > program, you don't even need any framework features since it's a simple > bytestream. > > In case you need the testament of someone who's done the work already take > a read at this: > https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m#L108-L136 > ___ > 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] libavdevice/decklink: advanced options for selecting an input connection
Am 03.07.2016 um 18:22 schrieb Michael Niedermayer: >>> Also it adds list_vinputs and list_ainputs >> There is no attachment? > there seems to be a pull req on github about this > https://github.com/FFmpeg/FFmpeg/pull/212 Doesnt really matter anymore, those new functionalities are also implemented in the patches from Marton Balint. Matthias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] decklink: fix: set fps on video stream
Provide the stream with the correct fps information when capturing.
Signed-off-by: Matthias Hunstock
---
libavdevice/decklink_dec.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index fcb024e..c25579a 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -571,6 +571,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
st->time_base.den = ctx->bmd_tb_den;
st->time_base.num = ctx->bmd_tb_num;
+av_stream_set_r_frame_rate(st, av_make_q(st->time_base.num,
st->time_base.den));
if (cctx->v210) {
st->codecpar->codec_id= AV_CODEC_ID_V210;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] decklink: enhancement: mode selection with AVRational
When finding a video mode based on frame size and frame rate,
use AVRational methods instead of simple comparison. Also fixes
a swap of num and den and add runtime debug level information.
Signed-off-by: Matthias Hunstock
---
libavdevice/decklink_common.cpp | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index b0f245f..fcdbef8 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -143,6 +143,9 @@ int ff_decklink_set_format(AVFormatContext *avctx,
int i = 1;
HRESULT res;
+av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d,
frame timing %d/%d, direction %d, mode number %d\n",
+width, height, tb_num, tb_den, direction, num);
+
if (ctx->duplex_mode) {
DECKLINK_BOOL duplex_supported = false;
@@ -178,29 +181,26 @@ int ff_decklink_set_format(AVFormatContext *avctx,
return AVERROR(EIO);
}
-
-if (tb_num == 1) {
-tb_num *= 1000;
-tb_den *= 1000;
-}
+AVRational target_tb = av_make_q(tb_num, tb_den);
ctx->bmd_mode = bmdModeUnknown;
while ((ctx->bmd_mode == bmdModeUnknown) && itermode->Next(&mode) == S_OK)
{
-BMDTimeValue bmd_tb_num, bmd_tb_den;
+BMDTimeValue bmd_tb_duration, bmd_tb_timescale;
int bmd_width = mode->GetWidth();
int bmd_height = mode->GetHeight();
-mode->GetFrameRate(&bmd_tb_num, &bmd_tb_den);
+mode->GetFrameRate(&bmd_tb_duration, &bmd_tb_timescale);
+AVRational mode_tb = av_make_q(bmd_tb_timescale, bmd_tb_duration);
if ((bmd_width == width && bmd_height == height &&
-bmd_tb_num == tb_num && bmd_tb_den == tb_den) || i == num) {
+(!av_cmp_q(mode_tb, target_tb))) || i == num) {
ctx->bmd_mode = mode->GetDisplayMode();
ctx->bmd_width = bmd_width;
ctx->bmd_height = bmd_height;
-ctx->bmd_tb_den = bmd_tb_den;
-ctx->bmd_tb_num = bmd_tb_num;
+ctx->bmd_tb_den = bmd_tb_duration;
+ctx->bmd_tb_num = bmd_tb_timescale;
ctx->bmd_field_dominance = mode->GetFieldDominance();
av_log(avctx, AV_LOG_INFO, "Found Decklink mode %d x %d with rate
%.2f%s\n",
-bmd_width, bmd_height, (float)bmd_tb_den/(float)bmd_tb_num,
+bmd_width, bmd_height, av_q2d(mode_tb),
(ctx->bmd_field_dominance==bmdLowerFieldFirst ||
ctx->bmd_field_dominance==bmdUpperFieldFirst)?"(i)":"");
}
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec : add psd image file decoder
Thanks for your comments
@James Almer : MKTAG, is maybe more comprehensive, than the 32i value.
Modify locally
@Carl Eugen Hoyos :
> > +{ AV_CODEC_ID_EXR, MKTAG('p', 's', 'd', ' ') }, /* Psd */
>
> What produces such files?
>
I think i do a mistake here. Remove locally
> psd_probe()
>
> Please also test for version (and color mode) and increase
> the probe score / if easily possible, don't detect things
> that are immediately rejected by the decoder.
>
> And don't remove the empty line from Changelog...
>
>
i will modify the probe function.
@Paul B Mahol :
Correct locally
@Rostislav Pehlivanov :
> This has the potential to turn into the shittiest thing in libavcodec. PSD
> is a notoriously horrible format and I believe code needed to read and
> render it belongs outside of libavcodec. Not to mention that close to 90%
> of the features it has are unsupported by the framework, be it vectors, the
> colorspaces, layers, etc. The decoder's also pretty raw and only supports
> uncompressed images, with every other mode currently unsupported, giving
> the deceptive idea it's a simple decoder for a simple format. A decoder
> which can open a very small part of all psd files floating around isn't a
> very useful one.
> There is simply no simple way to expose all the quirks of the format in a
> nice way to libavcodec, given that this decoder can be potentially as
> complex and bad as photoshop. Please make this a separate library or a
> program, you don't even need any framework features since it's a simple
> bytestream.
>
> In case you need the testament of someone who's done the work already take
> a read at this:
> https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m#L108-L136
> ___
>
>
You're right, this is a very complex file format, with lot of features.
But i disagree, with the idea, that this decoder have no interest. The
"useful question", highly depend of the point of view.
I write this decoder, because i sometime need to convert PSD image sequence
to video, or need to get a quick preview of a PSD file, without open
Photoshop.
This decoder for now, decode file created using "Maximize Compatibity"
option of Adobe Photoshop software (this option is recommand by Adobe for
compatibilty with other software).
I plan to add RLE decoding, in a future patch (After effects for example
use it for PSD sequence).
So i think a decoder, without all the feature of the file format, can be
useful.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On 5/8/2016 4:00 AM, Reimar Döffinger wrote: > On 07.05.2016, at 02:56, Hendrik Leppkes wrote: > >> On Sat, May 7, 2016 at 2:02 AM, James Almer wrote: >>> On 5/6/2016 8:48 PM, Timothy Gu wrote: On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote: > > Just to document it, this has caused build breakage in various > scenarios, even in GCC 5.3 (6.1 not tested). > > The latest reported on IRC just today here: > libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': > libavcodec/sbrdsp.c:47:13: internal compiler error: in > vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 > static void sbr_neg_odd_64_c(float *x) > > There are various other cases which usually involve inline asm when > building with SIMD (ie. --cpu=host) and the optimizer running out of > registers, for example: > libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible > constraints > > IMHO this feature is not quite ready to be enabled unconditionally in > our code base, and we should re-evaluate this change. I don't have a problem with reverting this commit, but as James mentioned I do prefer the bug to be reported to GCC if possible. Have you also considered the possibility to enable this feature only if inline assembly is not enabled? >>> >>> Nobody disables inline asm when using GCC, so it'd be the same as removing >>> tree >>> vectorization altogether to begin with. >>> >>> This feature gives some nice speed boost on parts of the code that don't >>> have >>> hand written asm, so I'd very much rather keep it and try to get GCC to fix >>> bugs >>> on their compilers. >> >> Fixing would be nice of course, but it should then only be enabled in >> versions we know do not have problems, which is none right now. > > I had to disable this option for some unrelated projects at work, too, since > even with 5.2.1 (didn't retest with later) it miscompiled multiple pieces of > code. > And that even on x86_64. > I really think there still is an EXTREMELY high risk that it still will > frequently cause miscompiled code. > Unless we actually get above 90% code coverage in FATE I just don't think > that is a reasonable option for us to ever enable in builds for users! > Even for developer builds I have some doubts the speedup we might get at some > point is worth the time wasted debugging. > If we have code parts with a significant speed advantage, enabling it only > for those and adding targeted tests would be an option. > It also avoids the cases where this option can cause some (generally very > minor) slowdown due to vectorizing loops where it's not worth it. [14:31:33] https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116 looks like some projects using ffmpeg are disabling tree vectorization to fix crashes [14:33:03] guess we should disable it for good. it's brought more problems than potential performance improvements [14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows [14:35:27] <@nevcairiel> because inline asm and registers [14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher) [14:36:05] yeah, happened to me [14:36:22] -march=haswell on mingw x86_32 = cabac fails to compile [14:37:38] also with 5.x Not a lot of arguments remain to keep this in place, so i'll revert this change soon if nobody objects. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] latest ffmpeg git master build is broken on osx powerpc
adding jingyu (author of 311a953c76081fca99b872629d248f9d69ebc0c3) to CC
On Sat, Jul 09, 2016 at 07:47:26AM -0600, Pavel Koshevoy wrote:
> Hi,
>
> PowerPC build on OSX 10.5 (Leopard) is broken:
>
> $ gcc --version
> powerpc-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> /nfs/scratch/Developer/ffmpeg-git-src/configure
> --prefix=/Developer/ppc --disable-debug --disable-shared
> --enable-static --enable-swscale --enable-avfilter
> --enable-libmp3lame --enable-libvorbis --enable-libopus
> --enable-libtheora --enable-libschroedinger --enable-libopenjpeg
> --enable-libmodplug --enable-libvpx --enable-libspeex
> --enable-pthreads --enable-gpl --enable-version3
> --enable-libopencore-amrnb --enable-libopencore-amrwb
> --enable-postproc --enable-libx264 --enable-libxvid --enable-libass
> --enable-gnutls --enable-runtime-cpudetect
> --extra-cflags=-I/opt/local/include
> --extra-ldflags='-headerpad_max_install_names -L/opt/local/lib'
> --disable-audiotoolbox --disable-videotoolbox --disable-sdl
> --disable-filter=coreimagesrc --disable-filter=coreimage
>
> $ make
> ASlibavcodec/ppc/fft_altivec.o
> {standard input}:257:Parameter syntax error (parameter 3)
> {standard input}:264:Parameter syntax error (parameter 3)
> {standard input}:265:Parameter syntax error (parameter 3)
> {standard input}:271:Parameter syntax error (parameter 3)
> {standard input}:278:Parameter syntax error (parameter 3)
> {standard input}:279:Parameter syntax error (parameter 3)
> {standard input}:285:Parameter syntax error (parameter 3)
> {standard input}:292:Parameter syntax error (parameter 3)
> {standard input}:293:Parameter syntax error (parameter 3)
> {standard input}:299:Parameter syntax error (parameter 3)
> {standard input}:306:Parameter syntax error (parameter 3)
> {standard input}:307:Parameter syntax error (parameter 3)
> {standard input}:313:Parameter syntax error (parameter 3)
> {standard input}:320:Parameter syntax error (parameter 3)
> {standard input}:321:Parameter syntax error (parameter 3)
> {standard input}:327:Parameter syntax error (parameter 3)
> {standard input}:334:Parameter syntax error (parameter 3)
> {standard input}:335:Parameter syntax error (parameter 3)
> {standard input}:341:Parameter syntax error (parameter 3)
> {standard input}:348:Parameter syntax error (parameter 3)
> {standard input}:349:Parameter syntax error (parameter 3)
> {standard input}:355:Parameter syntax error (parameter 3)
> {standard input}:362:Parameter syntax error (parameter 3)
> {standard input}:363:Parameter syntax error (parameter 3)
> {standard input}:369:Parameter syntax error (parameter 3)
> {standard input}:378:Parameter syntax error (parameter 3)
> {standard input}:379:Parameter syntax error (parameter 3)
> {standard input}:385:Parameter syntax error (parameter 3)
> {standard input}:394:Parameter syntax error (parameter 3)
> {standard input}:395:Parameter syntax error (parameter 3)
> {standard input}:401:Parameter syntax error (parameter 3)
> {standard input}:408:Parameter syntax error (parameter 3)
> {standard input}:409:Parameter syntax error (parameter 3)
> {standard input}:415:Parameter syntax error (parameter 3)
> {standard input}:422:Parameter syntax error (parameter 3)
> {standard input}:423:Parameter syntax error (parameter 3)
> {standard input}:433:Parameter syntax error (parameter 3)
> {standard input}:434:Parameter syntax error (parameter 3)
> {standard input}:464:Parameter syntax error (parameter 3)
> {standard input}:465:Parameter syntax error (parameter 2)
> {standard input}:521:Parameter syntax error (parameter 3)
> {standard input}:550:Parameter syntax error (parameter 3)
> {standard input}:552:Parameter syntax error (parameter 3)
> {standard input}:553:Parameter syntax error (parameter 3)
> {standard input}:799:Parameter syntax error (parameter 3)
> {standard input}:806:Parameter syntax error (parameter 3)
> {standard input}:807:Parameter syntax error (parameter 3)
> {standard input}:813:Parameter syntax error (parameter 3)
> {standard input}:820:Parameter syntax error (parameter 3)
> {standard input}:821:Parameter syntax error (parameter 3)
> {standard input}:827:Parameter syntax error (parameter 3)
> {standard input}:834:Parameter syntax error (parameter 3)
> {standard input}:835:Parameter syntax error (parameter 3)
> {standard input}:841:Parameter syntax error (parameter 3)
> {standard input}:848:Parameter syntax error (parameter 3)
> {standard input}:849:Parameter syntax error (parameter 3)
> {standard input}:855:Parameter syntax error (parameter 3)
> {standard input}:862:Parameter syntax error (parameter 3)
> {standard input}:863:Parameter syntax error (parameter 3)
> {standard input}:869:Parameter syntax error (parameter 3)
> {standard input}:876:Parameter syntax error (parameter 3)
>
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
Hi, On Sat, Jul 9, 2016 at 1:38 PM, James Almer wrote: > On 5/8/2016 4:00 AM, Reimar Döffinger wrote: > > On 07.05.2016, at 02:56, Hendrik Leppkes wrote: > > > >> On Sat, May 7, 2016 at 2:02 AM, James Almer wrote: > >>> On 5/6/2016 8:48 PM, Timothy Gu wrote: > On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote: > > > > Just to document it, this has caused build breakage in various > > scenarios, even in GCC 5.3 (6.1 not tested). > > > > The latest reported on IRC just today here: > > libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c': > > libavcodec/sbrdsp.c:47:13: internal compiler error: in > > vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 > > static void sbr_neg_odd_64_c(float *x) > > > > There are various other cases which usually involve inline asm when > > building with SIMD (ie. --cpu=host) and the optimizer running out of > > registers, for example: > > libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible > constraints > > > > IMHO this feature is not quite ready to be enabled unconditionally in > > our code base, and we should re-evaluate this change. > > I don't have a problem with reverting this commit, but as James > mentioned I do > prefer the bug to be reported to GCC if possible. > > Have you also considered the possibility to enable this feature only > if inline > assembly is not enabled? > >>> > >>> Nobody disables inline asm when using GCC, so it'd be the same as > removing tree > >>> vectorization altogether to begin with. > >>> > >>> This feature gives some nice speed boost on parts of the code that > don't have > >>> hand written asm, so I'd very much rather keep it and try to get GCC > to fix bugs > >>> on their compilers. > >> > >> Fixing would be nice of course, but it should then only be enabled in > >> versions we know do not have problems, which is none right now. > > > > I had to disable this option for some unrelated projects at work, too, > since even with 5.2.1 (didn't retest with later) it miscompiled multiple > pieces of code. > > And that even on x86_64. > > I really think there still is an EXTREMELY high risk that it still will > frequently cause miscompiled code. > > Unless we actually get above 90% code coverage in FATE I just don't > think that is a reasonable option for us to ever enable in builds for users! > > Even for developer builds I have some doubts the speedup we might get at > some point is worth the time wasted debugging. > > If we have code parts with a significant speed advantage, enabling it > only for those and adding targeted tests would be an option. > > It also avoids the cases where this option can cause some (generally > very minor) slowdown due to vectorizing loops where it's not worth it. > > [14:31:33] > https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116 > looks like some projects using ffmpeg are disabling tree vectorization to > fix crashes > [14:33:03] guess we should disable it for good. it's brought > more problems than potential performance improvements > [14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows > [14:35:27] <@nevcairiel> because inline asm and registers > [14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher) > [14:36:05] yeah, happened to me > [14:36:22] -march=haswell on mingw x86_32 = cabac fails to > compile > [14:37:38] also with 5.x > > Not a lot of arguments remain to keep this in place, so i'll revert this > change soon if nobody objects. OK. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On 7/9/2016 3:28 PM, Ronald S. Bultje wrote: > Hi, > > On Sat, Jul 9, 2016 at 1:38 PM, James Almer wrote: >> [14:31:33] >> https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116 >> looks like some projects using ffmpeg are disabling tree vectorization to >> fix crashes >> [14:33:03] guess we should disable it for good. it's brought >> more problems than potential performance improvements >> [14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows >> [14:35:27] <@nevcairiel> because inline asm and registers >> [14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher) >> [14:36:05] yeah, happened to me >> [14:36:22] -march=haswell on mingw x86_32 = cabac fails to >> compile >> [14:37:38] also with 5.x >> >> Not a lot of arguments remain to keep this in place, so i'll revert this >> change soon if nobody objects. > > > OK. > > Ronald Pushed. Should i backport this to the 3.1 and 3.0 branches? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec : add psd image file decoder
On 09.07.2016 19:37, Martin Vignali wrote: You're right, this is a very complex file format, with lot of features. indeed.. But i disagree, with the idea, that this decoder have no interest. The "useful question", highly depend of the point of view. I write this decoder, because i sometime need to convert PSD image sequence to video, or need to get a quick preview of a PSD file, without open Photoshop. This decoder for now, decode file created using "Maximize Compatibity" option of Adobe Photoshop software (this option is recommand by Adobe for compatibilty with other software). I plan to add RLE decoding, in a future patch (After effects for example use it for PSD sequence). So i think a decoder, without all the feature of the file format, can be useful. Yes, don't stop your work. It might be only a starting point for PSD support - but, apparently, it is a start and it's not the worst one. Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On Sat, Jul 09, 2016 at 04:07:14PM -0300, James Almer wrote: > On 7/9/2016 3:28 PM, Ronald S. Bultje wrote: > > Hi, > > > > On Sat, Jul 9, 2016 at 1:38 PM, James Almer wrote: > >> [14:31:33] > >> https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116 > >> looks like some projects using ffmpeg are disabling tree vectorization to > >> fix crashes > >> [14:33:03] guess we should disable it for good. it's brought > >> more problems than potential performance improvements > >> [14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows > >> [14:35:27] <@nevcairiel> because inline asm and registers > >> [14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher) > >> [14:36:05] yeah, happened to me > >> [14:36:22] -march=haswell on mingw x86_32 = cabac fails to > >> compile > >> [14:37:38] also with 5.x > >> > >> Not a lot of arguments remain to keep this in place, so i'll revert this > >> change soon if nobody objects. > > > > > > OK. > > > > Ronald > > Pushed. Should i backport this to the 3.1 and 3.0 branches? if they are affected, yes when in doubt yes 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] Changed metadata print option to accept general urls
On 7/8/16, sami.h...@gmail.com wrote: > From: Sami Hult > > This is an - once again - updated patch, that uses avio_write instead > of avio_puts to stream clean text output without null characters. Works > now for me as intended. > > Changes metadata filter to accept general urls as file argument without > breaking former behaviour. As a byproduct, it also allows for writing to > file "-" if specified as "file:-". > > Example: > > ffmpeg -i test.wav -filter_complex > "silencedetect=n=-40dB:d=0.1,ametadata=mode=print:file='pipe\:4'" -f null > > probably ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On 7/9/2016 4:56 PM, Michael Niedermayer wrote: > On Sat, Jul 09, 2016 at 04:07:14PM -0300, James Almer wrote: >> On 7/9/2016 3:28 PM, Ronald S. Bultje wrote: >>> Hi, >>> >>> On Sat, Jul 9, 2016 at 1:38 PM, James Almer wrote: [14:31:33] https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116 looks like some projects using ffmpeg are disabling tree vectorization to fix crashes [14:33:03] guess we should disable it for good. it's brought more problems than potential performance improvements [14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows [14:35:27] <@nevcairiel> because inline asm and registers [14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher) [14:36:05] yeah, happened to me [14:36:22] -march=haswell on mingw x86_32 = cabac fails to compile [14:37:38] also with 5.x Not a lot of arguments remain to keep this in place, so i'll revert this change soon if nobody objects. >>> >>> >>> OK. >>> >>> Ronald >> >> Pushed. Should i backport this to the 3.1 and 3.0 branches? > > if they are affected, yes They are, yes. > when in doubt yes I prefer to ask first :P Backported. > > thx > > [...] > > > > ___ > 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] Changed metadata print option to accept general urls
On Sat, Jul 09, 2016 at 10:16:20PM +0200, Paul B Mahol wrote: > On 7/8/16, sami.h...@gmail.com wrote: > > From: Sami Hult > > > > This is an - once again - updated patch, that uses avio_write instead > > of avio_puts to stream clean text output without null characters. Works > > now for me as intended. > > > > Changes metadata filter to accept general urls as file argument without > > breaking former behaviour. As a byproduct, it also allows for writing to > > file "-" if specified as "file:-". > > > > Example: > > > > ffmpeg -i test.wav -filter_complex > > "silencedetect=n=-40dB:d=0.1,ametadata=mode=print:file='pipe\:4'" -f null > > > > > > probably ok applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vaapi_encode_h264: Use av_clip_uintp2()
On Sun, Jul 03, 2016 at 10:41:20PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/vaapi_encode_h264.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] decklink: fix: set fps on video stream
On Sat, 9 Jul 2016, Matthias Hunstock wrote: Provide the stream with the correct fps information when capturing. Signed-off-by: Matthias Hunstock --- libavdevice/decklink_dec.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp index fcb024e..c25579a 100644 --- a/libavdevice/decklink_dec.cpp +++ b/libavdevice/decklink_dec.cpp @@ -571,6 +571,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx) st->time_base.den = ctx->bmd_tb_den; st->time_base.num = ctx->bmd_tb_num; +av_stream_set_r_frame_rate(st, av_make_q(st->time_base.num, st->time_base.den)); Aren't the frame rate supposed to be 1/time_base? Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] decklink: enhancement: mode selection with AVRational
On Sat, 9 Jul 2016, Matthias Hunstock wrote: When finding a video mode based on frame size and frame rate, use AVRational methods instead of simple comparison. Also fixes a swap of num and den and add runtime debug level information. I am a bit against renaming num and den to the names in the BlackMagic SDK. They are semantically equivalent to our frame rate num/den, and the reason for swapping them is to get the time base instead of frame rate. Or am I missing something here? Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
