Re: [FFmpeg-devel] [GSoC 2015] Segmentation fault with av_malloc()
Figured it out. Valgrind was pretty helpful. Thanks again. -Niklesh On Sat, Jul 4, 2015 at 12:40 AM, Niklesh Lalwani wrote: > Thanks guys, I'll try it out. > > -Niklesh > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
On Fri, Jul 03, 2015 at 07:53:43PM +0200, Michael Niedermayer wrote: > Hi all > > It is POSSIBLE that we need to move to different servers/hosting. > We have been informed that the free hosting and servers we use > currently may become unavailable in the future. > > Thus if someone can provide the FFmpeg/MPlayer/rtmpdump projects with > a free server and hosting, knows of some company who might provide us > with that or wants to sponsor a server & hosting > please reply ASAP > > Thank you! > > PS: please use reply to all so the thread does not get fragmented > between mailing lists The possibility changed to the worse we must move no details known ATM but if you can help please join https://lists.sourceforge.net/lists/listinfo/ffmpeg-admins used SF as i had nothing else, feel free to setup a better ML [...] -- 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
Re: [FFmpeg-devel] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
On Sat, Jul 04, 2015 at 12:45:18PM +0200, Michael Niedermayer wrote: > On Fri, Jul 03, 2015 at 07:53:43PM +0200, Michael Niedermayer wrote: > > Hi all > > > > It is POSSIBLE that we need to move to different servers/hosting. > > We have been informed that the free hosting and servers we use > > currently may become unavailable in the future. > > > > Thus if someone can provide the FFmpeg/MPlayer/rtmpdump projects with > > a free server and hosting, knows of some company who might provide us > > with that or wants to sponsor a server & hosting > > please reply ASAP > > > > Thank you! > > > > PS: please use reply to all so the thread does not get fragmented > > between mailing lists > > The possibility changed to the worse > we must move > > no details known ATM but if you can help please join > https://lists.sourceforge.net/lists/listinfo/ffmpeg-admins > used SF as i had nothing else, feel free to setup a better ML note, to make this clear there will be no ffmpeg.org or mplayerhq.hu soon if noone helps we need a server we need volunteers to help with the move [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: More correct selection of alignment of a frame height depending whether an encoded sequence progressive or not.
Hello All, There is patch which fixes too strong frame height rounding for case when progressive frame sequence encodes by QSV. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-libavcodec-qsvenc.c.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: More correct selection of alignment of a frame height depending whether an encoded sequence progressive or not.
On Sat, Jul 4, 2015 at 2:38 PM, Ivan Uskov wrote: > Hello All, > > There is patch which fixes too strong frame height rounding for case > when progressive frame sequence encodes by QSV. Is there any harm in always using 32 alignment for the height? Because the flag you are checking there is not correct. In fact, there is no reliable global interlaced flag. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: More correct selection of alignment of a frame height depending whether an encoded sequence progressive or not.
Hello Hendrik, The harm of hard-coded alignment 32 that typical 1280x720 progressive video should be encoded as 1280x736. I.e. absolutely superfluous stripe of macroblocks should be encoded. I can see that CODEC_FLAG_INTERLACED_DCT currently checks into dnxhddata.c dnxhdenc.c dvenc.c libx264.c libxavs.c mpegvideo_enc.c nvenc.c Why it can not be used by similar way in qsvenc.c? Saturday, July 4, 2015, 4:34:32 PM, you wrote: HL> On Sat, Jul 4, 2015 at 2:38 PM, Ivan Uskov wrote: >> Hello All, >> >> There is patch which fixes too strong frame height rounding for case >> when progressive frame sequence encodes by QSV. HL> Is there any harm in always using 32 alignment for the height? HL> Because the flag you are checking there is not correct. In fact, there HL> is no reliable global interlaced flag. -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] library.mak: add rpath to shared libraries
On Sat, Jun 27, 2015 at 7:18 PM, Ganesh Ajjanagadde wrote: > On Sat, Jun 27, 2015 at 9:49 AM, Ganesh Ajjanagadde wrote: >> On Sat, Jun 27, 2015 at 2:22 AM, Hendrik Leppkes wrote: >>> On Sat, Jun 27, 2015 at 3:09 AM, Ganesh Ajjanagadde >>> wrote: Fixes Ticket4673 Signed-off-by: Ganesh Ajjanagadde --- library.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/library.mak b/library.mak index 29460b8..401da7c 100644 --- a/library.mak +++ b/library.mak @@ -58,7 +58,7 @@ $(SUBDIR)$(SLIBNAME): $(SUBDIR)$(SLIBNAME_WITH_MAJOR) $(SUBDIR)$(SLIBNAME_WITH_MAJOR): $(OBJS) $(SLIBOBJS) $(SUBDIR)lib$(NAME).ver $(SLIB_CREATE_DEF_CMD) - $$(LD) $(SHFLAGS) $(LDFLAGS) $$(LD_O) $$(filter %.o,$$^) $(FFEXTRALIBS) + $$(LD) $(SHFLAGS) $(LDFLAGS) $(LDEXEFLAGS) $$(LD_O) $$(filter %.o,$$^) $(FFEXTRALIBS) $(SLIB_EXTRA_CMD) >>> >>> LDEXEFLAGS is clearly not the appropriate way to go about this. These >>> flags are for executables, not for shared libraries. >>> >>> - Hendrik >> >> Ok, so is it fine if this gets added to LDFLAGS instead? Or should a >> separate e.g LDLIBFLAGS be used? > > Attached is new patch that creates a LDLIBFLAGS. Ping. > >> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [MPlayer-dev-eng] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
On Sat, 4 Jul 2015 10:02:14 -0400 Devin Heitmueller wrote: > > note, to make this clear there will be no ffmpeg.org or mplayerhq.hu > > soon if noone helps > > we need a server we need volunteers to help with the move > > Is there anything you can share about what the current bandwidth > requirements are? It might make it easier to assess whether it's > feasible to host if interested parties could do some estimate of what > the costs would likely be. at least 4TB/month bandwidth. 4tb of storage space. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] api-seek-test: first version
I fixed brackets and added dependency on fate-lavf to be sure that lavf.flv exists. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] api-seek-test: first version
Works only with video stream.
---
tests/api/Makefile| 1 +
tests/api/api-seek-test.c | 194 ++
tests/fate/api.mak| 4 +
tests/ref/fate/api-seek | 147 +++
4 files changed, 346 insertions(+)
create mode 100644 tests/api/api-seek-test.c
create mode 100644 tests/ref/fate/api-seek
diff --git a/tests/api/Makefile b/tests/api/Makefile
index 704987e..59cbc7c 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -1,5 +1,6 @@
APITESTPROGS-$(call ENCDEC, FLAC, FLAC) += api-flac
APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
+APITESTPROGS-yes += api-seek
APITESTPROGS += $(APITESTPROGS-yes)
APITESTOBJS := $(APITESTOBJS:%=$(APITESTSDIR)%)
$(APITESTPROGS:%=$(APITESTSDIR)/%-test.o)
diff --git a/tests/api/api-seek-test.c b/tests/api/api-seek-test.c
new file mode 100644
index 000..85430a3
--- /dev/null
+++ b/tests/api/api-seek-test.c
@@ -0,0 +1,194 @@
+/*
+ * 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.
+ */
+
+/**
+ * Seek test.
+ */
+
+#include "libavutil/adler32.h"
+#include "libavcodec/avcodec.h"
+#include "libavformat/avformat.h"
+#include "libavutil/imgutils.h"
+
+static int compute_crc_of_packets(AVFormatContext *fmt_ctx, int video_stream,
+AVCodecContext *ctx, AVFrame *fr, uint64_t
ts_start, uint64_t ts_end)
+{
+int number_of_written_bytes;
+int got_frame = 0;
+int result;
+int end_of_stream = 0;
+int byte_buffer_size;
+uint8_t *byte_buffer;
+AVPacket pkt;
+
+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) {
+av_log(NULL, AV_LOG_ERROR, "Can't allocate buffer\n");
+return AVERROR(ENOMEM);
+}
+
+result = av_seek_frame(fmt_ctx, video_stream, ts_start, AVSEEK_FLAG_ANY);
+printf("Seeking to %"PRId64", computing crc for frames with pts <
%"PRId64"\n", ts_start, ts_end);
+if (result < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error in seeking\n");
+return result;
+}
+avcodec_flush_buffers(ctx);
+
+av_init_packet(&pkt);
+do {
+if (!end_of_stream)
+if (av_read_frame(fmt_ctx, &pkt) < 0)
+end_of_stream = 1;
+if (end_of_stream) {
+pkt.data = NULL;
+pkt.size = 0;
+}
+if (pkt.stream_index == video_stream || end_of_stream) {
+got_frame = 0;
+if (pkt.pts == AV_NOPTS_VALUE) {
+av_log(NULL, AV_LOG_ERROR, "Error: frames doesn't have pts
values\n");
+return -1;
+}
+result = avcodec_decode_video2(ctx, fr, &got_frame, &pkt);
+if (result < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error decoding frame\n");
+return result;
+}
+if (got_frame) {
+number_of_written_bytes = av_image_copy_to_buffer(byte_buffer,
byte_buffer_size,
+(const uint8_t* const *)fr->data,
(const int*) fr->linesize,
+ctx->pix_fmt, ctx->width, ctx->height,
1);
+if (number_of_written_bytes < 0) {
+av_log(NULL, AV_LOG_ERROR, "Can't copy image to buffer\n");
+return number_of_written_bytes;
+}
+if (fr->pkt_pts > ts_end)
+break;
+printf("%10"PRId64", 0x%08lx\n", fr->pkt_pts,
av_adler32_update(0, (const uint8_t*)byte_buffer,
+number_of_written_bytes));
+}
+}
+av_free_packet(&pkt);
+av_init_packet(&pkt);
+} while ((!end_of_stream || got_frame) && (fr->pkt_pts +
av_frame_get_pkt_duration(fr) <= ts_end));
+
+av_free_packet(&pkt);
+av_freep(&byte_buff
Re: [FFmpeg-devel] [MPlayer-dev-eng] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
> note, to make this clear there will be no ffmpeg.org or mplayerhq.hu > soon if noone helps > we need a server we need volunteers to help with the move Is there anything you can share about what the current bandwidth requirements are? It might make it easier to assess whether it's feasible to host if interested parties could do some estimate of what the costs would likely be. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [MPlayer-dev-eng] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
compn wrote: On Sat, 4 Jul 2015 10:02:14 -0400 Devin Heitmueller wrote: note, to make this clear there will be no ffmpeg.org or mplayerhq.hu soon if noone helps we need a server we need volunteers to help with the move Is there anything you can share about what the current bandwidth requirements are? It might make it easier to assess whether it's feasible to host if interested parties could do some estimate of what the costs would likely be. at least 4TB/month bandwidth. 4tb of storage space. Sorry I don't have any good suggestions. Two years ago we had to move the hosting for openldap.org, which had been hosted for free at ISC for over a dozen years. We setup on Linode and they sponsored us for a year; they're very friendly to open source projects. But we didn't renew sponsorship after that. I now pay $1440/year to keep the two openldap.org servers running on their systems. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
On Sat, Jul 04, 2015 at 01:15:51PM +0200, Michael Niedermayer wrote: > On Sat, Jul 04, 2015 at 12:45:18PM +0200, Michael Niedermayer wrote: > > On Fri, Jul 03, 2015 at 07:53:43PM +0200, Michael Niedermayer wrote: > > > Hi all > > > > > > It is POSSIBLE that we need to move to different servers/hosting. > > > We have been informed that the free hosting and servers we use > > > currently may become unavailable in the future. > > > > > > Thus if someone can provide the FFmpeg/MPlayer/rtmpdump projects with > > > a free server and hosting, knows of some company who might provide us > > > with that or wants to sponsor a server & hosting > > > please reply ASAP > > > > > > Thank you! > > > > > > PS: please use reply to all so the thread does not get fragmented > > > between mailing lists > > > > The possibility changed to the worse > > we must move > > > > no details known ATM but if you can help please join > > https://lists.sourceforge.net/lists/listinfo/ffmpeg-admins > > used SF as i had nothing else, feel free to setup a better ML > > note, to make this clear there will be no ffmpeg.org or mplayerhq.hu > soon if noone helps > we need a server we need volunteers to help with the move quick update we got a new server and transferred many things already (ill write more later) what is not transferred yet is trac and mailman if someone reading this knows mailman and want to help please join ##ffmpeg-admin on freenode [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
