Re: [FFmpeg-devel] [PATCH] avfilter: add ssim filter
On 6/23/15, Nicolas George geo...@nsup.org wrote: Le quintidi 5 messidor, an CCXXIII, Paul B Mahol a ecrit : Looks like there are no new comments so I can safely assume current state as is is good enough. If you want to be really safe, you can observe that there is an unanswered question and assume that 20 hours is not enough to be sure there will be no answer. So here it is right now, since you use ultimatums: Just to put it into same file? Moving it into same filter would be also possible but how would then new filter be named then? That depends on the code, you know it better than me. If it often makes sense to compute both the PSNR and the SSIM, then a single filter would be preferred, especially if some of the computations can be used for both. Well tiny_ssim computes PSNR from SSIM but numbers do not match other implementations. I'm sure that our MSE(and PSNR) calculations in vf_psnr.c matches numbers from some page linked from wikipedia. Computations of PSNR and SSIM have not much in common. So the only code that is actually shared is set_meta() which could be moved to some other place in lavfi. If this is done in a single filter, various names come to mind: -vf quality is the most obvious. I just do not like big filters, I made mistake putting multiple different filters in single histogram filter. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC update
This has better go to the mailing list.
Le quintidi 5 messidor, an CCXXIII, Stephan Holljes a écrit :
So far I have split ff_listen_bind() into ff_listen_bind() and
ff_accept() and added an url_accept field to URLProtocol (see attached
patch).
I do not believe this is the correct approach. ff_listen_bind() is an
internal helper that works specifically for sockets.
I read our past exchanges for a number of times and I am somewhat at a
loss as to where to allocate my additional Client(-Contexts).
No sourcefile I have looked at stores multiple AVIOContexts or
AVFormatContexts (or I have not seen it).
I also could not find out how ffmpeg would even accept multiple
clients. The ff_listen_bind() call is blocking on accept() and it is
only called once.
Maybe I'm also overlooking some documentation. Maybe I am also looking
in the wrong place. The files I have looked at the most have been:
url.h network.c/h, avio.c/h aviobuf.c and tcp.c.
You need to understand very well how it happens for plain Unix TCP clients.
First, the server create and prepares the server socket s, with socket(),
bind() and mostly listen(). There is also a list of client sockets c[i],
initially empty.
Then, indefinitely and in parallel:
* call accept() on s: this returns a new c[i] added to the list;
* perform read() / write() on each c[i], remove them from the list if they
are finished.
Here, in parallel means either threads, forked processes, or emulated
parallelism with poll() and non-blocking operations. For lavf, non-blocking
operations do not work, so you can assume parallelism between multiple
clients is achieved with threads; although I very much would like that all
new networking code is input-driven and therefore ready for non-blocking.
Now, as for how to transpose it into lavf terms:
* Creating and preparing the server socket: avio_open2() with various
options for the address and the listen option set.
* Accepting a new client: a new function that you have to design, probably
avio_accept().
There are a few caveats for avio_accept():
* Creating a new AVFormatContext, like accept() creates a new socket. That
is not really difficult, IMHO. It just means the API will look somewhat
like that:
int avio_accept(AVIOContext *s, AVIOContext **c, ...);
The c parameter is just like the s parameter to avio_open2(): it allocates
a new context if necessary and populates it.
* Except, the current API accepts a single client by replacing the server
context. This must still be possible after the change. Maybe just
overwriting the server context will work, but it must be considered.
* If you remember, a full TCP accept() requires three handshake packets: SYN
from the client, ACK-SYN from the server and then ACK from the client. The
kernel handles this in the background and accept() returns a new client
only when the full handshake is done. In lavf, we do not have a kernel
working in the background, so it must be explicit.
We can look at how non-blocking connect() works: first call connect() on
the socket, it returns EINPROGRESS immediately, the repeatedly call
getsockopt(SO_ERROR) to check the status of the connection until it stops
returning EAGAIN.
I believe we can do the same: avio_accept(s, c) to initiate the accept,
and then avio_accept_connect(c) or something (feel free to suggest better
names) to finish the handshake.
For the particular case of the HTTP server, the avio_accept() part would
call avio_accept() on the underlying socket (or TLS context), and the
avio_accept_connect() would call avio_accept_connect() on the underlying
context and then perform the handshake.
In terms of application, the code would probably look something like this
(error checks and stuff removed):
av_dict_set(options, listen, 1);
avio_open2(server, http://:8080;, options);
while (1) {
avio_accept(server, client);
thread_run {
avio_accept_connect(client);
communicate_with_the_client(client);
avio_close(client);
};
}
Hope this helps.
Regards,
--
Nicolas George
From 234199a18e0c3bfede5f04a9ade0a11c71061285 Mon Sep 17 00:00:00 2001
From: Stephan Holljes klaxa1...@googlemail.com
Date: Tue, 23 Jun 2015 16:41:51 +0200
Subject: [PATCH] lavf: Split ff_listen_bind into ff_listen_bind and ff_accept
and implement its usage in tcp.
Signed-off-by: Stephan Holljes klaxa1...@googlemail.com
---
libavformat/network.c | 7 ---
libavformat/network.h | 12 +++-
libavformat/tcp.c | 10 ++
libavformat/url.h | 1 +
4 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/libavformat/network.c b/libavformat/network.c
index 47ade8c..8d9434f 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -204,10 +204,11 @@ int ff_listen_bind(int fd, const struct sockaddr *addr,
if (ret)
return ff_neterrno();
-ret = ff_poll_interrupt(lp, 1, timeout,
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
On Tue, Jun 23, 2015 at 01:56:57PM +, Ludmila Glinskih wrote: Do you have any ideas why it differs from framecrc result on the same file? [...] --- /dev/null +++ b/tests/ref/fate/api-h264 @@ -0,0 +1,18 @@ +#tb 0: 1/120 the timebase and timestamps differ as ffmpeg*.c does more processing on timestamps, i dont think it makes sense to try to reproduce it the output should be fine as is thanks [...] -- 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] avfilter: add ssim filter
Hi, On Tue, Jun 23, 2015 at 10:42 AM, Paul B Mahol one...@gmail.com wrote: On 6/22/15, Paul B Mahol one...@gmail.com wrote: On 6/22/15, Nicolas George geo...@nsup.org wrote: Le quartidi 4 messidor, an CCXXIII, Paul B Mahol a ecrit : Signed-off-by: Paul B Mahol one...@gmail.com --- Changelog| 1 + doc/filters.texi | 53 libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_ssim.c| 340 +++ 5 files changed, 396 insertions(+) create mode 100644 libavfilter/vf_ssim.c Would it make sense to merge it with the psnr filter, sharing code and offering a common user interface for various quality measurements? Just to put it into same file? Moving it into same filter would be also possible but how would then new filter be named then? Looks like there are no new comments so I can safely assume current state as is is good enough. Yeah lgtm. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
On Tue, 23 Jun 2015 11:14:36 +0530 Niklesh Lalwani niklesh.lalw...@iitb.ac.in wrote: On 6/23/15, Philip Langdale phil...@overt.org wrote: I got a bunch of warnings when I compiled it. Please fix. Thanks. -- CC libavcodec/movtextenc.o libavcodec/movtextenc.c: In function ‘mov_text_style_cb’: libavcodec/movtextenc.c:124:17: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); ^ libavcodec/movtextenc.c:138:21: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); ^ libavcodec/movtextenc.c:167:13: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); The function mov_text_style_cb() is a void function, I'll make it int funciton to return a value. ^ libavcodec/movtextenc.c: In function ‘mov_text_encode_frame’: libavcodec/movtextenc.c:242:47: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-tsmb_size, 4); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint32_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:243:47: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-tsmb_type, 4); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint32_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:244:47: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_entries, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:246:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_attributes[j]-style_start, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:247:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_attributes[j]-style_end, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:248:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_fontID, 2); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint16_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ libavcodec/movtextenc.c:251:51: warning: passing argument 2 of ‘av_bprint_append_data’ from incompatible pointer type av_bprint_append_data(s-buffer, s-style_color, 4); ^ In file included from libavcodec/ass.h:26:0, from libavcodec/movtextenc.c:30: ./libavutil/bprint.h:146:6: note: expected ‘const char *’ but argument is of type ‘uint32_t *’ void av_bprint_append_data(AVBPrint *buf, const char *data, unsigned size); ^ As for these warnings, we discussed that they were fine as long as I am keeping check of alignment and placement into the buffer properly. Defining all these variables as char* would make the code lengthier and less clean. What do you suggest? In my opinion these warnings should either be silenced, or an av_bprint function taking void* should be added and used. While the warning is indeed a false positive here, they can obscure interesting warnings. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
On Tue, 23 Jun 2015 11:14:36 +0530 Niklesh Lalwani niklesh.lalw...@iitb.ac.in wrote: On 6/23/15, Philip Langdale phil...@overt.org wrote: I got a bunch of warnings when I compiled it. Please fix. Thanks. -- CC libavcodec/movtextenc.o libavcodec/movtextenc.c: In function ‘mov_text_style_cb’: libavcodec/movtextenc.c:124:17: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); ^ libavcodec/movtextenc.c:138:21: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); ^ libavcodec/movtextenc.c:167:13: warning: ‘return’ with a value, in function returning void return AVERROR(ENOMEM); The function mov_text_style_cb() is a void function, I'll make it int funciton to return a value. The function signature is fixed by the ASS callback struct - you can't change it. That means that it has to stay void. I guess you'll need to find a way to handle the allocation failures internally. I would suggest that means dropping styles if you can't allocate for them. Which is fine. If the user gets into this situation, they can't expect things to magically work. As for these warnings, we discussed that they were fine as long as I am keeping check of alignment and placement into the buffer properly. Defining all these variables as char* would make the code lengthier and less clean. What do you suggest? Fair. Keep it as is for now. Thanks, --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ssim filter
Le quintidi 5 messidor, an CCXXIII, Paul B Mahol a écrit : Looks like there are no new comments so I can safely assume current state as is is good enough. If you want to be really safe, you can observe that there is an unanswered question and assume that 20 hours is not enough to be sure there will be no answer. So here it is right now, since you use ultimatums: Just to put it into same file? Moving it into same filter would be also possible but how would then new filter be named then? That depends on the code, you know it better than me. If it often makes sense to compute both the PSNR and the SSIM, then a single filter would be preferred, especially if some of the computations can be used for both. If this is done in a single filter, various names come to mind: -vf quality is the most obvious. 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] avfilter: add ssim filter
Hi, On Tue, Jun 23, 2015 at 10:45 AM, Ronald S. Bultje rsbul...@gmail.com wrote: On Tue, Jun 23, 2015 at 10:42 AM, Paul B Mahol one...@gmail.com wrote: On 6/22/15, Paul B Mahol one...@gmail.com wrote: On 6/22/15, Nicolas George geo...@nsup.org wrote: Le quartidi 4 messidor, an CCXXIII, Paul B Mahol a ecrit : Signed-off-by: Paul B Mahol one...@gmail.com --- Changelog| 1 + doc/filters.texi | 53 libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_ssim.c| 340 +++ 5 files changed, 396 insertions(+) create mode 100644 libavfilter/vf_ssim.c Would it make sense to merge it with the psnr filter, sharing code and offering a common user interface for various quality measurements? Just to put it into same file? Moving it into same filter would be also possible but how would then new filter be named then? Looks like there are no new comments so I can safely assume current state as is is good enough. Yeah lgtm. Actually one question - how would I use this with with a raw yuv file as reference? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add ssim filter
Le quintidi 5 messidor, an CCXXIII, Paul B Mahol a écrit : Well tiny_ssim computes PSNR from SSIM but numbers do not match other implementations. I'm sure that our MSE(and PSNR) calculations in vf_psnr.c matches numbers from some page linked from wikipedia. Computations of PSNR and SSIM have not much in common. So the only code that is actually shared is set_meta() which could be moved to some other place in lavfi. I just do not like big filters, I made mistake putting multiple different filters in single histogram filter. Ok. As long as you thought about and made an informed decision I have no objection. 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] avfilter: add ssim filter
On 6/22/15, Paul B Mahol one...@gmail.com wrote: On 6/22/15, Nicolas George geo...@nsup.org wrote: Le quartidi 4 messidor, an CCXXIII, Paul B Mahol a ecrit : Signed-off-by: Paul B Mahol one...@gmail.com --- Changelog| 1 + doc/filters.texi | 53 libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_ssim.c| 340 +++ 5 files changed, 396 insertions(+) create mode 100644 libavfilter/vf_ssim.c Would it make sense to merge it with the psnr filter, sharing code and offering a common user interface for various quality measurements? Just to put it into same file? Moving it into same filter would be also possible but how would then new filter be named then? Looks like there are no new comments so I can safely assume current state as is is good enough. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] electronicarts: demux alpha stream
.vp6 files may contain two video streams: one for the primary video
stream and another for the alpha mask. The file format uses identical
data structures for both streams.
Signed-off-by: Peter Ross pr...@xvid.org
---
libavformat/electronicarts.c | 136 +--
1 file changed, 80 insertions(+), 56 deletions(-)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index d999a0b..1c35e2d 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/electronicarts.c
@@ -59,18 +59,25 @@
#define MVhd_TAG MKTAG('M', 'V', 'h', 'd')
#define MV0K_TAG MKTAG('M', 'V', '0', 'K')
#define MV0F_TAG MKTAG('M', 'V', '0', 'F')
+#define AVhd_TAG MKTAG('A', 'V', 'h', 'd')
+#define AV0K_TAG MKTAG('A', 'V', '0', 'K')
+#define AV0F_TAG MKTAG('A', 'V', '0', 'F')
#define MVIh_TAG MKTAG('M', 'V', 'I', 'h') /* CMV header */
#define MVIf_TAG MKTAG('M', 'V', 'I', 'f') /* CMV I-frame */
#define AVP6_TAG MKTAG('A', 'V', 'P', '6')
-typedef struct EaDemuxContext {
-int big_endian;
-
-enum AVCodecID video_codec;
+typedef struct VideoProperties {
+enum AVCodecID codec;
AVRational time_base;
int width, height;
int nb_frames;
-int video_stream_index;
+int stream_index;
+} VideoProperties;
+
+typedef struct EaDemuxContext {
+int big_endian;
+
+VideoProperties video, alpha;
enum AVCodecID audio_codec;
int audio_stream_index;
@@ -302,46 +309,43 @@ static void process_audio_header_sead(AVFormatContext *s)
ea-audio_codec = AV_CODEC_ID_ADPCM_IMA_EA_SEAD;
}
-static void process_video_header_mdec(AVFormatContext *s)
+static void process_video_header_mdec(AVFormatContext *s, VideoProperties
*video)
{
-EaDemuxContext *ea = s-priv_data;
AVIOContext *pb= s-pb;
avio_skip(pb, 4);
-ea-width = avio_rl16(pb);
-ea-height = avio_rl16(pb);
-ea-time_base = (AVRational) { 1, 15 };
-ea-video_codec = AV_CODEC_ID_MDEC;
+video-width = avio_rl16(pb);
+video-height = avio_rl16(pb);
+video-time_base = (AVRational) { 1, 15 };
+video-codec = AV_CODEC_ID_MDEC;
}
-static int process_video_header_vp6(AVFormatContext *s)
+static int process_video_header_vp6(AVFormatContext *s, VideoProperties *video)
{
-EaDemuxContext *ea = s-priv_data;
-AVIOContext *pb= s-pb;
+AVIOContext *pb = s-pb;
avio_skip(pb, 8);
-ea-nb_frames = avio_rl32(pb);
+video-nb_frames = avio_rl32(pb);
avio_skip(pb, 4);
-ea-time_base.den = avio_rl32(pb);
-ea-time_base.num = avio_rl32(pb);
-if (ea-time_base.den = 0 || ea-time_base.num = 0) {
+video-time_base.den = avio_rl32(pb);
+video-time_base.num = avio_rl32(pb);
+if (video-time_base.den = 0 || video-time_base.num = 0) {
av_log(s, AV_LOG_ERROR, Timebase is invalid\n);
return AVERROR_INVALIDDATA;
}
-ea-video_codec = AV_CODEC_ID_VP6;
+video-codec = AV_CODEC_ID_VP6;
return 1;
}
-static void process_video_header_cmv(AVFormatContext *s)
+static void process_video_header_cmv(AVFormatContext *s, VideoProperties
*video)
{
-EaDemuxContext *ea = s-priv_data;
int fps;
avio_skip(s-pb, 10);
fps = avio_rl16(s-pb);
if (fps)
-ea-time_base = (AVRational) { 1, fps };
-ea-video_codec = AV_CODEC_ID_CMV;
+video-time_base = (AVRational) { 1, fps };
+video-codec = AV_CODEC_ID_CMV;
}
/* Process EA file header.
@@ -353,7 +357,7 @@ static int process_ea_header(AVFormatContext *s)
AVIOContext *pb= s-pb;
int i;
-for (i = 0; i 5 (!ea-audio_codec || !ea-video_codec); i++) {
+for (i = 0; i 5 (!ea-audio_codec || !ea-video.codec); i++) {
uint64_t startpos = avio_tell(pb);
int err = 0;
@@ -395,40 +399,44 @@ static int process_ea_header(AVFormatContext *s)
break;
case MVIh_TAG:
-process_video_header_cmv(s);
+process_video_header_cmv(s, ea-video);
break;
case kVGT_TAG:
-ea-video_codec = AV_CODEC_ID_TGV;
+ea-video.codec = AV_CODEC_ID_TGV;
break;
case mTCD_TAG:
-process_video_header_mdec(s);
+process_video_header_mdec(s, ea-video);
break;
case MPCh_TAG:
-ea-video_codec = AV_CODEC_ID_MPEG2VIDEO;
+ea-video.codec = AV_CODEC_ID_MPEG2VIDEO;
break;
case pQGT_TAG:
case TGQs_TAG:
-ea-video_codec = AV_CODEC_ID_TGQ;
-ea-time_base = (AVRational) { 1, 15 };
+ea-video.codec = AV_CODEC_ID_TGQ;
+ea-video.time_base = (AVRational) { 1, 15 };
break;
case pIQT_TAG:
-ea-video_codec = AV_CODEC_ID_TQI;
-ea-time_base = (AVRational) { 1, 15 };
+ea-video.codec = AV_CODEC_ID_TQI;
+ea-video.time_base = (AVRational) { 1, 15 };
break;
Re: [FFmpeg-devel] [PATCH 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
On Tue, 23 Jun 2015 16:54:08 +0200 wm4 nfx...@googlemail.com wrote: In my opinion these warnings should either be silenced, or an av_bprint function taking void* should be added and used. While the warning is indeed a false positive here, they can obscure interesting warnings. A fair point. Niklesh, why don't you use a #define to add the cast without cluttering up the code too much. Something like: #define av_bprint_append_any(buf, data, size) \ av_bprint_append_data(buf, ((const char *)data), size) --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
Le quintidi 5 messidor, an CCXXIII, wm4 a écrit : People don't follow mathematic rules, and neither do human arguments. Not even software development does. And yet, even so, the reasoning discipline gives valuable results even in these areas. Wonderful, isn't it? The current architecture just doesn't allow it without committing API atrocities. There is no doubt that FFmpeg has a lot of round pegs in square holes. Just repeating it ad nauseam is not a constructive contribution. There are two kind of constructive contributions that you can do: 1. Help design round holes for the round pegs. 2. Build a case to prove that FFmpeg is better without the round pegs. For now, I have not yet seen you do any of these things. Personally, I consider that we should strive to make sure that all pegs, even the square ones and even the very useful ones, do not have a cost when they are not used (i.e. an application that uses lavf and lavc to demux and decode MP3 should not be burdened by initiating the H.266 tables or loading the TLS certificates). And in that case, it is better to have the pegs, even if we do not have the correctly shaped holes yet. 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] avfilter: add ssim filter
On 6/23/15, Ronald S. Bultje rsbul...@gmail.com wrote: Hi, On Tue, Jun 23, 2015 at 10:45 AM, Ronald S. Bultje rsbul...@gmail.com wrote: On Tue, Jun 23, 2015 at 10:42 AM, Paul B Mahol one...@gmail.com wrote: On 6/22/15, Paul B Mahol one...@gmail.com wrote: On 6/22/15, Nicolas George geo...@nsup.org wrote: Le quartidi 4 messidor, an CCXXIII, Paul B Mahol a ecrit : Signed-off-by: Paul B Mahol one...@gmail.com --- Changelog| 1 + doc/filters.texi | 53 libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_ssim.c| 340 +++ 5 files changed, 396 insertions(+) create mode 100644 libavfilter/vf_ssim.c Would it make sense to merge it with the psnr filter, sharing code and offering a common user interface for various quality measurements? Just to put it into same file? Moving it into same filter would be also possible but how would then new filter be named then? Looks like there are no new comments so I can safely assume current state as is is good enough. Yeah lgtm. Actually one question - how would I use this with with a raw yuv file as reference? ffmpeg -i main.movie -s WIDTHxHEIGHT [-pix_fmt yuv420p] -i REF.yuv -lavfi ssim -f null - Both psnr and ssim: ffmpeg -i main.movie -s WIDTHxHEIGHT -i REF.yuv -lavfi [0:v][1:v]ssim;[0:v][1:v]psnr -f null - ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
Hi,
On Tue, Jun 23, 2015 at 9:05 AM, Ludmila Glinskih lglins...@gmail.com
wrote:
+do {
+if (pkt.stream_index != video_stream)
+break;
That check shouldn't be necessary for the last frame. Sorry for missing
that on the first iteration.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
On Tue, 23 Jun 2015 16:05:38 +0300
Ludmila Glinskih lglins...@gmail.com wrote:
Result differs in pkt_duration and time_base.den for some reason.
Right now it tests only one example (adjusted to match the output).
Signed-off-by: Ludmila Glinskih lglins...@gmail.com
---
libavformat/Makefile| 1 +
libavformat/api-h264-test.c | 187
tests/fate/libavformat.mak | 4 +
tests/ref/fate/api-h264 | 18 +
4 files changed, 210 insertions(+)
create mode 100644 libavformat/api-h264-test.c
create mode 100644 tests/ref/fate/api-h264
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 993ec09..5cc0f6c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -547,6 +547,7 @@ TESTPROGS = seek
\
url \
TESTPROGS-$(CONFIG_NETWORK) += noproxy
+TESTPROGS-yes += api-h264
TESTPROGS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh
TOOLS = aviocat \
diff --git a/libavformat/api-h264-test.c b/libavformat/api-h264-test.c
new file mode 100644
index 000..ac4acc4
--- /dev/null
+++ b/libavformat/api-h264-test.c
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2015 Ludmila Glinskih
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * H264 codec test.
+ */
+
+#include libavutil/adler32.h
+#include libavcodec/avcodec.h
+#include libavformat/avformat.h
+#include libavutil/imgutils.h
+
+static int video_decode_example(const char *input_filename)
+{
+AVCodec *codec = NULL;
+AVCodecContext *origin_ctx = NULL, *ctx= NULL;
+AVFrame *fr = NULL;
+uint8_t *byte_buffer = NULL;
+AVPacket pkt;
+AVFormatContext *fmt_ctx = NULL;
+int number_of_written_bytes;
+int video_stream;
+int get_frame = 0;
+int byte_buffer_size;
+int i = 0;
+int result;
+
+result = avformat_open_input(fmt_ctx, input_filename, NULL, NULL);
+if (result 0) {
+av_log(NULL, AV_LOG_ERROR, Can't open file\n);
+return result;
+}
+
+result = avformat_find_stream_info(fmt_ctx, NULL);
+if (result 0) {
+av_log(NULL, AV_LOG_ERROR, Can't get stream info\n);
+return result;
+}
+
+video_stream = -1;
+for (i = 0; i fmt_ctx-nb_streams; i++) {
+if (fmt_ctx-streams[i]-codec-codec_type == AVMEDIA_TYPE_VIDEO) {
+video_stream = i;
+break;
+}
+}
+
+origin_ctx = fmt_ctx-streams[video_stream]-codec;
Maybe error out if video_stream is 0.
+codec = avcodec_find_decoder(origin_ctx-codec_id);
+if (codec == NULL) {
Style-wise, writing if (!codec) would probably be nicer, though
that's not important for this patch.
+av_log(NULL, AV_LOG_ERROR, Can't find decoder\n);
+return -1;
+}
+
+ctx = avcodec_alloc_context3(codec);
+if (ctx == NULL) {
+av_log(NULL, AV_LOG_ERROR, Can't allocate decoder context\n);
+return AVERROR(ENOMEM);
+}
+
+result = avcodec_copy_context(ctx, origin_ctx);
+if (result) {
+av_log(NULL, AV_LOG_ERROR, Can't copy decoder context\n);
+return result;
+}
+
+result = avcodec_open2(ctx, codec, NULL);
+if (result 0) {
+av_log(ctx, AV_LOG_ERROR, Can't open decoder\n);
+return result;
+}
+
+fr = av_frame_alloc();
+if (fr == NULL) {
+av_log(NULL, AV_LOG_ERROR, Can't allocate frame\n);
+return AVERROR(ENOMEM);
+}
+
+byte_buffer_size = av_image_get_buffer_size(ctx-pix_fmt, ctx-width,
ctx-height, 16);
+byte_buffer = av_malloc(byte_buffer_size);
+if (byte_buffer == NULL) {
+av_log(NULL, AV_LOG_ERROR, Can't allocate buffer\n);
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
Do you have any ideas why it differs from framecrc result on the same file?
пн, 22 июня 2015 г. в 12:50, Ludmila Glinskih lglins...@gmail.com:
Result differs in pkt_duration and time_base.den for some reason.
Right now it tests only one example (adjusted to match the output).
Signed-off-by: Ludmila Glinskih lglins...@gmail.com
---
libavformat/Makefile| 1 +
libavformat/api-h264-test.c | 155
tests/fate/libavformat.mak | 4 ++
tests/ref/fate/api-h264 | 18 +
4 files changed, 178 insertions(+)
create mode 100644 libavformat/api-h264-test.c
create mode 100644 tests/ref/fate/api-h264
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 993ec09..5cc0f6c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -547,6 +547,7 @@ TESTPROGS = seek
\
url \
TESTPROGS-$(CONFIG_NETWORK) += noproxy
+TESTPROGS-yes += api-h264
TESTPROGS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh
TOOLS = aviocat \
diff --git a/libavformat/api-h264-test.c b/libavformat/api-h264-test.c
new file mode 100644
index 000..e25c8f0
--- /dev/null
+++ b/libavformat/api-h264-test.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (c) 2015 Ludmila Glinskih
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
a copy
+ * of this software and associated documentation files (the Software),
to deal
+ * in the Software without restriction, including without limitation the
rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * H264 codec test.
+ */
+
+#include math.h
+
+#include libavutil/opt.h
+#include libavutil/adler32.h
+#include libavcodec/avcodec.h
+#include libavformat/avformat.h
+#include libavutil/common.h
+#include libavutil/imgutils.h
+#include libavutil/samplefmt.h
+#include libavformat/internal.h
+
+static int video_decode_example(const char *input_filename)
+{
+AVCodec *codec = NULL;
+AVCodecContext *origin_ctx = NULL, *ctx= NULL;
+AVFrame *fr = NULL;
+uint8_t *byte_buffer = NULL;
+AVPacket pkt;
+AVFormatContext *fmt_ctx = NULL;
+int number_of_written_bytes;
+int video_stream;
+int get_frame = 0;
+int byte_buffer_size;
+int i = 0;
+
+
+if (avformat_open_input(fmt_ctx, input_filename, NULL, NULL) 0) {
+fprintf(stderr, Could not open source file %s\n,
input_filename);
+exit(1);
+}
+
+if (avformat_find_stream_info(fmt_ctx, NULL) 0) {
+fprintf(stderr, Could not find stream information\n);
+exit(1);
+}
+
+video_stream = -1;
+for (i = 0; i fmt_ctx-nb_streams; i++) {
+if (fmt_ctx-streams[i]-codec-codec_type == AVMEDIA_TYPE_VIDEO)
{
+video_stream = i;
+break;
+}
+}
+
+origin_ctx = fmt_ctx-streams[video_stream]-codec;
+
+codec = avcodec_find_decoder(origin_ctx-codec_id);
+if (codec == NULL) {
+return -1;
+}
+ctx = avcodec_alloc_context3(codec);
+if (ctx == NULL) {
+return -1;
+}
+
+if (avcodec_copy_context(ctx, origin_ctx)) {
+return -1;
+}
+
+if (avcodec_open2(ctx, codec, NULL) 0) {
+return -1;
+}
+
+fr = av_frame_alloc();
+if (fr == NULL) {
+return -1;
+}
+
+byte_buffer_size = av_image_get_buffer_size(ctx-pix_fmt, ctx-width,
ctx-height, 16);
+byte_buffer = av_malloc(byte_buffer_size);
+
+printf(#tb %d: %d/%d\n, video_stream,
fmt_ctx-streams[video_stream]-time_base.num,
fmt_ctx-streams[video_stream]-time_base.den);
+i = 0;
+av_init_packet(pkt);
+while (av_read_frame(fmt_ctx, pkt) = 0) {
+if (pkt.stream_index == video_stream) {
+get_frame = 0;
+if (pkt.pts == AV_NOPTS_VALUE)
+pkt.pts = pkt.dts = i;
+avcodec_decode_video2(ctx, fr, get_frame, pkt);
+if (get_frame) {
+
Re: [FFmpeg-devel] [PATCH] libavformat: Add H264 API test
Hi,
On Tue, Jun 23, 2015 at 9:27 AM, wm4 nfx...@googlemail.com wrote:
On Tue, 23 Jun 2015 16:05:38 +0300
Ludmila Glinskih lglins...@gmail.com wrote:
Result differs in pkt_duration and time_base.den for some reason.
Right now it tests only one example (adjusted to match the output).
Signed-off-by: Ludmila Glinskih lglins...@gmail.com
---
libavformat/Makefile| 1 +
libavformat/api-h264-test.c | 187
tests/fate/libavformat.mak | 4 +
tests/ref/fate/api-h264 | 18 +
4 files changed, 210 insertions(+)
create mode 100644 libavformat/api-h264-test.c
create mode 100644 tests/ref/fate/api-h264
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 993ec09..5cc0f6c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -547,6 +547,7 @@ TESTPROGS = seek
\
url
\
TESTPROGS-$(CONFIG_NETWORK) += noproxy
+TESTPROGS-yes += api-h264
TESTPROGS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh
TOOLS = aviocat
\
diff --git a/libavformat/api-h264-test.c b/libavformat/api-h264-test.c
new file mode 100644
index 000..ac4acc4
--- /dev/null
+++ b/libavformat/api-h264-test.c
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2015 Ludmila Glinskih
+ *
+ * Permission is hereby granted, free of charge, to any person
obtaining a copy
+ * of this software and associated documentation files (the
Software), to deal
+ * in the Software without restriction, including without limitation
the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * H264 codec test.
+ */
+
+#include libavutil/adler32.h
+#include libavcodec/avcodec.h
+#include libavformat/avformat.h
+#include libavutil/imgutils.h
+
+static int video_decode_example(const char *input_filename)
+{
+AVCodec *codec = NULL;
+AVCodecContext *origin_ctx = NULL, *ctx= NULL;
+AVFrame *fr = NULL;
+uint8_t *byte_buffer = NULL;
+AVPacket pkt;
+AVFormatContext *fmt_ctx = NULL;
+int number_of_written_bytes;
+int video_stream;
+int get_frame = 0;
+int byte_buffer_size;
+int i = 0;
+int result;
+
+result = avformat_open_input(fmt_ctx, input_filename, NULL, NULL);
+if (result 0) {
+av_log(NULL, AV_LOG_ERROR, Can't open file\n);
+return result;
+}
+
+result = avformat_find_stream_info(fmt_ctx, NULL);
+if (result 0) {
+av_log(NULL, AV_LOG_ERROR, Can't get stream info\n);
+return result;
+}
+
+video_stream = -1;
+for (i = 0; i fmt_ctx-nb_streams; i++) {
+if (fmt_ctx-streams[i]-codec-codec_type ==
AVMEDIA_TYPE_VIDEO) {
+video_stream = i;
+break;
+}
+}
+
+origin_ctx = fmt_ctx-streams[video_stream]-codec;
Maybe error out if video_stream is 0.
Actually, this should use av_find_best_stream().
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat: Add H264 API test
Result differs in pkt_duration and time_base.den for some reason.
Right now it tests only one example (adjusted to match the output).
Signed-off-by: Ludmila Glinskih lglins...@gmail.com
---
libavformat/Makefile| 1 +
libavformat/api-h264-test.c | 187
tests/fate/libavformat.mak | 4 +
tests/ref/fate/api-h264 | 18 +
4 files changed, 210 insertions(+)
create mode 100644 libavformat/api-h264-test.c
create mode 100644 tests/ref/fate/api-h264
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 993ec09..5cc0f6c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -547,6 +547,7 @@ TESTPROGS = seek
\
url \
TESTPROGS-$(CONFIG_NETWORK) += noproxy
+TESTPROGS-yes += api-h264
TESTPROGS-$(CONFIG_FFRTMPCRYPT_PROTOCOL) += rtmpdh
TOOLS = aviocat \
diff --git a/libavformat/api-h264-test.c b/libavformat/api-h264-test.c
new file mode 100644
index 000..ac4acc4
--- /dev/null
+++ b/libavformat/api-h264-test.c
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2015 Ludmila Glinskih
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * H264 codec test.
+ */
+
+#include libavutil/adler32.h
+#include libavcodec/avcodec.h
+#include libavformat/avformat.h
+#include libavutil/imgutils.h
+
+static int video_decode_example(const char *input_filename)
+{
+AVCodec *codec = NULL;
+AVCodecContext *origin_ctx = NULL, *ctx= NULL;
+AVFrame *fr = NULL;
+uint8_t *byte_buffer = NULL;
+AVPacket pkt;
+AVFormatContext *fmt_ctx = NULL;
+int number_of_written_bytes;
+int video_stream;
+int get_frame = 0;
+int byte_buffer_size;
+int i = 0;
+int result;
+
+result = avformat_open_input(fmt_ctx, input_filename, NULL, NULL);
+if (result 0) {
+av_log(NULL, AV_LOG_ERROR, Can't open file\n);
+return result;
+}
+
+result = avformat_find_stream_info(fmt_ctx, NULL);
+if (result 0) {
+av_log(NULL, AV_LOG_ERROR, Can't get stream info\n);
+return result;
+}
+
+video_stream = -1;
+for (i = 0; i fmt_ctx-nb_streams; i++) {
+if (fmt_ctx-streams[i]-codec-codec_type == AVMEDIA_TYPE_VIDEO) {
+video_stream = i;
+break;
+}
+}
+
+origin_ctx = fmt_ctx-streams[video_stream]-codec;
+
+codec = avcodec_find_decoder(origin_ctx-codec_id);
+if (codec == NULL) {
+av_log(NULL, AV_LOG_ERROR, Can't find decoder\n);
+return -1;
+}
+
+ctx = avcodec_alloc_context3(codec);
+if (ctx == NULL) {
+av_log(NULL, AV_LOG_ERROR, Can't allocate decoder context\n);
+return AVERROR(ENOMEM);
+}
+
+result = avcodec_copy_context(ctx, origin_ctx);
+if (result) {
+av_log(NULL, AV_LOG_ERROR, Can't copy decoder context\n);
+return result;
+}
+
+result = avcodec_open2(ctx, codec, NULL);
+if (result 0) {
+av_log(ctx, AV_LOG_ERROR, Can't open decoder\n);
+return result;
+}
+
+fr = av_frame_alloc();
+if (fr == NULL) {
+av_log(NULL, AV_LOG_ERROR, Can't allocate frame\n);
+return AVERROR(ENOMEM);
+}
+
+byte_buffer_size = av_image_get_buffer_size(ctx-pix_fmt, ctx-width,
ctx-height, 16);
+byte_buffer = av_malloc(byte_buffer_size);
+if (byte_buffer == NULL) {
+av_log(NULL, AV_LOG_ERROR, Can't allocate buffer\n);
+return AVERROR(ENOMEM);
+}
+
+printf(#tb %d: %d/%d\n, video_stream,
fmt_ctx-streams[video_stream]-time_base.num,
fmt_ctx-streams[video_stream]-time_base.den);
+i = 0;
+av_init_packet(pkt);
+while (av_read_frame(fmt_ctx, pkt) = 0) {
+if (pkt.stream_index == video_stream) {
+get_frame = 0;
+if (pkt.pts
[FFmpeg-devel] [PATCH v2] libavformat: Add H264 API test
Now there are no warnings, more checks, more error messages. I changed the loop for the last frames. If the error occures program returns 1. Thank you for comments! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/avio: Move avio_delete() avio_move() to avpriv_ namespace
This was suggested in the discussion about these functions
With this change the functions are available internally but are not
part of the public API
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
doc/APIchanges |4
libavformat/avio.c |4 ++--
libavformat/avio.h |4 ++--
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index cc2ebf3..6e64a05 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,10 +15,6 @@ libavutil: 2014-08-09
API changes, most recent first:
-2015-xx-xx - xxx - lavf 56.38.100 - avio.h url.h
- Add avio_move(), avio_delete().
- Extend URLProtocol with url_move(), url_delete().
-
8 - FFmpeg 2.7 was cut here 8 -
2015-06-04 - cc17b43 - lswr 1.2.100
diff --git a/libavformat/avio.c b/libavformat/avio.c
index bd32944..dc6f210 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -421,7 +421,7 @@ int avio_check(const char *url, int flags)
return ret;
}
-int avio_move(const char *url_src, const char *url_dst)
+int avpriv_io_move(const char *url_src, const char *url_dst)
{
URLContext *h_src, *h_dst;
int ret = ffurl_alloc(h_src, url_src, AVIO_FLAG_READ_WRITE, NULL);
@@ -443,7 +443,7 @@ int avio_move(const char *url_src, const char *url_dst)
return ret;
}
-int avio_delete(const char *url)
+int avpriv_io_delete(const char *url)
{
URLContext *h;
int ret = ffurl_alloc(h, url, AVIO_FLAG_WRITE, NULL);
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 5ac5d38..d3d9bbd 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -238,7 +238,7 @@ int avio_check(const char *url, int flags);
* @param url_dst new url to resource if the operation succeeded
* @return =0 on success or negative on error.
*/
-int avio_move(const char *url_src, const char *url_dst);
+int avpriv_io_move(const char *url_src, const char *url_dst);
/**
* Delete a resource.
@@ -246,7 +246,7 @@ int avio_move(const char *url_src, const char *url_dst);
* @param url resource to be deleted.
* @return =0 on success or negative on error.
*/
-int avio_delete(const char *url);
+int avpriv_io_delete(const char *url);
/**
* Open directory for reading.
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Tue, 23 Jun 2015 17:33:42 +0200 Nicolas George geo...@nsup.org wrote: Le quintidi 5 messidor, an CCXXIII, wm4 a écrit : People don't follow mathematic rules, and neither do human arguments. Not even software development does. And yet, even so, the reasoning discipline gives valuable results even in these areas. Wonderful, isn't it? The current architecture just doesn't allow it without committing API atrocities. There is no doubt that FFmpeg has a lot of round pegs in square holes. Just repeating it ad nauseam is not a constructive contribution. There are two kind of constructive contributions that you can do: 1. Help design round holes for the round pegs. I've often enough suggested alternative ways how to do something, but you just keep calling me a troll instead of listening. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 13/15] lavf/brstm: add FATE tests for BFSTM and BCSTM files
On Tue, Jun 23, 2015 at 11:38:37AM +, Paul B Mahol wrote: On 6/23/15, Michael Niedermayer michae...@gmx.at wrote: On Sat, Jun 20, 2015 at 05:01:25AM -0500, Rodger Combs wrote: --- tests/fate/demux.mak | 4 tests/ref/fate/bfstm | 1 + 2 files changed, 5 insertions(+) create mode 100644 tests/ref/fate/bfstm seems to fail --- ./tests/ref/fate/bfstm 2015-06-23 13:24:53.153202270 +0200 +++ tests/data/fate/bfstm 2015-06-23 13:27:08.385205121 +0200 @@ -1 +1 @@ -CRC=0xc0ce0d33 +CRC=0xbd3d0d33 Test bfstm failed. Look at tests/data/fate/bfstm.err for details. make: *** [fate-bfstm] Error 1 make: *** Waiting for unfinished jobs reference file './tests/ref/fate/bcstm' not found ^ because of that. i think not only that, both fate-bfstm and fate-bcstm seem to fail the patch contains tests/ref/fate/bfstm but is missing ./tests/ref/fate/bcstm ./tests/fate-run.sh: 282: ./tests/fate-run.sh: cannot open tests/data/fate/bcstm.diff: No such file Test bcstm failed. Look at tests/data/fate/bcstm.err for details. make: *** [fate-bcstm] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- 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
Re: [FFmpeg-devel] [PATCH 1/3] swscale/x86/rgb2rgb_template: add missing xmm clobbers
On 23/06/15 7:48 AM, Michael Niedermayer wrote: On Tue, Jun 23, 2015 at 01:23:23AM -0300, James Almer wrote: Signed-off-by: James Almer jamr...@gmail.com --- libswscale/x86/rgb2rgb_template.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thanks All three patches pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
On 23-Jun-2015 8:41 PM, Philip Langdale phil...@overt.org wrote: On Tue, 23 Jun 2015 16:54:08 +0200 wm4 nfx...@googlemail.com wrote: In my opinion these warnings should either be silenced, or an av_bprint function taking void* should be added and used. While the warning is indeed a false positive here, they can obscure interesting warnings. A fair point. Niklesh, why don't you use a #define to add the cast without cluttering up the code too much. Something like: #define av_bprint_append_any(buf, data, size) \ av_bprint_append_data(buf, ((const char *)data), size) --phil Sure. I'll try this. Thanks, Niklesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] lavf/brstm: add FATE tests for BFSTM and BCSTM files
--- tests/fate/demux.mak | 4 tests/ref/fate/bcstm | 1 + tests/ref/fate/bfstm | 1 + 3 files changed, 6 insertions(+) create mode 100644 tests/ref/fate/bcstm create mode 100644 tests/ref/fate/bfstm diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak index 0eccc9b..05ce4bf 100644 --- a/tests/fate/demux.mak +++ b/tests/fate/demux.mak @@ -13,6 +13,10 @@ fate-ast: CMD = crc -i $(TARGET_SAMPLES)/ast/demo11_02_partial.ast -c copy FATE_SAMPLES_DEMUX-$(CONFIG_BINK_DEMUXER) += fate-bink-demux fate-bink-demux: CMD = crc -i $(TARGET_SAMPLES)/bink/Snd0a7d9b58.dee -vn -acodec copy +FATE_SAMPLES_DEMUX-$(CONFIG_BFSTM_DEMUXER) += fate-bfstm fate-bcstm +fate-bfstm: CMD = crc -i $(TARGET_SAMPLES)/bfstm/spl-forest-day.bfstm -acodec copy +fate-bcstm: CMD = crc -i $(TARGET_SAMPLES)/bfstm/loz-mm-mikau.bcstm -acodec copy + FATE_SAMPLES_DEMUX-$(CONFIG_BRSTM_DEMUXER) += fate-brstm fate-brstm: CMD = crc -i $(TARGET_SAMPLES)/brstm/lozswd_partial.brstm -acodec copy diff --git a/tests/ref/fate/bcstm b/tests/ref/fate/bcstm new file mode 100644 index 000..cde12b6 --- /dev/null +++ b/tests/ref/fate/bcstm @@ -0,0 +1 @@ +CRC=0xca62d03b diff --git a/tests/ref/fate/bfstm b/tests/ref/fate/bfstm new file mode 100644 index 000..4696ca6 --- /dev/null +++ b/tests/ref/fate/bfstm @@ -0,0 +1 @@ +CRC=0xbd3d0d33 -- 2.4.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] lavc+doc: adjust names to reflect ADPCM THP not being GameCube-only
---
doc/general.texi| 2 +-
libavcodec/adpcm.c | 4 ++--
libavcodec/codec_desc.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/general.texi b/doc/general.texi
index 471a11b..dc4d06e 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -878,7 +878,7 @@ following image formats are supported:
@item ADPCM MS IMA @tab X @tab X
@item ADPCM Nintendo Gamecube AFC @tab @tab X
@item ADPCM Nintendo Gamecube DTK @tab @tab X
-@item ADPCM Nintendo Gamecube THP @tab @tab X
+@item ADPCM Nintendo THP @tab @tab X
@item ADPCM QT IMA @tab X @tab X
@item ADPCM SEGA CRI ADX @tab X @tab X
@tab Used in Sega Dreamcast games.
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index c6ca880..bad0be4 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -1626,7 +1626,7 @@ ADPCM_DECODER(AV_CODEC_ID_ADPCM_SBPRO_2,
sample_fmts_s16, adpcm_sbpro_2,
ADPCM_DECODER(AV_CODEC_ID_ADPCM_SBPRO_3, sample_fmts_s16, adpcm_sbpro_3,
ADPCM Sound Blaster Pro 2.6-bit);
ADPCM_DECODER(AV_CODEC_ID_ADPCM_SBPRO_4, sample_fmts_s16, adpcm_sbpro_4,
ADPCM Sound Blaster Pro 4-bit);
ADPCM_DECODER(AV_CODEC_ID_ADPCM_SWF, sample_fmts_s16, adpcm_swf,
ADPCM Shockwave Flash);
-ADPCM_DECODER(AV_CODEC_ID_ADPCM_THP_LE, sample_fmts_s16p, adpcm_thp_le,
ADPCM Nintendo Gamecube THP (little-endian));
-ADPCM_DECODER(AV_CODEC_ID_ADPCM_THP, sample_fmts_s16p, adpcm_thp,
ADPCM Nintendo Gamecube THP);
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_THP_LE, sample_fmts_s16p, adpcm_thp_le,
ADPCM Nintendo THP (little-endian));
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_THP, sample_fmts_s16p, adpcm_thp,
ADPCM Nintendo THP);
ADPCM_DECODER(AV_CODEC_ID_ADPCM_XA, sample_fmts_s16p, adpcm_xa,
ADPCM CDROM XA);
ADPCM_DECODER(AV_CODEC_ID_ADPCM_YAMAHA, sample_fmts_s16, adpcm_yamaha,
ADPCM Yamaha);
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 87bbc776..43750e6 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1820,14 +1820,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
.id= AV_CODEC_ID_ADPCM_THP,
.type = AVMEDIA_TYPE_AUDIO,
.name = adpcm_thp,
-.long_name = NULL_IF_CONFIG_SMALL(ADPCM Nintendo Gamecube THP),
+.long_name = NULL_IF_CONFIG_SMALL(ADPCM Nintendo THP),
.props = AV_CODEC_PROP_LOSSY,
},
{
.id= AV_CODEC_ID_ADPCM_THP_LE,
.type = AVMEDIA_TYPE_AUDIO,
.name = adpcm_thp_le,
-.long_name = NULL_IF_CONFIG_SMALL(ADPCM Nintendo Gamecube THP
(Little-Endian)),
+.long_name = NULL_IF_CONFIG_SMALL(ADPCM Nintendo THP
(Little-Endian)),
.props = AV_CODEC_PROP_LOSSY,
},
{
--
2.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] lavf/brstm: expose the loop point when present
---
libavformat/brstm.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/libavformat/brstm.c b/libavformat/brstm.c
index 1d190c9..62940f0 100644
--- a/libavformat/brstm.c
+++ b/libavformat/brstm.c
@@ -93,6 +93,7 @@ static int read_header(AVFormatContext *s)
uint32_t size, asize, start = 0;
AVStream *st;
int ret = AVERROR_EOF;
+int loop = 0;
int bfstm = !strcmp(bfstm, s-iformat-name);
st = avformat_new_stream(s, NULL);
@@ -195,7 +196,7 @@ static int read_header(AVFormatContext *s)
return AVERROR_PATCHWELCOME;
}
-avio_skip(s-pb, 1); // loop flag
+loop = avio_r8(s-pb); // loop flag
st-codec-codec_id = codec;
st-codec-channels = avio_r8(s-pb);
if (!st-codec-channels)
@@ -209,7 +210,17 @@ static int read_header(AVFormatContext *s)
if (!bfstm)
avio_skip(s-pb, 2); // padding
-avio_skip(s-pb, 4); // loop start sample
+
+if (loop) {
+if (av_dict_set_int(s-metadata, loop_start,
+av_rescale(read32(s), AV_TIME_BASE,
+ st-codec-sample_rate),
+0) 0)
+return AVERROR(ENOMEM);
+} else {
+avio_skip(s-pb, 4);
+}
+
st-start_time = 0;
st-duration = read32(s);
avpriv_set_pts_info(st, 64, 1, st-codec-sample_rate);
--
2.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] lavf/brstm: if the file lies about the last block's size, correct it
---
libavformat/brstm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/brstm.c b/libavformat/brstm.c
index 62940f0..bf75d5b 100644
--- a/libavformat/brstm.c
+++ b/libavformat/brstm.c
@@ -369,6 +369,15 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
size= b-last_block_used_bytes;
samples = b-last_block_samples;
skip= b-last_block_size - b-last_block_used_bytes;
+
+if (samples size * 14 / 8) {
+uint32_t adjusted_size = samples / 14 * 8;
+if (samples % 14)
+adjusted_size += (samples % 14 + 1) / 2 + 1;
+
+skip += size - adjusted_size;
+size = adjusted_size;
+}
} else if (b-current_block b-block_count) {
size= b-block_size;
samples = b-samples_per_block;
--
2.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavf/brstm: add FATE tests for BFSTM and BCSTM files
On Tue, Jun 23, 2015 at 12:35:36PM -0500, Rodger Combs wrote: --- tests/fate/demux.mak | 4 tests/ref/fate/bcstm | 1 + tests/ref/fate/bfstm | 1 + 3 files changed, 6 insertions(+) create mode 100644 tests/ref/fate/bcstm create mode 100644 tests/ref/fate/bfstm 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 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
Updated patch.
Compiles without any warnings. Tested too.
Thanks,
Niklesh
On Tue, Jun 23, 2015 at 9:42 PM, Niklesh Lalwani niklesh.lalw...@iitb.ac.in
wrote:
On 23-Jun-2015 8:41 PM, Philip Langdale phil...@overt.org wrote:
On Tue, 23 Jun 2015 16:54:08 +0200
wm4 nfx...@googlemail.com wrote:
In my opinion these warnings should either be silenced, or an
av_bprint function taking void* should be added and used. While the
warning is indeed a false positive here, they can obscure interesting
warnings.
A fair point.
Niklesh, why don't you use a #define to add the cast without cluttering
up the code too much.
Something like:
#define av_bprint_append_any(buf, data, size) \
av_bprint_append_data(buf, ((const char *)data), size)
--phil
Sure. I'll try this.
Thanks,
Niklesh
From 8e208a44654a4015f0c398015d1cfec82aee96bd Mon Sep 17 00:00:00 2001
From: Niklesh niklesh.lalw...@iitb.ac.in
Date: Wed, 24 Jun 2015 01:17:46 +0530
Subject: [PATCH] movtextenc.c: Support for Bold, Italic and Underlined Styles
Signed-off-by: Niklesh niklesh.lalw...@iitb.ac.in
---
libavcodec/movtextenc.c | 186 ++--
1 file changed, 165 insertions(+), 21 deletions(-)
diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
index 1b8f454..3c818a0 100644
--- a/libavcodec/movtextenc.c
+++ b/libavcodec/movtextenc.c
@@ -24,14 +24,39 @@
#include libavutil/avassert.h
#include libavutil/avstring.h
#include libavutil/intreadwrite.h
+#include libavutil/mem.h
+#include libavutil/common.h
#include ass_split.h
#include ass.h
+#define STYLE_FLAG_BOLD (10)
+#define STYLE_FLAG_ITALIC (11)
+#define STYLE_FLAG_UNDERLINE(12)
+#define STYLE_RECORD_SIZE 12
+#define SIZE_ADD10
+
+#define av_bprint_append_any(buf, data, size) av_bprint_append_data(buf, ((const char*)data), size)
+
+typedef struct {
+uint16_t style_start;
+uint16_t style_end;
+uint8_t style_flag;
+} StyleBox;
+
typedef struct {
ASSSplitContext *ass_ctx;
-char buffer[2048];
-char *ptr;
-char *end;
+AVBPrint buffer;
+StyleBox **style_attributes;
+StyleBox *style_attributes_temp;
+int count;
+uint8_t style_box_flag;
+uint32_t tsmb_size;
+uint32_t tsmb_type;
+uint16_t style_entries;
+uint16_t style_fontID;
+uint8_t style_fontsize;
+uint32_t style_color;
+uint16_t text_pos;
} MovTextContext;
@@ -79,32 +104,110 @@ static av_cold int mov_text_encode_init(AVCodecContext *avctx)
if (!avctx-extradata)
return AVERROR(ENOMEM);
+av_bprint_init(s-buffer, 0, AV_BPRINT_SIZE_UNLIMITED);
+
memcpy(avctx-extradata, text_sample_entry, avctx-extradata_size);
s-ass_ctx = ff_ass_split(avctx-subtitle_header);
return s-ass_ctx ? 0 : AVERROR_INVALIDDATA;
}
+static void mov_text_style_cb(void *priv, const char style, int close)
+{
+MovTextContext *s = priv;
+if (!close) {
+if (s-style_box_flag == 0) { //first style entry
+
+s-style_attributes_temp = av_malloc(sizeof(*s-style_attributes_temp));
+
+if (!s-style_attributes_temp) {
+av_bprint_clear(s-buffer);
+s-style_box_flag = 0;
+return;
+}
+
+s-style_attributes_temp-style_flag = 0;
+s-style_attributes_temp-style_start = AV_RB16(s-text_pos);
+} else {
+if (s-style_attributes_temp-style_flag) { //break the style record here and start a new one
+s-style_attributes_temp-style_end = AV_RB16(s-text_pos);
+av_dynarray_add(s-style_attributes, s-count, s-style_attributes_temp);
+
+s-style_attributes_temp = av_malloc(sizeof(*s-style_attributes_temp));
+
+if (!s-style_attributes_temp) {
+av_bprint_clear(s-buffer);
+s-style_box_flag = 0;
+return;
+}
+
+s-style_attributes_temp-style_flag = s-style_attributes[s-count - 1]-style_flag;
+s-style_attributes_temp-style_start = AV_RB16(s-text_pos);
+} else {
+s-style_attributes_temp-style_flag = 0;
+s-style_attributes_temp-style_start = AV_RB16(s-text_pos);
+}
+}
+switch (style){
+case 'b':
+s-style_attributes_temp-style_flag |= STYLE_FLAG_BOLD;
+break;
+case 'i':
+s-style_attributes_temp-style_flag |= STYLE_FLAG_ITALIC;
+break;
+case 'u':
+s-style_attributes_temp-style_flag |= STYLE_FLAG_UNDERLINE;
+break;
+}
+} else {
+s-style_attributes_temp-style_end = AV_RB16(s-text_pos);
+av_dynarray_add(s-style_attributes, s-count, s-style_attributes_temp);
+
+s-style_attributes_temp = av_malloc(sizeof(*s-style_attributes_temp));
+
+if (!s-style_attributes_temp) {
+
Re: [FFmpeg-devel] [PATCH 2/2] movtextenc.c: Support for Bold, Italic and Underlined styles
On Wed, Jun 24, 2015 at 01:25:53AM +0530, Niklesh Lalwani wrote: Updated patch. Compiles without any warnings. Tested too. this changes the fate checksum --- ./tests/ref/fate/binsub-movtextenc 2015-06-23 21:52:17.741843656 +0200 +++ tests/data/fate/binsub-movtextenc 2015-06-23 22:06:37.389861767 +0200 @@ -1 +1 @@ -ef264064c522389d0cf267c4d6235561 +59cad033309cebac08fda1ebd01677ac TESTsub-cc Test binsub-movtextenc failed. Look at tests/data/fate/binsub-movtextenc.err for details. make: *** [fate-binsub-movtextenc] Error 1 make: *** Waiting for unfinished jobs if thats intended then the chnage should be included in the patch [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vaapi_h264: fix RefPicList[] field flags.
2015-06-23 13:10 GMT+02:00 Michael Niedermayer michae...@gmx.at: On Tue, Jun 23, 2015 at 11:50:52AM +0200, Gwenole Beauchesne wrote: Use new H264Ref.reference field to track field picture flags. The H264Picture.reference flag in DPB is now irrelevant here. This is a regression from git commit d8151a7, and that affected multiple interlaced video streams. Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com --- libavcodec/vaapi_h264.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) LGTM Pushed to git master and release/2.7, in case a 2.7.2 is planned. 2.6 was fine. All H.264 conformance tests now pass again. Exceptions are: - CVFC1_Sony_C: usual crop issues ; - BA3_SVA_C: probably driver issue. Usually disabled since this is extended profile with main profile only coding tools. Regards, -- Gwenole Beauchesne Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France Registration Number (RCS): Nanterre B 302 456 199 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC update
Thank you for the detailed reply. It has helped me understand the
structures a lot better than before.
Comments inline.
On Tue, Jun 23, 2015 at 5:25 PM, Nicolas George geo...@nsup.org wrote:
This has better go to the mailing list.
Le quintidi 5 messidor, an CCXXIII, Stephan Holljes a écrit :
So far I have split ff_listen_bind() into ff_listen_bind() and
ff_accept() and added an url_accept field to URLProtocol (see attached
patch).
I do not believe this is the correct approach. ff_listen_bind() is an
internal helper that works specifically for sockets.
I read our past exchanges for a number of times and I am somewhat at a
loss as to where to allocate my additional Client(-Contexts).
No sourcefile I have looked at stores multiple AVIOContexts or
AVFormatContexts (or I have not seen it).
I also could not find out how ffmpeg would even accept multiple
clients. The ff_listen_bind() call is blocking on accept() and it is
only called once.
Maybe I'm also overlooking some documentation. Maybe I am also looking
in the wrong place. The files I have looked at the most have been:
url.h network.c/h, avio.c/h aviobuf.c and tcp.c.
You need to understand very well how it happens for plain Unix TCP clients.
First, the server create and prepares the server socket s, with socket(),
bind() and mostly listen(). There is also a list of client sockets c[i],
initially empty.
Then, indefinitely and in parallel:
* call accept() on s: this returns a new c[i] added to the list;
* perform read() / write() on each c[i], remove them from the list if they
are finished.
Here, in parallel means either threads, forked processes, or emulated
parallelism with poll() and non-blocking operations. For lavf, non-blocking
operations do not work, so you can assume parallelism between multiple
clients is achieved with threads; although I very much would like that all
new networking code is input-driven and therefore ready for non-blocking.
Now, as for how to transpose it into lavf terms:
* Creating and preparing the server socket: avio_open2() with various
options for the address and the listen option set.
Am I correct to understand that this has to return immediately,
because if avio_open2() does not return, I have no (server)
AVIOContext to call avio_accept() with?
The HTTPContext will then not have any clients connected to it, which
is different from the current behaviour.
* Accepting a new client: a new function that you have to design, probably
avio_accept().
There are a few caveats for avio_accept():
* Creating a new AVFormatContext, like accept() creates a new socket. That
is not really difficult, IMHO. It just means the API will look somewhat
like that:
int avio_accept(AVIOContext *s, AVIOContext **c, ...);
The c parameter is just like the s parameter to avio_open2(): it allocates
a new context if necessary and populates it.
* Except, the current API accepts a single client by replacing the server
context. This must still be possible after the change. Maybe just
overwriting the server context will work, but it must be considered.
* If you remember, a full TCP accept() requires three handshake packets: SYN
from the client, ACK-SYN from the server and then ACK from the client. The
kernel handles this in the background and accept() returns a new client
only when the full handshake is done. In lavf, we do not have a kernel
working in the background, so it must be explicit.
We can look at how non-blocking connect() works: first call connect() on
the socket, it returns EINPROGRESS immediately, the repeatedly call
getsockopt(SO_ERROR) to check the status of the connection until it stops
returning EAGAIN.
I believe we can do the same: avio_accept(s, c) to initiate the accept,
and then avio_accept_connect(c) or something (feel free to suggest better
names) to finish the handshake.
For the particular case of the HTTP server, the avio_accept() part would
call avio_accept() on the underlying socket (or TLS context), and the
avio_accept_connect() would call avio_accept_connect() on the underlying
context and then perform the handshake.
In terms of application, the code would probably look something like this
(error checks and stuff removed):
av_dict_set(options, listen, 1);
avio_open2(server, http://:8080;, options);
while (1) {
avio_accept(server, client);
thread_run {
avio_accept_connect(client);
communicate_with_the_client(client);
avio_close(client);
};
}
Would this still be in http.c? If my thinking is correct, this should
be in http_open() then, but only if http_listen() returns without
accepting an initial client.
Hope this helps.
Regards,
--
Nicolas George
A lot of this I still can't wrap my head around. I am still not sure
about a lot of things, for example how and where to use threading to
serve clients in parallel, or
[FFmpeg-devel] [PATCH] vaapi_h264: fix RefPicList[] field flags.
Use new H264Ref.reference field to track field picture flags. The H264Picture.reference flag in DPB is now irrelevant here. This is a regression from git commit d8151a7, and that affected multiple interlaced video streams. Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com --- libavcodec/vaapi_h264.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c index eef3c29..151aca9 100644 --- a/libavcodec/vaapi_h264.c +++ b/libavcodec/vaapi_h264.c @@ -162,7 +162,8 @@ static void fill_vaapi_RefPicList(VAPictureH264 RefPicList[32], unsigned int i, n = 0; for (i = 0; i ref_count; i++) if (ref_list[i].reference) -fill_vaapi_pic(RefPicList[n++], ref_list[i].parent, 0); +fill_vaapi_pic(RefPicList[n++], ref_list[i].parent, + ref_list[i].reference); for (; n 32; n++) init_vaapi_pic(RefPicList[n]); -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
Le quintidi 5 messidor, an CCXXIII, Derek Buitenhuis a écrit : The crux of the issue here is that there is disagreement on whether some features should be in libav* at all. It's separation of functionality. It's not really possible to show something satisfactory when it's the wrong place for it in the first place, in someone's mind. I speak for myself here, only, of course. Take it with a grain of salt. As someone who pushed for a project that had similar opposition (the HTTP server), I believe I must intervene. First, let us try to agree on a few basic points. Statement: you only get to decide on what you spent your own time. Other developers decide for themselves. You can try to persuade them that optimizing a codec is more important than writing a spell checker, but in the end, if they want to write a spell checker, they will write a spell checker, for FFmpeg or for another project. Agreed? Second, and this is rather a big point, so it will be itemized; please read to the end before replying: What actual harm does it do if someone works on something that you believe is outside the scope of the project? I understand that you do not want to endorse committing lavu: add a spell checker, and even less spend time on it, but why actually oppose it? I can see a few reasons, let us discuss them. 1. It looks silly. Yes it does. And for that reason, nobody will actually support adding a spell checker to lavu. But that does not apply to exposing extra features of protocols that are already implemented. 2. It is a waste of valuable developer time. See my first statement: you do not get to decide that, each person decide for themselves. If someone decides to implement it now, if someone else decides to maintain it later, that is their decision, they do so because they find value in it. And if nobody does, you can let it bitrot and have the pleasure of removing it when it has become obvious it was useless. 3. It pollutes the code. That, I can agree with, but that can be mitigated: separate source files, optional compilation, well-defined entry points. You can insist on such things. Note that the notion of maintainership applies: AFAIK, you never wrote a line about the libssh client, so your say in what happens in it is limited. Limited, I would say, to the parts of the code that can be reached by your use cases. In other words: if it does not affect the code you actively work on and if it does not change the run path of the features you really use, let it be. 4. It wastes compilation time. That, I could agree too, having worked on under-powered boxes. But let us be realistic: all these features we are talking about are tiny. All together, they take less time building than the file for the optimized DSP code of a single major codec. 5. It wastes limited resources, in particular funding and sponsorship. Does it? Did we have a promising candidate that did not get a slot because of one of these project? As far as I can see, the limiting factor until now was the number of motivated candidates. 6. Anything else? There is another point I wish to make before ending this too long mail: I believe we can agree on a few very generic guidelines about what should be accepted in the project. In other words, I wish to explain why I support the directory listing API and the HTTP server but I would oppose libavspellcheck. I believe any of at least three conditions can make a new feature acceptable: 1. A feature that is similar, in essence, to an already widely accepted feature. New codecs are ok, because FFmpeg already has a lot of codecs. We already have a X11 screen capture device, that means a windows screen capture device or a Wayland capture device would have its place. 2. If we already have code that we need, then exposing the feature as a clean API makes sense. With a caveat: exposing a public API freezes it, so the evolution must be considered carefully. An example: we need FFTs for the codecs. Then exposing a public AVFFT interface makes sense. Another example: hashes, we need them for some the checksums in some formats, they have a rather natural an well-delimited interface, it would be absurd not to expose them. Well, we already have a HTTP server! It is hidden in ffserver and duplicates some of the HTTP client code. If Stephan can merge the code and give it a good overhaul, how is that bad? Same goes for the output devices in lavd: ffplay needs a window to display the video, other apps would benefit from it too. It does not look very good currently because the work is only less than halfway done: the devices are added, but they are not used in ffplay because the API has some missing features. But theoretically it would look really good. 3. If it makes existing feature
Re: [FFmpeg-devel] [PATCH] vda: unlock the pixel buffer base address.
On Sat, Jun 20, 2015 at 01:19:29PM +0200, Sebastien Zwickert wrote: The pixel buffer base address is never unlocked this causes a bug with some pixel format types that are produced natively by the hardware decoder: the first buffer was always used. Unlock the pixel buffer base address fixes the issue. --- ffmpeg_vda.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ffmpeg_vda.c b/ffmpeg_vda.c index d15648d..6fe4ed4 100644 --- a/ffmpeg_vda.c +++ b/ffmpeg_vda.c @@ -77,6 +77,8 @@ static int vda_retrieve_data(AVCodecContext *s, AVFrame *frame) frame-width, frame-height); ret = av_frame_copy_props(vda-tmp_frame, frame); +CVPixelBufferUnlockBaseAddress(pixbuf, kCVPixelBufferLock_ReadOnly); + if (ret 0) return ret; Applied, thanks. -- Clément B. pgpUN1SDPTi0K.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vaapi_h264: fix RefPicList[] field flags.
On Tue, Jun 23, 2015 at 11:50:52AM +0200, Gwenole Beauchesne wrote: Use new H264Ref.reference field to track field picture flags. The H264Picture.reference flag in DPB is now irrelevant here. This is a regression from git commit d8151a7, and that affected multiple interlaced video streams. Signed-off-by: Gwenole Beauchesne gwenole.beauche...@intel.com --- libavcodec/vaapi_h264.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) LGTM thx [...] -- 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/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Tue, 23 Jun 2015 12:51:18 +0200 Nicolas George geo...@nsup.org wrote: Le quintidi 5 messidor, an CCXXIII, wm4 a écrit : I think you're alone with this. I do not intend to push for it, it was just an extreme example. I do maths, and there is one thing we learn: if you want to know how solid an argument is, push it to the extreme. If you suspect f is monotonic and want to know whether it is increasing or decreasing, look at its asymptotic behaviour. If you want to know if libavremotefileoperations makes sense, wonder about libspellcheck. People don't follow mathematic rules, and neither do human arguments. Not even software development does. libav* are for (de)muxing and decoding/encoding. libav* are for what developers want to make them for. The current architecture just doesn't allow it without committing API atrocities. (You might consider this abuse, but I gave enough convincing examples.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 13/15] lavf/brstm: add FATE tests for BFSTM and BCSTM files
On Sat, Jun 20, 2015 at 05:01:25AM -0500, Rodger Combs wrote: --- tests/fate/demux.mak | 4 tests/ref/fate/bfstm | 1 + 2 files changed, 5 insertions(+) create mode 100644 tests/ref/fate/bfstm seems to fail --- ./tests/ref/fate/bfstm 2015-06-23 13:24:53.153202270 +0200 +++ tests/data/fate/bfstm 2015-06-23 13:27:08.385205121 +0200 @@ -1 +1 @@ -CRC=0xc0ce0d33 +CRC=0xbd3d0d33 Test bfstm failed. Look at tests/data/fate/bfstm.err for details. make: *** [fate-bfstm] Error 1 make: *** Waiting for unfinished jobs reference file './tests/ref/fate/bcstm' not found ./tests/fate-run.sh: 282: ./tests/fate-run.sh: cannot open tests/data/fate/bcstm.diff: No such file Test bcstm failed. Look at tests/data/fate/bcstm.err for details. make: *** [fate-bcstm] Error 1 [...] -- 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] [PATCH 13/15] lavf/brstm: add FATE tests for BFSTM and BCSTM files
On 6/23/15, Michael Niedermayer michae...@gmx.at wrote: On Sat, Jun 20, 2015 at 05:01:25AM -0500, Rodger Combs wrote: --- tests/fate/demux.mak | 4 tests/ref/fate/bfstm | 1 + 2 files changed, 5 insertions(+) create mode 100644 tests/ref/fate/bfstm seems to fail --- ./tests/ref/fate/bfstm 2015-06-23 13:24:53.153202270 +0200 +++ tests/data/fate/bfstm 2015-06-23 13:27:08.385205121 +0200 @@ -1 +1 @@ -CRC=0xc0ce0d33 +CRC=0xbd3d0d33 Test bfstm failed. Look at tests/data/fate/bfstm.err for details. make: *** [fate-bfstm] Error 1 make: *** Waiting for unfinished jobs reference file './tests/ref/fate/bcstm' not found ^ because of that. ./tests/fate-run.sh: 282: ./tests/fate-run.sh: cannot open tests/data/fate/bcstm.diff: No such file Test bcstm failed. Look at tests/data/fate/bcstm.err for details. make: *** [fate-bcstm] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Tue, 23 Jun 2015 11:05:31 +0200 Nicolas George geo...@nsup.org wrote: Yes, libavspellcheck! I used it as an absurd example, but if you think carefully on it, it is not actually absurd. I think you're alone with this. libav* are for (de)muxing and decoding/encoding. That's why people are using it. Everything else FFmpeg does extremely badly, and thus is better done somewhere else. It all boils down to API and organization really. It wouldn't be much of a problem to add a separate git repo that contains libavspellchecker. This would be truly independent. But I know what would happen... you'd add subtitle support to libavfilter, and the spell checker would be implemented as a filter. We could have libavremotefileoperations too, but no, it will just end up in libavformat. Oh, and even if we had libavspellchecker or libavremotefileoperations, it would have to be part of The Big Git Repo. For some reason. Even though the sub-libs are supposed to be independent. (Totally.) Your arguments all make sense, but the way things will actually be done is different and usually terrible. (Just think about it. Things such as adding video outputs through a muxer API just because the original authors didn't know a better place for it. Using a muxer API for video output is absurd, but if you bang your head against ffmpeg.c enough, your brain matter becomes squished enough that it starts making sense.) Regarding bloat: distro versions of FFmpeg are typically extremely bloated. It's fun to watch: merely linking a C source file containing only a main function to Debian's build of libavformat will allocate at least 10 MB of RAM on program start. Bloat is bad because it adds up. And you can't escape it either. If you link to a distro build of libavformat, your program will use more memory and will take longer to load as it would if you'd compile it yourself. I'm also not sure why you think maintaining essentially dead code is hard. Hint: it is pretty hard if you actually want to make FFmpeg saner overall. Bloat is like the concrete that keeps entangled software entangled. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
Le quintidi 5 messidor, an CCXXIII, wm4 a écrit : I think you're alone with this. I do not intend to push for it, it was just an extreme example. I do maths, and there is one thing we learn: if you want to know how solid an argument is, push it to the extreme. If you suspect f is monotonic and want to know whether it is increasing or decreasing, look at its asymptotic behaviour. If you want to know if libavremotefileoperations makes sense, wonder about libspellcheck. libav* are for (de)muxing and decoding/encoding. libav* are for what developers want to make them for. It wouldn't be much of a problem to add a separate git repo that contains libavspellchecker. This would be truly independent. But I know what would happen... you'd add subtitle support to libavfilter, and the spell checker would be implemented as a filter. Yes, exactly. We want everything in FFmpeg because multimedia is an entangled topic: if you want to do anything non-trivial, you need everything. We could have libavremotefileoperations too, but no, it will just end up in libavformat. Please give us ONE GOOD REASON to split the libraries. I myself advocate for one single libffmpeg.so, because the only practical consequences I see to the split is the hassle of intra-project ABI stability, with all the avpriv_frobnicate() stuff. Even libavformat and libavcodec belong together: demuxers require parsers, and parsers share code with decoders. The rest is peanuts. By having all together, we can have a common testing framework. Look at what happens in the Linux kernel: even for modules that could be shipped separately, the policy is to have it all in one huge repository. The FFmpeg code base is not nearly as big as the Linux code base. is different and usually terrible. For your information, I consider the paragraphs that contain that kind of gratuitous abuse non-existent. I'm also not sure why you think maintaining essentially dead code is hard. That is exactly the opposite, I think it is easy: just run the bulldozer on the oldest parts of the graveyard once in a while. 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 3/3] swscale/x86/rgb2rgb_template: fix signedness of v in shuffle_bytes_2103_{mmx, mmxext}
On Tue, Jun 23, 2015 at 01:23:25AM -0300, James Almer wrote: Signed-off-by: James Almer jamr...@gmail.com --- libswscale/x86/rgb2rgb_template.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 Used only once- Some unspecified defect prevented a second use In good condition - Can be repaird by experienced expert As is - You wouldnt want it even if you were payed for it, if you knew ... signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] swscale/x86/rgb2rgb_template: add missing xmm clobbers
On Tue, Jun 23, 2015 at 01:23:23AM -0300, James Almer wrote: Signed-off-by: James Almer jamr...@gmail.com --- libswscale/x86/rgb2rgb_template.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 Rare item - Common item with rare defect or maybe just a lie Professional - 'Toy' made in china, not functional except as doorstop Experts will know - The seller hopes you are not an expert signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] swscale/x86/rgb2rgb_template: don't call emms on sse2/avx functions
On Tue, Jun 23, 2015 at 01:23:24AM -0300, James Almer wrote: Signed-off-by: James Almer jamr...@gmail.com --- libswscale/x86/rgb2rgb_template.c | 4 1 file changed, 4 insertions(+) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libvpxdec: report colorspace
Hi, On Tue, Jun 23, 2015 at 6:21 PM, James Zern jz...@google.com wrote: --- libavcodec/libvpxdec.c | 7 +++ 1 file changed, 7 insertions(+) sgtm. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/file: check for dirent.h support
On Tue, Jun 23, 2015 at 8:34 PM, Michael Niedermayer michae...@gmx.at
wrote:
On Mon, Jun 22, 2015 at 12:01:33AM +0200, Mariusz Szczepańczyk wrote:
---
configure | 2 ++
libavformat/file.c | 34 ++
2 files changed, 36 insertions(+)
this and the previous patch fails to build
make distclean ; ./configure --disable-sdl make -j12
libavformat/file.c: In function ‘file_read_dir’:
libavformat/file.c:302:10: error: ‘DT_FIFO’ undeclared (first use in this
function)
libavformat/file.c:302:10: note: each undeclared identifier is reported
only once for each function it appears in
libavformat/file.c:305:10: error: ‘DT_CHR’ undeclared (first use in this
function)
libavformat/file.c:308:10: error: ‘DT_DIR’ undeclared (first use in this
function)
libavformat/file.c:311:10: error: ‘DT_BLK’ undeclared (first use in this
function)
libavformat/file.c:314:10: error: ‘DT_REG’ undeclared (first use in this
function)
libavformat/file.c:317:10: error: ‘DT_LNK’ undeclared (first use in this
function)
libavformat/file.c:320:10: error: ‘DT_SOCK’ undeclared (first use in this
function)
libavformat/file.c:323:10: error: ‘DT_UNKNOWN’ undeclared (first use in
this function)
make: *** [libavformat/file.o] Error 1
make: *** Waiting for unfinished jobs
sdl disable is needed to reproduce as sdls pkgcnonfig adds
GNU_SOURCE i suspect
Added contraint on _GNU_SOURCE and now it compiles fine on my linux in both
cases (with or without sdl).
I've sent two patches to keep my and Lukasz's work separated. Of course I
can squash them if you like.
Mariusz
From aa9ee21be55e565362740791a949b97e88631168 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mariusz=20Szczepa=C5=84czyk?= mszczepanc...@gmail.com
Date: Wed, 10 Jun 2015 03:30:29 +0200
Subject: [PATCH 2/2] lavf/file: check for dirent.h support
---
configure | 2 ++
libavformat/file.c | 34 ++
2 files changed, 36 insertions(+)
diff --git a/configure b/configure
index 0620936..069e997 100755
--- a/configure
+++ b/configure
@@ -1681,6 +1681,7 @@ HEADERS_LIST=
dev_video_bktr_ioctl_bt848_h
dev_video_meteor_ioctl_meteor_h
direct_h
+dirent_h
dlfcn_h
d3d11_h
dxva_h
@@ -4995,6 +4996,7 @@ enabled xlib
check_func_headers X11/Xlib.h X11/extensions/Xvlib.h XvGetPortAttribute -lXv -lX11 -lXext
check_header direct.h
+check_header dirent.h
check_header dlfcn.h
check_header d3d11.h
check_header dxva.h
diff --git a/libavformat/file.c b/libavformat/file.c
index 407540c..37da985 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -23,7 +23,9 @@
#include libavutil/internal.h
#include libavutil/opt.h
#include avformat.h
+#if HAVE_DIRENT_H
#include dirent.h
+#endif
#include fcntl.h
#if HAVE_IO_H
#include io.h
@@ -52,7 +54,9 @@ typedef struct FileContext {
int fd;
int trunc;
int blocksize;
+#if HAVE_DIRENT_H
DIR *dir;
+#endif
} FileContext;
static const AVOption file_options[] = {
@@ -229,6 +233,7 @@ static int file_close(URLContext *h)
static int file_open_dir(URLContext *h)
{
+#if HAVE_DIRENT_H
FileContext *c = h-priv_data;
c-dir = opendir(h-filename);
@@ -236,10 +241,14 @@ static int file_open_dir(URLContext *h)
return AVERROR(errno);
return 0;
+#else
+return AVERROR(ENOSYS);
+#endif /* HAVE_DIRENT_H */
}
static int file_read_dir(URLContext *h, AVIODirEntry **next)
{
+#if HAVE_DIRENT_H
FileContext *c = h-priv_data;
struct dirent *dir;
char *fullpath = NULL;
@@ -267,11 +276,28 @@ static int file_read_dir(URLContext *h, AVIODirEntry **next)
(*next)-modification_timestamp = INT64_C(100) * st.st_mtime;
(*next)-access_timestamp = INT64_C(100) * st.st_atime;
(*next)-status_change_timestamp = INT64_C(100) * st.st_ctime;
+
+#if !defined(_DIRENT_HAVE_D_TYPE) || !defined(_GNU_SOURCE)
+if (S_ISDIR(st.st_mode))
+(*next)-type = AVIO_ENTRY_DIRECTORY;
+else if (S_ISFIFO(st.st_mode))
+(*next)-type = AVIO_ENTRY_NAMED_PIPE;
+else if (S_ISCHR(st.st_mode))
+(*next)-type = AVIO_ENTRY_CHARACTER_DEVICE;
+else if (S_ISBLK(st.st_mode))
+(*next)-type = AVIO_ENTRY_BLOCK_DEVICE;
+else if (S_ISREG(st.st_mode))
+(*next)-type = AVIO_ENTRY_FILE;
+else
+(*next)-type = AVIO_ENTRY_UNKNOWN;
+#endif /* !defined(_DIRENT_HAVE_D_TYPE) || !defined(_GNU_SOURCE) */
}
av_free(fullpath);
}
(*next)-name = av_strdup(dir-d_name);
+
+#if defined(_DIRENT_HAVE_D_TYPE) defined(_GNU_SOURCE)
switch (dir-d_type) {
case DT_FIFO:
(*next)-type = AVIO_ENTRY_NAMED_PIPE;
@@ -299,14 +325,22 @@ static int file_read_dir(URLContext *h, AVIODirEntry **next)
(*next)-type = AVIO_ENTRY_UNKNOWN;
break;
}
+#endif /*
[FFmpeg-devel] [PATCH 2/2] fate/api-tests: Move api-flac-test to API tests directory.
---
libavcodec/Makefile| 2 -
libavcodec/api-flac-test.c | 266 -
tests/Makefile | 1 +
tests/api/Makefile | 3 +
tests/api/api-flac-test.c | 266 +
tests/fate/api.mak | 8 ++
tests/fate/libavcodec.mak | 6 -
7 files changed, 278 insertions(+), 274 deletions(-)
delete mode 100644 libavcodec/api-flac-test.c
create mode 100644 tests/api/api-flac-test.c
create mode 100644 tests/fate/api.mak
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a389f57..aca212c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -903,8 +903,6 @@ TESTPROGS = imgconvert
\
options \
avfft \
-TESTPROGS += api-flac
-
TESTPROGS-$(CONFIG_CABAC) += cabac
TESTPROGS-$(CONFIG_FFT) += fft fft-fixed fft-fixed32
TESTPROGS-$(CONFIG_IDCTDSP) += dct
diff --git a/libavcodec/api-flac-test.c b/libavcodec/api-flac-test.c
deleted file mode 100644
index 402d4df..000
--- a/libavcodec/api-flac-test.c
+++ /dev/null
@@ -1,266 +0,0 @@
-/*
- * Copyright (c) 2015 Ludmila Glinskih
- * Copyright (c) 2001 Fabrice Bellard
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this software and associated documentation files (the Software), to
deal
- * in the Software without restriction, including without limitation the rights
- * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
- * copies of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
- * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
- * THE SOFTWARE.
- */
-
-/*
- * FLAC codec test.
- * Encodes raw data to FLAC format and decodes it back to raw. Compares
raw-data
- * after that.
- */
-
-#include avcodec.h
-#include libavutil/common.h
-#include libavutil/samplefmt.h
-
-#define NUMBER_OF_FRAMES 200
-#define NAME_BUFF_SIZE 100
-
-/* generate i-th frame of test audio */
-static int generate_raw_frame(uint16_t *frame_data, int i, int sample_rate,
- int channels, int frame_size)
-{
-int j, k;
-
-for (j = 0; j frame_size; j++) {
-frame_data[channels * j] = 1 * ((j / 10 * i) % 2);
-for (k = 1; k channels; k++)
-frame_data[channels * j + k] = frame_data[channels * j] * (k + 1);
-}
-return 0;
-}
-
-static int init_encoder(AVCodec *enc, AVCodecContext **enc_ctx,
-int64_t ch_layout, int sample_rate)
-{
-AVCodecContext *ctx;
-int result;
-char name_buff[NAME_BUFF_SIZE];
-
-av_get_channel_layout_string(name_buff, NAME_BUFF_SIZE, 0, ch_layout);
-av_log(NULL, AV_LOG_INFO, channel layout: %s, sample rate: %i\n,
name_buff, sample_rate);
-
-ctx = avcodec_alloc_context3(enc);
-if (!ctx) {
-av_log(NULL, AV_LOG_ERROR, Can't allocate encoder context\n);
-return AVERROR(ENOMEM);
-}
-
-ctx-sample_fmt = AV_SAMPLE_FMT_S16;
-ctx-sample_rate = sample_rate;
-ctx-channel_layout = ch_layout;
-
-result = avcodec_open2(ctx, enc, NULL);
-if (result 0) {
-av_log(ctx, AV_LOG_ERROR, Can't open encoder\n);
-return result;
-}
-
-*enc_ctx = ctx;
-return 0;
-}
-
-static int init_decoder(AVCodec *dec, AVCodecContext **dec_ctx,
-int64_t ch_layout)
-{
-AVCodecContext *ctx;
-int result;
-
-ctx = avcodec_alloc_context3(dec);
-if (!ctx) {
-av_log(NULL, AV_LOG_ERROR , Can't allocate decoder context\n);
-return AVERROR(ENOMEM);
-}
-
-ctx-request_sample_fmt = AV_SAMPLE_FMT_S16;
-/* XXX: FLAC ignores it for some reason */
-ctx-request_channel_layout = ch_layout;
-ctx-channel_layout = ch_layout;
-
-result = avcodec_open2(ctx, dec, NULL);
-if (result 0) {
-av_log(ctx, AV_LOG_ERROR, Can't open decoder\n);
-return result;
-}
-
-*dec_ctx = ctx;
-return 0;
-}
-
-static int run_test(AVCodec *enc, AVCodec *dec, AVCodecContext *enc_ctx,
-AVCodecContext *dec_ctx)
-{
-AVPacket enc_pkt;
-AVFrame *in_frame, *out_frame;
-uint8_t *raw_in = NULL, *raw_out
[FFmpeg-devel] [PATCH 1/2] fate/api-tests: Add directory and Makefile for API tests
The intention of this change is to allow separation of API tests from the existing tests, and also to have a place for the API test source/executable files so they're not mixed in with the actual library code. --- tests/Makefile | 3 +++ tests/api/Makefile | 9 + 2 files changed, 12 insertions(+) create mode 100644 tests/api/Makefile diff --git a/tests/Makefile b/tests/Makefile index cffa541..2eaa0cc 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -89,6 +89,9 @@ FILTERDEMDECENCMUX = $(call ALLYES, $(1:%=%_FILTER) $(2)_DEMUXER $(3)_DECODER $( PARSERDEMDEC = $(call ALLYES, $(1)_PARSER $(2)_DEMUXER $(3)_DECODER) +APITESTSDIR := tests/api +include $(SRC_PATH)/$(APITESTSDIR)/Makefile + include $(SRC_PATH)/tests/fate/acodec.mak include $(SRC_PATH)/tests/fate/vcodec.mak include $(SRC_PATH)/tests/fate/avformat.mak diff --git a/tests/api/Makefile b/tests/api/Makefile new file mode 100644 index 000..9cb3d7f --- /dev/null +++ b/tests/api/Makefile @@ -0,0 +1,9 @@ +APITESTOBJS := $(APITESTPROGS:%=$(APITESTSDIR)/%-test.o) +APITESTPROGS := $(APITESTPROGS:%=$(APITESTSDIR)/%-test$(EXESUF)) +-include $(wildcard $(APITESTOBJS:.o=.d)) + +$(APITESTPROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF) + $(CP) $ $@ + $(STRIP) $@ + +$(foreach P,$(APITESTPROGS),$(eval $(call DOPROG,$(P:$(PROGSSUF)$(EXESUF)= -- 2.4.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/libsmbclient: implement move and delete callbacks
On Mon, Jun 22, 2015 at 04:58:00AM +0200, Mariusz Szczepańczyk wrote: --- libavformat/libsmbclient.c | 63 ++ 1 file changed, 63 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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] libvpxdec: report profile for vp9
Hello, On Tue, Jun 23, 2015 at 6:21 PM, James Zern jz...@google.com wrote: --- libavcodec/libvpxdec.c | 20 1 file changed, 20 insertions(+) lgtm. (This is probably a weird/stupid question, but I wonder if it makes sense, conceptually, to share the profiles array between vp9.c and libvpxdec.c?) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libvpxdec: report profile for vp9
On 23/06/15 7:21 PM, James Zern wrote:
---
libavcodec/libvpxdec.c | 20
1 file changed, 20 insertions(+)
diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index c69e888..b31e7b9 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -66,22 +66,28 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
return AVERROR_INVALIDDATA;
switch (img-fmt) {
case VPX_IMG_FMT_I420:
+if (avctx-codec_id == AV_CODEC_ID_VP9)
+avctx-profile = FF_PROFILE_VP9_0;
avctx-pix_fmt = AV_PIX_FMT_YUV420P;
return 0;
#if CONFIG_LIBVPX_VP9_DECODER
case VPX_IMG_FMT_I422:
+avctx-profile = FF_PROFILE_VP9_1;
avctx-pix_fmt = AV_PIX_FMT_YUV422P;
return 0;
#if VPX_IMAGE_ABI_VERSION = 3
case VPX_IMG_FMT_I440:
+avctx-profile = FF_PROFILE_VP9_1;
avctx-pix_fmt = AV_PIX_FMT_YUV440P;
return 0;
#endif
case VPX_IMG_FMT_I444:
+avctx-profile = FF_PROFILE_VP9_1;
avctx-pix_fmt = AV_PIX_FMT_YUV444P;
return 0;
#ifdef VPX_IMG_FMT_HIGHBITDEPTH
case VPX_IMG_FMT_I42016:
+avctx-profile = FF_PROFILE_VP9_2;
if (img-bit_depth == 10) {
avctx-pix_fmt = AV_PIX_FMT_YUV420P10LE;
return 0;
@@ -92,6 +98,7 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
return AVERROR_INVALIDDATA;
}
case VPX_IMG_FMT_I42216:
+avctx-profile = FF_PROFILE_VP9_3;
if (img-bit_depth == 10) {
avctx-pix_fmt = AV_PIX_FMT_YUV422P10LE;
return 0;
@@ -103,6 +110,7 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
}
#if VPX_IMAGE_ABI_VERSION = 3
case VPX_IMG_FMT_I44016:
+avctx-profile = FF_PROFILE_VP9_3;
if (img-bit_depth == 10) {
avctx-pix_fmt = AV_PIX_FMT_YUV440P10LE;
return 0;
@@ -114,6 +122,7 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
}
#endif
case VPX_IMG_FMT_I44416:
+avctx-profile = FF_PROFILE_VP9_3;
if (img-bit_depth == 10) {
avctx-pix_fmt = AV_PIX_FMT_YUV444P10LE;
return 0;
@@ -211,6 +220,16 @@ static av_cold int vp9_init(AVCodecContext *avctx)
return vpx_init(avctx, vpx_codec_vp9_dx_algo);
}
+static const AVProfile profiles[] = {
+{ FF_PROFILE_VP9_0, Profile 0 },
+{ FF_PROFILE_VP9_1, Profile 1 },
+#ifdef VPX_IMG_FMT_HIGHBITDEPTH
This is not needed (see libvpxenc.c).
There's enough unavoidable ifdeffery already on these files, so better not add
more
for no real gain.
+{ FF_PROFILE_VP9_2, Profile 2 },
+{ FF_PROFILE_VP9_3, Profile 3 },
+#endif
+{ FF_PROFILE_UNKNOWN },
+};
+
AVCodec ff_libvpx_vp9_decoder = {
.name = libvpx-vp9,
.long_name = NULL_IF_CONFIG_SMALL(libvpx VP9),
@@ -222,5 +241,6 @@ AVCodec ff_libvpx_vp9_decoder = {
.decode = vp8_decode,
.capabilities = CODEC_CAP_AUTO_THREADS | CODEC_CAP_DR1,
.init_static_data = ff_vp9_init_static,
+.profiles = NULL_IF_CONFIG_SMALL(profiles),
};
#endif /* CONFIG_LIBVPX_VP9_DECODER */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libvpxdec: report profile for vp9
On Tue, Jun 23, 2015 at 4:18 PM, Ronald S. Bultje rsbul...@gmail.com wrote: Hello, On Tue, Jun 23, 2015 at 6:21 PM, James Zern jz...@google.com wrote: --- libavcodec/libvpxdec.c | 20 1 file changed, 20 insertions(+) lgtm. (This is probably a weird/stupid question, but I wonder if it makes sense, conceptually, to share the profiles array between vp9.c and libvpxdec.c?) (and libvpxenc.c). They're fairly stable so the savings would be at link time if the duplicates weren't already merged. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] libvpxdec: report colorspace
---
libavcodec/libvpxdec.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index b31e7b9..0e3ed6f 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -62,6 +62,13 @@ static av_cold int vpx_init(AVCodecContext *avctx,
// returns 0 on success, AVERROR_INVALIDDATA otherwise
static int set_pix_fmt(AVCodecContext *avctx, struct vpx_image *img)
{
+#if VPX_IMAGE_ABI_VERSION = 3
+static const enum AVColorSpace colorspaces[8] = {
+AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
AVCOL_SPC_SMPTE170M,
+AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
AVCOL_SPC_RGB,
+};
+avctx-colorspace = colorspaces[img-cs];
+#endif
if (avctx-codec_id == AV_CODEC_ID_VP8 img-fmt != VPX_IMG_FMT_I420)
return AVERROR_INVALIDDATA;
switch (img-fmt) {
--
2.2.0.rc0.207.ga3a616c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavf/libssh: read empty path from url as /
On Tue, Jun 23, 2015 at 03:04:20AM +0200, Mariusz Szczepańczyk wrote: --- libavformat/libssh.c | 3 +++ 1 file changed, 3 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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] lavf/libssh: implement directory listing callbacks
On Tue, Jun 23, 2015 at 03:04:19AM +0200, Mariusz Szczepańczyk wrote: From: Lukasz Marek lukasz.m.lu...@gmail.com Signed-off-by: Lukasz Marek lukasz.m.luki2 at gmail.com --- libavformat/libssh.c | 111 --- 1 file changed, 105 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
