Re: [FFmpeg-devel] [PATCH 1/5] avutil/pixelutils: add av_pixelutils_bdiff()
On Fri, Aug 15, 2014 at 7:56 AM, Clément Bœsch wrote:
> On Fri, Aug 15, 2014 at 01:23:59AM +0200, Michael Niedermayer wrote:
>> On Thu, Aug 14, 2014 at 11:05:11PM +0200, Clément Bœsch wrote:
>> > ---
>> > doc/APIchanges | 3 +++
>> > libavutil/pixelutils.c | 21 +
>> > libavutil/pixelutils.h | 23 +++
>> > libavutil/version.h| 2 +-
>> > 4 files changed, 48 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/doc/APIchanges b/doc/APIchanges
>> > index 067f60f..72cfe96 100644
>> > --- a/doc/APIchanges
>> > +++ b/doc/APIchanges
>> > @@ -15,6 +15,9 @@ libavutil: 2014-08-09
>> >
>> > API changes, most recent first:
>> >
>> > +2014-08-xx - xxx - lavu 54.04.100 - pixelutils.h
>> > + Add av_pixelutils_bdiff().
>> > +
>> > 2014-08-xx - xxx - lavu 54.03.0 - mem.h
>> >Add av_strndup().
>> >
>> > diff --git a/libavutil/pixelutils.c b/libavutil/pixelutils.c
>> > index 10ff7e8..473d394 100644
>> > --- a/libavutil/pixelutils.c
>> > +++ b/libavutil/pixelutils.c
>> > @@ -85,6 +85,27 @@ av_pixelutils_sad_fn av_pixelutils_get_sad_fn(int
>> > w_bits, int h_bits, int aligne
>> > #endif
>> > }
>> >
>> > +int64_t av_pixelutils_bdiff(const uint8_t *s1, ptrdiff_t stride1,
>> > +const uint8_t *s2, ptrdiff_t stride2,
>> > +av_pixelutils_sad_fn sadfn,
>> > +int w, int h, int bsize)
>> > +{
>> > +#if !CONFIG_PIXELUTILS
>> > +return -1;
>> > +#else
IMHO external API functions shouldn't really be disableable,
especially in avutil.
Just my 2c.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Small patch for someone to push please
In libavfilter/lavfutils.c around line 77 the code is
if (ret < 0 || !frame_decoded) {
av_log(log_ctx, AV_LOG_ERROR, "Failed to decode image from file\n");
goto end;
}
ret = 0;
Now this causes a problem if ret>=0 and frame_decoded==0 as you get dropped out
of the routine with a failed decode and no width or height.
my changes
if (ret < 0 || !frame_decoded) {
av_log(log_ctx, AV_LOG_ERROR, "Failed to decode image from file\n");
+ ret = !frame_decoded ? -1:ret;
goto end;
}
ret = 0;
Maybe not the correct ret value but at least it stops code which checks for an
error from trying to do more stuff on the returned data, which wont be valid
This was caught becuase my code which has now started failing
static int load_image(uint8_t **image_data, int *w, int *h, int *stride,
const char *filename, void *log_ctx)
{
int ret;
enum AVPixelFormat pix_fmt;
uint8_t *src_data[4], *dst_data[4];
int src_linesize[4], dst_linesize[4];
av_log( NULL, AV_LOG_WARNING, "load_image %s\n", filename);
/* load image from file */
if ((ret = ff_load_image(src_data, src_linesize, w, h, &pix_fmt, filename,
log_ctx)) < 0)
return ret;
if ((ret = ff_scale_image(dst_data, dst_linesize, *w, *h, PIXEL_FORMAT,
src_data, src_linesize, *w, *h, pix_fmt,
log_ctx)) < 0)
goto end;
*stride = dst_linesize[0];
/* copy image_data to a newly allocated array */
*image_data = av_malloc(*stride * *h);
if (!*image_data)
ret = AVERROR(ENOMEM);
av_image_copy_plane(*image_data, *stride, dst_data[0], dst_linesize[0],
*w*4, *h);
end:
av_free(src_data[0]);
av_free(dst_data[0]);
return ret;
}
I dont know why as the pngs are the same, but i get ret=30148 and
decode_frame=0, 30148 is the filesize of the PNG.
output from ffmpeg when running my code is sparse even with '-loglevel debug'
load_image /home/encoder/images/GameNone_640x360.png
[AVIOContext @ 0x7f966802560] Statistics: 30148 bytes read, 0 seeks
Failed to decode image from file 31480 0
Any ideas
joolz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avutil/pixelutils: add av_pixelutils_bdiff()
On Fri, Aug 15, 2014 at 10:30:38AM +0200, Hendrik Leppkes wrote:
> On Fri, Aug 15, 2014 at 7:56 AM, Clément Bœsch wrote:
> > On Fri, Aug 15, 2014 at 01:23:59AM +0200, Michael Niedermayer wrote:
> >> On Thu, Aug 14, 2014 at 11:05:11PM +0200, Clément Bœsch wrote:
> >> > ---
> >> > doc/APIchanges | 3 +++
> >> > libavutil/pixelutils.c | 21 +
> >> > libavutil/pixelutils.h | 23 +++
> >> > libavutil/version.h| 2 +-
> >> > 4 files changed, 48 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/doc/APIchanges b/doc/APIchanges
> >> > index 067f60f..72cfe96 100644
> >> > --- a/doc/APIchanges
> >> > +++ b/doc/APIchanges
> >> > @@ -15,6 +15,9 @@ libavutil: 2014-08-09
> >> >
> >> > API changes, most recent first:
> >> >
> >> > +2014-08-xx - xxx - lavu 54.04.100 - pixelutils.h
> >> > + Add av_pixelutils_bdiff().
> >> > +
> >> > 2014-08-xx - xxx - lavu 54.03.0 - mem.h
> >> >Add av_strndup().
> >> >
> >> > diff --git a/libavutil/pixelutils.c b/libavutil/pixelutils.c
> >> > index 10ff7e8..473d394 100644
> >> > --- a/libavutil/pixelutils.c
> >> > +++ b/libavutil/pixelutils.c
> >> > @@ -85,6 +85,27 @@ av_pixelutils_sad_fn av_pixelutils_get_sad_fn(int
> >> > w_bits, int h_bits, int aligne
> >> > #endif
> >> > }
> >> >
> >> > +int64_t av_pixelutils_bdiff(const uint8_t *s1, ptrdiff_t stride1,
> >> > +const uint8_t *s2, ptrdiff_t stride2,
> >> > +av_pixelutils_sad_fn sadfn,
> >> > +int w, int h, int bsize)
> >> > +{
> >> > +#if !CONFIG_PIXELUTILS
> >> > +return -1;
> >> > +#else
>
> IMHO external API functions shouldn't really be disableable,
> especially in avutil.
>
> Just my 2c.
>
It was a request from Ronald to keep the size small initially.
Anyway, I'll drop this specific patch; the 2 loops can be inlined without
much effort anyway. I'll resend a patchset without it.
--
Clément B.
pgp4kSmHCWN2c.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote: > On 08/14/2014 11:59 PM, The Wanderer wrote: > > On 08/14/2014 11:27 AM, Thomas Goirand wrote: > > > >> On 08/13/2014 07:53 AM, Kieran Kunhya wrote: > > > >> On 08/13/2014 06:30 AM, Michael Niedermayer wrote: > > > >>> Also ive offered my resignation in the past. I do still offer to > >>> resign from the FFmpeg leader position, if it resolves this split > >>> between FFmpeg and Libav and make everyone work together again. > > > >> Why not just take the offer, and move on? > > > > Probably because of the condition he attached to it, which also dates > > back to the arguments preceding the original split: > > > >>> The part i insist on though is that everyone must be able to work > >>> on their code without people uninvolved in that specific parts > >>> maintaince or authorship being able to block their work. > > > > In other words, as I think I understand it from the discussion back > > then: people not involved with a particular area of the code can't NACK > > the work of someone who is working on it, and someone who works on a > > particular area of the code doesn't have to wait on review of people who > > aren't involved with that area of the code. > > > > Since one of the motivations of the people behind the libav side of the > > split seems, IIRC, to have been "no code gets in without having been > > reviewed by someone other than the author", this was apparently deemed > > an unacceptable condition. > > Hum... Well, to me, what's important is that the code gets > peer-reviewed. Yes, the tricky part in FFmpeg and Libav in relation to this is that theres quite a bit of code that is only well understood by a single person even if you would combine both projects together. So if that person posts a patch for review, theres noone who could do a real review > Setting-up something like gerrit may help, as it can be > setup in a way that review becomes mandatory. Then discussing who's > core-reviewer and can approve this or that part of the code can be setup > within gerrit. This should be discussed, and setup based on technical merit. Not commenting about gerrit as i dont have experience with it, but FFmpeg currently uses a simple file in main ffmpeg git that lists which part is maintained by whom, and these developers would in the rare case of a dispute have the final say in each area. OTOH, Libav early deleted their forked version of this file, and iam not aware of any replacement. But others should explain how it works in Libav ... > > Having a NACK review is often disappointing. It goes the wrong way if > there's only a NACK with no comments on how to improve things, so that > the code becomes acceptable. > Absolutely everyone should *always* be able > to leave comments, be it positive or negative. yes, i fully agree and this also was always so in FFmpeg. In that sense everyone is welcome to subscribe to ffmpeg-devel and review and comment patches. That of course includes Libav developers and everyone else. And more reviewers would also certainly help, so yeah anyone reading this and wanting to help review patches, you are welcome! Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- 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] lavd/avfoundation: Add device category.
Thilo Borgmann wrote: Hi, as reported by David Favor, the AVFoundation device is not yet listed by "ffmpeg -devices". This patch fixes that. Please Apply. -Thilo Many thanks for the patch... ffmpeg -devices looks to be working now... David-Favor-iMac> ffmpeg -devices ffmpeg version 2.3.2-2014-08-15-65657-gedd0dc8 Copyright (c) 2000-2014 the FFmpeg developers built on Aug 15 2014 08:16:07 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) configuration: --cc=/usr/bin/clang --prefix=/david-favor-tools/osx-10.9 --mandir=/david-favor-tools/osx-10.9/share/man --enable-gpl --enable-yasm --arch=x86_64 --enable-version3 --enable-pthreads --enable-shared --disable-static --disable-debug --extra-cflags='-I/david-favor-tools/osx-10.9/include -I/opt/local/include -I/usr/local/include -I/usr/include' --extra-ldflags='-Wl,-rpath,/david-favor-tools/osx-10.9/lib -Wl,-rpath,/opt/local/lib -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/lib -L/david-favor-tools/osx-10.9/lib -L/opt/local/lib -L/usr/local/lib -L/usr/lib' --enable-ffplay --enable-ffprobe --enable-ffserver --enable-indev=qtkit --enable-indev=avfoundation --enable-runtime-cpudetect --enable-nonfree --enable-zlib --enable-bzlib --enable-openssl --enable-gnutls --enable-swscale --enable-avfilter --enable-avresample --enable-postproc --enable-vda --enable-libfribidi --enable-libmp3lame --enable-libfaac --enable-libfdk_aac --enable-libvpx --enable-libtheora --enable-libvorbis --enable-libxvid --enable-libopus --enable-libopenjpeg --enable-libschroedinger --enable-libspeex --enable-libbluray --enable-libx264 --enable-libx265 --enable-postproc --enable-frei0r --enable-libopencore-amrnb --enable-fontconfig --enable-libfreetype --enable-libmodplug --enable-libass libavutil 54. 3.100 / 54. 3.100 libavcodec 56. 0.101 / 56. 0.101 libavformat56. 1.100 / 56. 1.100 libavdevice56. 0.100 / 56. 0.100 libavfilter 5. 0.100 / 5. 0.100 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 0.100 / 3. 0.100 libswresample 1. 0.100 / 1. 0.100 libpostproc53. 0.100 / 53. 0.100 Devices: D. = Demuxing supported .E = Muxing supported -- D avfoundationAVFoundation input device D lavfi Libavfilter virtual input device D qtkit QTKit input device E sdl SDL output device E xv XV (XVideo) output device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] 0001-Fix-packet_buffer-memory-leak-in-avformat_free_conte.patch
Hello, Attached path fixes potential memory leak in output format context when av_interleaved_write_frame() is used. This function can use AVFormatContext.packet_buffer for packet ordering, but this buffer is not feed later in avformat_free_context(). The Valgrind utiluty clearly shows this leak. Note polease that when closing input context with avformat_close_input(AVFormatContext **ps) , the packet_buffer is correctly freed by flush_packet_queue(s) -> free_packet_buffer(&s->packet_buffer, &s->packet_buffer_end). But free_packet_buffer() is declared as static in utils.c and can not be called directly from application code. So, I propose to add this call into avformat_free_context() to avoid memory leaks on output. Regards, Andrey Myznikov >From 9d83000821da8bbe1d0114c61f2dc703ea65 Mon Sep 17 00:00:00 2001 From: Andrey Myznikov Date: Fri, 15 Aug 2014 17:25:15 +0300 Subject: [PATCH] Fix packet_buffer memory leak in avformat_free_context --- libavformat/utils.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/utils.c b/libavformat/utils.c index 5d146d6..34eca17 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -3525,6 +3525,7 @@ void avformat_free_context(AVFormatContext *s) av_dict_free(&s->metadata); av_freep(&s->streams); av_freep(&s->internal); +free_packet_buffer(&s->packet_buffer, &s->packet_buffer_end); av_free(s); } -- 2.0.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/15/2014 11:23 AM, Thomas Goirand wrote: > On 08/15/2014 08:20 PM, Michael Niedermayer wrote: >>> Absolutely everyone should *always* be able to leave comments, be >>> it positive or negative. >> >> yes, i fully agree and this also was always so in FFmpeg. In that >> sense everyone is welcome to subscribe to ffmpeg-devel and review >> and comment patches. That of course includes Libav developers and >> everyone else. And more reviewers would also certainly help, so >> yeah anyone reading this and wanting to help review patches, you >> are welcome! > > Well, using a mailing list to review patches is something we were > doing 10 years ago. It's also something the Linux kernel is still doing, with apparent success. I for one consider it to be a much more public, transparent, and discoverable way to let proposed patches and the review of same be open to public view, compared to the way various other projects seem to do it. Making sure everything passes through the mailing list, and most if not all substantive discussion happens on the mailing list, is a lot better than having some discussion on the mailing lists and some on a bug tracker and some on IRC and some via private mail and so on. (The most ridiculously extreme example of this fragmentation that I know of is probably the Mozilla project.) There's nothing wrong with having discussion in those various areas, of course; it's probably inevitable, and it's even a good thing. It's just that it's a lot harder for someone not intimately involved with the project to follow discussion if it happens in such a variety of places, and there's value to be found in making sure that everything passes through one central (discussion-enabled) point before landing. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJT7izqAAoJEASpNY00KDJr8PwP+gNPrmz3G1SDFBP0WPW7WEn/ BBFAFkWXEkezThYnjqYfHxUjwHBZOOpLfykfhlx7uV5O+nqy5BDDMHLzBxVEvaKp 5On9SaRB6/DYzAf9HvSJm+teHqRtNP0xKrcjRI+AgQ9n3Meax3OWi7jiNSIijAlX srvhfjqgRAdNIB+dAnv8uhWhsAbN0njAPqegolFunAG8ZlWA4kcA5zt5uVaQrWPZ y8LqZ/bB7xYbqTAO+kENhNoMzItqANUKZNhJKW/Fk6Dln/kIKWYE5Uiiil2BOHc7 KNyPxvrfjAj/LYdazgknu2tcAlgHbPBbbjjqYFivkc2sG+9s1t5QkEdkdJw7w3v8 OQpUwwF3gRGHebp1ODtyCuVC8jsmtBAwM+s0H5aqF0Tp6NyjgYFxtYrfHvvnvXmX 1lew8VW6WogIlJ1wDXCS8057gR877wMa8r61d6XbdHXcnARxoFYI1ngUUsKYjXyU YJkRgxTZTtUZ9QNfex8sdja1PiIw96m4XLeW1uTozRR0EcQRBarphBCscQhmp0Sm pdopwrFYMnZtNOE2nEqbwQtkNm1AXmABG18GbhcPX7LqEXsys6Odn8o1zqJYpx2h 7aQzpXbhjHUwihelR5yV6dASRt1LBD3icCR0uoWaAb80b0Li9cdV07FLon20XExS mwURtzhiqxowV931+Bvh =Jxa+ -END PGP SIGNATURE- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Patching Libavformat RTP networking stack for packet-loss concealment
I’m working on patching libavformat in the RTP networking stack in order to be able to: a) get info on package loss and RTP Header Info b) optimize and reduce package loss and error concealment Some issues that have been mentioned by community members include: - whether to use RTP but specify it use TCP for acknowledges and retransmission; - since RTP uses numbering of packets, trying to implement a workaround/concurrent connection for requesting and receiving of lost packets using TCP; - potential complications with dealing with buffering with vbr; - how to best deal with latency while waiting for retransmitted packets (RFC 4588) If any community members are familiar with this and available to offer guidance, I'd greatly appreciate your help and am also willing to sponsor development of patch to libavformat. Thanks - SanJose_Kid ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] 0001-Fix-packet_buffer-memory-leak-in-avformat_free_conte.patch
On Fri, Aug 15, 2014 at 05:46:37PM +0300, Andrey Myznikov wrote: > Hello, > > Attached path fixes potential memory leak in output format > context when av_interleaved_write_frame() is used. > This function can use AVFormatContext.packet_buffer for packet > ordering, but this buffer is not feed later in > avformat_free_context(). > The Valgrind utiluty clearly shows this leak. > > Note polease that when closing input context with > avformat_close_input(AVFormatContext **ps) , the packet_buffer is > correctly freed by flush_packet_queue(s) -> > free_packet_buffer(&s->packet_buffer, &s->packet_buffer_end). But > free_packet_buffer() is declared as static in utils.c and can not be > called directly from application code. > > So, I propose to add this call into avformat_free_context() to avoid > memory leaks on output. > > Regards, > Andrey Myznikov > > > > > > > > > > > > utils.c |1 + > 1 file changed, 1 insertion(+) > 9260264a92287931471e7c1c1c21473ee2cc04bd > 0001-Fix-packet_buffer-memory-leak-in-avformat_free_conte.patch > From 9d83000821da8bbe1d0114c61f2dc703ea65 Mon Sep 17 00:00:00 2001 > From: Andrey Myznikov > Date: Fri, 15 Aug 2014 17:25:15 +0300 > Subject: [PATCH] Fix packet_buffer memory leak in avformat_free_context applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: look for encoding options in both avcodec and avformat
This patch is the same as 8a1714ad85dd5defdf1fb2baba9ababebfa47d01 but
applied to encoding. It fixes the current clash of the -password option
between tta decoder and the icecast protocol.
---
ffmpeg_opt.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 3cf78f0..593c4f0 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -2014,8 +2014,13 @@ loop_end:
const AVClass *class = avcodec_get_class();
const AVOption *option = av_opt_find(&class, e->key, NULL, 0,
AV_OPT_SEARCH_CHILDREN |
AV_OPT_SEARCH_FAKE_OBJ);
-if (!option)
+const AVClass *fclass = avformat_get_class();
+const AVOption *foption = av_opt_find(&fclass, e->key, NULL, 0,
+ AV_OPT_SEARCH_CHILDREN |
AV_OPT_SEARCH_FAKE_OBJ);
+if (!option || foption)
continue;
+
+
if (!(option->flags & AV_OPT_FLAG_ENCODING_PARAM)) {
av_log(NULL, AV_LOG_ERROR, "Codec AVOption %s (%s) specified for "
"output file #%d (%s) is not an encoding option.\n", e->key,
--
2.0.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Drop remaining unneeded != NULL
Signed-off-by: Michael Niedermayer
---
cmdutils.c |2 +-
ffmpeg.c |2 +-
ffplay.c |2 +-
ffserver.c | 42 ++--
libavcodec/libx264.c |2 +-
libavcodec/mpegaudiodec_template.c |2 +-
libavcodec/parser.c|2 +-
libavfilter/af_amix.c |4 ++--
libavfilter/libmpcodecs/vf_eq2.c |6 +++---
libavformat/lrcenc.c |6 +++---
libavformat/matroskadec.c |2 +-
libavformat/mov.c |2 +-
libavformat/rtpdec_h264.c |2 +-
libavformat/sctp.c |2 +-
libavformat/webmdashenc.c |2 +-
libpostproc/postprocess.c | 12 +--
16 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/cmdutils.c b/cmdutils.c
index 5344498..a71c7db 100644
--- a/cmdutils.c
+++ b/cmdutils.c
@@ -166,7 +166,7 @@ void show_help_options(const OptionDef *options, const char
*msg, int req_flags,
int first;
first = 1;
-for (po = options; po->name != NULL; po++) {
+for (po = options; po->name; po++) {
char buf[64];
if (((po->flags & req_flags) != req_flags) ||
diff --git a/ffmpeg.c b/ffmpeg.c
index 2582fbf..fa907b4 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2071,7 +2071,7 @@ static int process_input_packet(InputStream *ist, const
AVPacket *pkt)
if (!ist->saw_first_ts) {
ist->dts = ist->st->avg_frame_rate.num ? - ist->dec_ctx->has_b_frames
* AV_TIME_BASE / av_q2d(ist->st->avg_frame_rate) : 0;
ist->pts = 0;
-if (pkt != NULL && pkt->pts != AV_NOPTS_VALUE &&
!ist->decoding_needed) {
+if (pkt && pkt->pts != AV_NOPTS_VALUE && !ist->decoding_needed) {
ist->dts += av_rescale_q(pkt->pts, ist->st->time_base,
AV_TIME_BASE_Q);
ist->pts = ist->dts; //unused but better to set it to a value
thats not totally wrong
}
diff --git a/ffplay.c b/ffplay.c
index 6a16607..1af4764 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -441,7 +441,7 @@ static void packet_queue_flush(PacketQueue *q)
MyAVPacketList *pkt, *pkt1;
SDL_LockMutex(q->mutex);
-for (pkt = q->first_pkt; pkt != NULL; pkt = pkt1) {
+for (pkt = q->first_pkt; pkt; pkt = pkt1) {
pkt1 = pkt->next;
av_free_packet(&pkt->pkt);
av_freep(&pkt);
diff --git a/ffserver.c b/ffserver.c
index e2e0f68..1368d60 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -592,7 +592,7 @@ static void start_multicast(void)
int default_port, stream_index;
default_port = 6000;
-for(stream = first_stream; stream != NULL; stream = stream->next) {
+for(stream = first_stream; stream; stream = stream->next) {
if (stream->is_multicast) {
unsigned random0 = av_lfg_get(&random_state);
unsigned random1 = av_lfg_get(&random_state);
@@ -696,7 +696,7 @@ static int http_server(void)
/* wait for events on each HTTP handle */
c = first_http_ctx;
delay = 1000;
-while (c != NULL) {
+while (c) {
int fd;
fd = c->fd;
switch(c->state) {
@@ -763,7 +763,7 @@ static int http_server(void)
}
/* now handle the events */
-for(c = first_http_ctx; c != NULL; c = c_next) {
+for(c = first_http_ctx; c; c = c_next) {
c_next = c->next;
if (handle_connection(c) < 0) {
log_connection(c);
@@ -881,7 +881,7 @@ static void close_connection(HTTPContext *c)
/* remove connection from list */
cp = &first_http_ctx;
-while ((*cp) != NULL) {
+while ((*cp)) {
c1 = *cp;
if (c1 == c)
*cp = c->next;
@@ -890,7 +890,7 @@ static void close_connection(HTTPContext *c)
}
/* remove references, if any (XXX: do it faster) */
-for(c1 = first_http_ctx; c1 != NULL; c1 = c1->next) {
+for(c1 = first_http_ctx; c1; c1 = c1->next) {
if (c1->rtsp_c == c)
c1->rtsp_c = NULL;
}
@@ -1486,7 +1486,7 @@ static void compute_real_filename(char *filename, int
max_size)
p = strrchr(file1, '.');
if (p)
*p = '\0';
-for(stream = first_stream; stream != NULL; stream = stream->next) {
+for(stream = first_stream; stream; stream = stream->next) {
av_strlcpy(file2, stream->filename, sizeof(file2));
p = strrchr(file2, '.');
if (p)
@@ -1595,7 +1595,7 @@ static int http_parse_request(HTTPContext *c)
av_strlcpy(filename, "index.html", sizeof(filename) - 1);
stream = first_stream;
-while (stream != NULL) {
+while (stream) {
if (!strcmp(stream->filename, filename) && validate_acl(stream, c))
break;
stream = stream->next;
@@ -1974,7 +1974,7 @@ static void compute_status(HTTPContext *c)
avio_printf(pb, "\n");
avio_printf(pb, "PathServedConnsbytesForm
Re: [FFmpeg-devel] [PATCH] Drop remaining unneeded != NULL
On Fri, Aug 15, 2014 at 09:47:12PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> cmdutils.c |2 +-
> ffmpeg.c |2 +-
> ffplay.c |2 +-
> ffserver.c | 42
> ++--
> libavcodec/libx264.c |2 +-
> libavcodec/mpegaudiodec_template.c |2 +-
> libavcodec/parser.c|2 +-
> libavfilter/af_amix.c |4 ++--
> libavfilter/libmpcodecs/vf_eq2.c |6 +++---
> libavformat/lrcenc.c |6 +++---
> libavformat/matroskadec.c |2 +-
> libavformat/mov.c |2 +-
> libavformat/rtpdec_h264.c |2 +-
> libavformat/sctp.c |2 +-
> libavformat/webmdashenc.c |2 +-
> libpostproc/postprocess.c | 12 +--
> 16 files changed, 46 insertions(+), 46 deletions(-)
>
sure whatever...
did you use coccinelle?
[...]
> /* remove connection from list */
> cp = &first_http_ctx;
> -while ((*cp) != NULL) {
> +while ((*cp)) {
you can drop the () here
[...]
--
Clément B.
pgp751JCLQCvj.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: look for encoding options in both avcodec and avformat
On Fri, Aug 15, 2014 at 09:14:26PM +0200, Clément Bœsch wrote: > This patch is the same as 8a1714ad85dd5defdf1fb2baba9ababebfa47d01 but > applied to encoding. It fixes the current clash of the -password option > between tta decoder and the icecast protocol. > --- > ffmpeg_opt.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Drop remaining unneeded != NULL
On Fri, Aug 15, 2014 at 10:06:28PM +0200, Clément Bœsch wrote:
> On Fri, Aug 15, 2014 at 09:47:12PM +0200, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > cmdutils.c |2 +-
> > ffmpeg.c |2 +-
> > ffplay.c |2 +-
> > ffserver.c | 42
> > ++--
> > libavcodec/libx264.c |2 +-
> > libavcodec/mpegaudiodec_template.c |2 +-
> > libavcodec/parser.c|2 +-
> > libavfilter/af_amix.c |4 ++--
> > libavfilter/libmpcodecs/vf_eq2.c |6 +++---
> > libavformat/lrcenc.c |6 +++---
> > libavformat/matroskadec.c |2 +-
> > libavformat/mov.c |2 +-
> > libavformat/rtpdec_h264.c |2 +-
> > libavformat/sctp.c |2 +-
> > libavformat/webmdashenc.c |2 +-
> > libpostproc/postprocess.c | 12 +--
> > 16 files changed, 46 insertions(+), 46 deletions(-)
> >
>
> sure whatever...
>
> did you use coccinelle?
nope, just sed and bash
>
> [...]
> > /* remove connection from list */
> > cp = &first_http_ctx;
> > -while ((*cp) != NULL) {
> > +while ((*cp)) {
>
> you can drop the () here
ok, will do and push in a moment
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: look for encoding options in both avcodec and avformat
On Fri, Aug 15, 2014 at 10:15:48PM +0200, Michael Niedermayer wrote: > On Fri, Aug 15, 2014 at 09:14:26PM +0200, Clément Bœsch wrote: > > This patch is the same as 8a1714ad85dd5defdf1fb2baba9ababebfa47d01 but > > applied to encoding. It fixes the current clash of the -password option > > between tta decoder and the icecast protocol. > > --- > > ffmpeg_opt.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > LGTM > Applied. On a side note, we probably want to factorize that code and make a cleaner check. -- Clément B. pgpk5rYpIAqTd.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/7] avcodec/dvdsubdec: Dont mix integers with pointers
Signed-off-by: Michael Niedermayer
---
libavcodec/dvdsubdec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index e198a6c..7355c03 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -213,7 +213,7 @@ static int decode_dvd_subtitles(DVDSubContext *ctx,
AVSubtitle *sub_header,
{
int cmd_pos, pos, cmd, x1, y1, x2, y2, offset1, offset2, next_cmd_pos;
int big_offsets, offset_size, is_8bit = 0;
-const uint8_t *yuv_palette = 0;
+const uint8_t *yuv_palette = NULL;
uint8_t *colormap = ctx->colormap, *alpha = ctx->alpha;
int date;
int i;
@@ -362,7 +362,7 @@ static int decode_dvd_subtitles(DVDSubContext *ctx,
AVSubtitle *sub_header,
buf, offset2, buf_size, is_8bit);
sub_header->rects[0]->pict.data[1] =
av_mallocz(AVPALETTE_SIZE);
if (is_8bit) {
-if (yuv_palette == 0)
+if (!yuv_palette)
goto fail;
sub_header->rects[0]->nb_colors = 256;
yuv_a_to_rgba(yuv_palette, alpha,
(uint32_t*)sub_header->rects[0]->pict.data[1], 256);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/7] avformat/udp: dont mix integers with pointers
Signed-off-by: Michael Niedermayer
---
libavformat/udp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index a8baa5b..8412eeb 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -313,7 +313,7 @@ static int udp_set_url(struct sockaddr_storage *addr,
int addr_len;
res0 = udp_resolve_host(hostname, port, SOCK_DGRAM, AF_UNSPEC, 0);
-if (res0 == 0) return AVERROR(EIO);
+if (!res0) return AVERROR(EIO);
memcpy(addr, res0->ai_addr, res0->ai_addrlen);
addr_len = res0->ai_addrlen;
freeaddrinfo(res0);
@@ -332,7 +332,7 @@ static int udp_socket_create(UDPContext *s, struct
sockaddr_storage *addr,
family = ((struct sockaddr *) &s->dest_addr)->sa_family;
res0 = udp_resolve_host(localaddr[0] ? localaddr : NULL, s->local_port,
SOCK_DGRAM, family, AI_PASSIVE);
-if (res0 == 0)
+if (!res0)
goto fail;
for (res = res0; res; res=res->ai_next) {
udp_fd = ff_socket(res->ai_family, SOCK_DGRAM, 0);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/7] avformat/thp: dont mix integers with pointers
Signed-off-by: Michael Niedermayer
---
libavformat/thp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/thp.c b/libavformat/thp.c
index bc4f0daf..714cec6 100644
--- a/libavformat/thp.c
+++ b/libavformat/thp.c
@@ -98,7 +98,7 @@ static int thp_read_header(AVFormatContext *s)
for (i = 0; i < thp->compcount; i++) {
if (thp->components[i] == 0) {
-if (thp->vst != 0)
+if (thp->vst)
break;
/* Video component. */
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/7] doc/examples: remove unneeded NULL checks
Signed-off-by: Michael Niedermayer --- doc/examples/resampling_audio.c |3 +-- doc/examples/scaling_video.c|3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/examples/resampling_audio.c b/doc/examples/resampling_audio.c index 8a43b09..f35e7e1 100644 --- a/doc/examples/resampling_audio.c +++ b/doc/examples/resampling_audio.c @@ -199,8 +199,7 @@ int main(int argc, char **argv) fmt, dst_ch_layout, dst_nb_channels, dst_rate, dst_filename); end: -if (dst_file) -fclose(dst_file); +fclose(dst_file); if (src_data) av_freep(&src_data[0]); diff --git a/doc/examples/scaling_video.c b/doc/examples/scaling_video.c index fcb98b7..587f3ab 100644 --- a/doc/examples/scaling_video.c +++ b/doc/examples/scaling_video.c @@ -132,8 +132,7 @@ int main(int argc, char **argv) av_get_pix_fmt_name(dst_pix_fmt), dst_w, dst_h, dst_filename); end: -if (dst_file) -fclose(dst_file); +fclose(dst_file); av_freep(&src_data[0]); av_freep(&dst_data[0]); sws_freeContext(sws_ctx); -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/7] avcodec/dvbsubdec: dont mix integers with pointers
Signed-off-by: Michael Niedermayer
---
libavcodec/dvbsubdec.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
index a40da76..4cf5b02 100644
--- a/libavcodec/dvbsubdec.c
+++ b/libavcodec/dvbsubdec.c
@@ -888,7 +888,7 @@ static void dvbsub_parse_pixel_data_block(AVCodecContext
*avctx, DVBSubObjectDis
av_dlog(avctx, "\n");
#endif
-if (region == 0)
+if (!region)
return;
pbuf = region->pbuf;
@@ -1383,7 +1383,7 @@ static void save_display_set(DVBSubContext *ctx)
clut = get_clut(ctx, region->clut);
-if (clut == 0)
+if (!clut)
clut = &default_clut;
switch (region->depth) {
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/7] avcodec/hevc_mvs: dont redundantly initialize ref_idx_curr
Signed-off-by: Michael Niedermayer
---
libavcodec/hevc_mvs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index fffae88..3bc982b 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -607,7 +607,7 @@ void ff_hevc_luma_mv_mvp_mode(HEVCContext *s, int x0, int
y0, int nPbW,
Mv mvpcand_list[2] = { { 0 } };
Mv mxA;
Mv mxB;
-int ref_idx_curr = 0;
+int ref_idx_curr;
int ref_idx = 0;
int pred_flag_index_l0;
int pred_flag_index_l1;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 7/7] avcodec/mips/compute_antialias_float: remove unused variable
Signed-off-by: Michael Niedermayer
---
libavcodec/mips/compute_antialias_float.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/mips/compute_antialias_float.h
b/libavcodec/mips/compute_antialias_float.h
index 0f6f03f..e84abda 100644
--- a/libavcodec/mips/compute_antialias_float.h
+++ b/libavcodec/mips/compute_antialias_float.h
@@ -61,7 +61,6 @@ static void compute_antialias_mips_float(MPADecodeContext *s,
{
float *ptr, *ptr_end;
float *csa = &csa_table[0][0];
-int n;
/* temporary variables */
float in1, in2, in3, in4, in5, in6, in7, in8;
float out1, out2, out3, out4;
@@ -72,10 +71,8 @@ static void compute_antialias_mips_float(MPADecodeContext *s,
if (!g->switch_point)
return;
/* XXX: check this for 8000Hz case */
-n = 1;
ptr_end = ptr + 18;
} else {
-n = 31;
ptr_end = ptr + 558;
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/13/2014 07:53 AM, Kieran Kunhya wrote: > Whatever, people can work on their own code happily but the rest of > the world (cf this thread) has to deal with this annoying FFmpeg/libav > madness. Right! Not only a core of a few upstream authors are affected, but also downstream distributions (where we have to deal with numerous build issues), and final users (who may loose the possibility to use some nice software...). If you guys could find a solution to try to work together again, and merge back both projects, that'd be best for everyone. On 08/13/2014 06:30 AM, Michael Niedermayer wrote: > Also ive offered my resignation in the past. > I do still offer to resign from the FFmpeg leader position, if it > resolves this split between FFmpeg and Libav and make everyone work > together again. Why not just take the offer, and move on? Thomas Goirand (zigo) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
2014-08-14 13:58 GMT+02:00 Stefano Sabatini : > On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded: >> On Wed, 13 Aug 2014 00:30:05 +0200 >> Michael Niedermayer wrote: >> >> > I never understood why people who once where friends >> > became mutually so hostile >> >> You should know that better than anyone else! >> >> You still claim to be my friend, yet you said and did things >> that i have not seen from my enemies, let alone from my friends. >> To this day, after 3 years, i still get accused by random people >> of thing i supposedly have done against FFmpeg and the spirit >> of open source. After 3 years i still have to defend myself against >> these baseless attacks! >> >> If you trully want to mend ways, then you and your fellow FFmpeg >> developers should stop this constant spreading of lies, this >> defamation campaing against libav and its developers that has >> been going on for the last 3 and a half years and show at least >> the minimum respect you would show to a stranger you meet on the >> street. Until you do this, i see very little chance for a healthy >> cooperation. > > Please refrain from claiming other people are spreading lies, > especially with no specific references (and this is not the place > where to discuss such things). > > As for me, I don't consider Libav developers neither friends nor > enemies. We reached a point when we got two different projects with > different policies, culture, and guidelines. Then you should be aware > that the way the Libav fork was created was hostile towards FFmpeg, so > you shouldn't be surprised that there was (and still there is) a > perceived hostility between the two projects. If you or other Libav or > FFmpeg developers want the two projects to collaborate more, this can > be discussed, possibly with *specific* proposals, but again, > debian-devel is not the right place where to discuss such things. I have no problem with FFmpeg and Libav developers discussing collaboration on debian-devel especially if they finally sit together and find a way in which they could join efforts after years of working in separation. This would be Legen... ...dary. :-) Cheers, Balint ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/14/2014 11:59 PM, The Wanderer wrote: > On 08/14/2014 11:27 AM, Thomas Goirand wrote: > >> On 08/13/2014 07:53 AM, Kieran Kunhya wrote: > >> On 08/13/2014 06:30 AM, Michael Niedermayer wrote: > >>> Also ive offered my resignation in the past. I do still offer to >>> resign from the FFmpeg leader position, if it resolves this split >>> between FFmpeg and Libav and make everyone work together again. > >> Why not just take the offer, and move on? > > Probably because of the condition he attached to it, which also dates > back to the arguments preceding the original split: > >>> The part i insist on though is that everyone must be able to work >>> on their code without people uninvolved in that specific parts >>> maintaince or authorship being able to block their work. > > In other words, as I think I understand it from the discussion back > then: people not involved with a particular area of the code can't NACK > the work of someone who is working on it, and someone who works on a > particular area of the code doesn't have to wait on review of people who > aren't involved with that area of the code. > > Since one of the motivations of the people behind the libav side of the > split seems, IIRC, to have been "no code gets in without having been > reviewed by someone other than the author", this was apparently deemed > an unacceptable condition. Hum... Well, to me, what's important is that the code gets peer-reviewed. Setting-up something like gerrit may help, as it can be setup in a way that review becomes mandatory. Then discussing who's core-reviewer and can approve this or that part of the code can be setup within gerrit. This should be discussed, and setup based on technical merit. Having a NACK review is often disappointing. It goes the wrong way if there's only a NACK with no comments on how to improve things, so that the code becomes acceptable. Absolutely everyone should *always* be able to leave comments, be it positive or negative. With Gerrit, it's possible to comment directly in the patch, which helps going in the right direction. Of course, a technical solution will not solve all social issues, but it may improve the workflow and process, and avoid frictions. I hope this helps, Cheers, Thomas Goirand (zigo) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 15, 2014 at 2:53 PM, Thomas Goirand wrote: > Hum... Well, to me, what's important is that the code gets > peer-reviewed. ... by both humans and by automatically by computers; compiler warnings, static analysis tools, fuzz testers etc. -- bye, pabs https://wiki.debian.org/PaulWise ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/15/2014 08:20 PM, Michael Niedermayer wrote: > Yes, the tricky part in FFmpeg and Libav in relation to this is that > theres quite a bit of code that is only well understood by a single > person even if you would combine both projects together. Hum... Hang on here then! Does this mean that, in FFmpeg and/or Libav, there's some parts of the code which are understood by no-one? Scary! > So if that person posts a patch for review, theres noone who could > do a real review Then the person who posts the patch can leave it for review for a while (you should define a policy so that "for a while" means something: for example 2 or 3 weeks), and then if there's no negative review, he can self-approve his patch. >> Absolutely everyone should *always* be able >> to leave comments, be it positive or negative. > > yes, i fully agree and this also was always so in FFmpeg. In that > sense everyone is welcome to subscribe to ffmpeg-devel and review and > comment patches. That of course includes Libav developers and everyone > else. And more reviewers would also certainly help, so yeah anyone > reading this and wanting to help review patches, you are welcome! Well, using a mailing list to review patches is something we were doing 10 years ago. You should really consider using Gerrit (or something equivalent, but I don't know anything that works the way Gerrit does). The workflow will influence a lot the way contributors interact with each other. Almost certainly in a *good* way. Cheers, Thomas Goirand (zigo) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] doc/examples: remove unneeded NULL checks
On Sat, 16 Aug 2014 01:15:42 +0200 Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > doc/examples/resampling_audio.c |3 +-- > doc/examples/scaling_video.c|3 +-- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/doc/examples/resampling_audio.c b/doc/examples/resampling_audio.c > index 8a43b09..f35e7e1 100644 > --- a/doc/examples/resampling_audio.c > +++ b/doc/examples/resampling_audio.c > @@ -199,8 +199,7 @@ int main(int argc, char **argv) > fmt, dst_ch_layout, dst_nb_channels, dst_rate, dst_filename); > > end: > -if (dst_file) > -fclose(dst_file); > +fclose(dst_file); If dst_file can be NULL, then I don't think this is safe. > if (src_data) > av_freep(&src_data[0]); > diff --git a/doc/examples/scaling_video.c b/doc/examples/scaling_video.c > index fcb98b7..587f3ab 100644 > --- a/doc/examples/scaling_video.c > +++ b/doc/examples/scaling_video.c > @@ -132,8 +132,7 @@ int main(int argc, char **argv) > av_get_pix_fmt_name(dst_pix_fmt), dst_w, dst_h, dst_filename); > > end: > -if (dst_file) > -fclose(dst_file); > +fclose(dst_file); > av_freep(&src_data[0]); > av_freep(&dst_data[0]); > sws_freeContext(sws_ctx); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, 2014-08-15 14:20 GMT+02:00 Michael Niedermayer : > On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote: >> On 08/14/2014 11:59 PM, The Wanderer wrote: >> > On 08/14/2014 11:27 AM, Thomas Goirand wrote: >> > >> >> On 08/13/2014 07:53 AM, Kieran Kunhya wrote: >> > >> >> On 08/13/2014 06:30 AM, Michael Niedermayer wrote: >> > >> >>> Also ive offered my resignation in the past. I do still offer to >> >>> resign from the FFmpeg leader position, if it resolves this split >> >>> between FFmpeg and Libav and make everyone work together again. >> > >> >> Why not just take the offer, and move on? >> > >> > Probably because of the condition he attached to it, which also dates >> > back to the arguments preceding the original split: >> > >> >>> The part i insist on though is that everyone must be able to work >> >>> on their code without people uninvolved in that specific parts >> >>> maintaince or authorship being able to block their work. >> > >> > In other words, as I think I understand it from the discussion back >> > then: people not involved with a particular area of the code can't NACK >> > the work of someone who is working on it, and someone who works on a >> > particular area of the code doesn't have to wait on review of people who >> > aren't involved with that area of the code. >> > >> > Since one of the motivations of the people behind the libav side of the >> > split seems, IIRC, to have been "no code gets in without having been >> > reviewed by someone other than the author", this was apparently deemed >> > an unacceptable condition. >> >> Hum... Well, to me, what's important is that the code gets >> peer-reviewed. > > Yes, the tricky part in FFmpeg and Libav in relation to this is that > theres quite a bit of code that is only well understood by a single > person even if you would combine both projects together. > So if that person posts a patch for review, theres noone who could > do a real review This situation is not totally unique to FFmpeg/Libav. IMO in this real-life situation peers can do a best-effort review and people doing so would sooner or later will get familiar with those parts of the code as well. In case of a widely used library like this the biggest issue is breaking the ABI or modifying the ABI in a way which does not align with the team's vision about the ABI roadmap. That type of change can be pointed out by less experienced developers, too. Internal regressions in the code can be easily fixed even if they are not discovered during testing and enter the release. > > >> Setting-up something like gerrit may help, as it can be >> setup in a way that review becomes mandatory. Then discussing who's >> core-reviewer and can approve this or that part of the code can be setup >> within gerrit. This should be discussed, and setup based on technical merit. > > Not commenting about gerrit as i dont have experience with it, but > FFmpeg currently uses a simple file in main ffmpeg git that lists > which part is maintained by whom, and these developers would in the > rare case of a dispute have the final say in each area. Using Gerrit and "file ownersip" are not mutually exclusive. Gerrit can be configured to automatically invite the right people for review based on the changed path. We recently migrated to Gerrit at the Wireshark project and it helps a lot in coordinating the reviews. Cheers, Balint > > OTOH, Libav early deleted their forked version of this file, and > iam not aware of any replacement. But others should explain how it > works in Libav ... > > >> >> Having a NACK review is often disappointing. It goes the wrong way if >> there's only a NACK with no comments on how to improve things, so that >> the code becomes acceptable. > >> Absolutely everyone should *always* be able >> to leave comments, be it positive or negative. > > yes, i fully agree and this also was always so in FFmpeg. In that > sense everyone is welcome to subscribe to ffmpeg-devel and review and > comment patches. That of course includes Libav developers and everyone > else. And more reviewers would also certainly help, so yeah anyone > reading this and wanting to help review patches, you are welcome! > > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > it is not once nor twice but times without number that the same ideas make > their appearance in the world. -- Aristotle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Small patch for someone to push please
On Fri, Aug 15, 2014 at 11:26:40AM +0100, JULIAN GARDNER wrote:
> In libavfilter/lavfutils.c around line 77 the code is
>
> if (ret < 0 || !frame_decoded) {
> av_log(log_ctx, AV_LOG_ERROR, "Failed to decode image from file\n");
> goto end;
> }
> ret = 0;
>
> Now this causes a problem if ret>=0 and frame_decoded==0 as you get dropped
> out of the routine with a failed decode and no width or height.
>
> my changes
>
> if (ret < 0 || !frame_decoded) {
> av_log(log_ctx, AV_LOG_ERROR, "Failed to decode image from file\n");
> + ret = !frame_decoded ? -1:ret;
> goto end;
> }
> ret = 0;
>
applied similar solution
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] doc/examples: remove unneeded NULL checks
On Sat, Aug 16, 2014 at 01:30:44AM +0200, wm4 wrote: > On Sat, 16 Aug 2014 01:15:42 +0200 > Michael Niedermayer wrote: > > > Signed-off-by: Michael Niedermayer > > --- > > doc/examples/resampling_audio.c |3 +-- > > doc/examples/scaling_video.c|3 +-- > > 2 files changed, 2 insertions(+), 4 deletions(-) > > > > diff --git a/doc/examples/resampling_audio.c > > b/doc/examples/resampling_audio.c > > index 8a43b09..f35e7e1 100644 > > --- a/doc/examples/resampling_audio.c > > +++ b/doc/examples/resampling_audio.c > > @@ -199,8 +199,7 @@ int main(int argc, char **argv) > > fmt, dst_ch_layout, dst_nb_channels, dst_rate, dst_filename); > > > > end: > > -if (dst_file) > > -fclose(dst_file); > > +fclose(dst_file); > > If dst_file can be NULL, then I don't think this is safe. how can dst_file be NULL ? but if preferred, iam happy to leave it as it is, one could argue it to be more rubust against future changes [...] -- 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 1/7] doc/examples: remove unneeded NULL checks
On Sat, 16 Aug 2014 01:44:59 +0200 Michael Niedermayer wrote: > On Sat, Aug 16, 2014 at 01:30:44AM +0200, wm4 wrote: > > On Sat, 16 Aug 2014 01:15:42 +0200 > > Michael Niedermayer wrote: > > > > > Signed-off-by: Michael Niedermayer > > > --- > > > doc/examples/resampling_audio.c |3 +-- > > > doc/examples/scaling_video.c|3 +-- > > > 2 files changed, 2 insertions(+), 4 deletions(-) > > > > > > diff --git a/doc/examples/resampling_audio.c > > > b/doc/examples/resampling_audio.c > > > index 8a43b09..f35e7e1 100644 > > > --- a/doc/examples/resampling_audio.c > > > +++ b/doc/examples/resampling_audio.c > > > @@ -199,8 +199,7 @@ int main(int argc, char **argv) > > > fmt, dst_ch_layout, dst_nb_channels, dst_rate, dst_filename); > > > > > > end: > > > -if (dst_file) > > > -fclose(dst_file); > > > +fclose(dst_file); > > > > If dst_file can be NULL, then I don't think this is safe. > > how can dst_file be NULL ? > but if preferred, iam happy to leave it as it is, one could argue > it to be more rubust against future changes Oh, sorry, it wasn't clear from the context. Nevermind. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Invitation to VDD and registration
On Wed, Aug 13, 2014 at 06:42:39PM +0200, Stefano Sabatini wrote: > On date Sunday 2014-07-20 18:16:52 +0200, Jean-Baptiste Kempf encoded: > > My dear friends of the FFmpeg community, > > > > I'd like to invite you to the VideoLAN Dev Days 2014, the 3rd week-end > > of September, in Dublin, Ireland. Google is providing the hosting. > > > > This technical conference about open source multimedia, will see > > developers from VLC, libav, FFmpeg, x26*, Phonon, DVBlast, PulseAudio, > > KDE, Gnome, Xiph, handbrake, tomahawk and other projects gather to > > discuss about open source development of multimedia projects. > > This is a developer conference, so topics will be technical. > > > > The registration is now open here: http://goo.gl/NiCInJ > > Please register as soon as possible, to help us organize the conference. > [...] > > Hi, > > anybody is planning to go there? I remember that the registration will > close on August 20 (that is, the next week Wednesday), bye. I had not intended to come to VDD and reading this https://lists.debian.org/debian-devel/2014/08/msg00478.html I definitively will not come to VDD, as it would just be wasted time, [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Invitation to VDD and registration
On 16 Aug, Michael Niedermayer wrote : > I had not intended to come to VDD and reading this > https://lists.debian.org/debian-devel/2014/08/msg00478.html > > I definitively will not come to VDD, as it would just be wasted time, That's an easy excuse. -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Invitation to VDD and registration
On Sat, Aug 16, 2014 at 03:48:53AM +0200, Jean-Baptiste Kempf wrote: > On 16 Aug, Michael Niedermayer wrote : > > I had not intended to come to VDD and reading this > > https://lists.debian.org/debian-devel/2014/08/msg00478.html > > > > I definitively will not come to VDD, as it would just be wasted time, > > That's an easy excuse. Is it ? do you think me, the rest of the FFmpeg and Libav developers sitting together and people accusing each other of theft and lies. Would lead to improved relations ? I do want to resolve this, and i think if for example libav developers and ffmpeg developers would each say "shit happened, we all made mistakes" thats a start from which i think projects could be reunited. But from this, the best that one can get is some entertainment, the worst is depression, tears and further alieanated developers. -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
