Re: [FFmpeg-devel] GSoC '15 Introduction
On 3/8/15, compn te...@mi.rr.com wrote: On Sat, 7 Mar 2015 20:24:16 +0200 Ilinca Andrei andrei.ilinc...@gmail.com wrote: Hello! welcome! *Why directshow digital video capture ?* Simply because It sounds really interesting and entertaining. I have some experience using Matlab and Simulink for converting from time-domain to frequency-domain and back, Bode Nyquist Diagrams and I have basic knowledge about how filters work and how they can be used and implemented. I've done some research about video capturing in DirectShow , mainly on this link https://msdn.microsoft.com/en-us/library/windows/desktop/dd373406%28v=vs.85%29.aspx, and I believe this project suits me the best. dont forget you can check other open source projects (videolan, virtualdub etc) and maybe copy how they do dshow video capture. Just don't copy and paste, since the VLC stuff [at least] is straight GPL and we'll need this one to be LGPL [so basically base it off of the MSDN not off the VLC code base, that's what I do]. Look forward to corresponding more through private email on the issue with you. -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/8] ffmdec: break infinite resync loop
On 09.03.2015 13:59, Michael Niedermayer wrote:
i was thinking more about limiting the backward seek before resync
to the last resync position +1 if there was a previous resync
so that resync which moves forward could not end before. This would
avoid the failure and allow the demuxer to continue, or at least thats
the idea
I see, new patch attached.
The +1 is not necessary, because it always reads the PACKET_ID field
before resyncing.
Best regards,
Andreas
From 6bcd1b4a906e2da39f6361db19826a337ac5a745 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun andreas.cadhal...@googlemail.com
Date: Mon, 9 Mar 2015 14:59:44 +0100
Subject: [PATCH] ffmdec: limit the backward seek to the last resync position
If resyncing leads to the same position as previously, it will again
lead to a resync attempt, resulting in an infinite loop.
Thus don't seek back beyond the last syncpoint.
Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
---
libavformat/ffmdec.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/ffmdec.c b/libavformat/ffmdec.c
index fc43668..ec91b6f 100644
--- a/libavformat/ffmdec.c
+++ b/libavformat/ffmdec.c
@@ -79,6 +79,7 @@ static int ffm_read_data(AVFormatContext *s,
FFMContext *ffm = s-priv_data;
AVIOContext *pb = s-pb;
int len, fill_size, size1, frame_offset, id;
+int64_t last_pos = -1;
size1 = size;
while (size 0) {
@@ -98,9 +99,11 @@ static int ffm_read_data(AVFormatContext *s,
avio_seek(pb, tell, SEEK_SET);
}
id = avio_rb16(pb); /* PACKET_ID */
-if (id != PACKET_ID)
+if (id != PACKET_ID) {
if (ffm_resync(s, id) 0)
return -1;
+last_pos = avio_tell(pb);
+}
fill_size = avio_rb16(pb);
ffm-dts = avio_rb64(pb);
frame_offset = avio_rb16(pb);
@@ -114,7 +117,9 @@ static int ffm_read_data(AVFormatContext *s,
if (!frame_offset) {
/* This packet has no frame headers in it */
if (avio_tell(pb) = ffm-packet_size * 3LL) {
-avio_seek(pb, -ffm-packet_size * 2LL, SEEK_CUR);
+int64_t seekback = FFMIN(ffm-packet_size * 2LL, avio_tell(pb) - last_pos);
+seekback = FFMAX(seekback, 0);
+avio_seek(pb, -seekback, SEEK_CUR);
goto retry_read;
}
/* This is bad, we cannot find a valid frame header */
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/options_table: remove extradata_size from the AVOptions table
On 09.03.2015 03:42, Michael Niedermayer wrote:
allowing access to the size but not the extradata itself is not useful
and could lead to potential problems if writing happens through this field
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/options_table.h |1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 442b212..a906864 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -103,7 +103,6 @@ static const AVOption avcodec_options[] = {
{hex, hex motion estimation, 0, AV_OPT_TYPE_CONST, {.i64 = ME_HEX }, INT_MIN,
INT_MAX, V|E, me_method },
{umh, umh motion estimation, 0, AV_OPT_TYPE_CONST, {.i64 = ME_UMH }, INT_MIN,
INT_MAX, V|E, me_method },
{iter, iter motion estimation, 0, AV_OPT_TYPE_CONST, {.i64 = ME_ITER }, INT_MIN,
INT_MAX, V|E, me_method },
-{extradata_size, NULL, OFFSET(extradata_size), AV_OPT_TYPE_INT, {.i64 =
DEFAULT }, INT_MIN, INT_MAX},
{time_base, NULL, OFFSET(time_base), AV_OPT_TYPE_RATIONAL, {.dbl = 0},
INT_MIN, INT_MAX},
{g, set the group of picture (GOP) size, OFFSET(gop_size),
AV_OPT_TYPE_INT, {.i64 = 12 }, INT_MIN, INT_MAX, V|E},
{ar, set audio sampling rate (in Hz), OFFSET(sample_rate),
AV_OPT_TYPE_INT, {.i64 = DEFAULT }, 0, INT_MAX, A|D|E},
This looks very good, because it also fixes the ffm muxer to never
create files with extradata_size setting, but without extradata.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/8] ffmdec: don't return AVERROR(EAGAIN) from ffm_is_avail_data
On Mon, Mar 09, 2015 at 12:33:38PM +0100, Andreas Cadhalpun wrote: On 09.03.2015 03:56, Michael Niedermayer wrote: On Mon, Mar 09, 2015 at 12:05:01AM +0100, Andreas Cadhalpun wrote: Hi, if AVERROR(EAGAIN) is returned from ffm_is_avail_data it always causes an infinite EAGAIN loop. it should only loop until more data is written into the ffm file (this of course is not guranteed to ever happen) How should this work? If ffm_is_avail_data returns AVERROR(EAGAIN), this error is immediately forwarded to avformat_find_stream_info, which just tries reading a frame again, leading to ffm_read_packet, which first calls ffm_is_avail_data. Nothing changed the FFMContext, even if more data was written into the ffm file, so it returns AVERROR(EAGAIN) again. ffm_set_write_index() from ffserver could, this looks like ffm should export a clean API to be used by ffserver though also we really need regression tests for this ... CCing reynaldo as he probably knows the code better [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/srtenc: avoid segmentation fault when transcoding from SSA to SRT
On Sun, Mar 08, 2015 at 10:57:54AM +0100, Nicolas George wrote: L'octidi 18 ventôse, an CCXXIII, Clement Boesch a écrit : Try adding tags with no text maybe. You may also try ASS drawing mode, but FFmpeg probably doesn't do cray stuff about it. I tried various combinations, including empty styles, drawing mode, Picture, Comment, empty lines, missing comma, nothing produces a crash. Ok, I will remove the patch on my side, and chime in if I get the segfault again. Thanks for investigating, sorry for the noise. Regards. -- Gilles. pgpfq8h5xrkbH.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/8] ffmdec: don't return AVERROR(EAGAIN) from ffm_is_avail_data
On 09.03.2015 03:56, Michael Niedermayer wrote: On Mon, Mar 09, 2015 at 12:05:01AM +0100, Andreas Cadhalpun wrote: Hi, if AVERROR(EAGAIN) is returned from ffm_is_avail_data it always causes an infinite EAGAIN loop. it should only loop until more data is written into the ffm file (this of course is not guranteed to ever happen) How should this work? If ffm_is_avail_data returns AVERROR(EAGAIN), this error is immediately forwarded to avformat_find_stream_info, which just tries reading a frame again, leading to ffm_read_packet, which first calls ffm_is_avail_data. Nothing changed the FFMContext, even if more data was written into the ffm file, so it returns AVERROR(EAGAIN) again. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/8] ffmdec: initialize f_cprv, f_stvi and f_stau
On 09.03.2015 13:20, Lukasz Marek wrote: BTW, did you produced this malformed file using ffmpeg tools or just prevent theoretical case? I fuzzed a file created by ffmpeg. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 9 March 2015 13:34:24 CET, Hendrik Leppkes h.lepp...@gmail.com wrote: On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker fernetme...@online.de wrote: Reimar Döffinger Reimar.Doeffinger at gmx.de writes: Any reason to believe this patch causes it? Because I can't see how it would. Maybe it's just a bug with DXVA and multithreading in the HEVC code? Can you provide some more information like a stacktrace, possibly using a tool like DrMemory? I don't think the patch itself is the root cause of the issue, it just triggers it. get_format is called 4 times, something seems to get corrupted in opening our hw decoder. Do you have an explanation why it works with thread_safe_callbacks set to 1? I am wondering if hevc misses the multithreading fix done for other codecs: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html What do you think? I build the HEVC HWAccel support, and I consider frame-threading with hwaccel an abomination that should not be supported, so I didn't spend any time thinking about it. Honestly, there are several issues with MT+HWaccel in H264 as well, at least on Intel hardware, so I can only strongly urge everyone to not combine it. There is zero advantages, and only downsides! Only if you completely ignore the practical issues that anyone trying to use it will have. In many cases applications will not know whether hardware supports decoding the video until there get_format call. Worse, it can even change from supported to not supported. Do you expect everyone to disable multithreading just in case? Buffer the last n bits of data to be able to restart decoding? Hack things in get_format to trick FFmpeg into single threaded? All these have been tried and didn't work. (Kind of) supporting frame multithreading with hwaccel in contrast has worked and is convenient to our users. Unless you have a simple solution to these real world problems I very much think supporting it is a requirement. That is besides the fact that causing memory corruption it's not not supporting it but a bug. If it's not supported it should return an appropriate error. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/8] ffmdec: break infinite resync loop
On 09.03.2015 03:13, Michael Niedermayer wrote:
On Mon, Mar 09, 2015 at 12:04:13AM +0100, Andreas Cadhalpun wrote:
Hi,
some broken files can lead to an endless resync loop, which is
avoided by attached patch.
Best regards,
Andreas
ffmdec.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
048852d2d9b0c25157015a4befd76323fc4b2cc6
0005-ffmdec-break-infinite-resync-loop.patch
From 5682a0cafbaf9339352f3147ef7c494dea47 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun andreas.cadhal...@googlemail.com
Date: Sun, 8 Mar 2015 23:29:42 +0100
Subject: [PATCH 5/8] ffmdec: break infinite resync loop
If resyncing leads to the same position as previously, it will again
lead to a resync attempt, resulting in an infinite loop.
iam not sure this is sufficient and loops over more than 1 resync
point arent possible
maybe its better to never allow resync to start before
or at the previous resync point
I don't think this is possible, but it shouldn't hurt to change the
check to '='. This forces the syncpoints to always increase.
Best regards,
Andreas
From aa2d0cc852fe51734d9c9fd318dc94ec4af3970f Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun andreas.cadhal...@googlemail.com
Date: Sun, 8 Mar 2015 23:29:42 +0100
Subject: [PATCH 5/8] ffmdec: break infinite resync loop
If resyncing leads to the same position as previously, it will again
lead to a resync attempt, resulting in an infinite loop.
Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
---
libavformat/ffmdec.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavformat/ffmdec.c b/libavformat/ffmdec.c
index ee34e73..c54d1d6 100644
--- a/libavformat/ffmdec.c
+++ b/libavformat/ffmdec.c
@@ -82,6 +82,7 @@ static int ffm_read_data(AVFormatContext *s,
FFMContext *ffm = s-priv_data;
AVIOContext *pb = s-pb;
int len, fill_size, size1, frame_offset, id;
+int64_t last_pos = -1;
size1 = size;
while (size 0) {
@@ -101,9 +102,16 @@ static int ffm_read_data(AVFormatContext *s,
avio_seek(pb, tell, SEEK_SET);
}
id = avio_rb16(pb); /* PACKET_ID */
-if (id != PACKET_ID)
+if (id != PACKET_ID) {
if (ffm_resync(s, id) 0)
return -1;
+if (avio_tell(pb) = last_pos) {
+av_log(s, AV_LOG_ERROR,
+ breaking resync loop at pos %PRIx64\n, last_pos);
+return AVERROR_INVALIDDATA;
+}
+last_pos = avio_tell(pb);
+}
fill_size = avio_rb16(pb);
ffm-dts = avio_rb64(pb);
frame_offset = avio_rb16(pb);
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/8] ffmdec: initialize f_cprv, f_stvi and f_stau
On 9 March 2015 at 12:41, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: On 09.03.2015 10:53, Lukasz Marek wrote: In fact this is a bit wrong. COMM is guaranteed unless malformed file is parsed. These variables are dedicated to detect doubled sections. This patch allows them to occur twice in that case. So they should be initialized to 0. This patch doesn't change anything for valid files, it only prevents crashes with malformed files. For valid files, these variables are initialized to -1, then set to 0 in the COMM part of the switch. For invalid files, if another section comes before COMM, the counter is -1, thus e.g. 'if (f_stvi++)' is true and AVERROR(EINVAL) is returned. If they were initialized to 0, the check wouldn't trigger for malformed files, leading to crashes, because codec is not set. OK. BTW, did you produced this malformed file using ffmpeg tools or just prevent theoretical case? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/8] ffmdec: break infinite resync loop
On Mon, Mar 09, 2015 at 12:17:38PM +0100, Andreas Cadhalpun wrote: On 09.03.2015 03:13, Michael Niedermayer wrote: On Mon, Mar 09, 2015 at 12:04:13AM +0100, Andreas Cadhalpun wrote: Hi, some broken files can lead to an endless resync loop, which is avoided by attached patch. Best regards, Andreas ffmdec.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) 048852d2d9b0c25157015a4befd76323fc4b2cc6 0005-ffmdec-break-infinite-resync-loop.patch From 5682a0cafbaf9339352f3147ef7c494dea47 Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun andreas.cadhal...@googlemail.com Date: Sun, 8 Mar 2015 23:29:42 +0100 Subject: [PATCH 5/8] ffmdec: break infinite resync loop If resyncing leads to the same position as previously, it will again lead to a resync attempt, resulting in an infinite loop. iam not sure this is sufficient and loops over more than 1 resync point arent possible maybe its better to never allow resync to start before or at the previous resync point I don't think this is possible, but it shouldn't hurt to change the check to '='. This forces the syncpoints to always increase. i was thinking more about limiting the backward seek before resync to the last resync position +1 if there was a previous resync so that resync which moves forward could not end before. This would avoid the failure and allow the demuxer to continue, or at least thats the idea [...] -- 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] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker fernetme...@online.de wrote: Reimar Döffinger Reimar.Doeffinger at gmx.de writes: Any reason to believe this patch causes it? Because I can't see how it would. Maybe it's just a bug with DXVA and multithreading in the HEVC code? Can you provide some more information like a stacktrace, possibly using a tool like DrMemory? I don't think the patch itself is the root cause of the issue, it just triggers it. get_format is called 4 times, something seems to get corrupted in opening our hw decoder. Do you have an explanation why it works with thread_safe_callbacks set to 1? I am wondering if hevc misses the multithreading fix done for other codecs: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html What do you think? I build the HEVC HWAccel support, and I consider frame-threading with hwaccel an abomination that should not be supported, so I didn't spend any time thinking about it. Honestly, there are several issues with MT+HWaccel in H264 as well, at least on Intel hardware, so I can only strongly urge everyone to not combine it. There is zero advantages, and only downsides! - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/8] ffmdec: don't seek back at EOF
On Mon, Mar 09, 2015 at 12:27:15PM +0100, Andreas Cadhalpun wrote: On 09.03.2015 03:46, Michael Niedermayer wrote: On Mon, Mar 09, 2015 at 12:05:31AM +0100, Andreas Cadhalpun wrote: Hi, I'm not sure what the purpose of this avio_seek was, but it can result in an endless loop. Maybe it always does. ffm files can be written to and read at the same time, they can act as ring buffers so that data is written till the end and then continues at the begin i suspect this patch breaks that But if the file is not used as a ring buffer, it shouldn't play endlessly. yes Maybe one should add a check that the data at the beginning is actually different than the last time? maybe reynaldo can comment on how to best detect the ring buffer use i think it always involves ffserver currently unless iam missing something. It would of course make sense to allow other applications to use it too ... maybe a simple AVOption flag could be used to enable it, not sure [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- 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] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On 9 March 2015 13:34:24 CET, Hendrik Leppkes h.lepp...@gmail.com wrote: On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker fernetme...@online.de wrote: Reimar Döffinger Reimar.Doeffinger at gmx.de writes: Any reason to believe this patch causes it? Because I can't see how it would. Maybe it's just a bug with DXVA and multithreading in the HEVC code? Can you provide some more information like a stacktrace, possibly using a tool like DrMemory? I don't think the patch itself is the root cause of the issue, it just triggers it. get_format is called 4 times, something seems to get corrupted in opening our hw decoder. Do you have an explanation why it works with thread_safe_callbacks set to 1? I am wondering if hevc misses the multithreading fix done for other codecs: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html What do you think? I build the HEVC HWAccel support, and I consider frame-threading with hwaccel an abomination that should not be supported, so I didn't spend any time thinking about it. Honestly, there are several issues with MT+HWaccel in H264 as well, at least on Intel hardware, so I can only strongly urge everyone to not combine it. There is zero advantages, and only downsides! Only if you completely ignore the practical issues that anyone trying to use it will have. In many cases applications will not know whether hardware supports decoding the video until there get_format call. Worse, it can even change from supported to not supported. Do you expect everyone to disable multithreading just in case? Buffer the last n bits of data to be able to restart decoding? What I do is simply restart decoding with the packet that failed the hardware decoder. Don't need to buffer anything, you still have the AVPacket in question anyway. This allows a perfect and seamless change without requiring the hwaccel-mt hack. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Mon, Mar 09, 2015 at 04:53:52PM +0100, Michael Niedermayer wrote: On Mon, Mar 09, 2015 at 04:41:05PM +0100, Michael Niedermayer wrote: On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote: On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire klaussfre...@gmail.com wrote: On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer michae...@gmx.at wrote: i think its better to leave fuzz at a small value otherwise we would forget to update the target when it improves and then subsequent worsenings could be missed An updated version with that fixed. It's a bit tricky to squash commits with git format-patch, so if there's an issue with the patch just apply it with patch -p1, works that way (tried) Dang, forgot to attach the patch. Now truly attached. works on x86 but fails on mips: cpuflag 0 doesnt help, seems passing on ppc-qemu could try on actual ppc if needed the files look like this: mips: Duration: 00:00:06.89, bitrate: 57 kb/s Stream #0:0: Audio: aac (LC), 7350 Hz, stereo, fltp, 57 kb/s x86: Duration: 00:00:06.94, bitrate: 54 kb/s Stream #0:0: Audio: aac (LC), 7350 Hz, stereo, fltp, 54 kb/s ive attached the file genrated on mips-qemu [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle aac-s7350-encode.adts Description: Binary data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On Mon, Mar 9, 2015 at 3:28 PM, Hendrik Leppkes h.lepp...@gmail.com wrote: On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On 9 March 2015 13:34:24 CET, Hendrik Leppkes h.lepp...@gmail.com wrote: On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker fernetme...@online.de wrote: Reimar Döffinger Reimar.Doeffinger at gmx.de writes: Any reason to believe this patch causes it? Because I can't see how it would. Maybe it's just a bug with DXVA and multithreading in the HEVC code? Can you provide some more information like a stacktrace, possibly using a tool like DrMemory? I don't think the patch itself is the root cause of the issue, it just triggers it. get_format is called 4 times, something seems to get corrupted in opening our hw decoder. Do you have an explanation why it works with thread_safe_callbacks set to 1? I am wondering if hevc misses the multithreading fix done for other codecs: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html What do you think? I build the HEVC HWAccel support, and I consider frame-threading with hwaccel an abomination that should not be supported, so I didn't spend any time thinking about it. Honestly, there are several issues with MT+HWaccel in H264 as well, at least on Intel hardware, so I can only strongly urge everyone to not combine it. There is zero advantages, and only downsides! Only if you completely ignore the practical issues that anyone trying to use it will have. In many cases applications will not know whether hardware supports decoding the video until there get_format call. Worse, it can even change from supported to not supported. Do you expect everyone to disable multithreading just in case? Buffer the last n bits of data to be able to restart decoding? What I do is simply restart decoding with the packet that failed the hardware decoder. Don't need to buffer anything, you still have the AVPacket in question anyway. This allows a perfect and seamless change without requiring the hwaccel-mt hack. In the end it also comes down to this: On Intel hardware, MT+HWAccel (at least DXVA2) is fundamentally broken, and unfixable in the current design. The problem is that concurrent access to the decoded surfaces from different threads simply does not work, and while avcodec locks the decoding threads out that only ever one is working, it does not know when the user code accesses the surface, and there is no way to tell it either. So anytime a frame is used as a reference and you try to process it in user code at the same time, decoding fails. This can be reproduced with ffmpeg CLI even. This reason is enough to consider the entire concept flawed, imho. Of course avcodec shouldn't crash when you use it, but a patch to disallow this combination would never be accepted by yourself and some others that like this cheap (albeit wrong) method for fallback. So the only solution is to add the extra magic that makes it not crash, and someone should produce a patch for that if their setup can reproduce it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/8] ffmdec: break infinite resync loop
On Mon, Mar 09, 2015 at 03:14:50PM +0100, Andreas Cadhalpun wrote: On 09.03.2015 13:59, Michael Niedermayer wrote: i was thinking more about limiting the backward seek before resync to the last resync position +1 if there was a previous resync so that resync which moves forward could not end before. This would avoid the failure and allow the demuxer to continue, or at least thats the idea I see, new patch attached. The +1 is not necessary, because it always reads the PACKET_ID field before resyncing. Best regards, Andreas ffmdec.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) 2f242fcf689ae8307a818b8a219d08af7c27921e 0001-ffmdec-limit-the-backward-seek-to-the-last-resync-po.patch From 6bcd1b4a906e2da39f6361db19826a337ac5a745 Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun andreas.cadhal...@googlemail.com Date: Mon, 9 Mar 2015 14:59:44 +0100 Subject: [PATCH] ffmdec: limit the backward seek to the last resync position If resyncing leads to the same position as previously, it will again lead to a resync attempt, resulting in an infinite loop. Thus don't seek back beyond the last syncpoint. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote: On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire klaussfre...@gmail.com wrote: On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer michae...@gmx.at wrote: i think its better to leave fuzz at a small value otherwise we would forget to update the target when it improves and then subsequent worsenings could be missed An updated version with that fixed. It's a bit tricky to squash commits with git format-patch, so if there's an issue with the patch just apply it with patch -p1, works that way (tried) Dang, forgot to attach the patch. Now truly attached. works on x86 but fails on mips: stddev: 443.22 PSNR: 43.40 MAXDIFF: 5038 bytes: 176400/ 180224 stddev: |443.22 - 414| = 5 Test aac-s7350-encode failed. Look at tests/data/fate/aac-s7350-encode.err for details. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Mon, Mar 9, 2015 at 12:41 PM, Michael Niedermayer michae...@gmx.at wrote: On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote: On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire klaussfre...@gmail.com wrote: On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer michae...@gmx.at wrote: i think its better to leave fuzz at a small value otherwise we would forget to update the target when it improves and then subsequent worsenings could be missed An updated version with that fixed. It's a bit tricky to squash commits with git format-patch, so if there's an issue with the patch just apply it with patch -p1, works that way (tried) Dang, forgot to attach the patch. Now truly attached. works on x86 but fails on mips: stddev: 443.22 PSNR: 43.40 MAXDIFF: 5038 bytes: 176400/ 180224 stddev: |443.22 - 414| = 5 Test aac-s7350-encode failed. Look at tests/data/fate/aac-s7350-encode.err for details. That's weird. I didn't expect this code to be platform-specific. Head is still using a butterworth filter for the lowpass IIRC. That could very well be both platform and sample rate specific. Sadly, I cannot test mips, but commenting the lowpass could yield useful results. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Mon, Mar 09, 2015 at 12:55:43PM -0300, Claudio Freire wrote: On Mon, Mar 9, 2015 at 12:41 PM, Michael Niedermayer michae...@gmx.at wrote: On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote: On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire klaussfre...@gmail.com wrote: On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer michae...@gmx.at wrote: i think its better to leave fuzz at a small value otherwise we would forget to update the target when it improves and then subsequent worsenings could be missed An updated version with that fixed. It's a bit tricky to squash commits with git format-patch, so if there's an issue with the patch just apply it with patch -p1, works that way (tried) Dang, forgot to attach the patch. Now truly attached. works on x86 but fails on mips: stddev: 443.22 PSNR: 43.40 MAXDIFF: 5038 bytes: 176400/ 180224 stddev: |443.22 - 414| = 5 Test aac-s7350-encode failed. Look at tests/data/fate/aac-s7350-encode.err for details. That's weird. I didn't expect this code to be platform-specific. Head is still using a butterworth filter for the lowpass IIRC. That could very well be both platform and sample rate specific. Sadly, I cannot test mips, but commenting the lowpass could yield useful results. what exact change should i make / can you provide a diff? what exact should i test / can you provide a command line ? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Mon, Mar 09, 2015 at 04:41:05PM +0100, Michael Niedermayer wrote: On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote: On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire klaussfre...@gmail.com wrote: On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer michae...@gmx.at wrote: i think its better to leave fuzz at a small value otherwise we would forget to update the target when it improves and then subsequent worsenings could be missed An updated version with that fixed. It's a bit tricky to squash commits with git format-patch, so if there's an issue with the patch just apply it with patch -p1, works that way (tried) Dang, forgot to attach the patch. Now truly attached. works on x86 but fails on mips: cpuflag 0 doesnt help, seems passing on ppc-qemu could try on actual ppc if needed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/options_table: remove extradata_size from the AVOptions table
On 9 March 2015 at 14:28, Michael Niedermayer michae...@gmx.at wrote:
On Mon, Mar 09, 2015 at 01:27:58PM +0100, Lukasz Marek wrote:
On 9 March 2015 at 12:19, Andreas Cadhalpun
andreas.cadhal...@googlemail.com wrote:
On 09.03.2015 03:42, Michael Niedermayer wrote:
allowing access to the size but not the extradata itself is not useful
and could lead to potential problems if writing happens through this
field
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/options_table.h |1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 442b212..a906864 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -103,7 +103,6 @@ static const AVOption avcodec_options[] = {
{hex, hex motion estimation, 0, AV_OPT_TYPE_CONST, {.i64 =
ME_HEX
}, INT_MIN, INT_MAX, V|E, me_method },
{umh, umh motion estimation, 0, AV_OPT_TYPE_CONST, {.i64 =
ME_UMH
}, INT_MIN, INT_MAX, V|E, me_method },
{iter, iter motion estimation, 0, AV_OPT_TYPE_CONST, {.i64 =
ME_ITER }, INT_MIN, INT_MAX, V|E, me_method },
-{extradata_size, NULL, OFFSET(extradata_size), AV_OPT_TYPE_INT,
{.i64
= DEFAULT }, INT_MIN, INT_MAX},
{time_base, NULL, OFFSET(time_base), AV_OPT_TYPE_RATIONAL, {.dbl =
0}, INT_MIN, INT_MAX},
{g, set the group of picture (GOP) size, OFFSET(gop_size),
AV_OPT_TYPE_INT, {.i64 = 12 }, INT_MIN, INT_MAX, V|E},
{ar, set audio sampling rate (in Hz), OFFSET(sample_rate),
AV_OPT_TYPE_INT, {.i64 = DEFAULT }, 0, INT_MAX, A|D|E},
This looks very good, because it also fixes the ffm muxer to never
create
files with extradata_size setting, but without extradata.
Isn't it API break? Maybe it is better to have a look on asv1 or ffm
muxer
to fix problem itself, not to cover it.
I can have a look on this today's evening.
you miss the problem, this is a demuxer side problem,
a attacker can at least crash your application no muxer side change
can fix this, the attacker has his own self written muxer that
produces a mallicious bitstream
of course you are correct that there is possibly also a problem on the
muxer side and that this too should be fixed but that is less
important.
OK.
I checked this issue and your patch fixes the issue so if you are OK with
removing this option I have no more remarks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Add support to process_command in vf_eq.c
I was going through the code, and I realized that I have made a mistake. I
have corrected the code, and attached the corresponding patch.
From 2ebd299b55a34914d5549f21d264e8cb7f5f605d Mon Sep 17 00:00:00 2001
From: Arwa Arif arwaarif1...@gmail.com
Date: Mon, 9 Mar 2015 19:50:32 +0530
Subject: [PATCH] Fix the wrong parsing style in vf_eq
blah
---
libavfilter/vf_eq.c | 33 -
libavfilter/vf_eq.h | 34 --
2 files changed, 24 insertions(+), 43 deletions(-)
diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
index 980e9ca..816c734 100644
--- a/libavfilter/vf_eq.c
+++ b/libavfilter/vf_eq.c
@@ -111,16 +111,16 @@ static void check_values(EQParameters *param, EQContext *eq)
static void set_contrast(EQContext *eq)
{
-eq-var_values[VAR_CONTRAST] = av_clipf(av_expr_eval(eq-contrast_pexpr, eq-var_values, eq),-2.0, 2.0);
-eq-param[0].contrast = eq-var_values[VAR_CONTRAST];
+eq-contrast = av_clipf(av_expr_eval(eq-contrast_pexpr, NULL, eq),-2.0, 2.0);
+eq-param[0].contrast = eq-contrast;
eq-param[0].lut_clean = 0;
check_values(eq-param[0], eq);
}
static void set_brightness(EQContext *eq)
{
-eq-var_values[VAR_BRIGHTNESS] = av_clipf(av_expr_eval(eq-brightness_pexpr, eq-var_values, eq), -1.0, 1.0);
-eq-param[0].brightness = eq-var_values[VAR_BRIGHTNESS];
+eq-brightness = av_clipf(av_expr_eval(eq-brightness_pexpr, NULL, eq), -1.0, 1.0);
+eq-param[0].brightness = eq-brightness;
eq-param[0].lut_clean = 0;
check_values(eq-param[0], eq);
}
@@ -129,18 +129,18 @@ static void set_gamma(EQContext *eq)
{
int i;
-eq-var_values[VAR_GAMMA]= av_clipf(av_expr_eval(eq-gamma_pexpr,eq-var_values, eq), 0.1, 10.0);
-eq-var_values[VAR_GAMMA_R] = av_clipf(av_expr_eval(eq-gamma_r_pexpr, eq-var_values, eq), 0.1, 10.0);
-eq-var_values[VAR_GAMMA_G] = av_clipf(av_expr_eval(eq-gamma_g_pexpr, eq-var_values, eq), 0.1, 10.0);
-eq-var_values[VAR_GAMMA_B] = av_clipf(av_expr_eval(eq-gamma_b_pexpr, eq-var_values, eq), 0.1, 10.0);
-eq-var_values[VAR_GAMMA_WEIGHT] = av_clipf(av_expr_eval(eq-gamma_weight_pexpr, eq-var_values, eq), 0.0, 1.0);
+eq-gamma= av_clipf(av_expr_eval(eq-gamma_pexpr,NULL, eq), 0.1, 10.0);
+eq-gamma_r = av_clipf(av_expr_eval(eq-gamma_r_pexpr, NULL, eq), 0.1, 10.0);
+eq-gamma_g = av_clipf(av_expr_eval(eq-gamma_g_pexpr, NULL, eq), 0.1, 10.0);
+eq-gamma_b = av_clipf(av_expr_eval(eq-gamma_b_pexpr, NULL, eq), 0.1, 10.0);
+eq-gamma_weight = av_clipf(av_expr_eval(eq-gamma_weight_pexpr, NULL, eq), 0.0, 1.0);
-eq-param[0].gamma = eq-var_values[VAR_GAMMA] * eq-var_values[VAR_GAMMA_G];
-eq-param[1].gamma = sqrt(eq-var_values[VAR_GAMMA_B] / eq-var_values[VAR_GAMMA_G]);
-eq-param[2].gamma = sqrt(eq-var_values[VAR_GAMMA_R] / eq-var_values[VAR_GAMMA_G]);
+eq-param[0].gamma = eq-gamma * eq-gamma_g;
+eq-param[1].gamma = sqrt(eq-gamma_b / eq-gamma_g);
+eq-param[2].gamma = sqrt(eq-gamma_r / eq-gamma_g);
for (i = 0; i 3; i++) {
-eq-param[i].gamma_weight = eq-var_values[VAR_GAMMA_WEIGHT];
+eq-param[i].gamma_weight = eq-gamma_weight;
eq-param[i].lut_clean = 0;
check_values(eq-param[i], eq);
}
@@ -150,10 +150,10 @@ static void set_saturation(EQContext *eq)
{
int i;
-eq-var_values[VAR_SATURATION] = av_clipf(av_expr_eval(eq-saturation_pexpr, eq-var_values, eq), 0.0, 3.0);
+eq-saturation = av_clipf(av_expr_eval(eq-saturation_pexpr, NULL, eq), 0.0, 3.0);
for (i = 1; i 3; i++) {
-eq-param[i].contrast = eq-var_values[VAR_SATURATION];
+eq-param[i].contrast = eq-saturation;
eq-param[i].lut_clean = 0;
check_values(eq-param[i], eq);
}
@@ -166,8 +166,7 @@ static int set_expr(AVExpr **pexpr, const char *expr, const char *option, void *
if (*pexpr)
old = *pexpr;
-ret = av_expr_parse(pexpr, expr, var_names,
-NULL, NULL, NULL, NULL, 0, log_ctx);
+ret = av_expr_parse(pexpr, expr, NULL, NULL, NULL, NULL, NULL, 0, log_ctx);
if (ret 0) {
av_log(log_ctx, AV_LOG_ERROR,
Error when evaluating the expression '%s' for %s\n,
diff --git a/libavfilter/vf_eq.h b/libavfilter/vf_eq.h
index fe9c09c..f036664 100644
--- a/libavfilter/vf_eq.h
+++ b/libavfilter/vf_eq.h
@@ -28,30 +28,6 @@
#include avfilter.h
#include libavutil/eval.h
-static const char * const var_names[] = {
-contrast,
-brightness,
-saturation,
-gamma,
-gamma_weight,
-gamma_r,
-gamma_g,
-gamma_b,
-NULL
-};
-
-enum var_name {
-VAR_CONTRAST ,
-VAR_BRIGHTNESS ,
-VAR_SATURATION ,
-VAR_GAMMA ,
-VAR_GAMMA_WEIGHT ,
-VAR_GAMMA_R ,
-VAR_GAMMA_G ,
-VAR_GAMMA_B ,
-VAR_VARS_NB ,
-};
-
typedef struct EQParameters {
void (*adjust)(struct EQParameters *eq,
Re: [FFmpeg-devel] GSoC '15 Introduction
Thank you very much for your kind replies and advices compn, Timo and Roger. I am at the very beginning of the journey , I've never worked with Dshow before but I'm very excited to learn and develop. I will look through all the materials given and start doing stuff as soon as possible. On Mon, Mar 9, 2015 at 2:21 PM, Roger Pack rogerdpa...@gmail.com wrote: On 3/8/15, compn te...@mi.rr.com wrote: On Sat, 7 Mar 2015 20:24:16 +0200 Ilinca Andrei andrei.ilinc...@gmail.com wrote: Hello! welcome! *Why directshow digital video capture ?* Simply because It sounds really interesting and entertaining. I have some experience using Matlab and Simulink for converting from time-domain to frequency-domain and back, Bode Nyquist Diagrams and I have basic knowledge about how filters work and how they can be used and implemented. I've done some research about video capturing in DirectShow , mainly on this link https://msdn.microsoft.com/en-us/library/windows/desktop/dd373406%28v=vs.85%29.aspx , and I believe this project suits me the best. dont forget you can check other open source projects (videolan, virtualdub etc) and maybe copy how they do dshow video capture. Just don't copy and paste, since the VLC stuff [at least] is straight GPL and we'll need this one to be LGPL [so basically base it off of the MSDN not off the VLC code base, that's what I do]. Look forward to corresponding more through private email on the issue with you. -roger- ___ 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] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote:
On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire klaussfre...@gmail.com
wrote:
On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer michae...@gmx.at
wrote:
i think its better to leave fuzz at a small value otherwise we
would forget to update the target when it improves and then
subsequent worsenings could be missed
An updated version with that fixed.
It's a bit tricky to squash commits with git format-patch, so if
there's an issue with the patch just apply it with patch -p1, works
that way (tried)
Dang, forgot to attach the patch.
Now truly attached.
fate-run.sh |6 ++
fate/aac.mak | 29 +
2 files changed, 35 insertions(+)
94ffe372679351a8d3ec19bcebaf77349f2ef46d s7350test.patch
From 9ebb5b6d0085a547938afb32c7d203686f7fcf11 Mon Sep 17 00:00:00 2001
From: Claudio Freire klaussfre...@gmail.com
Date: Sun, 8 Mar 2015 03:53:22 -0300
Subject: [PATCH] Add AAC tests for 7350hz sampling rates and M/S
Also tweak fuzz factor to not error out on too little distortion (ie: codec
improvement)
---
tests/fate-run.sh | 6 ++
tests/fate/aac.mak | 33 +++--
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 824d5f4..feac731 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -50,6 +50,12 @@ do_tiny_psnr(){
size_cmp=$(compare $size1 $size2 $size_tolerance)
if [ $val_cmp != 0 ] || [ $size_cmp != 0 ]; then
echo $psnr
+if [ $val_cmp != 0 ]; then
+echo $3: |$val - $cmp_target| = $fuzz
+fi
+if [ $size_cmp != 0 ]; then
+echo size: |$size1 - $size2| = $size_tolerance
+fi
return 1
fi
}
applied above hunk
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
100% positive feedback - All either got their money back or didnt complain
Best seller ever, very honest - Seller refunded buyer after failed scam
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Mon, Mar 9, 2015 at 1:05 PM, Michael Niedermayer michae...@gmx.at wrote: Head is still using a butterworth filter for the lowpass IIRC. That could very well be both platform and sample rate specific. Sadly, I cannot test mips, but commenting the lowpass could yield useful results. what exact change should i make / can you provide a diff? what exact should i test / can you provide a command line ? It should be enough to add -cutoff 7350 to the command line ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/options_table: remove extradata_size from the AVOptions table
Le nonidi 19 ventôse, an CCXXIII, Michael Niedermayer a écrit : you miss the problem, this is a demuxer side problem, a attacker can at least crash your application no muxer side change can fix this, the attacker has his own self written muxer that produces a mallicious bitstream (Unrelated to this particular change, which seems right to me.) Maybe we need a flag to indicate whether an option can be safely set, even with a value coming from an hostile source. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/options_table: remove extradata_size from the AVOptions table
On Mon, Mar 09, 2015 at 03:42:00AM +0100, Michael Niedermayer wrote: allowing access to the size but not the extradata itself is not useful and could lead to potential problems if writing happens through this field Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavcodec/options_table.h |1 - 1 file changed, 1 deletion(-) patch applied thanks to all [...] -- 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] avcodec/hevc_parser: use avpriv_find_start_code in hevc_split()
在 2015/3/8 20:14, Michael Niedermayer 写道:
On Sat, Mar 07, 2015 at 11:47:08PM +0800, zhaoxiu.zeng wrote:
From ab12e3081ba987c2e05d819be97cde96952f1c2a Mon Sep 17 00:00:00 2001
From: Zeng Zhaoxiu zhaoxiu.z...@gmail.com
Date: Sat, 7 Mar 2015 23:29:46 +0800
Subject: [PATCH 1/1] avcodec/hevc_parser: use avpriv_find_start_code in
hevc_split()
Signed-off-by: Zeng Zhaoxiu zhaoxiu.z...@gmail.com
---
libavcodec/hevc_parser.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index a6fdbb7..91fc0d4 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -286,21 +286,21 @@ static int hevc_parse(AVCodecParserContext *s,
// Split after the parameter sets at the beginning of the stream if they
exist.
static int hevc_split(AVCodecContext *avctx, const uint8_t *buf, int
buf_size)
{
-int i;
+const uint8_t *ptr = buf, end = buf + buf_size;
end is a uint8_t, that will not work
also please make sure to test the code you change
Sorry for my carelessness. (I tested with make fate only)
Thanks!
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
The new patch:
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index a6fdbb7..7076897 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -286,21 +286,21 @@ static int hevc_parse(AVCodecParserContext *s,
// Split after the parameter sets at the beginning of the stream if they exist.
static int hevc_split(AVCodecContext *avctx, const uint8_t *buf, int buf_size)
{
-int i;
+const uint8_t *ptr = buf, *end = buf + buf_size;
uint32_t state = -1;
-int has_ps = 0;
+int has_ps = 0, nut;
-for (i = 0; i buf_size; i++) {
-state = (state 8) | buf[i];
-if (((state 8) 0xFF) == START_CODE) {
-int nut = (state 1) 0x3F;
-if (nut = NAL_VPS nut = NAL_PPS)
-has_ps = 1;
-else if (has_ps)
-return i - 3;
-else // no parameter set at the beginning of the stream
-return 0;
-}
+while (ptr end) {
+ptr = avpriv_find_start_code(ptr, end, state);
+if ((state 8) != START_CODE)
+break;
+nut = (state 1) 0x3F;
+if (nut = NAL_VPS nut = NAL_PPS)
+has_ps = 1;
+else if (has_ps)
+return ptr - 4 - buf;
+else // no parameter set at the beginning of the stream
+return 0;
}
return 0;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 9 March 2015 15:28:48 CET, Hendrik Leppkes h.lepp...@gmail.com wrote: On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger reimar.doeffin...@gmx.de wrote: On 9 March 2015 13:34:24 CET, Hendrik Leppkes h.lepp...@gmail.com wrote: On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker fernetme...@online.de wrote: Reimar Döffinger Reimar.Doeffinger at gmx.de writes: Any reason to believe this patch causes it? Because I can't see how it would. Maybe it's just a bug with DXVA and multithreading in the HEVC code? Can you provide some more information like a stacktrace, possibly using a tool like DrMemory? I don't think the patch itself is the root cause of the issue, it just triggers it. get_format is called 4 times, something seems to get corrupted in opening our hw decoder. Do you have an explanation why it works with thread_safe_callbacks set to 1? I am wondering if hevc misses the multithreading fix done for other codecs: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html What do you think? I build the HEVC HWAccel support, and I consider frame-threading with hwaccel an abomination that should not be supported, so I didn't spend any time thinking about it. Honestly, there are several issues with MT+HWaccel in H264 as well, at least on Intel hardware, so I can only strongly urge everyone to not combine it. There is zero advantages, and only downsides! Only if you completely ignore the practical issues that anyone trying to use it will have. In many cases applications will not know whether hardware supports decoding the video until there get_format call. Worse, it can even change from supported to not supported. Do you expect everyone to disable multithreading just in case? Buffer the last n bits of data to be able to restart decoding? What I do is simply restart decoding with the packet that failed the hardware decoder. Don't need to buffer anything, you still have the AVPacket in question anyway. Uh, so you simply assume that decoding the same frame twice doesn't break anything? How do you enable multithreading? Do you just assume you can do that in the middle of decoding? Or do you create a new decoder? In which case, how do you ensure that the new SPS wasn't in an earlier packet due to bad muxing for example? Also the buffering issue is the other way, when you try to go from multithreading to HW decode, how do you handle that? If it works well I'd be totally in favour, but I strongly suspect it only works because you both got lucky and don't even try the hard things and still need more code on the user side. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/options_table: remove extradata_size from the AVOptions table
On Mon, Mar 09, 2015 at 05:33:46PM +0100, Nicolas George wrote: Le nonidi 19 ventôse, an CCXXIII, Michael Niedermayer a écrit : you miss the problem, this is a demuxer side problem, a attacker can at least crash your application no muxer side change can fix this, the attacker has his own self written muxer that produces a mallicious bitstream (Unrelated to this particular change, which seems right to me.) Maybe we need a flag to indicate whether an option can be safely set, even with a value coming from an hostile source. yes, indeed -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Mon, Mar 09, 2015 at 01:31:26PM -0300, Claudio Freire wrote: On Mon, Mar 9, 2015 at 1:26 PM, Michael Niedermayer michae...@gmx.at wrote: doesnt help but this does: -fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict -2 -c:a aac -b:a 256k +fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict -2 -c:a aac -b:a 88k this seems to fix it, didnt ivestigate why ... 88k is the maximum allowed bitrate at 7350hz, but it shouldn't make any difference given that lavc/aacenc.c:775 already clamps the bitrate to that number. i think it clamps to 88200 while 88k sets 88000 i can reproduce the difference with -b:a 88200 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Mon, Mar 9, 2015 at 1:26 PM, Michael Niedermayer michae...@gmx.at wrote: doesnt help but this does: -fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict -2 -c:a aac -b:a 256k +fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict -2 -c:a aac -b:a 88k this seems to fix it, didnt ivestigate why ... 88k is the maximum allowed bitrate at 7350hz, but it shouldn't make any difference given that lavc/aacenc.c:775 already clamps the bitrate to that number. Unless some parts of the code aren't getting the message sent by aacenc, which would be a bug on its own right. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_parser: use avpriv_find_start_code in hevc_split()
On Tue, Mar 10, 2015 at 12:57:57AM +0800, zhaoxiu.zeng wrote:
在 2015/3/8 20:14, Michael Niedermayer 写道:
On Sat, Mar 07, 2015 at 11:47:08PM +0800, zhaoxiu.zeng wrote:
From ab12e3081ba987c2e05d819be97cde96952f1c2a Mon Sep 17 00:00:00 2001
From: Zeng Zhaoxiu zhaoxiu.z...@gmail.com
Date: Sat, 7 Mar 2015 23:29:46 +0800
Subject: [PATCH 1/1] avcodec/hevc_parser: use avpriv_find_start_code in
hevc_split()
Signed-off-by: Zeng Zhaoxiu zhaoxiu.z...@gmail.com
---
libavcodec/hevc_parser.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index a6fdbb7..91fc0d4 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -286,21 +286,21 @@ static int hevc_parse(AVCodecParserContext *s,
// Split after the parameter sets at the beginning of the stream if they
exist.
static int hevc_split(AVCodecContext *avctx, const uint8_t *buf, int
buf_size)
{
-int i;
+const uint8_t *ptr = buf, end = buf + buf_size;
end is a uint8_t, that will not work
also please make sure to test the code you change
Sorry for my carelessness. (I tested with make fate only)
Thanks!
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
The new patch:
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Patch proposal : filter ebur128 : add filter name before each line of summary print
In attach a patch proposal, in order to make easier parse result of ebur128 filter by external scripts command line for testing : ffmpeg -i aFile.wav -filter ebur128=peak=true+sample -f null - Before patch, summary look like this : [Parsed_ebur128_0 @ 0x7fe8b0d0] Summary: Integrated loudness: I: -23.0 LUFS Threshold: -33.0 LUFS Loudness range: LRA: 5.0 LU Threshold: -43.0 LUFS LRA low: -26.2 LUFS LRA high: -21.2 LUFS Sample peak: Peak: -8.9 dBFS True peak: Peak: -8.9 dBFS After the patch, summary looks like that : [Parsed_ebur128_0 @ 0x7f9882c018c0] Summary: [Parsed_ebur128_0 @ 0x7f9882c018c0] Integrated loudness: [Parsed_ebur128_0 @ 0x7f9882c018c0] I: -23.0 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] Threshold: -33.0 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] Loudness range: [Parsed_ebur128_0 @ 0x7f9882c018c0] LRA: 5.0 LU [Parsed_ebur128_0 @ 0x7f9882c018c0] Threshold: -43.0 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] LRA low: -26.2 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] LRA high: -21.2 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] Sample peak: [Parsed_ebur128_0 @ 0x7f9882c018c0] Peak: -8.9 dBFS [Parsed_ebur128_0 @ 0x7f9882c018c0] True peak: [Parsed_ebur128_0 @ 0x7f9882c018c0] Peak: -8.9 dBFS I know it can break some scripts, but it can also help script to parse result, when there is multiple filters I keep in this patch indent in print line. Martin 0001-Start-each-log-line-with-filter-name-in-order-to-mak.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] rtpenc_mpegts: set rtp_ctx to NULL on avformat_write_header failure
Hi, trying to encode e.g. codec bmp with format rtp_mpegts crashes, because the avformat_write_header failure isn't handled correctly. Attached is a patch fixing this. Best regards, Andreas From c0ba3afc828bc6255a1bcf0feb34af3caa892572 Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun andreas.cadhal...@googlemail.com Date: Mon, 9 Mar 2015 21:09:25 +0100 Subject: [PATCH] rtpenc_mpegts: set rtp_ctx to NULL on avformat_write_header failure If avformat_write_header fails, rtp_ctx is not set to NULL, thus it is freed in the fail goto. This leaves chain-rtp_ctx as a stale pointer to the freed context, leading to a crash in rtp_mpegts_write_close. Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com --- libavformat/rtpenc_mpegts.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c index 5b94e73..3bb06d5 100644 --- a/libavformat/rtpenc_mpegts.c +++ b/libavformat/rtpenc_mpegts.c @@ -90,9 +90,10 @@ static int rtp_mpegts_write_header(AVFormatContext *s) st-codec-codec_id = AV_CODEC_ID_MPEG2TS; chain-rtp_ctx = rtp_ctx; rtp_ctx-pb = s-pb; -if ((ret = avformat_write_header(rtp_ctx, NULL)) 0) -goto fail; +ret = avformat_write_header(rtp_ctx, NULL); rtp_ctx = NULL; +if (ret 0) +goto fail; return 0; -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/wmalossless: use av_clip_intp2
On Mon, Mar 09, 2015 at 10:01:20PM +0100, Reimar Döffinger wrote: On Sun, Mar 08, 2015 at 10:32:03PM +0100, Michael Niedermayer wrote: On Sat, Mar 07, 2015 at 11:44:10PM +0800, zhaoxiu.zeng wrote: From 47c997fa0623ab94a7a93b2d2e4cc4fa64c85d5f Mon Sep 17 00:00:00 2001 From: Zeng Zhaoxiu zhaoxiu.z...@gmail.com Date: Sat, 7 Mar 2015 23:26:42 +0800 Subject: [PATCH 1/1] avcodec/wmalossless: use av_clip_intp2 this breaks build on ARM ffmpeg/libavutil/arm/intmath.h:69:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:69:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:69:5: error: impossible constraint in ‘asm’ ffmpeg/libavutil/arm/intmath.h:69:5: error: impossible constraint in ‘asm’ ARM uses asm code based on the ssat instruction. That one requires the number of bits to be a constant. This means that for ARM this function may only be used with constant p argument. I guess whether this is ok depends on whether there are other cases/architectures where av_clip_intp2 is actually faster than a normal clip even when p is not constant. The C code doesn't look particularly faster to me in that case, but I haven't tested it. maybe we should make use of av_builtin_constant_p()? -- Clément B. pgpjPLnuQM8Mp.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] asfenc: fix leaking asf-index_ptr on error
On Mon, Mar 09, 2015 at 07:37:56PM +0100, Andreas Cadhalpun wrote: Hi, asfenc leaks asf-index_ptr if asf_write_header1 fails. Attached patch fixes this. Best regards, Andreas asfenc.c |1 + 1 file changed, 1 insertion(+) bd66fe12def4c8cd582c02d65eb85caa8306ceb7 0001-asfenc-fix-leaking-asf-index_ptr-on-error.patch From cd1ec21196f8f8fb0a7f4a9f42b9811ccf8109d7 Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun andreas.cadhal...@googlemail.com Date: Mon, 9 Mar 2015 19:31:39 +0100 Subject: [PATCH] asfenc: fix leaking asf-index_ptr on error Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/colormatrix:add slice threading
Hi
On Mon, Mar 09, 2015 at 10:56:18AM -0700, Yayoi wrote:
---
libavfilter/vf_colormatrix.c | 146
---
1 file changed, 95 insertions(+), 51 deletions(-)
[...]
@@ -372,12 +402,26 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
calc_coefficients(ctx);
+ThreadData td = {
+td.src = in;
+td.dst = out;
+td.c2 = color-yuv_convert[color-mode][0][1];
+td.c3 = color-yuv_convert[color-mode][0][2];
+td.c4 = color-yuv_convert[color-mode][1][1];
+td.c5 = color-yuv_convert[color-mode][1][2];
+td.c6 = color-yuv_convert[color-mode][2][1];
+td.c7 = color-yuv_convert[color-mode][2][2];
+};
That does not compile
ffmpeg/libavfilter/vf_colormatrix.c: In function ‘filter_frame’:
ffmpeg/libavfilter/vf_colormatrix.c:406:9: warning: initialization discards
‘const’ qualifier from pointer target type [enabled by default]
ffmpeg/libavfilter/vf_colormatrix.c:406:20: error: expected ‘}’ before ‘;’ token
ffmpeg/libavfilter/vf_colormatrix.c:405:5: warning: ISO C90 forbids mixed
declarations and code [-Wdeclaration-after-statement]
[...]
--
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] pthread: Fix?ff_thread_get_formatissues?when called outside frame decode.
On Mon, Mar 09, 2015 at 06:38:18AM +, Rainer Hochecker wrote: Reimar Döffinger Reimar.Doeffinger at gmx.de writes: Any reason to believe this patch causes it? Because I can't see how it would. Maybe it's just a bug with DXVA and multithreading in the HEVC code? Can you provide some more information like a stacktrace, possibly using a tool like DrMemory? I don't think the patch itself is the root cause of the issue, it just triggers it. get_format is called 4 times, something seems to get corrupted in opening our hw decoder. Do you have an explanation why it works with thread_safe_callbacks set to 1? I am wondering if hevc misses the multithreading fix done for other codecs: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html from a quick look yes, this appears missing can someone who can reprodeuce this problem test if adding such code would fix it ? if yes please send a patch [...] -- 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] avcodec/wmalossless: use av_clip_intp2
On Sun, Mar 08, 2015 at 10:32:03PM +0100, Michael Niedermayer wrote: On Sat, Mar 07, 2015 at 11:44:10PM +0800, zhaoxiu.zeng wrote: From 47c997fa0623ab94a7a93b2d2e4cc4fa64c85d5f Mon Sep 17 00:00:00 2001 From: Zeng Zhaoxiu zhaoxiu.z...@gmail.com Date: Sat, 7 Mar 2015 23:26:42 +0800 Subject: [PATCH 1/1] avcodec/wmalossless: use av_clip_intp2 this breaks build on ARM ffmpeg/libavutil/arm/intmath.h:69:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:69:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:69:5: error: impossible constraint in ‘asm’ ffmpeg/libavutil/arm/intmath.h:69:5: error: impossible constraint in ‘asm’ ARM uses asm code based on the ssat instruction. That one requires the number of bits to be a constant. This means that for ARM this function may only be used with constant p argument. I guess whether this is ok depends on whether there are other cases/architectures where av_clip_intp2 is actually faster than a normal clip even when p is not constant. The C code doesn't look particularly faster to me in that case, but I haven't tested it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/wmalossless: use av_clip_intp2
On Mon, Mar 09, 2015 at 10:05:03PM +0100, Clément Bœsch wrote: On Mon, Mar 09, 2015 at 10:01:20PM +0100, Reimar Döffinger wrote: On Sun, Mar 08, 2015 at 10:32:03PM +0100, Michael Niedermayer wrote: On Sat, Mar 07, 2015 at 11:44:10PM +0800, zhaoxiu.zeng wrote: From 47c997fa0623ab94a7a93b2d2e4cc4fa64c85d5f Mon Sep 17 00:00:00 2001 From: Zeng Zhaoxiu zhaoxiu.z...@gmail.com Date: Sat, 7 Mar 2015 23:26:42 +0800 Subject: [PATCH 1/1] avcodec/wmalossless: use av_clip_intp2 this breaks build on ARM ffmpeg/libavutil/arm/intmath.h:69:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:69:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:69:5: error: impossible constraint in ‘asm’ ffmpeg/libavutil/arm/intmath.h:69:5: error: impossible constraint in ‘asm’ ARM uses asm code based on the ssat instruction. That one requires the number of bits to be a constant. This means that for ARM this function may only be used with constant p argument. I guess whether this is ok depends on whether there are other cases/architectures where av_clip_intp2 is actually faster than a normal clip even when p is not constant. The C code doesn't look particularly faster to me in that case, but I haven't tested it. maybe we should make use of av_builtin_constant_p()? Assuming we want av_clip_intp2 to work for non-constant that would be an option, but note that it will basically break the optimization on non-gcc. However if we don't I am not so sure what to do about it, or can we use av_builtin_constant_p to error out compile-time? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_parser: use avpriv_find_start_code in hevc_split()
On Mon, Mar 09, 2015 at 09:49:04PM +0100, Reimar Döffinger wrote:
On Tue, Mar 10, 2015 at 12:57:57AM +0800, zhaoxiu.zeng wrote:
在 2015/3/8 20:14, Michael Niedermayer 写道:
On Sat, Mar 07, 2015 at 11:47:08PM +0800, zhaoxiu.zeng wrote:
From ab12e3081ba987c2e05d819be97cde96952f1c2a Mon Sep 17 00:00:00 2001
From: Zeng Zhaoxiu zhaoxiu.z...@gmail.com
Date: Sat, 7 Mar 2015 23:29:46 +0800
Subject: [PATCH 1/1] avcodec/hevc_parser: use avpriv_find_start_code in
hevc_split()
Signed-off-by: Zeng Zhaoxiu zhaoxiu.z...@gmail.com
---
libavcodec/hevc_parser.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index a6fdbb7..91fc0d4 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -286,21 +286,21 @@ static int hevc_parse(AVCodecParserContext *s,
// Split after the parameter sets at the beginning of the stream if
they exist.
static int hevc_split(AVCodecContext *avctx, const uint8_t *buf, int
buf_size)
{
-int i;
+const uint8_t *ptr = buf, end = buf + buf_size;
end is a uint8_t, that will not work
also please make sure to test the code you change
Sorry for my carelessness. (I tested with make fate only)
What would be needed so that this will be tested by make fate?
At least from my side contributions to tests are highly appreciated.
some case that inputs a raw hevc stream and then uses extradata on
the outside, maybe some hevc-something with headers streamcopy
[...]
--
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 proposal : filter ebur128 : add filter name before each line of summary print
On Mon, Mar 09, 2015 at 10:28:43PM +0100, Martin Vignali wrote: In attach a patch proposal, in order to make easier parse result of ebur128 filter by external scripts command line for testing : ffmpeg -i aFile.wav -filter ebur128=peak=true+sample -f null - Before patch, summary look like this : [Parsed_ebur128_0 @ 0x7fe8b0d0] Summary: Integrated loudness: I: -23.0 LUFS Threshold: -33.0 LUFS Loudness range: LRA: 5.0 LU Threshold: -43.0 LUFS LRA low: -26.2 LUFS LRA high: -21.2 LUFS Sample peak: Peak: -8.9 dBFS True peak: Peak: -8.9 dBFS After the patch, summary looks like that : [Parsed_ebur128_0 @ 0x7f9882c018c0] Summary: [Parsed_ebur128_0 @ 0x7f9882c018c0] Integrated loudness: [Parsed_ebur128_0 @ 0x7f9882c018c0] I: -23.0 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] Threshold: -33.0 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] Loudness range: [Parsed_ebur128_0 @ 0x7f9882c018c0] LRA: 5.0 LU [Parsed_ebur128_0 @ 0x7f9882c018c0] Threshold: -43.0 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] LRA low: -26.2 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] LRA high: -21.2 LUFS [Parsed_ebur128_0 @ 0x7f9882c018c0] Sample peak: [Parsed_ebur128_0 @ 0x7f9882c018c0] Peak: -8.9 dBFS [Parsed_ebur128_0 @ 0x7f9882c018c0] True peak: [Parsed_ebur128_0 @ 0x7f9882c018c0] Peak: -8.9 dBFS I know it can break some scripts, but it can also help script to parse result, when there is multiple filters I keep in this patch indent in print line. FFmpeg output is not supposed to be parsed. You have to use ffprobe to extract the information in an appropriate format instead. The filter exports metadata. Martin -- Clément B. pgpKmT9Md0OTz.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dump: show audio service type
L'octidi 18 ventôse, an CCXXIII, Thomas Volkert a écrit :
We could add const char *av_get_audio_service_name(enum AVAudioServiceType
type) to avutil.h and use this function both in avformat and avfilter.
In the short term, that would probably be the best (although I would
slightly prefer if the function name was based on the full DeCamelCased name
of the type, i.e. av_get_audio_service_type_name(), but that is not very
important).
For the longer term, I have started to try a more generic approach, but
before wasting time on something that can not work, I would like to know if
the following works on all supported platforms, including as shared library
with a crappy linker:
lavu/something.h:
extern struct Foo foo_constants;
lavu/something.c:
struct Foo foo_constants;
lavc/something.c:
AVOption dummy = { .default_val = {.str=foo_constants} };
In other words: initializing a pointer field in a structure with the address
of an object in another library.
If someone knows, especially if someone knows it does not work, that would
be very useful.
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] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Mon, Mar 9, 2015 at 1:38 PM, Michael Niedermayer michae...@gmx.at wrote: On Mon, Mar 09, 2015 at 01:31:26PM -0300, Claudio Freire wrote: On Mon, Mar 9, 2015 at 1:26 PM, Michael Niedermayer michae...@gmx.at wrote: doesnt help but this does: -fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict -2 -c:a aac -b:a 256k +fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict -2 -c:a aac -b:a 88k this seems to fix it, didnt ivestigate why ... 88k is the maximum allowed bitrate at 7350hz, but it shouldn't make any difference given that lavc/aacenc.c:775 already clamps the bitrate to that number. i think it clamps to 88200 while 88k sets 88000 i can reproduce the difference with -b:a 88200 Oh... I see. There's a specific implementation for mips, I had completely overlooked it on all patchesets. I'll have to look into it more thoroughly, most earlier patches should be applied to that implementation as well when applicable. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] roqvideoenc: set enc-avctx in roq_encode_init
Hi,
trying to encode roqvideo into asf currently crashes, because enc-avctx
is not set in roq_encode_end, which calls:
av_frame_free(enc-avctx-coded_frame);
Best regards,
Andreas
From 4cd715ab02e25948f695c0a4186dab4b864a5ce3 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun andreas.cadhal...@googlemail.com
Date: Mon, 9 Mar 2015 19:24:09 +0100
Subject: [PATCH] roqvideoenc: set enc-avctx in roq_encode_init
So far it is only set in roq_encode_frame, but it is used in
roq_encode_end to free the coded_frame. This currently segfaults if
roq_encode_frame is not called between roq_encode_init and
roq_encode_end.
Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
---
libavcodec/roqvideoenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/roqvideoenc.c b/libavcodec/roqvideoenc.c
index 3215f0a..89879e8 100644
--- a/libavcodec/roqvideoenc.c
+++ b/libavcodec/roqvideoenc.c
@@ -999,6 +999,8 @@ static av_cold int roq_encode_init(AVCodecContext *avctx)
av_lfg_init(enc-randctx, 1);
+enc-avctx = avctx;
+
enc-framesSinceKeyframe = 0;
if ((avctx-width 0xf) || (avctx-height 0xf)) {
av_log(avctx, AV_LOG_ERROR, Dimensions must be divisible by 16\n);
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Add support to process_command in vf_eq.c
On Fri, Feb 20, 2015 at 5:41 AM, Stefano Sabatini stefa...@gmail.com
wrote:
On date Thursday 2015-02-19 17:13:15 +0530, Arwa Arif encoded:
Updated the patch.
From 66a8c9d03995c9e7c6ccc05fb9b20756f51c17f4 Mon Sep 17 00:00:00 2001
From: Arwa Arif arwaarif1...@gmail.com
Date: Thu, 19 Feb 2015 01:26:44 +0530
Subject: [PATCH] Add process_command to eq.
---
doc/filters.texi| 35 +++
libavfilter/vf_eq.c | 171
+--
libavfilter/vf_eq.h | 56 +++--
3 files changed, 210 insertions(+), 52 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 191b52f..e5bf3a2 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4402,6 +4402,41 @@ Default is @code{1.0}.
@end table
+@subsection Commands
+The filter supports the following commands:
+
+@table @option
+@item contrast
+Set the contrast expression.
+
+@item brightness
+Set the brightness expression.
+
+@item saturation
+Set the saturation expression.
+
+@item gamma
+Set the gamma expression.
+
+@item gamma_r
+Set the gamma_r expression.
+
+@item gamma_g
+Set gamma_g expression.
+
+@item gamma_b
+Set gamma_b expression.
+
+@item gamma_weight
+Set gamma_weight expression.
+
+The command accepts the same syntax of the corresponding option.
What parameters do the expressions accept? Can you suggest some useful
use-case? (And add useful examples in the docs?)
There are no parameters accepted by the expressions. I will add some
examples in the doc.
+
+If the specified expression is not valid, it is kept at its current
+value.
Also, you should update the options section to make it clear that the
filter options accept expressions as well.
Okay, I will do that.
+
+@end table
+
@section extractplanes
Extract color channel components from input video stream into
diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
index 5899abb..1740bd4 100644
--- a/libavfilter/vf_eq.c
+++ b/libavfilter/vf_eq.c
@@ -106,14 +106,16 @@ static void check_values(EQParameters *param,
EQContext *eq)
static void set_contrast(EQContext *eq)
{
-eq-param[0].contrast = eq-contrast;
+eq-var_values[VAR_CONTRAST] =
av_clipf(av_expr_eval(eq-contrast_pexpr, eq-var_values, eq),-2.0, 2.0);
+eq-param[0].contrast = eq-var_values[VAR_CONTRAST];
eq-param[0].lut_clean = 0;
check_values(eq-param[0], eq);
}
static void set_brightness(EQContext *eq)
{
-eq-param[0].brightness = eq-brightness;
+eq-var_values[VAR_BRIGHTNESS] =
av_clipf(av_expr_eval(eq-brightness_pexpr, eq-var_values, eq), -1.0, 1.0);
+eq-param[0].brightness = eq-var_values[VAR_BRIGHTNESS];
eq-param[0].lut_clean = 0;
check_values(eq-param[0], eq);
}
@@ -121,12 +123,19 @@ static void set_brightness(EQContext *eq)
static void set_gamma(EQContext *eq)
{
int i;
-eq-param[0].gamma = eq-gamma * eq-gamma_g;
-eq-param[1].gamma = sqrt(eq-gamma_b / eq-gamma_g);
-eq-param[2].gamma = sqrt(eq-gamma_r / eq-gamma_g);
+
+eq-var_values[VAR_GAMMA]=
av_clipf(av_expr_eval(eq-gamma_pexpr,eq-var_values, eq), 0.1,
10.0);
+eq-var_values[VAR_GAMMA_R] =
av_clipf(av_expr_eval(eq-gamma_r_pexpr, eq-var_values, eq), 0.1,
10.0);
+eq-var_values[VAR_GAMMA_G] =
av_clipf(av_expr_eval(eq-gamma_g_pexpr, eq-var_values, eq), 0.1,
10.0);
+eq-var_values[VAR_GAMMA_B] =
av_clipf(av_expr_eval(eq-gamma_b_pexpr, eq-var_values, eq), 0.1,
10.0);
+eq-var_values[VAR_GAMMA_WEIGHT] =
av_clipf(av_expr_eval(eq-gamma_weight_pexpr, eq-var_values, eq), 0.0,
1.0);
+
+eq-param[0].gamma = eq-var_values[VAR_GAMMA] *
eq-var_values[VAR_GAMMA_G];
+eq-param[1].gamma = sqrt(eq-var_values[VAR_GAMMA_B] /
eq-var_values[VAR_GAMMA_G]);
+eq-param[2].gamma = sqrt(eq-var_values[VAR_GAMMA_R] /
eq-var_values[VAR_GAMMA_G]);
for (i = 0; i 3; i++) {
-eq-param[i].gamma_weight = eq-gamma_weight;
+eq-param[i].gamma_weight = eq-var_values[VAR_GAMMA_WEIGHT];
eq-param[i].lut_clean = 0;
check_values(eq-param[i], eq);
}
@@ -135,19 +144,54 @@ static void set_gamma(EQContext *eq)
static void set_saturation(EQContext *eq)
{
int i;
+
+eq-var_values[VAR_SATURATION] =
av_clipf(av_expr_eval(eq-saturation_pexpr, eq-var_values, eq), 0.0, 3.0);
+
for (i = 1; i 3; i++) {
-eq-param[i].contrast = eq-saturation;
+eq-param[i].contrast = eq-var_values[VAR_SATURATION];
eq-param[i].lut_clean = 0;
check_values(eq-param[i], eq);
}
}
+static int set_expr(AVExpr **pexpr, const char *expr, const char
*option, void *log_ctx)
+{
+int ret;
+AVExpr *old = NULL;
+
+if (*pexpr)
+old = *pexpr;
+ret = av_expr_parse(pexpr,
Re: [FFmpeg-devel] [PATCH] is_compiled flag not being cleared in av_opencl_uninit
Hi Michael,
I did the fix and verified compilation and run.
Confirmed it works.
Here is the patch
---
libavutil/opencl.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index 36cb6fe..2df5653 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -588,6 +588,7 @@ end:
void av_opencl_uninit(void)
{
+int i;
cl_int status;
LOCK_OPENCL;
opencl_ctx.init_count--;
@@ -611,6 +612,9 @@ void av_opencl_uninit(void)
}
opencl_ctx.context = NULL;
}
+for (i = 0; i opencl_ctx.kernel_code_count; i++) {
+opencl_ctx.kernel_code[i].is_compiled = 0;
+}
free_device_list(opencl_ctx.device_list);
end:
if (opencl_ctx.init_count = 0)
--
1.9.0.msysgit.0
Thanks,
Srikanth
On Sat, Mar 7, 2015 at 12:14 PM, Michael Niedermayer michae...@gmx.at
wrote:
On Sat, Mar 07, 2015 at 10:53:05AM -0600, Srikanth G wrote:
Hi Michael,
Can you let me know the compilation errors?
I tried with this fix and things were working for me.
I will try again though.
you can checkout a fresh ffmpeg and apply the patch
i is not declared in that function so it will not build
the fix is trivial but i expect code to be tested, which this
obviously has not been and would not magically be if i add int i
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker.
User
questions about the command line tools should be sent to the ffmpeg-user
ML.
And questions about how to use libav* should be sent to the libav-user ML.
___
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
[FFmpeg-devel] [PATCH] avfilter/colormatrix:add slice threading
---
fixed the issue and cleaned up the code a bit
---
libavfilter/vf_colormatrix.c | 146 +++
1 file changed, 92 insertions(+), 54 deletions(-)
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index daba16e..d0839cc 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -73,6 +73,17 @@ typedef struct {
int hsub, vsub;
} ColorMatrixContext;
+typedef struct ThreadData {
+AVFrame *dst;
+const AVFrame *src;
+int c2;
+int c3;
+int c4;
+int c5;
+int c6;
+int c7;
+} ThreadData;
+
#define OFFSET(x) offsetof(ColorMatrixContext, x)
#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
@@ -179,24 +190,28 @@ static av_cold int init(AVFilterContext *ctx)
return 0;
}
-static void process_frame_uyvy422(ColorMatrixContext *color,
- AVFrame *dst, AVFrame *src)
+static int process_slice_uyvy422(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
{
-const unsigned char *srcp = src-data[0];
-const int src_pitch = src-linesize[0];
+const ThreadData *td = arg;
+const AVFrame *src = td-src;
+AVFrame *dst = td-dst;
const int height = src-height;
const int width = src-width*2;
-unsigned char *dstp = dst-data[0];
+const int src_pitch = src-linesize[0];
const int dst_pitch = dst-linesize[0];
-const int c2 = color-yuv_convert[color-mode][0][1];
-const int c3 = color-yuv_convert[color-mode][0][2];
-const int c4 = color-yuv_convert[color-mode][1][1];
-const int c5 = color-yuv_convert[color-mode][1][2];
-const int c6 = color-yuv_convert[color-mode][2][1];
-const int c7 = color-yuv_convert[color-mode][2][2];
+const int slice_start = (height * jobnr ) / nb_jobs;
+const int slice_end = (height * (jobnr+1)) / nb_jobs;
+const unsigned char *srcp = src-data[0] + slice_start * src_pitch;
+unsigned char *dstp = dst-data[0] + slice_start * dst_pitch;
+const int c2 = td-c2;
+const int c3 = td-c3;
+const int c4 = td-c4;
+const int c5 = td-c5;
+const int c6 = td-c6;
+const int c7 = td-c7;
int x, y;
-for (y = 0; y height; y++) {
+for (y = slice_start; y slice_end; y++) {
for (x = 0; x width; x += 4) {
const int u = srcp[x + 0] - 128;
const int v = srcp[x + 2] - 128;
@@ -209,32 +224,36 @@ static void process_frame_uyvy422(ColorMatrixContext
*color,
srcp += src_pitch;
dstp += dst_pitch;
}
+return 0;
}
-static void process_frame_yuv422p(ColorMatrixContext *color,
- AVFrame *dst, AVFrame *src)
+static int process_slice_yuv422p(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
{
-const unsigned char *srcpU = src-data[1];
-const unsigned char *srcpV = src-data[2];
-const unsigned char *srcpY = src-data[0];
-const int src_pitchY = src-linesize[0];
-const int src_pitchUV = src-linesize[1];
+const ThreadData *td = arg;
+const AVFrame *src = td-src;
+AVFrame *dst = td-dst;
const int height = src-height;
const int width = src-width;
-unsigned char *dstpU = dst-data[1];
-unsigned char *dstpV = dst-data[2];
-unsigned char *dstpY = dst-data[0];
+const int slice_start = (height * jobnr ) / nb_jobs;
+const int slice_end = (height * (jobnr+1)) / nb_jobs;
+const int src_pitchY = src-linesize[0];
+const int src_pitchUV = src-linesize[1];
+const unsigned char *srcpU = src-data[1] + slice_start * src_pitchUV;
+const unsigned char *srcpV = src-data[2] + slice_start * src_pitchUV;
+const unsigned char *srcpY = src-data[0] + slice_start * src_pitchY;
const int dst_pitchY = dst-linesize[0];
const int dst_pitchUV = dst-linesize[1];
-const int c2 = color-yuv_convert[color-mode][0][1];
-const int c3 = color-yuv_convert[color-mode][0][2];
-const int c4 = color-yuv_convert[color-mode][1][1];
-const int c5 = color-yuv_convert[color-mode][1][2];
-const int c6 = color-yuv_convert[color-mode][2][1];
-const int c7 = color-yuv_convert[color-mode][2][2];
+unsigned char *dstpU = dst-data[1] + slice_start * dst_pitchUV;
+unsigned char *dstpV = dst-data[2] + slice_start * dst_pitchUV;
+unsigned char *dstpY = dst-data[0] + slice_start * dst_pitchY;
+const int c2 = td-c2;
+const int c3 = td-c3;
+const int c4 = td-c4;
+const int c5 = td-c5;
+const int c6 = td-c6;
+const int c7 = td-c7;
int x, y;
-
-for (y = 0; y height; y++) {
+for (y = slice_start; y slice_end; y++) {
for (x = 0; x width; x += 2) {
const int u = srcpU[x 1] - 128;
const int v = srcpV[x 1] - 128;
@@ -251,34 +270,38 @@ static void process_frame_yuv422p(ColorMatrixContext
*color,
dstpU += dst_pitchUV;
dstpV += dst_pitchUV;
}
+return 0;
}
-static void
Re: [FFmpeg-devel] [PATCH]Force __EXTENSIONS__ on Solaris
On Thu, Feb 26, 2015 at 05:23:52PM +0100, Carl Eugen Hoyos wrote: Hi! A user reported that the Solaris libc detection has never worked on all installations. Attached patch forces the definition of __EXTENSIONS__ which is needed for network compilation. This fixes the following error: libavformat/udp.c:174: error: storage size of 'mreq' isn't known Please comment, Carl Eugen i do not know it but i have the suspicion that this is wrong maybe theres some _XOPEN_SOURCE or _WHATEVER_SOURCE not set/detected correctly the feature_tests.h and the header that contains mreq likely should point at what is the cause [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 2/2] rtpenc_mpegts: Set chain-rtp_ctx only after avformat_write_header succeeded
On 09.03.2015 22:15, Martin Storsjö wrote: By making sure we at each time only have one pointer set, either a local variable or one in the context, we avoid potential double frees in the cleanup routines. If chain-rtp_ctx is set, it is closed by calling avformat_write_trailer, but that shouldn't be called unless avformat_write_header succeeded. This issue was pointed out by Andreas Cadhalpun. --- Andreas, does this seem to fix the issue for you as well? Yes, it does. --- libavformat/rtpenc_mpegts.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c index 8ced6a9..585d1ad 100644 --- a/libavformat/rtpenc_mpegts.c +++ b/libavformat/rtpenc_mpegts.c @@ -88,11 +88,10 @@ static int rtp_mpegts_write_header(AVFormatContext *s) st-time_base.num = 1; st-time_base.den = 9; st-codec-codec_id = AV_CODEC_ID_MPEG2TS; -chain-rtp_ctx = rtp_ctx; rtp_ctx-pb = s-pb; if ((ret = avformat_write_header(rtp_ctx, NULL)) 0) goto fail; -rtp_ctx = NULL; +chain-rtp_ctx = rtp_ctx; return 0; This looks like the proper fix. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC '15 Introduction
Hi, I'm currently working on* dshow digital video capture* and it's really interesting, even if I' m making slow progress, as I' m not familiar with graphstudionext and DShow principles . I decided to apply for another project as well, the *MPEG-4 ALS encoder** project, *for two reasons, as suggested by a developer on IRC: it involves more mathematical work and signal processing as well as giving mentors more flexibilty and improving my understanding of ffmpeg. I will start with the links in the project description and work my way up . Any thoughts/ advices are welcome . Regards, Andrei ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 1/2] rtpenc_mpegts: Free the right -pb in the error path in the init function
On 09.03.2015 22:15, Martin Storsjö wrote:
This fixes a typo from 8e32b1f096.
---
libavformat/rtpenc_mpegts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
index 8ad446b..8ced6a9 100644
--- a/libavformat/rtpenc_mpegts.c
+++ b/libavformat/rtpenc_mpegts.c
@@ -98,7 +98,7 @@ static int rtp_mpegts_write_header(AVFormatContext *s)
fail:
if (mpegts_ctx) {
-ffio_free_dyn_buf(chain-mpegts_ctx-pb);
+ffio_free_dyn_buf(mpegts_ctx-pb);
avformat_free_context(mpegts_ctx);
}
if (rtp_ctx)
This change looks correct, because chain-mpegts_ctx is NULL if
mpegts_ctx isn't.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
On Thu, Feb 26, 2015 at 04:28:54PM +0100, Carl Eugen Hoyos wrote:
On Thursday 26 February 2015 03:31:39 pm Derek Buitenhuis wrote:
On 2/26/2015 2:09 PM, Carl Eugen Hoyos wrote:
+snprintf(header, len + 3, %s\r\n, s-headers);
This does not necessarily work on windows. The C standard idctates that in
text mode, \n is translated to the system's native newline.
Use memcpy and 0x0D / 0X0A / 0x00.
New patch attached.
This may also accidentally allow for headers to end with '\n\r\n',
wouldn't it?
Yes, I don't know if this is a problem.
Thank you, Carl Eugen
http.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
6114a18a8dd0b1737c844b18a839a6ef99617145 patchhttpcrlf2.diff
diff --git a/libavformat/http.c b/libavformat/http.c
index 55dcb6e..59e5acb 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -312,9 +312,17 @@ static int http_open(URLContext *h, const char *uri, int
flags,
if (s-headers) {
int len = strlen(s-headers);
-if (len 2 || strcmp(\r\n, s-headers + len - 2))
+if (len 2 || strcmp(\r\n, s-headers + len - 2)) {
+char *header = av_malloc(len + 3);
+if (!header)
+return AVERROR(ENOMEM);
+memcpy(header, s-headers, len);
+memcpy(header + len, \r\n\0, 3);
there should be a loop that replaces each sequence of any \n\r
by a single crlf sequency using no \r \n codes but only litteral bytes
and also ensure that one such sequence is at the end
if you only want t fix the end, then existing \r and \n should be
stripped and crlf be added litterally without use of \r\n but
literal byte values
to repeat, the input checks should use \r\n the output should not
we assume the user would provide headers in the platforms encoding
while we need http encoding on the output side
i hope above is correct and not missing something
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] rtpenc_mpegts: set rtp_ctx to NULL on avformat_write_header failure
Hi Martin, On 09.03.2015 22:08, Martin Storsjö wrote: Thanks for the patch, and thanks for finding the issue. You're quite correct that the error handling here is broken, but I'm not able to reproduce it by trying to mux bmp into this muxer - that actually succeeds. I guess I'm using the wrong command then, because it doesn't work with any codec: avconv -i anything -f rtp_mpegts out It always fails with: Max packet size 0 too low Would you mind sending the patches inline - that would ease review of them. I'll try. Your patch causes avformat_write_trailer to be called, even if avformat_write_header failed - that's not the right way to handle it. Indeed that's wrong. I'll send a new version of the patch that handles it correctly. Thanks. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6] libavformat/mxfenc: write package name metadata
On Thu, Mar 05, 2015 at 10:59:11AM -0800, Mark Reid wrote: --- libavformat/mxfenc.c | 97 +-- tests/ref/lavf/mxf| 6 +-- tests/ref/lavf/mxf_d10| 2 +- tests/ref/lavf/mxf_opatom | 2 +- 4 files changed, 91 insertions(+), 16 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix?ff_thread_get_formatissues?when called outside frame decode.
On Mon, Mar 9, 2015 at 11:06 PM, Michael Niedermayer michae...@gmx.at wrote: On Mon, Mar 09, 2015 at 06:38:18AM +, Rainer Hochecker wrote: Reimar Döffinger Reimar.Doeffinger at gmx.de writes: Any reason to believe this patch causes it? Because I can't see how it would. Maybe it's just a bug with DXVA and multithreading in the HEVC code? Can you provide some more information like a stacktrace, possibly using a tool like DrMemory? I don't think the patch itself is the root cause of the issue, it just triggers it. get_format is called 4 times, something seems to get corrupted in opening our hw decoder. Do you have an explanation why it works with thread_safe_callbacks set to 1? I am wondering if hevc misses the multithreading fix done for other codecs: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html from a quick look yes, this appears missing can someone who can reprodeuce this problem test if adding such code would fix it ? if yes please send a patch Just making the ff_thread_finish_setup call in hevc_frame_start conditional on !hwaccel should do what the other patches did. My code isn't setup to use this path, so someone that does should test it and send it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/colormatrix:add slice threading
---
separate a struct variable declaraion and assignment statements.
---
libavfilter/vf_colormatrix.c | 146 ---
1 file changed, 94 insertions(+), 52 deletions(-)
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index daba16e..f5835cb 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -73,6 +73,17 @@ typedef struct {
int hsub, vsub;
} ColorMatrixContext;
+typedef struct ThreadData {
+AVFrame *dst;
+const AVFrame *src;
+int c2;
+int c3;
+int c4;
+int c5;
+int c6;
+int c7;
+} ThreadData;
+
#define OFFSET(x) offsetof(ColorMatrixContext, x)
#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
@@ -179,24 +190,28 @@ static av_cold int init(AVFilterContext *ctx)
return 0;
}
-static void process_frame_uyvy422(ColorMatrixContext *color,
- AVFrame *dst, AVFrame *src)
+static int process_slice_uyvy422(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
{
-const unsigned char *srcp = src-data[0];
-const int src_pitch = src-linesize[0];
+const ThreadData *td = arg;
+const AVFrame *src = td-src;
+AVFrame *dst = td-dst;
const int height = src-height;
const int width = src-width*2;
-unsigned char *dstp = dst-data[0];
+const int src_pitch = src-linesize[0];
const int dst_pitch = dst-linesize[0];
-const int c2 = color-yuv_convert[color-mode][0][1];
-const int c3 = color-yuv_convert[color-mode][0][2];
-const int c4 = color-yuv_convert[color-mode][1][1];
-const int c5 = color-yuv_convert[color-mode][1][2];
-const int c6 = color-yuv_convert[color-mode][2][1];
-const int c7 = color-yuv_convert[color-mode][2][2];
+const int slice_start = (height * jobnr ) / nb_jobs;
+const int slice_end = (height * (jobnr+1)) / nb_jobs;
+const unsigned char *srcp = src-data[0] + slice_start * src_pitch;
+unsigned char *dstp = dst-data[0] + slice_start * dst_pitch;
+const int c2 = td-c2;
+const int c3 = td-c3;
+const int c4 = td-c4;
+const int c5 = td-c5;
+const int c6 = td-c6;
+const int c7 = td-c7;
int x, y;
-for (y = 0; y height; y++) {
+for (y = slice_start; y slice_end; y++) {
for (x = 0; x width; x += 4) {
const int u = srcp[x + 0] - 128;
const int v = srcp[x + 2] - 128;
@@ -209,32 +224,38 @@ static void process_frame_uyvy422(ColorMatrixContext
*color,
srcp += src_pitch;
dstp += dst_pitch;
}
+
+return 0;
}
-static void process_frame_yuv422p(ColorMatrixContext *color,
- AVFrame *dst, AVFrame *src)
+static int process_slice_yuv422p(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
{
-const unsigned char *srcpU = src-data[1];
-const unsigned char *srcpV = src-data[2];
-const unsigned char *srcpY = src-data[0];
-const int src_pitchY = src-linesize[0];
-const int src_pitchUV = src-linesize[1];
+const ThreadData *td = arg;
+const AVFrame *src = td-src;
+AVFrame *dst = td-dst;
const int height = src-height;
const int width = src-width;
-unsigned char *dstpU = dst-data[1];
-unsigned char *dstpV = dst-data[2];
-unsigned char *dstpY = dst-data[0];
+const int slice_start = (height * jobnr ) / nb_jobs;
+const int slice_end = (height * (jobnr+1)) / nb_jobs;
+const int src_pitchY = src-linesize[0];
+const int src_pitchUV = src-linesize[1];
+const unsigned char *srcpU = src-data[1] + slice_start * src_pitchUV;
+const unsigned char *srcpV = src-data[2] + slice_start * src_pitchUV;
+const unsigned char *srcpY = src-data[0] + slice_start * src_pitchY;
const int dst_pitchY = dst-linesize[0];
const int dst_pitchUV = dst-linesize[1];
-const int c2 = color-yuv_convert[color-mode][0][1];
-const int c3 = color-yuv_convert[color-mode][0][2];
-const int c4 = color-yuv_convert[color-mode][1][1];
-const int c5 = color-yuv_convert[color-mode][1][2];
-const int c6 = color-yuv_convert[color-mode][2][1];
-const int c7 = color-yuv_convert[color-mode][2][2];
+unsigned char *dstpU = dst-data[1] + slice_start * dst_pitchUV;
+unsigned char *dstpV = dst-data[2] + slice_start * dst_pitchUV;
+unsigned char *dstpY = dst-data[0] + slice_start * dst_pitchY;
+const int c2 = td-c2;
+const int c3 = td-c3;
+const int c4 = td-c4;
+const int c5 = td-c5;
+const int c6 = td-c6;
+const int c7 = td-c7;
int x, y;
-for (y = 0; y height; y++) {
+for (y = slice_start; y slice_end; y++) {
for (x = 0; x width; x += 2) {
const int u = srcpU[x 1] - 128;
const int v = srcpV[x 1] - 128;
@@ -251,34 +272,40 @@ static void process_frame_yuv422p(ColorMatrixContext
*color,
dstpU += dst_pitchUV;
dstpV += dst_pitchUV;
}
+
+return 0;
}
Re: [FFmpeg-devel] [PATCH] avfilter/colormatrix:add slice threading
On Mon, Mar 9, 2015 at 4:34 PM Yayoi yayoi.u...@gmail.com wrote:
@@ -372,12 +396,26 @@ static int filter_frame(AVFilterLink *link, AVFrame
*in)
calc_coefficients(ctx);
+ThreadData td = {
+.src = in,
+.dst = out,
+.c2 = color-yuv_convert[color-mode][0][1],
+.c3 = color-yuv_convert[color-mode][0][2],
+.c4 = color-yuv_convert[color-mode][1][1],
+.c5 = color-yuv_convert[color-mode][1][2],
+.c6 = color-yuv_convert[color-mode][2][1],
+.c7 = color-yuv_convert[color-mode][2][2],
+};
+
It is an FFmpeg policy to separate declaration and code.
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
On Mon, Mar 9, 2015 at 3:31 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Mon, Mar 9, 2015 at 1:38 PM, Michael Niedermayer michae...@gmx.at wrote:
On Mon, Mar 09, 2015 at 01:31:26PM -0300, Claudio Freire wrote:
On Mon, Mar 9, 2015 at 1:26 PM, Michael Niedermayer michae...@gmx.at
wrote:
doesnt help
but
this does:
-fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict
-2 -c:a aac -b:a 256k
+fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict
-2 -c:a aac -b:a 88k
this seems to fix it, didnt ivestigate why ...
88k is the maximum allowed bitrate at 7350hz, but it shouldn't make
any difference given that lavc/aacenc.c:775 already clamps the bitrate
to that number.
i think it clamps to 88200 while 88k sets 88000
i can reproduce the difference with -b:a 88200
Oh... I see.
There's a specific implementation for mips, I had completely
overlooked it on all patchesets.
I'll have to look into it more thoroughly, most earlier patches should
be applied to that implementation as well when applicable.
Ok, try the attached patch on top of the previous ones, see what it
does. I cannot test myself yet (cannot build against mips, it will
probably take me a long while before I can set up qemu for that), but
the patch should bring both implementations in sync, at least enough
for the test to pass without the -b:a 88k
diff --git a/libavcodec/mips/aaccoder_mips.c b/libavcodec/mips/aaccoder_mips.c
index ea0bf31..dfbbd04 100644
--- a/libavcodec/mips/aaccoder_mips.c
+++ b/libavcodec/mips/aaccoder_mips.c
@@ -2139,7 +2139,7 @@ static void search_for_quantizers_twoloop_mips(AVCodecContext *avctx,
const float lambda)
{
int start = 0, i, w, w2, g;
-int destbits = avctx-bit_rate * 1024.0 / avctx-sample_rate / avctx-channels;
+int destbits = avctx-bit_rate * 1024.0 / avctx-sample_rate / avctx-channels * (lambda / 120.f);
float dists[128] = { 0 }, uplims[128];
float maxvals[128];
int fflag, minscaler;
@@ -2329,23 +2329,23 @@ static void search_for_ms_mips(AACEncContext *s, ChannelElement *cpe,
float minthr = FFMIN(band0-threshold, band1-threshold);
float maxthr = FFMAX(band0-threshold, band1-threshold);
for (i = 0; i sce0-ics.swb_sizes[g]; i+=4) {
-M[i ] = (sce0-coeffs[start+w2*128+i ]
-+ sce1-coeffs[start+w2*128+i ]) * 0.5;
-M[i+1] = (sce0-coeffs[start+w2*128+i+1]
-+ sce1-coeffs[start+w2*128+i+1]) * 0.5;
-M[i+2] = (sce0-coeffs[start+w2*128+i+2]
-+ sce1-coeffs[start+w2*128+i+2]) * 0.5;
-M[i+3] = (sce0-coeffs[start+w2*128+i+3]
-+ sce1-coeffs[start+w2*128+i+3]) * 0.5;
+M[i ] = (sce0-pcoeffs[start+w2*128+i ]
++ sce1-pcoeffs[start+w2*128+i ]) * 0.5;
+M[i+1] = (sce0-pcoeffs[start+w2*128+i+1]
++ sce1-pcoeffs[start+w2*128+i+1]) * 0.5;
+M[i+2] = (sce0-pcoeffs[start+w2*128+i+2]
++ sce1-pcoeffs[start+w2*128+i+2]) * 0.5;
+M[i+3] = (sce0-pcoeffs[start+w2*128+i+3]
++ sce1-pcoeffs[start+w2*128+i+3]) * 0.5;
S[i ] = M[i ]
-- sce1-coeffs[start+w2*128+i ];
+- sce1-pcoeffs[start+w2*128+i ];
S[i+1] = M[i+1]
-- sce1-coeffs[start+w2*128+i+1];
+- sce1-pcoeffs[start+w2*128+i+1];
S[i+2] = M[i+2]
-- sce1-coeffs[start+w2*128+i+2];
+- sce1-pcoeffs[start+w2*128+i+2];
S[i+3] = M[i+3]
-- sce1-coeffs[start+w2*128+i+3];
+- sce1-pcoeffs[start+w2*128+i+3];
}
abs_pow34_v(L34, sce0-coeffs+start+w2*128, sce0-ics.swb_sizes[g]);
abs_pow34_v(R34, sce1-coeffs+start+w2*128, sce0-ics.swb_sizes[g]);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
On 09.03.2015, at 07:38, Rainer Hochecker fernetme...@online.de wrote: Reimar Döffinger Reimar.Doeffinger at gmx.de writes: Any reason to believe this patch causes it? Because I can't see how it would. Maybe it's just a bug with DXVA and multithreading in the HEVC code? Can you provide some more information like a stacktrace, possibly using a tool like DrMemory? I don't think the patch itself is the root cause of the issue, it just triggers it. get_format is called 4 times, something seems to get corrupted in opening our hw decoder. Do you have an explanation why it works with thread_safe_callbacks set to 1? As you get green frames it does not really work. It might simply be that setting it breaks decoding of the first frames and thus the code causing the issues is never executed. I am wondering if hevc misses the multithreading fix done for other codecs: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html What do you think? Mostly I think that I don't have enough information by far, someone will have to do proper debugging. And as long as this is a Windows-only issue very few people will be able to help. But the fact that my previous patch worked for me despite the major bug suggests that HEVC does not call the can_start function properly. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] For x264, should I contribute to videoLan directly
All, x264 is the external library of FFmpeg. If I want to contribute to it, should I contribute to VideoLan directly? Thanks. Rong ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_formatissues when called outside frame decode.
Reimar Döffinger Reimar.Doeffinger at gmx.de writes: Any reason to believe this patch causes it? Because I can't see how it would. Maybe it's just a bug with DXVA and multithreading in the HEVC code? Can you provide some more information like a stacktrace, possibly using a tool like DrMemory? I don't think the patch itself is the root cause of the issue, it just triggers it. get_format is called 4 times, something seems to get corrupted in opening our hw decoder. Do you have an explanation why it works with thread_safe_callbacks set to 1? I am wondering if hevc misses the multithreading fix done for other codecs: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2013-March/062620.html What do you think? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Autoselect ffv1 coder also for RGB colourpaces
Michael Niedermayer michaelni at gmx.at writes: Attached patch makes the behaviour of ffv1 using gprp more similar to yuv for 8 bit. Reported by Christoph Gerstbauer . Please comment, Carl Eugen LGTM Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Improve video creation examples
Michael Niedermayer michaelni at gmx.at writes: ffmpeg.texi |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 3e2ef09ab39df5eb9d54af4ddef424b8b1cc7c26 patchimg2framerate.diff probably ok Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Force __EXTENSIONS__ on Solaris
Carl Eugen Hoyos cehoyos at ag.or.at writes: A user reported that the Solaris libc detection has never worked on all installations. This should have been ... since 3a5cbc91. Attached patch forces the definition of __EXTENSIONS__ which is needed for network compilation. This fixes the following error: libavformat/udp.c:174: error: storage size of 'mreq' isn't known Ping. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Carl Eugen Hoyos cehoyos at ag.or.at writes: I believe attached patch fixes ticket #3268 in some cases. Ping, should one of the patches get applied? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] For x264, should I contribute to videoLan directly
rongyan rongyan236 at foxmail.com writes: x264 is the external library of FFmpeg. If I want to contribute to it, should I contribute to VideoLan directly? Please see https://mailman.videolan.org/listinfo/x264-devel Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Improve the intra_dc_precision API doc
Michael Niedermayer michaelni at gmx.at writes: The mpegvideo decoder sets intra_dc_precision since forever (!). Please comment, Carl Eugen LGTM Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/8] ffmdec: initialize f_cprv, f_stvi and f_stau
On 09.03.2015 02:45, Michael Niedermayer wrote: On Mon, Mar 09, 2015 at 12:02:55AM +0100, Andreas Cadhalpun wrote: Hi, attached patch fixes 'Conditional jump or move depends on uninitialized variables' valgrind warnings. Best regards, Andreas ffmdec.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 4a297cdd7cdb822a449cd846139a86ae284893aa 0001-ffmdec-initialize-f_cprv-f_stvi-and-f_stau.patch From 8b1088fa1509b1613d095fbe1c11eec6d251c95c Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun andreas.cadhal...@googlemail.com Date: Sun, 8 Mar 2015 22:52:47 +0100 Subject: [PATCH 1/8] ffmdec: initialize f_cprv, f_stvi and f_stau They are used in a switch statement, but it is not guaranteed that the COMM case (where they are set to 0) is reached before the other cases. applied thanks In fact this is a bit wrong. COMM is guaranteed unless malformed file is parsed. These variables are dedicated to detect doubled sections. This patch allows them to occur twice in that case. So they should be initialized to 0. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Clarify documentation for fade duration
Carl Eugen Hoyos cehoyos at ag.or.at writes: -If both duration and nb_frames are specified, duration is used. Default is 0. +If both duration and nb_frames are specified, duration is used. Default is 0 +(nb_frames is used by default). I pushed this patch as I believe it improves the documentation. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Set bits_per_raw_sample for hqx
Paul B Mahol onemda at gmail.com writes: Attached patch sets bits_per_raw_sample when decoding hqx. I will push this if nobody objects. How do you know this is correct? I had the feeling the current code cannot be correct but please consider the patch dropped. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
