Re: [FFmpeg-devel] [PATCH] avcodec/utils: silence some deprecation warnings
On 21/07/15 5:39 AM, Michael Niedermayer wrote: On Tue, Jul 21, 2015 at 12:46:18AM -0300, James Almer wrote: And prevent eventual compilation failures once the relevant functions and fields are removed. Signed-off-by: James Almer jamr...@gmail.com --- libavcodec/utils.c | 13 + 1 file changed, 13 insertions(+) LGTM thanks Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/vf_scale: implement process_command
On Tue, Jul 21, 2015 at 12:45:43PM +0200, Bernd Bleßmann wrote: Signed-off-by: Bernd Bleßmann b...@it-entwicklung.de --- doc/filters.texi | 13 + libavfilter/vf_scale.c | 43 ++- 2 files changed, 47 insertions(+), 9 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras 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-test: don't alloc avctx-coded_frame
On 21/07/15 5:19 AM, Michael Niedermayer wrote: On Tue, Jul 21, 2015 at 12:29:15AM -0300, James Almer wrote: It's done automatically by avcodec_open2() now. Fixes memleaks in fate-libavcodec-options. Signed-off-by: James Almer jamr...@gmail.com --- libavcodec/options.c | 2 -- 1 file changed, 2 deletions(-) LGTM thanks Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] conversion of FFV1 specification from lyx to markdown
On Jul 21, 2015, at 10:24 AM, Michael Niedermayer mich...@niedermayer.cc wrote: On Mon, Jul 20, 2015 at 11:55:41PM -0400, Dave Rice wrote: On Jul 20, 2015, at 8:52 PM, Michael Niedermayer mich...@niedermayer.cc wrote: On Tue, Jul 21, 2015 at 02:14:11AM +0200, Michael Niedermayer wrote: [...] ill take another quick look and then will probably push your changes its probably easier to work on top of it then wait with pushing until its perfect pushed it btw please remove trailing whitespace unless some of it is required for the formating or something Send this pull request to clean up white spaces, indentation, and trailing slashes. https://github.com/FFmpeg/FFV1/pull/12 also, it seems github doesnt render all parts of the file well, some look quite broken (found by jamrial) Github's markdown rendering is a little different than pandoc's rendering. Some table updates were done here: https://github.com/FFmpeg/FFV1/pull/11 https://github.com/FFmpeg/FFV1/pull/11. There's still the header which starts with percent signs, this is a workaround to get pandoc to render that as a header but to not include it within the table of contents. Unless I'm missing something, Github doesn't seem to support rendering latex style equations in markdown (although pandoc does) so we may not be able to have a markdown that can be fully rendered by Github alone (unless we remove the need for latex). Perhaps the ffv1.md could occasionally be rendered (via the makefile) with the outputs updated on ffmpeg.org http://ffmpeg.org/. Then within the README of the FFV1 repo we could link to the rendered copy on ffmpeg.org http://ffmpeg.org/. ive uploaded a temporary version to http://ffmpeg.org/~michael/ffv1-markdown/ffv1.html http://ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf http://ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf Thanks. these are created with pandoc 1.13.2.1 locally the huffman/suffix/example tables still are wrong, that could be worked aroun by placing one of the magic non breaking or whatever spaces before the tables I'm not sure I understand why they are 'wrong'. also the html lost its left border/margin which looks odd Agreed. For HTML we're using http://elyxer.nongnu.org/lyx.css http://elyxer.nongnu.org/lyx.css which uses margin: 0. For a number of reasons I think we'll need to use a custom css, will send a PR for that later. [...] Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] conversion of FFV1 specification from lyx to markdown
On Tue, Jul 21, 2015 at 10:37:30AM -0400, Dave Rice wrote: On Jul 21, 2015, at 10:24 AM, Michael Niedermayer mich...@niedermayer.cc wrote: On Mon, Jul 20, 2015 at 11:55:41PM -0400, Dave Rice wrote: On Jul 20, 2015, at 8:52 PM, Michael Niedermayer mich...@niedermayer.cc wrote: On Tue, Jul 21, 2015 at 02:14:11AM +0200, Michael Niedermayer wrote: [...] ill take another quick look and then will probably push your changes its probably easier to work on top of it then wait with pushing until its perfect pushed it btw please remove trailing whitespace unless some of it is required for the formating or something Send this pull request to clean up white spaces, indentation, and trailing slashes. https://github.com/FFmpeg/FFV1/pull/12 also, it seems github doesnt render all parts of the file well, some look quite broken (found by jamrial) Github's markdown rendering is a little different than pandoc's rendering. Some table updates were done here: https://github.com/FFmpeg/FFV1/pull/11 https://github.com/FFmpeg/FFV1/pull/11. There's still the header which starts with percent signs, this is a workaround to get pandoc to render that as a header but to not include it within the table of contents. Unless I'm missing something, Github doesn't seem to support rendering latex style equations in markdown (although pandoc does) so we may not be able to have a markdown that can be fully rendered by Github alone (unless we remove the need for latex). Perhaps the ffv1.md could occasionally be rendered (via the makefile) with the outputs updated on ffmpeg.org http://ffmpeg.org/. Then within the README of the FFV1 repo we could link to the rendered copy on ffmpeg.org http://ffmpeg.org/. ive uploaded a temporary version to http://ffmpeg.org/~michael/ffv1-markdown/ffv1.html http://ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf http://ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf Thanks. these are created with pandoc 1.13.2.1 locally the huffman/suffix/example tables still are wrong, that could be worked aroun by placing one of the magic non breaking or whatever spaces before the tables I'm not sure I understand why they are 'wrong'. ive the suspicion something is smart and associates the title with teh tables by putting them below the tables (which is not uncommon for tables to have the associated text below them) but this is guessing by someone who knows 0 about this stuff so iam likely wrong [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Remote participation options for IETF session on MKV/FFV1 at July 22 @ 9 CEST
Hi all, Tomorrow, Wednesday, July 22nd, at 9:00am CEST, the Dispatch working group of the IETF is holding their meeting at IETF93 in Prague. The standardization of FFV1 and Matroska is on the agenda [1] and will be chaired by Tessa Fallon. Also presenting will be Emanuel Lorrain representing the Preforma project [2] and Jerome Martinez of MediaArea. Participation is encouraged and the IETF provides several ways to participate in the session remotely. The dispatch chatroom is available here: xmpp:dispa...@jabber.ietf.org?join xmpp:dispa...@jabber.ietf.org?join. During the meeting there will be a session scribe who will type a running commentary as to what is going on in the room. During question time, remote participants can type questions into the chatroom and the scribe will pass the question along to the speaker. The dispatch chatroom will be logged here: http://www.ietf.org/jabber/logs/dispatch/ http://www.ietf.org/jabber/logs/dispatch/. Audio of the session will be streamed at http://ietf93streaming.dnsalias.net/ietf/ietf935.m3u http://ietf93streaming.dnsalias.net/ietf/ietf935.m3u (as m3u) and http://congresshall3.conf.meetecho.com:8000/congresshall3.opus http://congresshall3.conf.meetecho.com:8000/congresshall3.opus (as opus). Interactive sessions via Meetecho to the session are available at https://congresshall3.conf.meetecho.com/meetecho/login.jsp?ietf=dispatch https://congresshall3.conf.meetecho.com/meetecho/login.jsp?ietf=dispatch or http://www.meetecho.com/ietf93/dispatch http://www.meetecho.com/ietf93/dispatch. Meeting minutes: http://tools.ietf.org/wg/dispatch/minutes http://tools.ietf.org/wg/dispatch/minutes The current state of the standardization efforts of Matroska is available in github [3]. Work is initially focusing on the underlying specification of EBML (Extensible Binary Meta Language). Matroska is a document type of EBML. To participate in the current standardization efforts of Matroska and EBML please visit the matroska-devel mailing list [4] or the #matroska IRC channel on freenode. The FFV1 specification work may also be reviewed at github [5] with recent rendering in HTML [6] and PDF [7] available. To participate in the current standardization efforts of FFV1 please visit the ffmpeg-devel mailing list [8] or the #ffmpeg-devel [8] IRC channel on freenode. [1] https://datatracker.ietf.org/meeting/93/agenda/dispatch/ https://datatracker.ietf.org/meeting/93/agenda/dispatch/ [2] http://preforma-project.eu/ http://preforma-project.eu/ [3] https://github.com/Matroska-Org/ebml-specification https://github.com/Matroska-Org/ebml-specification [4] http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel [5] https://github.com/ffmpeg/ffv1 https://github.com/ffmpeg/ffv1 [6] http://ffmpeg.org/~michael/ffv1-markdown/ffv1.html http://ffmpeg.org/~michael/ffv1-markdown/ffv1.html [7] http://ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf http://ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf [8] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel https://ffmpeg.org/mailman/listinfo/ffmpeg-devel I'm happy to answer any questions or concerns, I'm also participating remotely and will be logging in to relevant chatrooms about a half hour before it starts tomorrow. Best Regards, Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: loongson optimize blockdsp with mmi
On Tue, Jul 21, 2015 at 09:29:11PM +0800, 周晓勇 wrote: From 431c8fe5d418d79d5c7cb137499a26e88e6c84dc Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Tue, 21 Jul 2015 20:55:51 +0800 Subject: [PATCH] avcodec: loongson optimize blockdsp with mmi Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn --- libavcodec/mips/Makefile | 1 + libavcodec/mips/blockdsp_init_mips.c | 16 libavcodec/mips/blockdsp_mips.h | 6 ++ libavcodec/mips/blockdsp_mmi.c | 147 +++ 4 files changed, 170 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] trying ffprobe on AAC file with LATM fails
On Mon, Jul 20, 2015 at 5:08 AM, Venelin Efremov veffremov...@gmail.com wrote: The error message I get from the latest git head is: [aac_latm @ 0x3a226e0] Non-byte-aligned audio-specific config is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [aac_latm @ 0x3a226e0] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) I uploaded the file as aac_latm_non_byte_aligned.bin. The file is aac-lc 2 channel 44100 sampling rate. If someone can create a ticket with that attachment and cc me in the ticket, I'll be happy to take a stab at it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter/vf_crop: implement process_command
On Tue, Jul 21, 2015 at 12:48:33PM +0200, Bernd Bleßmann wrote: Signed-off-by: Bernd Bleßmann b...@it-entwicklung.de --- doc/filters.texi | 20 +-- libavfilter/vf_crop.c | 53 +++ 2 files changed, 63 insertions(+), 10 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle 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] Remote participation options for IETF session on MKV/FFV1 at July 22 @ 9 CEST
Hi, On Tue, Jul 21, 2015 at 12:58 PM, Kostya Shishkov kostya.shish...@gmail.com wrote: On Tue, Jul 21, 2015 at 11:52:55AM -0400, Dave Rice wrote: Hi all, [...] The FFV1 specification work may also be reviewed at github [5] with recent rendering in HTML [6] and PDF [7] available. To participate in the current standardization efforts of FFV1 please visit the ffmpeg-devel mailing list [8] or the #ffmpeg-devel [8] IRC channel on freenode. I'd suggest that any standardisation includes not only specification but also an independent implementation - it helps to figure out what's wrong with the specification and maybe gives a small standalone library instead of something spread out on half a dozen files in a large software project. +1. I can't stress how important this is. In addition, the spec should be the master, not any one implementation (because then the bugs in that one implementation will be the spec, regardless of what the bug is). Thank you Kostya. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] trying ffprobe on AAC file with LATM fails
The error message I get from the latest git head is: [aac_latm @ 0x3a226e0] Non-byte-aligned audio-specific config is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [aac_latm @ 0x3a226e0] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) I uploaded the file as aac_latm_non_byte_aligned.bin. The file is aac-lc 2 channel 44100 sampling rate. ~Venelin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] movtextenc.c: Reorganize the code for easier maintenance
On Mon, 20 Jul 2015 23:57:28 +0530 Niklesh Lalwani niklesh.lalw...@iitb.ac.in wrote: From: Niklesh niklesh.lalw...@iitb.ac.in This patch reorganizes the code to make it easier to add support for different text modifier boxes and other styles in the future. Signed-off-by: Niklesh niklesh.lalw...@iitb.ac.in --- libavcodec/movtextenc.c | 104 ++-- 1 file changed, 65 insertions(+), 39 deletions(-) Pushed, thanks. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] movtextenc.c: Add support for text highlighting
On Tue, 21 Jul 2015 00:02:31 +0530 Niklesh Lalwani niklesh.lalw...@iitb.ac.in wrote: From: Niklesh niklesh.lalw...@iitb.ac.in This patch takes care of the secondary color changes in ASS through highlight and hilightcolor boxes. Signed-off-by: Niklesh niklesh.lalw...@iitb.ac.in --- libavcodec/movtextenc.c | 60 + 1 file changed, 60 insertions(+) Pushed, thanks. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GCC 5.1 warning: -Warray-bounds
Hi, On Tue, Jul 21, 2015 at 10:07 PM, Ganesh Ajjanagadde gajja...@mit.edu wrote: On Tue, Jul 21, 2015 at 5:31 PM, Ganesh Ajjanagadde gajja...@mit.edu wrote: On Tue, Jul 21, 2015 at 5:14 PM, Michael Niedermayer mich...@niedermayer.cc wrote: On Thu, Jun 25, 2015 at 01:25:08AM -0300, James Almer wrote: On 04/06/15 6:55 PM, Ganesh Ajjanagadde wrote: I have created a small test case which gets at the heart of one of these spurious warnings, namely the one for libavfilter/vf_swapuv.c. Here is the ticket on the GCC Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422 Note that as of the moment, -Warray-bounds appears quite broken on GCC (especially on -O3), and the bugzilla is full of bug reports on this. For the record, these bogus warnings have been fixed on the gcc 5 branch. do any warnings remain for ffmpeg ? are they real issues or false positives as well ? Most are gone, only two files trigger these, namely libavformat/dvenc.c and libavcodec/dca_x11.c. I have attached a logfile from the build and will investigate this to see whether they are real or false positives. So I checked the above, and it turns out both are false positives. However, in neither case was it trivial to see that access patterns are well defined, and both required analysis across the function boundary. Perhaps this is why GCC still struggles with this stuff. I will try creating a test case based on this and file a GCC ticket. By the way, both false positives can be easily silenced with one line changes, but of course we should not needlessly bend our code to satisfy the whims of GCC. Well, that depends, right? So, the question is one of benefit vs. effort. If all warnings are useless and gcc never provided us any new insights we didn't already have (i.e. identify a real bug), it's probably not worth it. However, if gcc turned out to help us find real bugs and the changes are minor and clean, I see no problem silencing the noise a little. I believe we've done that in the past to make valgrind happier. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GCC 5.1 warning: -Warray-bounds
On 21/07/15 11:43 PM, Ganesh Ajjanagadde wrote: or try to work upstream with GCC to remove these spurious warnings. If it can be fixed upstream then that's certainly the best option. For all we know new code we add in the future may trigger this bug again. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GCC 5.1 warning: -Warray-bounds
On Tue, Jul 21, 2015 at 5:31 PM, Ganesh Ajjanagadde gajja...@mit.edu wrote: On Tue, Jul 21, 2015 at 5:14 PM, Michael Niedermayer mich...@niedermayer.cc wrote: On Thu, Jun 25, 2015 at 01:25:08AM -0300, James Almer wrote: On 04/06/15 6:55 PM, Ganesh Ajjanagadde wrote: I have created a small test case which gets at the heart of one of these spurious warnings, namely the one for libavfilter/vf_swapuv.c. Here is the ticket on the GCC Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422 Note that as of the moment, -Warray-bounds appears quite broken on GCC (especially on -O3), and the bugzilla is full of bug reports on this. For the record, these bogus warnings have been fixed on the gcc 5 branch. do any warnings remain for ffmpeg ? are they real issues or false positives as well ? Most are gone, only two files trigger these, namely libavformat/dvenc.c and libavcodec/dca_x11.c. I have attached a logfile from the build and will investigate this to see whether they are real or false positives. So I checked the above, and it turns out both are false positives. However, in neither case was it trivial to see that access patterns are well defined, and both required analysis across the function boundary. Perhaps this is why GCC still struggles with this stuff. I will try creating a test case based on this and file a GCC ticket. By the way, both false positives can be easily silenced with one line changes, but of course we should not needlessly bend our code to satisfy the whims of GCC. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates ___ 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 4/4] avformat/async: wake up main thread before exit background thread
---
libavformat/async.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/async.c b/libavformat/async.c
index 856b4dd..a905f8d 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -99,6 +99,7 @@ static void *async_buffer_task(void *arg)
if (async_check_interrupt(h)) {
c-io_eof_reached = 1;
c-io_error = AVERROR_EXIT;
+pthread_cond_signal(c-cond_wakeup_main);
pthread_mutex_unlock(c-mutex);
break;
}
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] checkasm: fix build with --enable-shared
Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
---
libavcodec/bswapdsp.c | 4
libavcodec/bswapdsp.h | 1 +
libavcodec/h264pred.c | 7 +++
libavcodec/h264pred.h | 2 ++
libavcodec/h264qpel.c | 5 +
libavcodec/h264qpel.h | 1 +
tests/checkasm/bswapdsp.c | 2 +-
tests/checkasm/h264pred.c | 2 +-
tests/checkasm/h264qpel.c | 2 +-
9 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/libavcodec/bswapdsp.c b/libavcodec/bswapdsp.c
index a6e1ec0..5edb0c4 100644
--- a/libavcodec/bswapdsp.c
+++ b/libavcodec/bswapdsp.c
@@ -54,3 +54,7 @@ av_cold void ff_bswapdsp_init(BswapDSPContext *c)
if (ARCH_X86)
ff_bswapdsp_init_x86(c);
}
+
+av_cold void avpriv_bswapdsp_init(BswapDSPContext *c) {
+ff_bswapdsp_init(c);
+}
diff --git a/libavcodec/bswapdsp.h b/libavcodec/bswapdsp.h
index f167d77..00b529b 100644
--- a/libavcodec/bswapdsp.h
+++ b/libavcodec/bswapdsp.h
@@ -27,6 +27,7 @@ typedef struct BswapDSPContext {
} BswapDSPContext;
void ff_bswapdsp_init(BswapDSPContext *c);
+void avpriv_bswapdsp_init(BswapDSPContext *c);
void ff_bswapdsp_init_x86(BswapDSPContext *c);
#endif /* AVCODEC_BSWAP_BUF_H */
diff --git a/libavcodec/h264pred.c b/libavcodec/h264pred.c
index 8f15f71..c28c010 100644
--- a/libavcodec/h264pred.c
+++ b/libavcodec/h264pred.c
@@ -601,3 +601,10 @@ av_cold void ff_h264_pred_init(H264PredContext *h, int
codec_id,
if (ARCH_MIPS)
ff_h264_pred_init_mips(h, codec_id, bit_depth, chroma_format_idc);
}
+
+av_cold void avpriv_h264_pred_init(H264PredContext *h, int codec_id,
+ const int bit_depth,
+ int chroma_format_idc)
+{
+ff_h264_pred_init(h, codec_id, bit_depth, chroma_format_idc);
+}
diff --git a/libavcodec/h264pred.h b/libavcodec/h264pred.h
index 091dcbb..bd71dcf 100644
--- a/libavcodec/h264pred.h
+++ b/libavcodec/h264pred.h
@@ -113,6 +113,8 @@ typedef struct H264PredContext {
void ff_h264_pred_init(H264PredContext *h, int codec_id,
const int bit_depth, const int chroma_format_idc);
+void avpriv_h264_pred_init(H264PredContext *h, int codec_id,
+ const int bit_depth, const int chroma_format_idc);
void ff_h264_pred_init_aarch64(H264PredContext *h, int codec_id,
const int bit_depth,
const int chroma_format_idc);
diff --git a/libavcodec/h264qpel.c b/libavcodec/h264qpel.c
index 50e82e2..024fe84 100644
--- a/libavcodec/h264qpel.c
+++ b/libavcodec/h264qpel.c
@@ -107,3 +107,8 @@ av_cold void ff_h264qpel_init(H264QpelContext *c, int
bit_depth)
if (ARCH_MIPS)
ff_h264qpel_init_mips(c, bit_depth);
}
+
+av_cold void avpriv_h264qpel_init(H264QpelContext *c, int bit_depth)
+{
+ff_h264qpel_init(c, bit_depth);
+}
diff --git a/libavcodec/h264qpel.h b/libavcodec/h264qpel.h
index 7c57ad0..a1a6f04 100644
--- a/libavcodec/h264qpel.h
+++ b/libavcodec/h264qpel.h
@@ -30,6 +30,7 @@ typedef struct H264QpelContext {
} H264QpelContext;
void ff_h264qpel_init(H264QpelContext *c, int bit_depth);
+void avpriv_h264qpel_init(H264QpelContext *c, int bit_depth);
void ff_h264qpel_init_aarch64(H264QpelContext *c, int bit_depth);
void ff_h264qpel_init_arm(H264QpelContext *c, int bit_depth);
diff --git a/tests/checkasm/bswapdsp.c b/tests/checkasm/bswapdsp.c
index 6aa7a81..bc055f7 100644
--- a/tests/checkasm/bswapdsp.c
+++ b/tests/checkasm/bswapdsp.c
@@ -61,7 +61,7 @@ void checkasm_check_bswapdsp(void)
DECLARE_ALIGNED(16, uint8_t, dst1)[BUF_SIZE];
BswapDSPContext h;
-ff_bswapdsp_init(h);
+avpriv_bswapdsp_init(h);
if (check_func(h.bswap_buf, bswap_buf))
check_bswap(uint32_t);
diff --git a/tests/checkasm/h264pred.c b/tests/checkasm/h264pred.c
index edb4f89..ab0aba5 100644
--- a/tests/checkasm/h264pred.c
+++ b/tests/checkasm/h264pred.c
@@ -243,7 +243,7 @@ void checkasm_check_h264pred(void)
int codec_id = codec_ids[codec];
for (bit_depth = 8; bit_depth = (codec_id == AV_CODEC_ID_H264 ?
10 : 8); bit_depth++)
for (chroma_format = 1; chroma_format = (codec_id ==
AV_CODEC_ID_H264 ? 2 : 1); chroma_format++) {
-ff_h264_pred_init(h, codec_id, bit_depth, chroma_format);
+avpriv_h264_pred_init(h, codec_id, bit_depth,
chroma_format);
tests[test].func(h, buf0, buf1, codec, chroma_format,
bit_depth);
}
}
diff --git a/tests/checkasm/h264qpel.c b/tests/checkasm/h264qpel.c
index 7579f94..5727dd5 100644
--- a/tests/checkasm/h264qpel.c
+++ b/tests/checkasm/h264qpel.c
@@ -60,7 +60,7 @@ void checkasm_check_h264qpel(void)
const char *op_name = op ? avg : put;
for (bit_depth = 8; bit_depth = 10; bit_depth++) {
-ff_h264qpel_init(h, bit_depth);
+avpriv_h264qpel_init(h, bit_depth);
for (i = 0; i (op ? 3 : 4); i++) {
int size
[FFmpeg-devel] [PATCH 1/4] avformat/async: fix interrupt_callback usage and return code
---
libavformat/async.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index be02308..0c7f054 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -75,13 +75,12 @@ static int async_interrupt_callback(void *arg)
{
URLContext *h = arg;
Context*c = h-priv_data;
-int ret = 0;
-if (c-interrupt_callback.callback) {
-ret = c-interrupt_callback.callback(c-interrupt_callback.opaque);
-if (!ret)
-return ret;
-}
+if (c-abort_request)
+return 1;
+
+if (ff_check_interrupt(c-interrupt_callback))
+c-abort_request = 1;
return c-abort_request;
}
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] Remote participation options for IETF session on MKV/FFV1 at July 22 @ 9 CEST
On Tue, Jul 21, 2015 at 02:03:16PM -0400, Ronald S. Bultje wrote: Hi, On Tue, Jul 21, 2015 at 12:58 PM, Kostya Shishkov kostya.shish...@gmail.com wrote: On Tue, Jul 21, 2015 at 11:52:55AM -0400, Dave Rice wrote: Hi all, [...] The FFV1 specification work may also be reviewed at github [5] with recent rendering in HTML [6] and PDF [7] available. To participate in the current standardization efforts of FFV1 please visit the ffmpeg-devel mailing list [8] or the #ffmpeg-devel [8] IRC channel on freenode. I'd suggest that any standardisation includes not only specification but also an independent implementation - it helps to figure out what's wrong with the specification and maybe gives a small standalone library instead of something spread out on half a dozen files in a large software project. +1. I can't stress how important this is. In addition, the spec should be the master, not any one implementation (because then the bugs in that one implementation will be the spec, regardless of what the bug is). Thank you Kostya. that makes sense for future versions but not for past ones There is a large number of existing ffv1 files out there. Now most likely spec and implementation match anyway but assuming they do not match for version 1 then there are 2 options A: change the spec for version 1 B: change the implementation for version 1 If now all implementations match and just the spec mismatches then If the spec is changed it would probably affect noone If the implementation is changed then suddenly there are 2 interpretations of what version 1 means and possibly no easy way to find out if a existing file used the old or new one (as both would claim to be version 1). That would be really bad, especially for a lossless format. IMO if there ever is a difference found, the exact case and difference need to be carefully analyzed and all options considered with what impact they would have on implementations and users -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avformat/async: rename async_interrupt_callback to async_check_interrupt
---
libavformat/async.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index 0c7f054..e524d33 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -71,7 +71,7 @@ typedef struct Context {
AVIOInterruptCB interrupt_callback;
} Context;
-static int async_interrupt_callback(void *arg)
+static int async_check_interrupt(void *arg)
{
URLContext *h = arg;
Context*c = h-priv_data;
@@ -95,7 +95,7 @@ static void *async_buffer_task(void *arg)
while (1) {
int fifo_space, to_copy;
-if (async_interrupt_callback(h)) {
+if (async_check_interrupt(h)) {
c-io_eof_reached = 1;
c-io_error = AVERROR_EXIT;
break;
@@ -154,7 +154,7 @@ static int async_open(URLContext *h, const char *arg, int
flags, AVDictionary **
{
Context *c = h-priv_data;
int ret;
-AVIOInterruptCB interrupt_callback = {.callback =
async_interrupt_callback, .opaque = h};
+AVIOInterruptCB interrupt_callback = {.callback = async_check_interrupt,
.opaque = h};
av_strstart(arg, async:, arg);
@@ -250,7 +250,7 @@ static int async_read_internal(URLContext *h, void *dest,
int size, int read_com
while (to_read 0) {
int fifo_size, to_copy;
-if (async_interrupt_callback(h)) {
+if (async_check_interrupt(h)) {
ret = AVERROR_EXIT;
break;
}
@@ -342,7 +342,7 @@ static int64_t async_seek(URLContext *h, int64_t pos, int
whence)
c-seek_ret = 0;
while (1) {
-if (async_interrupt_callback(h)) {
+if (async_check_interrupt(h)) {
ret = AVERROR_EXIT;
break;
}
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avformat/async: move more code into locked area in background thread
---
libavformat/async.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index e524d33..856b4dd 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -95,15 +95,15 @@ static void *async_buffer_task(void *arg)
while (1) {
int fifo_space, to_copy;
+pthread_mutex_lock(c-mutex);
if (async_check_interrupt(h)) {
c-io_eof_reached = 1;
c-io_error = AVERROR_EXIT;
+pthread_mutex_unlock(c-mutex);
break;
}
if (c-seek_request) {
-pthread_mutex_lock(c-mutex);
-
ret = ffurl_seek(c-inner, c-seek_pos, c-seek_whence);
if (ret 0) {
c-io_eof_reached = 1;
@@ -126,15 +126,17 @@ static void *async_buffer_task(void *arg)
fifo_space = av_fifo_space(fifo);
if (c-io_eof_reached || fifo_space = 0) {
-pthread_mutex_lock(c-mutex);
pthread_cond_signal(c-cond_wakeup_main);
pthread_cond_wait(c-cond_wakeup_background, c-mutex);
pthread_mutex_unlock(c-mutex);
continue;
}
+pthread_mutex_unlock(c-mutex);
to_copy = FFMIN(4096, fifo_space);
ret = av_fifo_generic_write(fifo, c-inner, to_copy, (void
*)ffurl_read);
+
+pthread_mutex_lock(c-mutex);
if (ret = 0) {
c-io_eof_reached = 1;
if (ret 0) {
@@ -142,7 +144,6 @@ static void *async_buffer_task(void *arg)
}
}
-pthread_mutex_lock(c-mutex);
pthread_cond_signal(c-cond_wakeup_main);
pthread_mutex_unlock(c-mutex);
}
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avformat/async: fix interrupt_callback usage and return code
On Wed, Jul 22, 2015 at 02:47:23AM +0800, Zhang Rui wrote: --- libavformat/async.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) applied thanks [...] -- 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 2/4] avformat/async: rename async_interrupt_callback to async_check_interrupt
On Wed, Jul 22, 2015 at 02:47:24AM +0800, Zhang Rui wrote: --- libavformat/async.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] trying ffprobe on AAC file with LATM fails
On Tue, Jul 21, 2015 at 2:50 PM, Claudio Freire klaussfre...@gmail.com wrote: On Mon, Jul 20, 2015 at 5:08 AM, Venelin Efremov veffremov...@gmail.com wrote: The error message I get from the latest git head is: [aac_latm @ 0x3a226e0] Non-byte-aligned audio-specific config is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [aac_latm @ 0x3a226e0] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org) I uploaded the file as aac_latm_non_byte_aligned.bin. The file is aac-lc 2 channel 44100 sampling rate. If someone can create a ticket with that attachment and cc me in the ticket, I'll be happy to take a stab at it. Created: https://trac.ffmpeg.org/ticket/4730 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GCC 5.1 warning: -Warray-bounds
On Tue, Jul 21, 2015 at 5:14 PM, Michael Niedermayer
mich...@niedermayer.cc wrote:
On Thu, Jun 25, 2015 at 01:25:08AM -0300, James Almer wrote:
On 04/06/15 6:55 PM, Ganesh Ajjanagadde wrote:
I have created a small test case which gets at the heart of one of
these spurious
warnings, namely the one for libavfilter/vf_swapuv.c.
Here is the ticket on the GCC Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422
Note that as of the moment, -Warray-bounds appears quite broken on GCC
(especially on -O3), and the bugzilla is full of bug reports on this.
For the record, these bogus warnings have been fixed on the gcc 5 branch.
do any warnings remain for ffmpeg ?
are they real issues or false positives as well ?
Most are gone, only two files trigger these, namely
libavformat/dvenc.c and libavcodec/dca_x11.c.
I have attached a logfile from the build and will investigate this to
see whether they are real or false positives.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
CC libavdevice/alldevices.o
CC libavdevice/alsa.o
CC libavdevice/alsa_dec.o
CC libavdevice/alsa_enc.o
CC libavdevice/fbdev_common.o
CC libavdevice/avdevice.o
CC libavdevice/fbdev_dec.o
CC libavdevice/dv1394.o
CC libavdevice/fbdev_enc.o
CC libavdevice/lavfi.o
CC libavdevice/oss.o
CC libavdevice/oss_dec.o
CC libavdevice/pulse_audio_common.o
CC libavdevice/oss_enc.o
CC libavdevice/pulse_audio_dec.o
CC libavdevice/pulse_audio_enc.o
CC libavdevice/sdl.o
CC libavdevice/timefilter.o
CC libavdevice/utils.o
CC libavdevice/v4l2-common.o
CC libavdevice/v4l2.o
CC libavdevice/v4l2enc.o
CC libavdevice/xcbgrab.o
CC libavdevice/xv.o
CC libavfilter/aeval.o
CC libavfilter/af_adelay.o
CC libavfilter/af_aecho.o
CC libavfilter/af_afade.o
CC libavfilter/af_aformat.o
CC libavfilter/af_amerge.o
CC libavfilter/af_amix.o
CC libavfilter/af_anull.o
CC libavfilter/af_apad.o
CC libavfilter/af_aphaser.o
CC libavfilter/af_aresample.o
CC libavfilter/af_asetnsamples.o
CC libavfilter/af_asetrate.o
CC libavfilter/af_ashowinfo.o
CC libavfilter/af_astats.o
CC libavfilter/af_astreamsync.o
CC libavfilter/af_asyncts.o
CC libavfilter/af_atempo.o
CC libavfilter/af_biquads.o
CC libavfilter/af_channelmap.o
CC libavfilter/af_channelsplit.o
CC libavfilter/af_chorus.o
CC libavfilter/af_compand.o
CC libavfilter/af_dcshift.o
CC libavfilter/af_dynaudnorm.o
CC libavfilter/af_earwax.o
CC libavfilter/af_flanger.o
CC libavfilter/af_join.o
CC libavfilter/af_pan.o
CC libavfilter/af_replaygain.o
CC libavfilter/af_resample.o
CC libavfilter/af_silencedetect.o
CC libavfilter/af_silenceremove.o
CC libavfilter/af_volume.o
CC libavfilter/af_volumedetect.o
CC libavfilter/allfilters.o
CC libavfilter/asink_anullsink.o
CC libavfilter/asrc_anullsrc.o
CC libavfilter/asrc_sine.o
CC libavfilter/audio.o
CC libavfilter/avcodec.o
CC libavfilter/avf_avectorscope.o
CC libavfilter/avf_showcqt.o
CC libavfilter/avf_concat.o
CC libavfilter/avf_showspectrum.o
CC libavfilter/avf_showvolume.o
CC libavfilter/avf_showwaves.o
libavfilter/avcodec.c: In function ‘avfilter_get_video_buffer_ref_from_frame’:
libavfilter/avcodec.c:36:9: warning: ‘avfilter_get_video_buffer_ref_from_arrays’ is deprecated [-Wdeprecated-declarations]
avfilter_get_video_buffer_ref_from_arrays(frame-data, frame-linesize, perms,
^
In file included from libavfilter/avcodec.h:31:0,
from libavfilter/avcodec.c:26:
libavfilter/avfilter.h:914:1: note: declared here
avfilter_get_video_buffer_ref_from_arrays(uint8_t * const data[4], const int linesize[4], int perms,
^
libavfilter/avcodec.c:41:5: warning: ‘avfilter_copy_frame_props’ is deprecated [-Wdeprecated-declarations]
if (avfilter_copy_frame_props(picref, frame) 0) {
^
In file included from libavfilter/avcodec.h:31:0,
from libavfilter/avcodec.c:26:
libavfilter/avfilter.h:1117:5: note: declared here
int avfilter_copy_frame_props(AVFilterBufferRef *dst, const AVFrame *src);
^
libavfilter/avcodec.c:43:9: warning: ‘avfilter_unref_bufferp’ is deprecated [-Wdeprecated-declarations]
avfilter_unref_bufferp(picref);
^
In file included from libavfilter/avcodec.h:31:0,
from libavfilter/avcodec.c:26:
libavfilter/avfilter.h:236:6: note: declared here
void avfilter_unref_bufferp(AVFilterBufferRef **ref);
^
libavfilter/avcodec.c: In function ‘avfilter_get_audio_buffer_ref_from_frame’:
libavfilter/avcodec.c:60:5: warning: ‘avfilter_get_audio_buffer_ref_from_arrays_channels’ is deprecated [-Wdeprecated-declarations]
samplesref = avfilter_get_audio_buffer_ref_from_arrays_channels(
^
In file included from libavfilter/avcodec.h:31:0,
from libavfilter/avcodec.c:26:
Re: [FFmpeg-devel] [PATCH 6/8] lavf/http: increase range for listen, handle connection closing accordingly, add http_accept, add http_handshake and move handshake logic there
On Tue, Jul 21, 2015 at 12:14 PM, Nicolas George geo...@nsup.org wrote:
Le tridi 3 thermidor, an CCXXIII, Stephan Holljes a écrit :
From 2dc2be7e8576fd064579d37c75c343a6f18c068c Mon Sep 17 00:00:00 2001
From: Stephan Holljes klaxa1...@googlemail.com
Date: Fri, 3 Jul 2015 02:28:56 +0200
Subject: [PATCH 6/8] lavf/http: increase range for listen, handle connection
closing accordingly, add http_accept, add http_handshake and move handshake
logic there
Nit: Git practice advise to have a short first line and add details later,
with lines wrapped not too long (git log adds intendation).
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/http.c | 127
-
1 file changed, 106 insertions(+), 21 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 676bfd5..b8016a7 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -25,6 +25,7 @@
#include zlib.h
#endif /* CONFIG_ZLIB */
+#include libavutil/avassert.h
#include libavutil/avstring.h
#include libavutil/opt.h
@@ -44,6 +45,9 @@
* path names). */
#define BUFFER_SIZE MAX_URL_SIZE
#define MAX_REDIRECTS 8
+#define HTTP_ONESHOT 1
+#define HTTP_MUTLI2
+#define HTTP_MULTI_CLIENT 4
Are they supposed to be flags? Otherwise: where did 3 go?
I wasn't sure if in the future something might want to filter the
different server modes so using 3 would mess up bitmasking. By
introducing a new field as you suggested, this would become obsolete
anyway.
typedef struct HTTPContext {
const AVClass *class;
@@ -97,6 +101,7 @@ typedef struct HTTPContext {
char *method;
int reconnect;
int listen;
+char *resource;
} HTTPContext;
#define OFFSET(x) offsetof(HTTPContext, x)
@@ -128,7 +133,9 @@ static const AVOption options[] = {
{ end_offset, try to limit the request to bytes preceding this
offset, OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
{ method, Override the HTTP method or set the expected HTTP method
from a client, OFFSET(method), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D
| E },
{ reconnect, auto reconnect after disconnect before EOF,
OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
-{ listen, listen on HTTP, OFFSET(listen), AV_OPT_TYPE_INT, { .i64 =
0 }, 0, 1, D | E },
+{ listen, listen on HTTP, OFFSET(listen), AV_OPT_TYPE_INT, { .i64 =
0 }, 0, 4, D | E },
Does it make sense for the application/user to set 4? If not, then a
separate field may be better.
This would probably make more sense. I am somewhat hesitant to just
add more and more fields to the HTTPContext; am I worrying too much
about memory footprint here?
+{ resource, The resource requested by a client, OFFSET(resource),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
+{ http_code, The http code to send to a client, OFFSET(http_code),
AV_OPT_TYPE_INT, { .i64 = 0}, 0, 599, E},
Nit: Since this is HTTP anyway, the name is redundant. Maybe reply_code?
I merely reused the already present field http_code, should this be avoided?
{ NULL }
};
@@ -299,32 +306,87 @@ int ff_http_averror(int status_code, int
default_averror)
return default_averror;
}
+static int http_write_header(URLContext* h, int status_code)
The name is misleading: it does not only write the header, it also writes a
single-line reply, except in the 200 case. More on that later.
+{
+int ret;
+const char *message;
+// Maybe this should be done more elegantly?
+static const char bad_request[] = HTTP/1.1 400 Bad
Request\r\nContent-Type: text/plain\r\nContent-Length: 17\r\n400 Bad
Request\r\n;
+static const char forbidden[] = HTTP/1.1 403
Forbidden\r\nContent-Type: text/plain\r\nContent-Length: 15\r\n\r\n403
Forbidden\r\n;
+static const char not_found[] = HTTP/1.1 404 Not
Found\r\nContent-Type: text/plain\r\nContent-Length: 15\r\n\r\n404 Not
Found\r\n;
+static const char internal_server_error[] = HTTP/1.1 500 Internal
server error\r\nContent-Type: text/plain\r\nContent-Length: 25\r\n\r\n500
Internal server error\r\n;
Well, all the reply strings have the following format:
HTTP/1.1 %03d %s\r\n
Content-Type: application/octet-stream\r\n
Content-Length: %d\r\n
\r\n
%03d %s\r\n
So you can probably have just int reply_code and const char *reply_text
and fill in in a local buffer.
http_connect() uses s-buffer for the same purpose. Should I just reuse that?
+static const char ok[] = HTTP/1.1 200 OK\r\nContent-Type:
application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n;
+av_log(h, AV_LOG_TRACE, err: %d\n, status_code);
+if (status_code == 200) {
+message = ok;
+goto end;
+}
It could go back inside the switch. That avoids the goto.
+switch(status_code) {
+case AVERROR_HTTP_BAD_REQUEST:
Nit: usual style is switchspace{ and case
Re: [FFmpeg-devel] [libav-devel] [PATCH] checkasm: Always link statically
On 21.07.2015 23:23, Luca Barbato wrote: Checkasm needs to use internal symbols that should not be made public. --- Makefile| 1 + common.mak | 5 +++-- tests/checkasm/Makefile | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 5807acd..e9a95aa 100644 --- a/Makefile +++ b/Makefile @@ -100,6 +100,7 @@ include $(SRC_PATH)/common.mak FF_EXTRALIBS := $(FFEXTRALIBS) FF_DEP_LIBS := $(DEP_LIBS) +FF_STATIC_DEP_LIBS := $(STATIC_DEP_LIBS) all: $(AVPROGS) diff --git a/common.mak b/common.mak index 9244fd3..adab9d1 100644 --- a/common.mak +++ b/common.mak @@ -24,8 +24,9 @@ TOOLOBJS := $(TOOLS:%=tools/%.o) TOOLS := $(TOOLS:%=tools/%$(EXESUF)) HEADERS += $(HEADERS-yes) -PATH_LIBNAME = $(foreach NAME,$(1),lib$(NAME)/$($(CONFIG_SHARED:yes=S)LIBNAME)) -DEP_LIBS := $(foreach lib,$(FFLIBS),$(call PATH_LIBNAME,$(lib))) +PATH_LIBNAME = $(foreach NAME,$(1),lib$(NAME)/$($(2)LIBNAME)) +DEP_LIBS := $(foreach lib,$(FFLIBS),$(call PATH_LIBNAME,$(lib),$(CONFIG_SHARED:yes=S))) +STATIC_DEP_LIBS := $(foreach lib,$(FFLIBS),$(call PATH_LIBNAME,$(lib))) SRC_DIR:= $(SRC_PATH)/lib$(NAME) ALLHEADERS := $(subst $(SRC_DIR)/,$(SUBDIR),$(wildcard $(SRC_DIR)/*.h $(SRC_DIR)/$(ARCH)/*.h)) diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile index 483ad13..9498ebf 100644 --- a/tests/checkasm/Makefile +++ b/tests/checkasm/Makefile @@ -22,8 +22,8 @@ tests/checkasm/%.o: CFLAGS := $(CFLAGS:-Wstrict-prototypes=-Wno-strict-prototype CHECKASM := tests/checkasm/checkasm$(EXESUF) -$(CHECKASM): $(EXEOBJS) $(CHECKASMOBJS) $(FF_DEP_LIBS) - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) $(FF_EXTRALIBS) +$(CHECKASM): $(EXEOBJS) $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS) + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS) $(EXTRALIBS) checkasm: $(CHECKASM) This works basically fine and avoids the problems of making more internal symbols public. Consider my patch drop in favor of this. The only problem I see with this is that it ignores --disable-static. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: fix build with --enable-shared
On Tue, Jul 21, 2015 at 09:18:58PM +0200, Andreas Cadhalpun wrote: Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com --- libavcodec/bswapdsp.c | 4 libavcodec/bswapdsp.h | 1 + libavcodec/h264pred.c | 7 +++ libavcodec/h264pred.h | 2 ++ libavcodec/h264qpel.c | 5 + libavcodec/h264qpel.h | 1 + tests/checkasm/bswapdsp.c | 2 +- tests/checkasm/h264pred.c | 2 +- tests/checkasm/h264qpel.c | 2 +- 9 files changed, 23 insertions(+), 3 deletions(-) ok, but avpriv would imply that the ABI doesnt change (incompatibly) without soname bump so either there would be the gurantee that the various H264 DSP contexts wont change in a incompatible way or it should be documented that these avpriv functions (or exported ff_ functions) are an exception and only to be used by the selftest code build from a matching checkout [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] checkasm: fix build with --enable-shared
On 21.07.2015 21:31, Luca Barbato wrote: On 21/07/15 21:18, Andreas Cadhalpun wrote: Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com --- libavcodec/bswapdsp.c | 4 libavcodec/bswapdsp.h | 1 + libavcodec/h264pred.c | 7 +++ libavcodec/h264pred.h | 2 ++ libavcodec/h264qpel.c | 5 + libavcodec/h264qpel.h | 1 + tests/checkasm/bswapdsp.c | 2 +- tests/checkasm/h264pred.c | 2 +- tests/checkasm/h264qpel.c | 2 +- 9 files changed, 23 insertions(+), 3 deletions(-) I'd rather solve it by force the linking of the tested objects, thanks for noticing. I'm fine with any solution that works. ;) How can one force the linking? Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: fix build with --enable-shared
On 21/07/15 5:16 PM, Michael Niedermayer wrote: On Tue, Jul 21, 2015 at 09:18:58PM +0200, Andreas Cadhalpun wrote: Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com --- libavcodec/bswapdsp.c | 4 libavcodec/bswapdsp.h | 1 + libavcodec/h264pred.c | 7 +++ libavcodec/h264pred.h | 2 ++ libavcodec/h264qpel.c | 5 + libavcodec/h264qpel.h | 1 + tests/checkasm/bswapdsp.c | 2 +- tests/checkasm/h264pred.c | 2 +- tests/checkasm/h264qpel.c | 2 +- 9 files changed, 23 insertions(+), 3 deletions(-) ok, but avpriv would imply that the ABI doesnt change (incompatibly) without soname bump so either there would be the gurantee that the various H264 DSP contexts wont change in a incompatible way or it should be documented that these avpriv functions (or exported ff_ functions) are an exception and only to be used by the selftest code build from a matching checkout Lets just make checkasm depend on static builds for the time being, until someone comes up with a better solution. Worst case scenario, if we end up adding avpriv functions for this then they should probably be like avpriv_float_dsp_alloc() and similar to avoid what you mentioned. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/8] lavf/tcp: add tcp_accept
On Tue, Jul 21, 2015 at 11:09 AM, Nicolas George geo...@nsup.org wrote:
Le tridi 3 thermidor, an CCXXIII, Stephan Holljes a écrit :
From 12d9a1e1c511615275260977941aff3067f103ea Mon Sep 17 00:00:00 2001
From: Stephan Holljes klaxa1...@googlemail.com
Date: Tue, 21 Jul 2015 06:10:25 +0200
Subject: [PATCH 4/8] lavf/tcp: add tcp_accept
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/tcp.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index f24cad2..9f8c2a0 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -19,6 +19,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
*/
#include avformat.h
+#include libavutil/avassert.h
#include libavutil/parseutils.h
#include libavutil/opt.h
#include libavutil/time.h
@@ -163,6 +164,23 @@ static int tcp_open(URLContext *h, const char *uri, int
flags)
return ret;
}
+static int tcp_accept(URLContext *s, URLContext **c)
+{
+TCPContext *sc = s-priv_data;
+TCPContext *cc;
+int ret;
+av_assert0(sc-listen);
+if ((ret = ffurl_alloc(c, s-filename, s-flags (AVIO_FLAG_READ_WRITE
| AVIO_FLAG_DIRECT),
+ s-interrupt_callback)) 0)
What about NONBLOCK? If the client is non-blocking, the application will
probably also want non-blocking clients.
Filtering s-flags was suggested in an earlier version of this patch
(you said NONBLOCK wouldn't work?), but I'll gladly remove the
filtering and just pass s-flags.
AFAICS, currently, all the flags are relevant to clients, you can probably
pass s-flags entirely, and leave the issue to the person who introduce
server-specific flags.
+return ret;
+cc = (*c)-priv_data;
+ret = ff_accept(sc-fd, sc-listen_timeout, s);
+if (ret 0)
+return ff_neterrno();
+cc-fd = ret;
+return 0;
+}
+
static int tcp_read(URLContext *h, uint8_t *buf, int size)
{
TCPContext *s = h-priv_data;
@@ -223,6 +241,7 @@ static int tcp_get_file_handle(URLContext *h)
URLProtocol ff_tcp_protocol = {
.name= tcp,
.url_open= tcp_open,
+.url_accept = tcp_accept,
.url_read= tcp_read,
.url_write = tcp_write,
.url_close = tcp_close,
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Regards,
Stephan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] Remote participation options for IETF session on MKV/FFV1 at July 22 @ 9 CEST
On Jul 21, 2015, at 2:59 PM, Michael Niedermayer mich...@niedermayer.cc wrote: On Tue, Jul 21, 2015 at 02:03:16PM -0400, Ronald S. Bultje wrote: Hi, On Tue, Jul 21, 2015 at 12:58 PM, Kostya Shishkov kostya.shish...@gmail.com wrote: On Tue, Jul 21, 2015 at 11:52:55AM -0400, Dave Rice wrote: Hi all, [...] The FFV1 specification work may also be reviewed at github [5] with recent rendering in HTML [6] and PDF [7] available. To participate in the current standardization efforts of FFV1 please visit the ffmpeg-devel mailing list [8] or the #ffmpeg-devel [8] IRC channel on freenode. I'd suggest that any standardisation includes not only specification but also an independent implementation - it helps to figure out what's wrong with the specification and maybe gives a small standalone library instead of something spread out on half a dozen files in a large software project. +1. I can't stress how important this is. In addition, the spec should be the master, not any one implementation (because then the bugs in that one implementation will be the spec, regardless of what the bug is). Thank you Kostya. that makes sense for future versions but not for past ones There is a large number of existing ffv1 files out there. Now most likely spec and implementation match anyway but assuming they do not match for version 1 then there are 2 options A: change the spec for version 1 B: change the implementation for version 1 IMHO I'd propose option A in most cases. IIRC, the implementation of version 1 of FFV1 came before the specification for FFV1 was in development and the goal of the specification is to properly document the implementation. Also the implementation of version 1 had some sort of event (the removal of the experimental flag http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b548f2b91b701e1235608ac882ea6df915167c7e) that signified a form of official status. The specification of version 1 started years later (2012?) and has been in gradual development with no event or commit that has signified that the specification is official. IMO the implementation of version 1 is complete and in use and the specification continues to be under development to define the implementation. At some point, hopefully after enough eyes verify that the implementation and the specification match, the specification should be marked as official (ideally through an open standards organization). Still it seems wise to, as Opus did, declare what happens if a mismatch between the spec and the implementation is discovered at a later point. If now all implementations match and just the spec mismatches then If the spec is changed it would probably affect noone Presently MediaArea is tasked with developing a conformance checker with FFV1. Jerome has attempted this work solely off of the specification and not the implementation, but the specification is not sufficiently self-descriptive to support developing another implementation without a review of the existing implementation. This issue is why we had initially proposed a standardization project. If the implementation is changed then suddenly there are 2 interpretations of what version 1 means and possibly no easy way to find out if a existing file used the old or new one (as both would claim to be version 1). That would be really bad, especially for a lossless format. Agreed. IMO if there ever is a difference found, the exact case and difference need to be carefully analyzed and all options considered with what impact they would have on implementations and users [...] Dave Rice ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] Add support for TEA (Tiny Encryption Algorithm)
On Mon, Jul 20, 2015 at 04:56:19PM +0300, Vesselin Bontchev wrote: libavutil/Makefile |3 libavutil/tea.c | 213 +++ libavutil/tea.h | 71 +++ tests/fate/libavutil.mak |4 tests/ref/fate/tea |1 5 files changed, 292 insertions(+) 386fbcfa2d92372eea3a457fb7ce3f9048093f64 0001-Add-support-for-TEA-Tiny-Encryption-Algorithm.patch From 492262598aa5d029b6bd9c8da4ccdfad4403bc83 Mon Sep 17 00:00:00 2001 From: Vesselin Bontchev vesselin.bontc...@yandex.com Date: Sun, 19 Jul 2015 22:25:53 +0200 Subject: [PATCH] Add support for TEA (Tiny Encryption Algorithm) --- libavutil/Makefile |3 + libavutil/tea.c | 213 ++ libavutil/tea.h | 71 tests/fate/libavutil.mak |4 + tests/ref/fate/tea |1 + 5 files changed, 292 insertions(+) create mode 100644 libavutil/tea.c create mode 100644 libavutil/tea.h create mode 100644 tests/ref/fate/tea applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] Remote participation options for IETF session on MKV/FFV1 at July 22 @ 9 CEST
Le 21/07/2015 20:03, Ronald S. Bultje a écrit : +1. I can't stress how important this is. In addition, the spec should be the master, not any one implementation (because then the bugs in that one implementation will be the spec, regardless of what the bug is). In theory, spec should be the reference, I totally agree. In practice, both Matroska and FFV1 formal specifications show up after these formats are widely used, without relying on any specification. So saying that the specification is the reference does not make a lot of sense here. I argue for: - previous and current versions: specifications are more an official state of the art and we try to have a specification the most compatible with most used tools. If 2 tools are incompatible, we discuss with developers case by case about the best method for fixing the incompatibility and we write the decision as part of the specification. Example of specification which takes care of compatibility with files in the wild: O is a reserved value. Encoders MUST NOT store bits_per_raw_sample = 0. Decoders SHOULD accept and interpret bits_per_raw_sample = 0 as 8. - next version: the spec is the master, not any one implementation, and we have 2-3 independent implementations ready *before* the formal release of the specification. FYI, we are on the way of having a completely independent FFV1 parser/decoder in libmediainfo and a complete Matroska and FFV1 conformance checker tool, without relying on other libraries (e.g. ffmpeg, libav, libmatroska) so we hope to catch any issue in the specs and/or files created by other tools before the formal release of specifications. Please comment. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GCC 5.1 warning: -Warray-bounds
On Thu, Jun 25, 2015 at 01:25:08AM -0300, James Almer wrote: On 04/06/15 6:55 PM, Ganesh Ajjanagadde wrote: I have created a small test case which gets at the heart of one of these spurious warnings, namely the one for libavfilter/vf_swapuv.c. Here is the ticket on the GCC Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422 Note that as of the moment, -Warray-bounds appears quite broken on GCC (especially on -O3), and the bugzilla is full of bug reports on this. For the record, these bogus warnings have been fixed on the gcc 5 branch. do any warnings remain for ffmpeg ? are they real issues or false positives as well ? [...] -- 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] GCC 5.1 warning: -Warray-bounds
On Tue, Jul 21, 2015 at 10:28 PM, Ronald S. Bultje rsbul...@gmail.com wrote: Hi, On Tue, Jul 21, 2015 at 10:07 PM, Ganesh Ajjanagadde gajja...@mit.edu wrote: On Tue, Jul 21, 2015 at 5:31 PM, Ganesh Ajjanagadde gajja...@mit.edu wrote: On Tue, Jul 21, 2015 at 5:14 PM, Michael Niedermayer mich...@niedermayer.cc wrote: On Thu, Jun 25, 2015 at 01:25:08AM -0300, James Almer wrote: On 04/06/15 6:55 PM, Ganesh Ajjanagadde wrote: I have created a small test case which gets at the heart of one of these spurious warnings, namely the one for libavfilter/vf_swapuv.c. Here is the ticket on the GCC Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422 Note that as of the moment, -Warray-bounds appears quite broken on GCC (especially on -O3), and the bugzilla is full of bug reports on this. For the record, these bogus warnings have been fixed on the gcc 5 branch. do any warnings remain for ffmpeg ? are they real issues or false positives as well ? Most are gone, only two files trigger these, namely libavformat/dvenc.c and libavcodec/dca_x11.c. I have attached a logfile from the build and will investigate this to see whether they are real or false positives. So I checked the above, and it turns out both are false positives. However, in neither case was it trivial to see that access patterns are well defined, and both required analysis across the function boundary. Perhaps this is why GCC still struggles with this stuff. I will try creating a test case based on this and file a GCC ticket. By the way, both false positives can be easily silenced with one line changes, but of course we should not needlessly bend our code to satisfy the whims of GCC. Well, that depends, right? So, the question is one of benefit vs. effort. If all warnings are useless and gcc never provided us any new insights we didn't already have (i.e. identify a real bug), it's probably not worth it. However, if gcc turned out to help us find real bugs and the changes are minor and clean, I see no problem silencing the noise a little. I believe we've done that in the past to make valgrind happier. That's essentially the issue of -Warray-bounds. Warray-bounds is a great concept, and to me on first glance should be super useful to a project like ffmpeg, given the number of loops, array manipulations/indexing, etc that are performed. Moreover, it is very easy to screw up the indexing and make off by one mistakes, etc which could lead to segfaults/corruption of buffers, and the like. Thus, I would have hoped this was more useful to ffmpeg. It seems like instead it can only catch simple cases, and in complex situations (like most cases in ffmpeg) it either does nothing or gives false positives. On a positive note, as above thread indicates, most spurious stuff has been silenced, and in ffmpeg, only two instances remain. I am happy to provide simple patches to silence these two cases, or try to work upstream with GCC to remove these spurious warnings. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] trying ffprobe on AAC file with LATM fails
Venelin Efremov veffremov.ve at gmail.com writes: I uploaded the file as aac_latm_non_byte_aligned.bin. How was this file produced / what software allows decoding? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avformat/async: avoid deadlock on close
---
libavformat/async.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index 1ab28d3..36c86d0 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -129,7 +129,8 @@ static void *async_buffer_task(void *arg)
if (c-io_eof_reached || fifo_space = 0) {
pthread_mutex_lock(c-mutex);
pthread_cond_signal(c-cond_wakeup_main);
-pthread_cond_wait(c-cond_wakeup_background, c-mutex);
+if (!async_interrupt_callback(h))
+pthread_cond_wait(c-cond_wakeup_background, c-mutex);
pthread_mutex_unlock(c-mutex);
continue;
}
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] fate: add test for async protocol
---
libavformat/Makefile | 3 +-
libavformat/async.c| 169 +
tests/fate/libavformat.mak | 4 ++
tests/ref/fate/async | 7 ++
4 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/async
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 108b6a6..cc73fd8 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -546,7 +546,8 @@ SLIBOBJS-$(HAVE_GNU_WINDRES) += avformatres.o
SKIPHEADERS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh.h
SKIPHEADERS-$(CONFIG_NETWORK)+= network.h rtsp.h
-TESTPROGS = seek\
+TESTPROGS = async \
+seek\
srtp\
url \
diff --git a/libavformat/async.c b/libavformat/async.c
index 0748309..1ab28d3 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -385,3 +385,172 @@ URLProtocol ff_async_protocol = {
.priv_data_size = sizeof(Context),
.priv_data_class = async_context_class,
};
+
+#ifdef TEST
+
+#define TEST_SEEK_POS(1536)
+#define TEST_STREAM_SIZE (2048)
+
+typedef struct TestContext {
+AVClass*class;
+size_t logical_pos;
+size_t logical_size;
+} TestContext;
+
+static int async_test_open(URLContext *h, const char *arg, int flags,
AVDictionary **options)
+{
+TestContext *c = h-priv_data;
+c-logical_pos = 0;
+c-logical_size = TEST_STREAM_SIZE;
+return 0;
+}
+
+static int async_test_close(URLContext *h)
+{
+return 0;
+}
+
+static int async_test_read(URLContext *h, unsigned char *buf, int size)
+{
+TestContext *c = h-priv_data;
+int read_len = 0;
+
+if (c-logical_pos = c-logical_size)
+return AVERROR_EOF;
+
+for (int i = 0; i size; ++i) {
+buf[i] = c-logical_pos 0xFF;
+
+c-logical_pos++;
+read_len++;
+
+if (c-logical_pos = c-logical_size)
+break;
+}
+
+return read_len;
+}
+
+static int64_t async_test_seek(URLContext *h, int64_t pos, int whence)
+{
+TestContext *c = h-priv_data;
+int64_t new_logical_pos;
+
+if (whence == AVSEEK_SIZE) {
+return c-logical_size;
+} if (whence == SEEK_CUR) {
+new_logical_pos = pos + c-logical_pos;
+} else if (whence == SEEK_SET){
+new_logical_pos = pos;
+} else {
+return AVERROR(EINVAL);
+}
+if (new_logical_pos 0)
+return AVERROR(EINVAL);
+
+c-logical_pos = new_logical_pos;
+return new_logical_pos;
+}
+
+static const AVClass async_test_context_class = {
+.class_name = Async-Test,
+.item_name = av_default_item_name,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+URLProtocol ff_async_test_protocol = {
+.name= async-test,
+.url_open2 = async_test_open,
+.url_read= async_test_read,
+.url_seek= async_test_seek,
+.url_close = async_test_close,
+.priv_data_size = sizeof(TestContext),
+.priv_data_class = async_test_context_class,
+};
+
+int main(void)
+{
+URLContext *h = NULL;
+int ret;
+int64_t size;
+int64_t pos;
+int64_t read_len;
+unsigned char buf[4096];
+
+ffurl_register_protocol(ff_async_protocol);
+ffurl_register_protocol(ff_async_test_protocol);
+
+ret = ffurl_open(h, async:async-test:, AVIO_FLAG_READ, NULL, NULL);
+printf(open: %d\n, ret);
+
+size = ffurl_size(h);
+printf(size: %PRId64\n, size);
+
+pos = ffurl_seek(h, 0, SEEK_CUR);
+read_len = 0;
+while (1) {
+ret = ffurl_read(h, buf, sizeof(buf));
+if (ret == AVERROR_EOF) {
+printf(read-error: AVERROR_EOF at %PRId64\n, ffurl_seek(h, 0,
SEEK_CUR));
+break;
+}
+else if (ret == 0)
+break;
+else if (ret 0) {
+printf(read-error: %d at %PRId64\n, ret, ffurl_seek(h, 0,
SEEK_CUR));
+goto fail;
+} else {
+for (int i = 0; i ret; ++i) {
+if (buf[i] != (pos 0xFF)) {
+printf(read-mismatch: actual %d, expecting %d, at
%PRId64\n,
+ (int)buf[i], (int)(pos 0xFF), pos);
+break;
+}
+pos++;
+}
+}
+
+read_len += ret;
+}
+printf(read: %PRId64\n, read_len);
+
+ret = ffurl_read(h, buf, 1);
+printf(read: %d\n, ret);
+
+pos = ffurl_seek(h, TEST_SEEK_POS, SEEK_SET);
+printf(seek: %PRId64\n, pos);
+
+read_len = 0;
+while (1) {
+ret = ffurl_read(h, buf, sizeof(buf));
+if (ret == AVERROR_EOF)
+break;
+
Re: [FFmpeg-devel] [PATCH] avcodec/options-test: don't alloc avctx-coded_frame
On Tue, Jul 21, 2015 at 12:29:15AM -0300, James Almer wrote: It's done automatically by avcodec_open2() now. Fixes memleaks in fate-libavcodec-options. Signed-off-by: James Almer jamr...@gmail.com --- libavcodec/options.c | 2 -- 1 file changed, 2 deletions(-) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] MAINTAINERS: add myself as a maintainer for async protocol
--- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 886ecae..6eff022 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -504,6 +504,7 @@ Muxers/Demuxers: wvenc.c Paul B Mahol Protocols: + async.c Zhang Rui bluray.c Petri Hintukainen ftp.c Lukasz Marek http.cRonald S. Bultje -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/8] lavf/http: increase range for listen, handle connection closing accordingly, add http_accept, add http_handshake and move handshake logic there
Le tridi 3 thermidor, an CCXXIII, Stephan Holljes a écrit :
From 2dc2be7e8576fd064579d37c75c343a6f18c068c Mon Sep 17 00:00:00 2001
From: Stephan Holljes klaxa1...@googlemail.com
Date: Fri, 3 Jul 2015 02:28:56 +0200
Subject: [PATCH 6/8] lavf/http: increase range for listen, handle connection
closing accordingly, add http_accept, add http_handshake and move handshake
logic there
Nit: Git practice advise to have a short first line and add details later,
with lines wrapped not too long (git log adds intendation).
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/http.c | 127
-
1 file changed, 106 insertions(+), 21 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index 676bfd5..b8016a7 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -25,6 +25,7 @@
#include zlib.h
#endif /* CONFIG_ZLIB */
+#include libavutil/avassert.h
#include libavutil/avstring.h
#include libavutil/opt.h
@@ -44,6 +45,9 @@
* path names). */
#define BUFFER_SIZE MAX_URL_SIZE
#define MAX_REDIRECTS 8
+#define HTTP_ONESHOT 1
+#define HTTP_MUTLI2
+#define HTTP_MULTI_CLIENT 4
Are they supposed to be flags? Otherwise: where did 3 go?
typedef struct HTTPContext {
const AVClass *class;
@@ -97,6 +101,7 @@ typedef struct HTTPContext {
char *method;
int reconnect;
int listen;
+char *resource;
} HTTPContext;
#define OFFSET(x) offsetof(HTTPContext, x)
@@ -128,7 +133,9 @@ static const AVOption options[] = {
{ end_offset, try to limit the request to bytes preceding this
offset, OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D },
{ method, Override the HTTP method or set the expected HTTP method
from a client, OFFSET(method), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D
| E },
{ reconnect, auto reconnect after disconnect before EOF,
OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
-{ listen, listen on HTTP, OFFSET(listen), AV_OPT_TYPE_INT, { .i64 =
0 }, 0, 1, D | E },
+{ listen, listen on HTTP, OFFSET(listen), AV_OPT_TYPE_INT, { .i64 =
0 }, 0, 4, D | E },
Does it make sense for the application/user to set 4? If not, then a
separate field may be better.
+{ resource, The resource requested by a client, OFFSET(resource),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
+{ http_code, The http code to send to a client, OFFSET(http_code),
AV_OPT_TYPE_INT, { .i64 = 0}, 0, 599, E},
Nit: Since this is HTTP anyway, the name is redundant. Maybe reply_code?
{ NULL }
};
@@ -299,32 +306,87 @@ int ff_http_averror(int status_code, int
default_averror)
return default_averror;
}
+static int http_write_header(URLContext* h, int status_code)
The name is misleading: it does not only write the header, it also writes a
single-line reply, except in the 200 case. More on that later.
+{
+int ret;
+const char *message;
+// Maybe this should be done more elegantly?
+static const char bad_request[] = HTTP/1.1 400 Bad
Request\r\nContent-Type: text/plain\r\nContent-Length: 17\r\n400 Bad
Request\r\n;
+static const char forbidden[] = HTTP/1.1 403 Forbidden\r\nContent-Type:
text/plain\r\nContent-Length: 15\r\n\r\n403 Forbidden\r\n;
+static const char not_found[] = HTTP/1.1 404 Not Found\r\nContent-Type:
text/plain\r\nContent-Length: 15\r\n\r\n404 Not Found\r\n;
+static const char internal_server_error[] = HTTP/1.1 500 Internal
server error\r\nContent-Type: text/plain\r\nContent-Length: 25\r\n\r\n500
Internal server error\r\n;
Well, all the reply strings have the following format:
HTTP/1.1 %03d %s\r\n
Content-Type: application/octet-stream\r\n
Content-Length: %d\r\n
\r\n
%03d %s\r\n
So you can probably have just int reply_code and const char *reply_text
and fill in in a local buffer.
+static const char ok[] = HTTP/1.1 200 OK\r\nContent-Type:
application/octet-stream\r\nTransfer-Encoding: chunked\r\n\r\n;
+av_log(h, AV_LOG_TRACE, err: %d\n, status_code);
+if (status_code == 200) {
+message = ok;
+goto end;
+}
It could go back inside the switch. That avoids the goto.
+switch(status_code) {
+case AVERROR_HTTP_BAD_REQUEST:
Nit: usual style is switchspace{ and case indented at the same level.
+message = bad_request;
+break;
+case AVERROR_HTTP_FORBIDDEN:
+message = forbidden;
+break;
+case AVERROR_HTTP_NOT_FOUND:
+message = not_found;
+break;
+default:
+message = internal_server_error;
+}
+end:
+if ((ret = ffurl_write(h, message, strlen(message))) 0)
+return ret;
+// Avoid returning a positive value from ffurl_write()
+ret = ret 0 ? 0 : ret;
+return ret;
If I read the logic correctly, ret is always 0 when it
Re: [FFmpeg-devel] [PATCH 3/3] avformat/async: avoid deadlock on close
On Tue, Jul 21, 2015 at 03:46:04PM +0800, Zhang Rui wrote:
---
libavformat/async.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index 1ab28d3..36c86d0 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -129,7 +129,8 @@ static void *async_buffer_task(void *arg)
if (c-io_eof_reached || fifo_space = 0) {
pthread_mutex_lock(c-mutex);
pthread_cond_signal(c-cond_wakeup_main);
-pthread_cond_wait(c-cond_wakeup_background, c-mutex);
+if (!async_interrupt_callback(h))
+pthread_cond_wait(c-cond_wakeup_background, c-mutex);
i dont think this can work
the callback could return 0 here and 1 for the other call
also the if (!ret) in async_interrupt_callback() looks odd
should that be a if (ret) ?
also ff_check_interrupt() could be used in async_interrupt_callback()
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
What does censorship reveal? It reveals fear. -- Julian Assange
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] fate: add test for async protocol
2015-07-21 17:22 GMT+08:00 Michael Niedermayer mich...@niedermayer.cc:
On Tue, Jul 21, 2015 at 03:46:03PM +0800, Zhang Rui wrote:
---
libavformat/Makefile | 3 +-
libavformat/async.c| 169
+
tests/fate/libavformat.mak | 4 ++
tests/ref/fate/async | 7 ++
4 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/async
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 108b6a6..cc73fd8 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -546,7 +546,8 @@ SLIBOBJS-$(HAVE_GNU_WINDRES) += avformatres.o
SKIPHEADERS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh.h
SKIPHEADERS-$(CONFIG_NETWORK)+= network.h rtsp.h
-TESTPROGS = seek\
+TESTPROGS = async \
+seek\
srtp\
url \
diff --git a/libavformat/async.c b/libavformat/async.c
index 0748309..1ab28d3 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -385,3 +385,172 @@ URLProtocol ff_async_protocol = {
.priv_data_size = sizeof(Context),
.priv_data_class = async_context_class,
};
+
+#ifdef TEST
+
+#define TEST_SEEK_POS(1536)
+#define TEST_STREAM_SIZE (2048)
+
+typedef struct TestContext {
+AVClass*class;
+size_t logical_pos;
+size_t logical_size;
+} TestContext;
+
+static int async_test_open(URLContext *h, const char *arg, int flags,
AVDictionary **options)
+{
+TestContext *c = h-priv_data;
+c-logical_pos = 0;
+c-logical_size = TEST_STREAM_SIZE;
+return 0;
+}
+
+static int async_test_close(URLContext *h)
+{
+return 0;
+}
+
+static int async_test_read(URLContext *h, unsigned char *buf, int size)
+{
+TestContext *c = h-priv_data;
+int read_len = 0;
+
+if (c-logical_pos = c-logical_size)
+return AVERROR_EOF;
+
+for (int i = 0; i size; ++i) {
some compilers have problems with the for(int ... syntax
I'll fix it.
+buf[i] = c-logical_pos 0xFF;
+
+c-logical_pos++;
+read_len++;
+
+if (c-logical_pos = c-logical_size)
+break;
+}
+
+return read_len;
+}
+
+static int64_t async_test_seek(URLContext *h, int64_t pos, int whence)
+{
+TestContext *c = h-priv_data;
+int64_t new_logical_pos;
+
+if (whence == AVSEEK_SIZE) {
+return c-logical_size;
+} if (whence == SEEK_CUR) {
else if
+new_logical_pos = pos + c-logical_pos;
+} else if (whence == SEEK_SET){
+new_logical_pos = pos;
+} else {
+return AVERROR(EINVAL);
+}
+if (new_logical_pos 0)
+return AVERROR(EINVAL);
+
+c-logical_pos = new_logical_pos;
+return new_logical_pos;
+}
+
+static const AVClass async_test_context_class = {
+.class_name = Async-Test,
+.item_name = av_default_item_name,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+URLProtocol ff_async_test_protocol = {
+.name= async-test,
+.url_open2 = async_test_open,
+.url_read= async_test_read,
+.url_seek= async_test_seek,
+.url_close = async_test_close,
+.priv_data_size = sizeof(TestContext),
+.priv_data_class = async_test_context_class,
+};
+
+int main(void)
+{
+URLContext *h = NULL;
+int ret;
+int64_t size;
+int64_t pos;
+int64_t read_len;
+unsigned char buf[4096];
+
+ffurl_register_protocol(ff_async_protocol);
+ffurl_register_protocol(ff_async_test_protocol);
+
+ret = ffurl_open(h, async:async-test:, AVIO_FLAG_READ, NULL, NULL);
+printf(open: %d\n, ret);
+
+size = ffurl_size(h);
+printf(size: %PRId64\n, size);
+
+pos = ffurl_seek(h, 0, SEEK_CUR);
+read_len = 0;
+while (1) {
+ret = ffurl_read(h, buf, sizeof(buf));
+if (ret == AVERROR_EOF) {
+printf(read-error: AVERROR_EOF at %PRId64\n, ffurl_seek(h,
0, SEEK_CUR));
+break;
+}
+else if (ret == 0)
+break;
+else if (ret 0) {
+printf(read-error: %d at %PRId64\n, ret, ffurl_seek(h, 0,
SEEK_CUR));
+goto fail;
+} else {
+for (int i = 0; i ret; ++i) {
+if (buf[i] != (pos 0xFF)) {
+printf(read-mismatch: actual %d, expecting %d, at
%PRId64\n,
+ (int)buf[i], (int)(pos 0xFF), pos);
+break;
+}
+pos++;
+}
+}
Re: [FFmpeg-devel] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
Le tridi 3 thermidor, an CCXXIII, Rodney Baker a écrit : I'm not a lawyer, so I can't comment authoritatively on the copyright laws - I don't think they're that bad, though. IANAL either, this is not strictly-speaking copyright and the truth is in Wikipedia, but I found this: In Australia, [...] but if the method is implemented using a computer, it avoids the exclusion for business methods. Compared to, for example: In April 2013, the German Parliament adopted a joint motion against the growing trend of patent offices to grant patents on software programs. Since FFmpeg is quite exposed to patent- and copyright-trolls, local law is probably a fact that needs to be taken into account. We do not want the hosting to be seized just because someone made an informal complaint between two doors. OTOH, VLC seems hosted in the land of the DMCA and is just fine. (Maybe we should ask Mega to host us in New Zealand ;-) Cost very much depends on what you're looking for. I found them competitive for my needs (but then, they're also local). You could also look at Rackspace (UK based, claim to be Linux specialists) but I know only what I've seen in their ads in Linux Format magazine. YMMV. I was just surprised to see that much discrepancy between Australian and European prices, especially in that direction: twice the price for less than half the power. And IIRC, someone insisted that unmetered traffic was absolutely necessary. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavfilter/vf_scale: implement process_command
Signed-off-by: Bernd Bleßmann b...@it-entwicklung.de
---
doc/filters.texi | 13 +
libavfilter/vf_scale.c | 43 ++-
2 files changed, 47 insertions(+), 9 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 2b0359d..28aaef3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8906,6 +8906,19 @@ scale=w='min(500\, iw*3/2):h=-1'
@end example
@end itemize
+@subsection Commands
+
+This filter supports the following commands:
+@table @option
+@item width, w
+@item height, h
+Set the output video dimension expression.
+The command accepts the same syntax of the corresponding option.
+
+If the specified expression is not valid, it is kept at its current
+value.
+@end table
+
@section separatefields
The @code{separatefields} takes a frame-based video input and splits
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 2a3d008..d4c0be2 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -544,6 +544,30 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
return ff_filter_frame(outlink, out);
}
+static int process_command(AVFilterContext *ctx, const char *cmd, const char
*args,
+ char *res, int res_len, int flags)
+{
+ScaleContext *scale = ctx-priv;
+int ret;
+
+if ( !strcmp(cmd, width) || !strcmp(cmd, w)
+|| !strcmp(cmd, height) || !strcmp(cmd, h)) {
+
+int old_w = scale-w;
+int old_h = scale-h;
+AVFilterLink *outlink = ctx-outputs[0];
+
+av_opt_set(scale, cmd, args, 0);
+if ((ret = config_props(outlink)) 0) {
+scale-w = old_w;
+scale-h = old_h;
+}
+} else
+ret = AVERROR(ENOSYS);
+
+return ret;
+}
+
static const AVClass *child_class_next(const AVClass *prev)
{
return prev ? NULL : sws_get_class();
@@ -610,13 +634,14 @@ static const AVFilterPad avfilter_vf_scale_outputs[] = {
};
AVFilter ff_vf_scale = {
-.name = scale,
-.description = NULL_IF_CONFIG_SMALL(Scale the input video size and/or
convert the image format.),
-.init_dict = init_dict,
-.uninit= uninit,
-.query_formats = query_formats,
-.priv_size = sizeof(ScaleContext),
-.priv_class= scale_class,
-.inputs= avfilter_vf_scale_inputs,
-.outputs = avfilter_vf_scale_outputs,
+.name= scale,
+.description = NULL_IF_CONFIG_SMALL(Scale the input video size and/or
convert the image format.),
+.init_dict = init_dict,
+.uninit = uninit,
+.query_formats = query_formats,
+.priv_size = sizeof(ScaleContext),
+.priv_class = scale_class,
+.inputs = avfilter_vf_scale_inputs,
+.outputs = avfilter_vf_scale_outputs,
+.process_command = process_command,
};
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavfilter/vf_crop: implement process_command
Signed-off-by: Bernd Bleßmann b...@it-entwicklung.de
---
doc/filters.texi | 20 +--
libavfilter/vf_crop.c | 53 +++
2 files changed, 63 insertions(+), 10 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 28aaef3..348e8d7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3481,12 +3481,12 @@ It accepts the following parameters:
@item w, out_w
The width of the output video. It defaults to @code{iw}.
This expression is evaluated only once during the filter
-configuration.
+configuration, or when the @samp{w} or @samp{out_w} command is sent.
@item h, out_h
The height of the output video. It defaults to @code{ih}.
This expression is evaluated only once during the filter
-configuration.
+configuration, or when the @samp{h} or @samp{out_h} command is sent.
@item x
The horizontal position, in the input video, of the left edge of the output
@@ -3646,6 +3646,22 @@ crop=in_w/2:in_h/2:y:10+10*sin(n/10)
@end example
@end itemize
+@subsection Commands
+
+This filter supports the following commands:
+@table @option
+@item w, out_w
+@item h, out_h
+@item x
+@item y
+Set width/height of the output video and the horizontal/vertical position
+in the input video.
+The command accepts the same syntax of the corresponding option.
+
+If the specified expression is not valid, it is kept at its current
+value.
+@end table
+
@section cropdetect
Auto-detect the crop size.
diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
index f58a7ae..5679a44 100644
--- a/libavfilter/vf_crop.c
+++ b/libavfilter/vf_crop.c
@@ -296,6 +296,42 @@ static int filter_frame(AVFilterLink *link, AVFrame *frame)
return ff_filter_frame(link-dst-outputs[0], frame);
}
+static int process_command(AVFilterContext *ctx, const char *cmd, const char
*args,
+ char *res, int res_len, int flags)
+{
+CropContext *s = ctx-priv;
+int ret;
+
+if ( !strcmp(cmd, out_w) || !strcmp(cmd, w)
+|| !strcmp(cmd, out_h) || !strcmp(cmd, h)
+|| !strcmp(cmd, x) || !strcmp(cmd, y)) {
+
+int old_x = s-x;
+int old_y = s-y;
+int old_w = s-w;
+int old_h = s-h;
+
+AVFilterLink *outlink = ctx-outputs[0];
+AVFilterLink *inlink = ctx-inputs[0];
+
+av_opt_set(s, cmd, args, 0);
+
+if ((ret = config_input(inlink)) 0) {
+s-x = old_x;
+s-y = old_y;
+s-w = old_w;
+s-h = old_h;
+return ret;
+}
+
+ret = config_output(outlink);
+
+} else
+ret = AVERROR(ENOSYS);
+
+return ret;
+}
+
#define OFFSET(x) offsetof(CropContext, x)
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
@@ -332,12 +368,13 @@ static const AVFilterPad avfilter_vf_crop_outputs[] = {
};
AVFilter ff_vf_crop = {
-.name = crop,
-.description = NULL_IF_CONFIG_SMALL(Crop the input video.),
-.priv_size = sizeof(CropContext),
-.priv_class= crop_class,
-.query_formats = query_formats,
-.uninit= uninit,
-.inputs= avfilter_vf_crop_inputs,
-.outputs = avfilter_vf_crop_outputs,
+.name= crop,
+.description = NULL_IF_CONFIG_SMALL(Crop the input video.),
+.priv_size = sizeof(CropContext),
+.priv_class = crop_class,
+.query_formats = query_formats,
+.uninit = uninit,
+.inputs = avfilter_vf_crop_inputs,
+.outputs = avfilter_vf_crop_outputs,
+.process_command = process_command,
};
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Replace AV_PKT_DATA_QUALITY_FACTOR by AV_PKT_DATA_QUALITY_STATS
From: Michael Niedermayer mich...@niedermayer.cc
The stats are a superset of the quality factor, also allowing the picture type
and encoder PSNR stats to be exported
This also replaces the native by fixed little endian order for the affected
side data
TODO: set pict_type for all encoders which export AV_PKT_DATA_QUALITY_STATS
Signed-off-by: Michael Niedermayer mich...@niedermayer.cc
---
doc/APIchanges |5 +++--
ffmpeg.c |4 ++--
libavcodec/avcodec.h | 15 +++
libavcodec/avpacket.c | 25 +
libavcodec/dnxhdenc.c |5 +
libavcodec/internal.h |2 ++
libavcodec/libx264.c |6 +-
libavcodec/libxavs.c |5 +
libavcodec/libxvid.c | 25 +
libavcodec/mpegvideo_enc.c |6 +-
libavcodec/svq1enc.c |5 +
libavcodec/version.h |4 ++--
libavformat/dump.c |4 ++--
13 files changed, 65 insertions(+), 46 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index a7d9952..e90e23e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,8 +15,9 @@ libavutil: 2014-08-09
API changes, most recent first:
-2015-xx-xx - xxx - lavc 56.33.0 - avcodec.h
- Add AV_PKT_DATA_QUALITY_FACTOR to export the quality value of an AVPacket.
+2015-xx-xx - xxx - lavc 56.51.100 - avcodec.h
+ Add AV_PKT_DATA_QUALITY_STATS to export the quality value, PSNR, and
pict_type
+ of an AVPacket.
2015-07-16 - - lavc 56.49.100
Add av_codec_get_codec_properties(), FF_CODEC_PROPERTY_LOSSLESS
diff --git a/ffmpeg.c b/ffmpeg.c
index ce9cac7..751c7d3 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -669,9 +669,9 @@ static void write_frame(AVFormatContext *s, AVPacket *pkt,
OutputStream *ost)
ost-frame_number++;
}
if (avctx-codec_type == AVMEDIA_TYPE_VIDEO) {
-uint8_t *sd = av_packet_get_side_data(pkt, AV_PKT_DATA_QUALITY_FACTOR,
+uint8_t *sd = av_packet_get_side_data(pkt, AV_PKT_DATA_QUALITY_STATS,
NULL);
-ost-quality = sd ? *(int *)sd : -1;
+ost-quality = sd ? AV_RL32(sd) : -1;
}
if (bsfc)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 6cfbea4..a86a152 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1055,11 +1055,16 @@ enum AVPacketSideDataType {
AV_PKT_DATA_AUDIO_SERVICE_TYPE,
/**
- * This side data contains an integer value representing the quality
- * factor of the compressed frame. Allowed range is between 1 (good)
- * and FF_LAMBDA_MAX (bad).
+ * This side data contains quality related information from the encoder.
+ * @code
+ * u32le quality factor of the compressed frame. Allowed range is between
1 (good) and FF_LAMBDA_MAX (bad).
+ * u8picture type
+ * u8error count
+ * u16 reserved
+ * u64le[error count] sum of squared differences between encoder in and
output
+ * @endcode
*/
-AV_PKT_DATA_QUALITY_FACTOR,
+AV_PKT_DATA_QUALITY_STATS,
/**
* Recommmends skipping the specified number of samples
@@ -1126,6 +1131,8 @@ enum AVPacketSideDataType {
AV_PKT_DATA_METADATA_UPDATE,
};
+#define AV_PKT_DATA_QUALITY_FACTOR
please_use_AV_PKT_DATA_QUALITY_STATS_which_is_a_superset_of_it
+
typedef struct AVPacketSideData {
uint8_t *data;
int size;
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index aae67c5..6ba9c0b 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -602,3 +602,28 @@ void av_packet_rescale_ts(AVPacket *pkt, AVRational
src_tb, AVRational dst_tb)
if (pkt-convergence_duration 0)
pkt-convergence_duration = av_rescale_q(pkt-convergence_duration,
src_tb, dst_tb);
}
+
+int ff_side_data_set_encoder_stats(AVPacket *pkt, int quality, int64_t *error,
int error_count, int pict_type)
+{
+uint8_t *side_data;
+int side_data_size;
+int i;
+
+side_data = av_packet_get_side_data(pkt, AV_PKT_DATA_QUALITY_STATS,
side_data_size);
+if (!side_data) {
+side_data_size = 4+4+8*error_count;
+side_data = av_packet_new_side_data(pkt, AV_PKT_DATA_QUALITY_STATS,
+side_data_size);
+}
+
+if (!side_data || side_data_size 4+4+8*error_count)
+return AVERROR(ENOMEM);
+
+AV_WL32(side_data , quality );
+side_data[4] = pict_type;
+side_data[5] = error_count;
+for (i = 0; ierror_count; i++)
+AV_WL64(side_data+8 + 8*i , error[i]);
+
+return 0;
+}
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 9302402..3f5f17f 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -1115,10 +1115,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
FF_ENABLE_DEPRECATION_WARNINGS
#endif
-sd = av_packet_new_side_data(pkt, AV_PKT_DATA_QUALITY_FACTOR, sizeof(int));
-if (!sd)
-return AVERROR(ENOMEM);
-*(int *)sd =
Re: [FFmpeg-devel] [PATCH 2/3] aacenc: move the generation of ff_aac_pow34sf_tab[]
On Tue, Jul 21, 2015 at 02:46:54AM -0300, Claudio Freire wrote: On Mon, Jul 20, 2015 at 10:05 PM, Claudio Freire klaussfre...@gmail.com wrote: This will need rebasing, the fixed tablegen got in recently On Fri, Jul 17, 2015 at 6:20 PM, Rostislav Pehlivanov atomnu...@gmail.com wrote: This commit moves the generation of ff_aac_pow34sf_tab[] out of the encoder and into the table generator. The original commit log for this table in 2011 actually mentions that it should be moved outside but this never happened. This is the first commit which cleans up the encoder a little. --- libavcodec/aac_tablegen.c | 2 ++ libavcodec/aac_tablegen.h | 5 - libavcodec/aac_tablegen_decl.h | 2 ++ libavcodec/aaccoder.c | 1 + libavcodec/aacenc.c| 4 libavcodec/aacenc.h| 2 -- 6 files changed, 9 insertions(+), 7 deletions(-) Forget I said anything, the tablegen changes that got in don't conflict. LGTM then. applied thanks [...] -- 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] Replace AV_PKT_DATA_QUALITY_FACTOR by AV_PKT_DATA_QUALITY_STATS
Le tridi 3 thermidor, an CCXXIII, Michael Niedermayer a écrit : -AV_PKT_DATA_QUALITY_FACTOR, +AV_PKT_DATA_QUALITY_STATS, +#define AV_PKT_DATA_QUALITY_FACTOR please_use_AV_PKT_DATA_QUALITY_STATS_which_is_a_superset_of_it It breaks source compatibility with the fork. Is it on purpose? Is there a drawback in making AV_PKT_DATA_QUALITY_FACTOR a synonym of AV_PKT_DATA_QUALITY_STATS (possibly with a deprecation warning if possible) instead? 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] Replace AV_PKT_DATA_QUALITY_FACTOR by AV_PKT_DATA_QUALITY_STATS
On Tue, Jul 21, 2015 at 01:41:59PM +0200, Nicolas George wrote: Le tridi 3 thermidor, an CCXXIII, Michael Niedermayer a écrit : -AV_PKT_DATA_QUALITY_FACTOR, +AV_PKT_DATA_QUALITY_STATS, +#define AV_PKT_DATA_QUALITY_FACTOR please_use_AV_PKT_DATA_QUALITY_STATS_which_is_a_superset_of_it It breaks source compatibility with the fork. Is it on purpose? Is there a drawback in making AV_PKT_DATA_QUALITY_FACTOR a synonym of AV_PKT_DATA_QUALITY_STATS (possibly with a deprecation warning if possible) instead? i wasnt sure how to make it show a deprecation warning, do you have an idea ? the drawback without any warning is that endianness mismatches on big endian and that could lead to bugs [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] MAINTAINERS: add myself as a maintainer for async protocol
On Tue, Jul 21, 2015 at 03:46:02PM +0800, Zhang Rui wrote: --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) applied thanks [...] -- 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 4/8] lavf/tcp: add tcp_accept
Le tridi 3 thermidor, an CCXXIII, Stephan Holljes a écrit :
From 12d9a1e1c511615275260977941aff3067f103ea Mon Sep 17 00:00:00 2001
From: Stephan Holljes klaxa1...@googlemail.com
Date: Tue, 21 Jul 2015 06:10:25 +0200
Subject: [PATCH 4/8] lavf/tcp: add tcp_accept
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/tcp.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index f24cad2..9f8c2a0 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -19,6 +19,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
*/
#include avformat.h
+#include libavutil/avassert.h
#include libavutil/parseutils.h
#include libavutil/opt.h
#include libavutil/time.h
@@ -163,6 +164,23 @@ static int tcp_open(URLContext *h, const char *uri, int
flags)
return ret;
}
+static int tcp_accept(URLContext *s, URLContext **c)
+{
+TCPContext *sc = s-priv_data;
+TCPContext *cc;
+int ret;
+av_assert0(sc-listen);
+if ((ret = ffurl_alloc(c, s-filename, s-flags (AVIO_FLAG_READ_WRITE
| AVIO_FLAG_DIRECT),
+ s-interrupt_callback)) 0)
What about NONBLOCK? If the client is non-blocking, the application will
probably also want non-blocking clients.
AFAICS, currently, all the flags are relevant to clients, you can probably
pass s-flags entirely, and leave the issue to the person who introduce
server-specific flags.
+return ret;
+cc = (*c)-priv_data;
+ret = ff_accept(sc-fd, sc-listen_timeout, s);
+if (ret 0)
+return ff_neterrno();
+cc-fd = ret;
+return 0;
+}
+
static int tcp_read(URLContext *h, uint8_t *buf, int size)
{
TCPContext *s = h-priv_data;
@@ -223,6 +241,7 @@ static int tcp_get_file_handle(URLContext *h)
URLProtocol ff_tcp_protocol = {
.name= tcp,
.url_open= tcp_open,
+.url_accept = tcp_accept,
.url_read= tcp_read,
.url_write = tcp_write,
.url_close = tcp_close,
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]Set CODEC_PROPERTY_LOSSLESS for j2k for dwt53
Michael Niedermayer michael at niedermayer.cc writes:
+else if (c-transform == FF_DWT53) {
+s-avctx-properties |= FF_CODEC_PROPERTY_LOSSLESS;
+}
LGTM
The patch was merged.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] fate: add test for async protocol
On Tue, Jul 21, 2015 at 03:46:03PM +0800, Zhang Rui wrote:
---
libavformat/Makefile | 3 +-
libavformat/async.c| 169
+
tests/fate/libavformat.mak | 4 ++
tests/ref/fate/async | 7 ++
4 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/async
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 108b6a6..cc73fd8 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -546,7 +546,8 @@ SLIBOBJS-$(HAVE_GNU_WINDRES) += avformatres.o
SKIPHEADERS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh.h
SKIPHEADERS-$(CONFIG_NETWORK)+= network.h rtsp.h
-TESTPROGS = seek\
+TESTPROGS = async \
+seek\
srtp\
url \
diff --git a/libavformat/async.c b/libavformat/async.c
index 0748309..1ab28d3 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -385,3 +385,172 @@ URLProtocol ff_async_protocol = {
.priv_data_size = sizeof(Context),
.priv_data_class = async_context_class,
};
+
+#ifdef TEST
+
+#define TEST_SEEK_POS(1536)
+#define TEST_STREAM_SIZE (2048)
+
+typedef struct TestContext {
+AVClass*class;
+size_t logical_pos;
+size_t logical_size;
+} TestContext;
+
+static int async_test_open(URLContext *h, const char *arg, int flags,
AVDictionary **options)
+{
+TestContext *c = h-priv_data;
+c-logical_pos = 0;
+c-logical_size = TEST_STREAM_SIZE;
+return 0;
+}
+
+static int async_test_close(URLContext *h)
+{
+return 0;
+}
+
+static int async_test_read(URLContext *h, unsigned char *buf, int size)
+{
+TestContext *c = h-priv_data;
+int read_len = 0;
+
+if (c-logical_pos = c-logical_size)
+return AVERROR_EOF;
+
+for (int i = 0; i size; ++i) {
some compilers have problems with the for(int ... syntax
+buf[i] = c-logical_pos 0xFF;
+
+c-logical_pos++;
+read_len++;
+
+if (c-logical_pos = c-logical_size)
+break;
+}
+
+return read_len;
+}
+
+static int64_t async_test_seek(URLContext *h, int64_t pos, int whence)
+{
+TestContext *c = h-priv_data;
+int64_t new_logical_pos;
+
+if (whence == AVSEEK_SIZE) {
+return c-logical_size;
+} if (whence == SEEK_CUR) {
else if
+new_logical_pos = pos + c-logical_pos;
+} else if (whence == SEEK_SET){
+new_logical_pos = pos;
+} else {
+return AVERROR(EINVAL);
+}
+if (new_logical_pos 0)
+return AVERROR(EINVAL);
+
+c-logical_pos = new_logical_pos;
+return new_logical_pos;
+}
+
+static const AVClass async_test_context_class = {
+.class_name = Async-Test,
+.item_name = av_default_item_name,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+URLProtocol ff_async_test_protocol = {
+.name= async-test,
+.url_open2 = async_test_open,
+.url_read= async_test_read,
+.url_seek= async_test_seek,
+.url_close = async_test_close,
+.priv_data_size = sizeof(TestContext),
+.priv_data_class = async_test_context_class,
+};
+
+int main(void)
+{
+URLContext *h = NULL;
+int ret;
+int64_t size;
+int64_t pos;
+int64_t read_len;
+unsigned char buf[4096];
+
+ffurl_register_protocol(ff_async_protocol);
+ffurl_register_protocol(ff_async_test_protocol);
+
+ret = ffurl_open(h, async:async-test:, AVIO_FLAG_READ, NULL, NULL);
+printf(open: %d\n, ret);
+
+size = ffurl_size(h);
+printf(size: %PRId64\n, size);
+
+pos = ffurl_seek(h, 0, SEEK_CUR);
+read_len = 0;
+while (1) {
+ret = ffurl_read(h, buf, sizeof(buf));
+if (ret == AVERROR_EOF) {
+printf(read-error: AVERROR_EOF at %PRId64\n, ffurl_seek(h,
0, SEEK_CUR));
+break;
+}
+else if (ret == 0)
+break;
+else if (ret 0) {
+printf(read-error: %d at %PRId64\n, ret, ffurl_seek(h, 0,
SEEK_CUR));
+goto fail;
+} else {
+for (int i = 0; i ret; ++i) {
+if (buf[i] != (pos 0xFF)) {
+printf(read-mismatch: actual %d, expecting %d, at
%PRId64\n,
+ (int)buf[i], (int)(pos 0xFF), pos);
+break;
+}
+pos++;
+}
+}
+
+read_len += ret;
+}
+printf(read: %PRId64\n, read_len);
+
+
Re: [FFmpeg-devel] [PATCH 5/8] lavf/tcp: increase range for listen and call the underlying socket operations accordingly
Le tridi 3 thermidor, an CCXXIII, Stephan Holljes a écrit :
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/tcp.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index 6f5e175..5505945 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -45,7 +45,7 @@ typedef struct TCPContext {
#define D AV_OPT_FLAG_DECODING_PARAM
#define E AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
-{ listen, Listen for incoming connections, OFFSET(listen),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags = D|E },
+{ listen, Listen for incoming connections, OFFSET(listen),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2, .flags = D|E },
{ timeout, set timeout (in microseconds) of socket I/O
operations, OFFSET(rw_timeout), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, INT_MAX, .flags = D|E },
{ listen_timeout, Connection awaiting timeout (in milliseconds),
OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
INT_MAX, .flags = D|E },
{ NULL }
@@ -126,12 +126,18 @@ static int tcp_open(URLContext *h, const char *uri, int
flags)
goto fail;
}
-if (s-listen) {
-if ((ret = ff_listen_bind(fd, cur_ai-ai_addr, cur_ai-ai_addrlen,
- s-listen_timeout, h)) 0) {
+if (s-listen == 2) {
+// multi-client
+if ((ret = ff_listen(fd, cur_ai-ai_addr, cur_ai-ai_addrlen)) 0) {
+goto fail1;
+}
Nit: braces are unnecessary.
+} else if (s-listen == 1) {
+// single client
+if ((fd = ff_listen_bind(fd, cur_ai-ai_addr, cur_ai-ai_addrlen,
+ s-listen_timeout, h)) 0) {
+ret = fd;
goto fail1;
}
-fd = ret;
} else {
if ((ret = ff_listen_connect(fd, cur_ai-ai_addr, cur_ai-ai_addrlen,
s-open_timeout / 1000, h,
!!cur_ai-ai_next)) 0) {
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/utils: silence some deprecation warnings
On Tue, Jul 21, 2015 at 12:46:18AM -0300, James Almer wrote: And prevent eventual compilation failures once the relevant functions and fields are removed. Signed-off-by: James Almer jamr...@gmail.com --- libavcodec/utils.c | 13 + 1 file changed, 13 insertions(+) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/8] lavf/avio: add ffurl_accept and ffurl_handshake
Le tridi 3 thermidor, an CCXXIII, Stephan Holljes a écrit :
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/avio.c | 19 +++
libavformat/url.h | 18 ++
2 files changed, 37 insertions(+)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index c188adc..1182336 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -211,6 +211,25 @@ int ffurl_connect(URLContext *uc, AVDictionary **options)
return 0;
}
+int ffurl_accept(URLContext *s, URLContext **c)
+{
Maybe av_assert0(!*c); here would make sense: the application would have
to clear the pointer initially. That way, we are free to expand the API
later to allow using a context that was already allocated or something. If
you think it makes sense, do not forget to update the doxys.
+if (s-prot-url_accept)
+return s-prot-url_accept(s, c);
+return 0;
I had not spotted it earlier: an error code here would probably make more
sense. AVERROR(EBADF) would probably be the best choice, it is supposed to
be portable.
+}
+
+int ffurl_handshake(URLContext *c)
+{
+int ret;
+if (c-prot-url_handshake) {
+ret = c-prot-url_handshake(c);
+if (ret)
+return ret;
+}
+c-is_connected = 1;
+return 0;
+}
+
#define URL_SCHEME_CHARS\
abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ\
diff --git a/libavformat/url.h b/libavformat/url.h
index 99a3201..d010a77 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -58,6 +58,8 @@ typedef struct URLProtocol {
* for those nested protocols.
*/
int (*url_open2)(URLContext *h, const char *url, int flags,
AVDictionary **options);
+int (*url_accept)(URLContext *s, URLContext **c);
+int (*url_handshake)(URLContext *c);
Since the API has become non-trivial, it needs a doxy. I suggest something
like this:
/**
* Perform one step of the protocol handshake to accept a new client.
* See avio_handshake() for details.
* Implementations should try to return decreasing values.
* If the protocol uses an underlying protocol, the underlying handshake is
* usually the first step, and the return value can be:
* (largest value for this protocol) + (return value from other protocol)
*/
It references a doxy that is in a later patch; this would be a deal breaker
if it was a function call, but for a doxy that seems acceptable.
The doxy for avio_handshake() must explain in more details:
/**
* Perform one step of the protocol handshake to accept a new client.
* This function must be called on a client returned by avio_accept() before
* using as a read/write context.
* It is separate from avio_accept() because it may block.
* A step of the handshake is defined by places where the application may
* decide to change the proceedings.
* For example, on a protocol with a request header and a reply header, each
* one can constitute a step because the application may use the parameters
* from the request to change parameters in the reply; or each individual
* chunk of the request can constitute a step.
*
* @return 0 if the handshake is complete and successful;
* 0 if the handshake has progressed but is not complete;
* 0 for an AVERROR code
*/
Feel free to alter the wording if you find better.
/**
* Read data from the protocol.
@@ -140,6 +142,22 @@ int ffurl_open(URLContext **puc, const char *filename,
int flags,
const AVIOInterruptCB *int_cb, AVDictionary **options);
/**
+ * Accept an URLContext c on an URLContext s
+ * @param s server context
+ * @param c client context
+ * @return = 0 on success, ff_neterrno() on failure.
+ */
+int ffurl_accept(URLContext *s, URLContext **c);
+
+/**
+ * Perform a protocol handshake on the passed client context.
+ * @param c the client context
+ * @return = 0 on success or a negative value corresponding
+ * to an AVERROR code on failure
+ */
+int ffurl_handshake(URLContext *c);
+
+/**
* Read up to size bytes from the resource accessed by h, and store
* the read bytes in buf.
*
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]lavf/rtpenc_jpeg: Warn if number of present quantization tables is not two
Carl Eugen Hoyos cehoyos at ag.or.at writes: +if (nb_qtables nb_qtables != 2) +av_log(s1, AV_LOG_WARNING, + RFC 2435 suggests two quantization tables, %d provided\n, + nb_qtables); Reviewed and merged by Michael. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
On Mon, 20 Jul 2015 10:09:27 Nicolas George wrote: Le duodi 2 thermidor, an CCXXIII, Rodney Baker a écrit : I have had very good experiences with Digital Pacific and their prices are reasonable (by Australian standards, anyway). They seem much more expensive than their French counterpart. For example, comparing their first price with Online's first prices: CPU mark 3530 vs 6530, RAM 4G vs 16G, HD 2×73 Go vs 2×1 To, and most importantly, traffic 100 Go/month vs unlimited. All that for 99$ vs 30 EUR per month. Also, aren't Australian copyright laws slightly crazier than average (and French)? I'm not a lawyer, so I can't comment authoritatively on the copyright laws - I don't think they're that bad, though. Cost very much depends on what you're looking for. I found them competitive for my needs (but then, they're also local). You could also look at Rackspace (UK based, claim to be Linux specialists) but I know only what I've seen in their ads in Linux Format magazine. YMMV. -- == Rodney Baker VK5ZTV rodney.ba...@iinet.net.au == ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/8] lavf/avio: add avio_accept and avio_handshake
Le tridi 3 thermidor, an CCXXIII, Stephan Holljes a écrit : Signed-off-by: Stephan Holljes klaxa1...@googlemail.com --- libavformat/avio.h| 16 libavformat/aviobuf.c | 17 + 2 files changed, 33 insertions(+) As explained in the previous comment, the doxy for avio_handshake() must explain the return value in more details. 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]lavf/mxf: Map codec_tag for Avid files if everything else fails
On Fri, 2015-07-17 at 12:36 +0200, Carl Eugen Hoyos wrote:
On Saturday 11 July 2015 04:13:52 pm Tomas Härdin wrote:
Just a quick review since I have to bounce:
+const MXFCodecUL ff_mxf_codec_tag_uls[] = {
Haven't we moved this to mxf.c already? Or rather, don't we
have a whole bunch of very similar tables already?
The new table is (together with others) in mxf.c, none of the
existing tables maps to codec_tag. AVup cannot be decoded
without codec_tag because we currently treat it as rawvideo.
Alright
[...]
Messy bracing. Something like putting a check on codec_tag after setting
it, inside braces like before. Hard to explain and I don't have time to
type it out but:
if (st-codec-pix_fmt == AV_PIX_FMT_NONE) {
codec_tag = ...
if (!codec_tag) {
do the old thing
}
}
New patch attached.
Looks alright. You can reindent in a separate patch if you like.
Sorry for taking a few days with replying, thought I'd already sorted it
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] fate: add test for async protocol
On Tue, Jul 21, 2015 at 09:04:03PM +0800, Zhang Rui wrote: --- libavformat/Makefile | 3 +- libavformat/async.c| 171 + tests/fate/libavformat.mak | 4 ++ tests/ref/fate/async | 7 ++ 4 files changed, 184 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/async applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: loongson optimize xvid idct with mmi
On Tue, Jul 21, 2015 at 01:54:55PM +0800, 周晓勇 wrote: From 0e387e3057deb1390adc1d12e738d7c91b59be18 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Tue, 21 Jul 2015 10:14:40 +0800 Subject: [PATCH 2/2] avcodec: loongson optimize xvid idct with mmi Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn --- libavcodec/mips/Makefile | 2 + libavcodec/mips/xvid_idct_mmi.c | 253 +++ libavcodec/mips/xvididct_init_mips.c | 45 +++ libavcodec/mips/xvididct_mips.h | 30 + libavcodec/xvididct.c| 2 + libavcodec/xvididct.h| 2 + 6 files changed, 334 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avformat/async: avoid deadlock on close
---
libavformat/async.c | 53 ++---
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index be02308..45c484a 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -71,17 +71,16 @@ typedef struct Context {
AVIOInterruptCB interrupt_callback;
} Context;
-static int async_interrupt_callback(void *arg)
+static int async_check_interrupt(void *arg)
{
-URLContext *h = arg;
-Context*c = h-priv_data;
-int ret = 0;
-
-if (c-interrupt_callback.callback) {
-ret = c-interrupt_callback.callback(c-interrupt_callback.opaque);
-if (!ret)
-return ret;
-}
+URLContext *h = arg;
+Context*c = h-priv_data;
+
+if (c-abort_request)
+return 1;
+
+if (ff_check_interrupt(c-interrupt_callback))
+c-abort_request = 1;
return c-abort_request;
}
@@ -96,15 +95,15 @@ static void *async_buffer_task(void *arg)
while (1) {
int fifo_space, to_copy;
-if (async_interrupt_callback(h)) {
+pthread_mutex_lock(c-mutex);
+if (async_check_interrupt(h)) {
c-io_eof_reached = 1;
c-io_error = AVERROR_EXIT;
+pthread_mutex_unlock(c-mutex);
break;
}
if (c-seek_request) {
-pthread_mutex_lock(c-mutex);
-
ret = ffurl_seek(c-inner, c-seek_pos, c-seek_whence);
if (ret 0) {
c-io_eof_reached = 1;
@@ -121,33 +120,41 @@ static void *async_buffer_task(void *arg)
av_fifo_reset(fifo);
pthread_cond_signal(c-cond_wakeup_main);
-pthread_mutex_unlock(c-mutex);
-continue;
+goto unlock_and_continue;
}
fifo_space = av_fifo_space(fifo);
if (c-io_eof_reached || fifo_space = 0) {
-pthread_mutex_lock(c-mutex);
pthread_cond_signal(c-cond_wakeup_main);
+if (async_check_interrupt(h))
+goto unlock_and_continue;
pthread_cond_wait(c-cond_wakeup_background, c-mutex);
-pthread_mutex_unlock(c-mutex);
-continue;
+goto unlock_and_continue;
}
+pthread_mutex_unlock(c-mutex);
+/* unlocked area: begin */
to_copy = FFMIN(4096, fifo_space);
ret = av_fifo_generic_write(fifo, c-inner, to_copy, (void
*)ffurl_read);
+/* unlocked area: end */
+
+pthread_mutex_lock(c-mutex);
if (ret = 0) {
c-io_eof_reached = 1;
if (ret 0) {
c-io_error = ret;
}
}
-
-pthread_mutex_lock(c-mutex);
pthread_cond_signal(c-cond_wakeup_main);
+unlock_and_continue:
pthread_mutex_unlock(c-mutex);
}
+pthread_mutex_lock(c-mutex);
+av_assert2(c-abort_request != 0);
+pthread_cond_signal(c-cond_wakeup_main);
+pthread_mutex_unlock(c-mutex);
+
return NULL;
}
@@ -155,7 +162,7 @@ static int async_open(URLContext *h, const char *arg, int
flags, AVDictionary **
{
Context *c = h-priv_data;
int ret;
-AVIOInterruptCB interrupt_callback = {.callback =
async_interrupt_callback, .opaque = h};
+AVIOInterruptCB interrupt_callback = {.callback = async_check_interrupt,
.opaque = h};
av_strstart(arg, async:, arg);
@@ -251,7 +258,7 @@ static int async_read_internal(URLContext *h, void *dest,
int size, int read_com
while (to_read 0) {
int fifo_size, to_copy;
-if (async_interrupt_callback(h)) {
+if (async_check_interrupt(h)) {
ret = AVERROR_EXIT;
break;
}
@@ -343,7 +350,7 @@ static int64_t async_seek(URLContext *h, int64_t pos, int
whence)
c-seek_ret = 0;
while (1) {
-if (async_interrupt_callback(h)) {
+if (async_check_interrupt(h)) {
ret = AVERROR_EXIT;
break;
}
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] libavcodec/qsvdec_h264.c: packet buffering has been removed since qsvdec.c does maintain own data buffering now.
Hello all, Since after [PATCH 3/4] the ff_qsv_decode() always consume whole packet payload buffering of packets into qsvdec_h264.c is need not more. Suggested patch makes qsvdec_h264.c simple as far as it possible. Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0004-libavcodec-qsvdec_h264.c-packet-buffering-has-been-r.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] libavcodec/qsvdec.c: The ff_qsv_decode() now guarantees the consumption of whole packet.
Hello all, Actual implementation of ff_qsv_decode() is not reliable, it may return without consumption of 1..3 last bytes of packet which initiates infinitive loop. New implementation guarantees that packet will consumed, now internal fifo uses to join unconsumed previous packet tail with new packet. Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0003-libavcodec-qsvdec.c-The-ff_qsv_decode-now-guarantees.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/hapdec: log reason for failure when texture type doesn't match stream
On Tue, Jul 21, 2015 at 01:12:11AM +0100, Tom Butterworth wrote: --- libavcodec/hapdec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) applied thanks [...] -- 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 1/2] avcodec: loongson move simple idct functions to a separate file
On Tue, Jul 21, 2015 at 01:53:44PM +0800, 周晓勇 wrote: From f90a2009bd7fc6832cd9c1df174e52e7a1431c0e Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn Date: Tue, 21 Jul 2015 10:08:21 +0800 Subject: [PATCH 1/2] avcodec: loongson move simple idct functions to a separate file Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn --- libavcodec/mips/Makefile| 3 +- libavcodec/mips/idctdsp_init_mips.c | 4 +- libavcodec/mips/idctdsp_mmi.c | 811 --- libavcodec/mips/simple_idct_mmi.c | 833 4 files changed, 837 insertions(+), 814 deletions(-) applied thanks PS: with -C you can generate smaller patches when code is moved [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] fate: add test for async protocol
---
libavformat/Makefile | 3 +-
libavformat/async.c| 171 +
tests/fate/libavformat.mak | 4 ++
tests/ref/fate/async | 7 ++
4 files changed, 184 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/async
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 108b6a6..cc73fd8 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -546,7 +546,8 @@ SLIBOBJS-$(HAVE_GNU_WINDRES) += avformatres.o
SKIPHEADERS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh.h
SKIPHEADERS-$(CONFIG_NETWORK)+= network.h rtsp.h
-TESTPROGS = seek\
+TESTPROGS = async \
+seek\
srtp\
url \
diff --git a/libavformat/async.c b/libavformat/async.c
index 0748309..be02308 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -385,3 +385,174 @@ URLProtocol ff_async_protocol = {
.priv_data_size = sizeof(Context),
.priv_data_class = async_context_class,
};
+
+#ifdef TEST
+
+#define TEST_SEEK_POS(1536)
+#define TEST_STREAM_SIZE (2048)
+
+typedef struct TestContext {
+AVClass*class;
+size_t logical_pos;
+size_t logical_size;
+} TestContext;
+
+static int async_test_open(URLContext *h, const char *arg, int flags,
AVDictionary **options)
+{
+TestContext *c = h-priv_data;
+c-logical_pos = 0;
+c-logical_size = TEST_STREAM_SIZE;
+return 0;
+}
+
+static int async_test_close(URLContext *h)
+{
+return 0;
+}
+
+static int async_test_read(URLContext *h, unsigned char *buf, int size)
+{
+TestContext *c = h-priv_data;
+int i;
+int read_len = 0;
+
+if (c-logical_pos = c-logical_size)
+return AVERROR_EOF;
+
+for (i = 0; i size; ++i) {
+buf[i] = c-logical_pos 0xFF;
+
+c-logical_pos++;
+read_len++;
+
+if (c-logical_pos = c-logical_size)
+break;
+}
+
+return read_len;
+}
+
+static int64_t async_test_seek(URLContext *h, int64_t pos, int whence)
+{
+TestContext *c = h-priv_data;
+int64_t new_logical_pos;
+
+if (whence == AVSEEK_SIZE) {
+return c-logical_size;
+} if (whence == SEEK_CUR) {
+new_logical_pos = pos + c-logical_pos;
+} else if (whence == SEEK_SET){
+new_logical_pos = pos;
+} else {
+return AVERROR(EINVAL);
+}
+if (new_logical_pos 0)
+return AVERROR(EINVAL);
+
+c-logical_pos = new_logical_pos;
+return new_logical_pos;
+}
+
+static const AVClass async_test_context_class = {
+.class_name = Async-Test,
+.item_name = av_default_item_name,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+URLProtocol ff_async_test_protocol = {
+.name= async-test,
+.url_open2 = async_test_open,
+.url_read= async_test_read,
+.url_seek= async_test_seek,
+.url_close = async_test_close,
+.priv_data_size = sizeof(TestContext),
+.priv_data_class = async_test_context_class,
+};
+
+int main(void)
+{
+URLContext *h = NULL;
+int i;
+int ret;
+int64_t size;
+int64_t pos;
+int64_t read_len;
+unsigned char buf[4096];
+
+ffurl_register_protocol(ff_async_protocol);
+ffurl_register_protocol(ff_async_test_protocol);
+
+ret = ffurl_open(h, async:async-test:, AVIO_FLAG_READ, NULL, NULL);
+printf(open: %d\n, ret);
+
+size = ffurl_size(h);
+printf(size: %PRId64\n, size);
+
+pos = ffurl_seek(h, 0, SEEK_CUR);
+read_len = 0;
+while (1) {
+ret = ffurl_read(h, buf, sizeof(buf));
+if (ret == AVERROR_EOF) {
+printf(read-error: AVERROR_EOF at %PRId64\n, ffurl_seek(h, 0,
SEEK_CUR));
+break;
+}
+else if (ret == 0)
+break;
+else if (ret 0) {
+printf(read-error: %d at %PRId64\n, ret, ffurl_seek(h, 0,
SEEK_CUR));
+goto fail;
+} else {
+for (i = 0; i ret; ++i) {
+if (buf[i] != (pos 0xFF)) {
+printf(read-mismatch: actual %d, expecting %d, at
%PRId64\n,
+ (int)buf[i], (int)(pos 0xFF), pos);
+break;
+}
+pos++;
+}
+}
+
+read_len += ret;
+}
+printf(read: %PRId64\n, read_len);
+
+ret = ffurl_read(h, buf, 1);
+printf(read: %d\n, ret);
+
+pos = ffurl_seek(h, TEST_SEEK_POS, SEEK_SET);
+printf(seek: %PRId64\n, pos);
+
+read_len = 0;
+while (1) {
+ret = ffurl_read(h, buf, sizeof(buf));
+if (ret ==
[FFmpeg-devel] [PATCH 1/4] libavcodec/qsvdec_h264.c: SPS parsing now performs by MFXVideoDECODE_DecodeHeader() into libavcodec/qsvdec.c
Hello All, There is first patch from 4 which makes qsv-based decode implementation more simple and reliable. This patch replaces external frame parse to internal MFXVideoDECODE_DecodeHeader() function which able to parse any supported stream kind (h.264, hevc, mpeg2, vc-1) by universal way. Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-libavcodec-qsvdec_h264.c-SPS-parsing-now-performs-by.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] libavcodec/qsvdec_h264.c: refactoring: functional of qsv_process_data() has been moved into qsvdec.c
Hello All, The qsv_process_data() doing nothing h.264-specific, so it has been moved into qsvdec.c with new name ff_qsv_prepare(). Please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0002-libavcodec-qsvdec_h264.c-refactoring-functional-of-q.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: loongson optimize blockdsp with mmi
From 431c8fe5d418d79d5c7cb137499a26e88e6c84dc Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong zhouxiaoy...@loongson.cn
Date: Tue, 21 Jul 2015 20:55:51 +0800
Subject: [PATCH] avcodec: loongson optimize blockdsp with mmi
Signed-off-by: ZhouXiaoyong zhouxiaoy...@loongson.cn
---
libavcodec/mips/Makefile | 1 +
libavcodec/mips/blockdsp_init_mips.c | 16
libavcodec/mips/blockdsp_mips.h | 6 ++
libavcodec/mips/blockdsp_mmi.c | 147 +++
4 files changed, 170 insertions(+)
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index a105661..da91608 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -67,3 +67,4 @@ MMI-OBJS-$(CONFIG_MPEGVIDEO) +=
mips/mpegvideo_mmi.o
MMI-OBJS-$(CONFIG_IDCTDSP)+= mips/idctdsp_mmi.o \
mips/simple_idct_mmi.o
MMI-OBJS-$(CONFIG_MPEG4_DECODER) += mips/xvid_idct_mmi.o
+MMI-OBJS-$(CONFIG_BLOCKDSP) += mips/blockdsp_mmi.o
diff --git a/libavcodec/mips/blockdsp_init_mips.c
b/libavcodec/mips/blockdsp_init_mips.c
index 99ae316..2278613 100644
--- a/libavcodec/mips/blockdsp_init_mips.c
+++ b/libavcodec/mips/blockdsp_init_mips.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2015 Parag Salasakar (parag.salasa...@imgtec.com)
+ *Zhou Xiaoyong zhouxiaoy...@loongson.cn
*
* This file is part of FFmpeg.
*
@@ -32,9 +33,24 @@ static av_cold void blockdsp_init_msa(BlockDSPContext *c,
}
#endif // #if HAVE_MSA
+#if HAVE_MMI
+static av_cold void blockdsp_init_mmi(BlockDSPContext *c,
+unsigned high_bit_depth)
+{
+c-clear_block = ff_clear_block_mmi;
+c-clear_blocks = ff_clear_blocks_mmi;
+
+c-fill_block_tab[0] = ff_fill_block16_mmi;
+c-fill_block_tab[1] = ff_fill_block8_mmi;
+}
+#endif /* HAVE_MMI */
+
void ff_blockdsp_init_mips(BlockDSPContext *c, unsigned high_bit_depth)
{
#if HAVE_MSA
blockdsp_init_msa(c, high_bit_depth);
#endif // #if HAVE_MSA
+#if HAVE_MMI
+blockdsp_init_mmi(c, high_bit_depth);
+#endif /* HAVE_MMI */
}
diff --git a/libavcodec/mips/blockdsp_mips.h b/libavcodec/mips/blockdsp_mips.h
index 0b6bb67..9559d40 100644
--- a/libavcodec/mips/blockdsp_mips.h
+++ b/libavcodec/mips/blockdsp_mips.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2015 Parag Salasakar (parag.salasa...@imgtec.com)
+ *Zhou Xiaoyong zhouxiaoy...@loongson.cn
*
* This file is part of FFmpeg.
*
@@ -28,4 +29,9 @@ void ff_fill_block8_msa(uint8_t *src, uint8_t val, int
stride, int height);
void ff_clear_block_msa(int16_t *block);
void ff_clear_blocks_msa(int16_t *block);
+void ff_fill_block16_mmi(uint8_t *block, uint8_t value, int line_size, int h);
+void ff_fill_block8_mmi(uint8_t *block, uint8_t value, int line_size, int h);
+void ff_clear_block_mmi(int16_t *block);
+void ff_clear_blocks_mmi(int16_t *block);
+
#endif // #ifndef AVCODEC_MIPS_BLOCKDSP_MIPS_H
diff --git a/libavcodec/mips/blockdsp_mmi.c b/libavcodec/mips/blockdsp_mmi.c
new file mode 100644
index 000..63eaf69
--- /dev/null
+++ b/libavcodec/mips/blockdsp_mmi.c
@@ -0,0 +1,147 @@
+/*
+ * Loongson SIMD optimized blockdsp
+ *
+ * Copyright (c) 2015 Loongson Technology Corporation Limited
+ * Copyright (c) 2015 Zhou Xiaoyong zhouxiaoy...@loongson.cn
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include blockdsp_mips.h
+
+void ff_fill_block16_mmi(uint8_t *block, uint8_t value, int line_size, int h)
+{
+__asm__ volatile (
+move $8, %3\r\n
+move $9, %0\r\n
+dmtc1 %1, $f2 \r\n
+punpcklbh $f2, $f2, $f2\r\n
+punpcklbh $f2, $f2, $f2\r\n
+punpcklbh $f2, $f2, $f2\r\n
+1: \r\n
+gssdlc1 $f2, 7($9) \r\n
+gssdrc1 $f2, 0($9) \r\n
+gssdlc1 $f2, 15($9)\r\n
+gssdrc1 $f2, 8($9) \r\n
+daddi $8, $8, -1 \r\n
+daddu $9, $9, %2 \r\n
+bnez $8, 1b\r\n
+::r(block),r(value),r(line_size),r(h)
+: $8,$9
+);
+}
+
+void ff_fill_block8_mmi(uint8_t *block, uint8_t value, int line_size, int h)
+{
+__asm__
Re: [FFmpeg-devel] [PATCH 3/3] avformat/async: avoid deadlock on close
On Tue, Jul 21, 2015 at 09:09:47PM +0800, Zhang Rui wrote:
---
libavformat/async.c | 53
++---
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/libavformat/async.c b/libavformat/async.c
index be02308..45c484a 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -71,17 +71,16 @@ typedef struct Context {
AVIOInterruptCB interrupt_callback;
} Context;
-static int async_interrupt_callback(void *arg)
+static int async_check_interrupt(void *arg)
{
-URLContext *h = arg;
-Context*c = h-priv_data;
+URLContext *h = arg;
+Context*c = h-priv_data;
please dont mix cosmetic and non cosmeatic changes in the same patch
it makes reading and understanding it harder
[...]
@@ -155,7 +162,7 @@ static int async_open(URLContext *h, const char *arg, int
flags, AVDictionary **
{
Context *c = h-priv_data;
int ret;
-AVIOInterruptCB interrupt_callback = {.callback =
async_interrupt_callback, .opaque = h};
+AVIOInterruptCB interrupt_callback = {.callback =
async_check_interrupt, .opaque = h};
renaming a function also should be in a seperate patch
[...]
--
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] conversion of FFV1 specification from lyx to markdown
On Mon, Jul 20, 2015 at 11:55:41PM -0400, Dave Rice wrote: On Jul 20, 2015, at 8:52 PM, Michael Niedermayer mich...@niedermayer.cc wrote: On Tue, Jul 21, 2015 at 02:14:11AM +0200, Michael Niedermayer wrote: [...] ill take another quick look and then will probably push your changes its probably easier to work on top of it then wait with pushing until its perfect pushed it btw please remove trailing whitespace unless some of it is required for the formating or something Send this pull request to clean up white spaces, indentation, and trailing slashes. https://github.com/FFmpeg/FFV1/pull/12 also, it seems github doesnt render all parts of the file well, some look quite broken (found by jamrial) Github's markdown rendering is a little different than pandoc's rendering. Some table updates were done here: https://github.com/FFmpeg/FFV1/pull/11 https://github.com/FFmpeg/FFV1/pull/11. There's still the header which starts with percent signs, this is a workaround to get pandoc to render that as a header but to not include it within the table of contents. Unless I'm missing something, Github doesn't seem to support rendering latex style equations in markdown (although pandoc does) so we may not be able to have a markdown that can be fully rendered by Github alone (unless we remove the need for latex). Perhaps the ffv1.md could occasionally be rendered (via the makefile) with the outputs updated on ffmpeg.org http://ffmpeg.org/. Then within the README of the FFV1 repo we could link to the rendered copy on ffmpeg.org http://ffmpeg.org/. ive uploaded a temporary version to http://ffmpeg.org/~michael/ffv1-markdown/ffv1.html http://ffmpeg.org/~michael/ffv1-markdown/ffv1.pdf these are created with pandoc 1.13.2.1 locally the huffman/suffix/example tables still are wrong, that could be worked aroun by placing one of the magic non breaking or whatever spaces before the tables also the html lost its left border/margin which looks odd pandoc on the server would be older so i dont think generating it per cronjob on the server makes much sense ATM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
