Re: [FFmpeg-devel] [PATCH 3/4] lavf/concat: switch to new BSF API.
Le primidi 1er prairial, an CCXXIV, Michael Niedermayer a écrit : > can you do a quick time ffmpeg ... with -codec copy just to double > check ? theres no major effect It seems the memory management is not as negligible as I expected. The result is a ~2.3% slow-down for ~90k frames from AVI, which is approximately equal to the standard deviation on 10 runs. I suspect this is acceptable compared to the overhead of more complex containers. 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] Tee improvement - discussion
Le duodi 2 prairial, an CCXXIV, Marton Balint a écrit : > What caused these complications? Do you have some references? I do not remember exactly. There is the problem quoted by Michael. There is also a more global issue that options will be inconsistent: one implementation of non-blocking would have some set of options to control the queue size and overflow behaviour and such, and another implementation will have a different set of options. All very confusing for the user. Guideline: if at some point it makes sense for the users to run the tee muxer with a single output, just to get extra features it brings, then there is something deeply wrong with the design. > The only way this can work if someone steps up and helps both designing the > generic API and co-mentoring Jan. > > If that not happens, I would like to stick to the original plan. We can only > hope that we will learn something valuable which can be used later when > somebody takes the time and effort to actually redesign the API. My advice would be to try and focus on enhancements other than non-blocking output. If that is not possible, and the "stick everything in threads" approach is chosen, then IMHO it must not go in the tee muxer itself. But the "stick everything in threads" approach is flawed. Just think about what will happen if the actual muxer is blocking on a write while the application, seeing non-blocking behaviour, wants to close it: how do you kill the blocked write? 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] Ffmpeg with own filter
On Wed, May 25, 2016 at 16:11:58 +0300, Semen Zaytsev wrote: > I defined my filter in those files, and i string about configure this > filter in config.mak, I move content of vf_edgedetect.c to vf_foobar.c, > defined in makefile and in allfilters.c, when i trying to use "ffmpeg -i > http://samples.ffmpeg.org/image-samples/lena.pnm -vf foobar foobar.png". > I'm receiving [AVFilterGraph @ 003a8c40] No such filter: > 'foobar' Error opening filters! After integrating your source, run ./configure --list-filters to see whether the filter of that name is found. Then, re-run ./configure. When done, it will show you a summary of all features it will build - binaries, formats, filters, ... Check that list of filters first. Otherwise you need not even bother to build. After running make, you can check the availability of the filter by running ./ffmpeg -filters | grep foobar Then tell us where along that chain of commands your filter got lost. BTW, I consider this a question for the ffmpeg-users list, not ffmpeg-devel. But it might also fit onto libav-user. Or none of the three. ;-) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Filter: Add snapshot filter. It is enable to save snapshot.
On Wed, May 25, 2016 at 10:36:13PM +0800, kl222 wrote:
> Filter: Add snapshot filter.
> It can save a snapshot picture. Supports .png, .jpg, .bmp formats
> Snapshot with process_command api.
>
>
> doc/filters.texi | 23
> libavfilter/Makefile |1
> libavfilter/allfilters.c |1
> libavfilter/vf_snapshot.c | 234
> ++
> 4 files changed, 259 insertions(+)
> 0982d4ea5c463a71f36cb6b984ef00e418ba1380
> 0003-Filter-Add-snapshot-filter.-It-is-enable-to-save-sna.patch
> From a467346bea3849222c25aed2bb342b3d5fb51aeb Mon Sep 17 00:00:00 2001
> From: KangLin
> Date: Wed, 25 May 2016 16:29:45 +0800
> Subject: [PATCH 3/3] Filter: Add snapshot filter. It is enable to save
> snapshot.
[...]
> @@ -306,6 +306,7 @@ void avfilter_register_all(void)
> REGISTER_FILTER(ZMQ,zmq,vf);
> REGISTER_FILTER(ZOOMPAN,zoompan,vf);
> REGISTER_FILTER(ZSCALE, zscale, vf);
> + REGISTER_FILTER(SNAPSHOT, snapshot, vf);
tabs are forbidden in ffmpeg git
>
> REGISTER_FILTER(ALLRGB, allrgb, vsrc);
> REGISTER_FILTER(ALLYUV, allyuv, vsrc);
> diff --git a/libavfilter/vf_snapshot.c b/libavfilter/vf_snapshot.c
> new file mode 100644
> index 000..2c76ba5
> --- /dev/null
> +++ b/libavfilter/vf_snapshot.c
> @@ -0,0 +1,234 @@
> +/**
> + * @file
> + * Snapshot video filter, it can save a snapshot picture.
> + * Author:KangLin
> + */
Missing license header
[...]
> +static int snapshot_open(AVFilterContext *ctx, AVFrame* frame){
> +int ret = 0;
> +SnapshotContext *s = ctx->priv;
> +char f[1024] = { 0 };
> +if (s->ofmt_ctx)
> +return 0;
> +
> +if (s->pDir){
> +av_strlcpy(f, s->pDir, 1024);
> +av_strlcat(f, "/", 1024);
> +}
> +if (s->pFileName)
> +av_strlcat(f, s->pFileName, 1024);
> +else{
> +av_log(ctx, AV_LOG_ERROR, "please set filename.\n");
> +return AVERROR(EPERM);
> +}
> +
> +ret = avformat_alloc_output_context2(&s->ofmt_ctx, NULL, NULL, f);
> +if (ret < 0){
> +av_log(ctx, AV_LOG_ERROR, "open file is fail:%d;filename:%s\n", ret,
> f);
> +return ret;
> +}
> +if (!s->ofmt_ctx) {
> +av_log(ctx, AV_LOG_ERROR, "open file is fail:%d\n", ret);
> +return ret;
> +}
> +
> +av_init_packet(&s->outPacket);
> +
> +do{
> +s->pEncodec =
> avcodec_find_encoder(s->ofmt_ctx->oformat->video_codec);
> +if (!s->pEncodec){
> +av_log(ctx, AV_LOG_ERROR, "encodec isn't found.codec id:%d\n",
> + s->ofmt_ctx->oformat->video_codec);
> +break;
> +}
> +
> +AVStream *out_stream = avformat_new_stream(s->ofmt_ctx, s->pEncodec);
libavfilter/vf_snapshot.c: In function ‘snapshot_open’:
libavfilter/vf_snapshot.c:102:9: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement]
[...]
--
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
[FFmpeg-devel] [PATCH] avcodec/dca: move EXSS sampling frequency arrays to dca.c
Avoids unwanted parser dependency on dcadata.
---
libavcodec/Makefile | 2 +-
libavcodec/dca.c| 9 +
libavcodec/dca.h| 3 +++
libavcodec/dca_exss.c | 1 -
libavcodec/dca_parser.c | 1 -
libavcodec/dcadata.c| 9 -
libavcodec/dcadata.h| 3 ---
7 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 224ccf7..46dd9e1 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -900,7 +900,7 @@ OBJS-$(CONFIG_ADX_PARSER) += adx_parser.o adx.o
OBJS-$(CONFIG_BMP_PARSER) += bmp_parser.o
OBJS-$(CONFIG_CAVSVIDEO_PARSER)+= cavs_parser.o
OBJS-$(CONFIG_COOK_PARSER) += cook_parser.o
-OBJS-$(CONFIG_DCA_PARSER) += dca_parser.o dca_exss.o dcadata.o
dca.o
+OBJS-$(CONFIG_DCA_PARSER) += dca_parser.o dca_exss.o dca.o
OBJS-$(CONFIG_DIRAC_PARSER)+= dirac_parser.o
OBJS-$(CONFIG_DNXHD_PARSER)+= dnxhd_parser.o
OBJS-$(CONFIG_DPX_PARSER) += dpx_parser.o
diff --git a/libavcodec/dca.c b/libavcodec/dca.c
index 714509b..f11c73c 100644
--- a/libavcodec/dca.c
+++ b/libavcodec/dca.c
@@ -36,6 +36,15 @@ const uint32_t avpriv_dca_sample_rates[16] = {
12000, 24000, 48000, 96000, 192000
};
+const uint32_t ff_dca_sampling_freqs[16] = {
+ 8000, 16000, 32000, 64000, 128000, 22050, 44100, 88200,
+176400, 352800, 12000, 24000, 48000, 96000, 192000, 384000,
+};
+
+const uint8_t ff_dca_freq_ranges[16] = {
+0, 1, 2, 3, 4, 1, 2, 3, 4, 4, 0, 1, 2, 3, 4, 4
+};
+
int avpriv_dca_convert_bitstream(const uint8_t *src, int src_size, uint8_t
*dst,
int max_size)
{
diff --git a/libavcodec/dca.h b/libavcodec/dca.h
index a1ac763..bd96bc9 100644
--- a/libavcodec/dca.h
+++ b/libavcodec/dca.h
@@ -154,6 +154,9 @@ enum DCADownMixType {
extern av_export const uint32_t avpriv_dca_sample_rates[16];
+extern const uint32_t ff_dca_sampling_freqs[16];
+extern const uint8_t ff_dca_freq_ranges[16];
+
/**
* Convert bitstream to one representation based on sync marker
*/
diff --git a/libavcodec/dca_exss.c b/libavcodec/dca_exss.c
index fcabd07..e873088 100644
--- a/libavcodec/dca_exss.c
+++ b/libavcodec/dca_exss.c
@@ -19,7 +19,6 @@
*/
#include "dcadec.h"
-#include "dcadata.h"
static void parse_xll_parameters(DCAExssParser *s, DCAExssAsset *asset)
{
diff --git a/libavcodec/dca_parser.c b/libavcodec/dca_parser.c
index 6c84575..e5bea33 100644
--- a/libavcodec/dca_parser.c
+++ b/libavcodec/dca_parser.c
@@ -23,7 +23,6 @@
*/
#include "dca.h"
-#include "dcadata.h"
#include "dca_exss.h"
#include "dca_syncwords.h"
#include "get_bits.h"
diff --git a/libavcodec/dcadata.c b/libavcodec/dcadata.c
index 2d533d0..39aea73 100644
--- a/libavcodec/dcadata.c
+++ b/libavcodec/dcadata.c
@@ -8725,15 +8725,6 @@ const int32_t ff_dca_xll_band_coeff[20] = {
3259333, -5074941, 6928550, -8204883
};
-const uint32_t ff_dca_sampling_freqs[16] = {
- 8000, 16000, 32000, 64000, 128000, 22050, 44100, 88200,
-176400, 352800, 12000, 24000, 48000, 96000, 192000, 384000,
-};
-
-const uint8_t ff_dca_freq_ranges[16] = {
-0, 1, 2, 3, 4, 1, 2, 3, 4, 4, 0, 1, 2, 3, 4, 4
-};
-
const uint16_t ff_dca_avg_g3_freqs[3] = { 16000, 18000, 24000 };
const uint16_t ff_dca_fst_amp[44] = {
diff --git a/libavcodec/dcadata.h b/libavcodec/dcadata.h
index 1ef1342..17aa712 100644
--- a/libavcodec/dcadata.h
+++ b/libavcodec/dcadata.h
@@ -71,9 +71,6 @@ extern const uint16_t ff_dca_xll_refl_coeff[128];
extern const int32_t ff_dca_xll_band_coeff[20];
-extern const uint32_t ff_dca_sampling_freqs[16];
-extern const uint8_t ff_dca_freq_ranges[16];
-
extern const uint16_t ff_dca_avg_g3_freqs[3];
extern const uint16_t ff_dca_fst_amp[44];
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Tee improvement - discussion
On Thu, May 26, 2016 at 12:09:14PM +0200, Nicolas George wrote: > Le duodi 2 prairial, an CCXXIV, Marton Balint a écrit : > > What caused these complications? Do you have some references? > > I do not remember exactly. There is the problem quoted by Michael. There is > also a more global issue that options will be inconsistent: > one > implementation of non-blocking would have some set of options to control the > queue size and overflow behaviour and such, and another implementation will > have a different set of options. All very confusing for the user. Isnt that just a matter of making options consistent or using a option in AVStream / AVFormatContext which would be the same for all muxers > > Guideline: if at some point it makes sense for the users to run the tee > muxer with a single output, just to get extra features it brings, then there > is something deeply wrong with the design. can you elaborate what is deeply wrong in that case ? > > > The only way this can work if someone steps up and helps both designing the > > generic API and co-mentoring Jan. > > > > If that not happens, I would like to stick to the original plan. We can only > > hope that we will learn something valuable which can be used later when > > somebody takes the time and effort to actually redesign the API. > > My advice would be to try and focus on enhancements other than non-blocking > output. If that is not possible, and the "stick everything in threads" > approach is chosen, then IMHO it must not go in the tee muxer itself. > > But the "stick everything in threads" approach is flawed. Just think about > what will happen if the actual muxer is blocking on a write while the > application, seeing non-blocking behaviour, wants to close it: how do you > kill the blocked write? How does a thread make it worse here ? If a muxer blocks without threads the application blocks (till the user kills it or the condition on which it blocks changes) If a muxer blocks in its own thread the application wont block the same moment but might block when trying to write more than the fifo can hold or on closing, thats just blocking the same way a single threaded design would block just a tiny bit later maybe iam missing something but it seems the problem is the blocking write and threads do not really add more problems to it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dca: move EXSS sampling frequency arrays to dca.c
On 5/26/2016 8:29 AM, foo86 wrote: > Avoids unwanted parser dependency on dcadata. > --- > libavcodec/Makefile | 2 +- > libavcodec/dca.c| 9 + > libavcodec/dca.h| 3 +++ > libavcodec/dca_exss.c | 1 - > libavcodec/dca_parser.c | 1 - > libavcodec/dcadata.c| 9 - > libavcodec/dcadata.h| 3 --- > 7 files changed, 13 insertions(+), 15 deletions(-) Applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Tee improvement - discussion
On Thu, 26 May 2016, Nicolas George wrote: Le duodi 2 prairial, an CCXXIV, Marton Balint a écrit : What caused these complications? Do you have some references? I do not remember exactly. There is the problem quoted by Michael. There is also a more global issue that options will be inconsistent: one implementation of non-blocking would have some set of options to control the queue size and overflow behaviour and such, and another implementation will have a different set of options. All very confusing for the user. Guideline: if at some point it makes sense for the users to run the tee muxer with a single output, just to get extra features it brings, then there is something deeply wrong with the design. What if we decouple the non-blocking queue and the retry on failure logic to a separate "buffer" or "fifo" muxer? This seems like what you are trying to do, and by using the exisiting muxer interface, we don't have to design new API around it. Although I don't yet see if using three levels of muxing (E.g. the tee muxer invokes the fifo muxer, which will invoke the underlying real muxer) can cause any unseen problems or not. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Load CUDA driver API dynamically when needed
Enabling CUDA support adds some extremely useful features but it also
adds hard runtime dependency on NVidia driver. This commit removes that
dependency; driver library would be loaded when required.
This allows to use same CUDA-enabled FFMpeg build on machines with and
without NVidia cards.
CUDA toolkit is still needed at build time. scale_npp filter still adds
runtime dependency on libnppc and libnppi (which is fine since these
libraries have to be redistributed with FFMpeg anyway, and they load
CUDA internally on demand as well).
---
Same patch was sent to libav ML
configure | 9 ++--
libavcodec/nvenc.c | 24 ++
libavfilter/vf_hwupload_cuda.c | 22 ++---
libavfilter/vf_scale_npp.c | 12 -
libavutil/Makefile | 4 +-
libavutil/cuda_api.c | 102 +
libavutil/cuda_api.h | 53 +
libavutil/hwcontext_cuda.c | 36 +--
8 files changed, 227 insertions(+), 35 deletions(-)
create mode 100644 libavutil/cuda_api.c
create mode 100644 libavutil/cuda_api.h
diff --git a/configure b/configure
index cc2c9e7..ab2d9c9 100755
--- a/configure
+++ b/configure
@@ -157,7 +157,7 @@ Hardware accelerators:
--disable-vdpau disable VDPAU code [autodetect]
Hardware-accelerated decoding/encoding:
- --enable-cudaenable dynamically linked CUDA [no]
+ --enable-cudaenable CUDA support [no]
--enable-libmfx enable HW acceleration through libmfx
--enable-mmalenable decoding via MMAL [no]
--enable-nvenc enable NVIDIA NVENC support [no]
@@ -5577,8 +5577,11 @@ enabled avfoundation_indev && { check_lib2 CoreGraphics/CoreGraphics.h CGGetActi
enabled avisynth && { { check_lib2 "windows.h" LoadLibrary; } ||
{ check_lib2 "dlfcn.h" dlopen -ldl; } ||
die "ERROR: LoadLibrary/dlopen not found for avisynth"; }
-enabled cuda && { check_lib cuda.h cuInit -lcuda ||
- die "ERROR: CUDA not found"; }
+enabled cuda && { check_header cuda.h ||
+ die "ERROR: CUDA toolkit not found"; } &&
+ { { check_lib2 "windows.h" LoadLibrary; } ||
+ { check_lib2 "dlfcn.h" dlopen -ldl; } ||
+ die "ERROR: LoadLibrary/dlopen not found for CUDA"; }
enabled chromaprint && require chromaprint chromaprint.h chromaprint_get_version -lchromaprint
enabled coreimage_filter && { check_header_objcc QuartzCore/CoreImage.h || disable coreimage_filter; }
enabled coreimagesrc_filter && { check_header_objcc QuartzCore/CoreImage.h || disable coreimagesrc_filter; }
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 73d0584..4ce45b3 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -40,8 +40,8 @@
#if CONFIG_CUDA
-#include
#include "libavutil/hwcontext_cuda.h"
+#include "libavutil/cuda_api.h"
#else
#if defined(_WIN32)
@@ -330,14 +330,20 @@ static av_cold int nvenc_dyload_cuda(AVCodecContext *avctx)
NvencDynLoadFunctions *dl_fn = &ctx->nvenc_dload_funcs;
#if CONFIG_CUDA
-dl_fn->cu_init = cuInit;
-dl_fn->cu_device_get_count = cuDeviceGetCount;
-dl_fn->cu_device_get= cuDeviceGet;
-dl_fn->cu_device_get_name = cuDeviceGetName;
-dl_fn->cu_device_compute_capability = cuDeviceComputeCapability;
-dl_fn->cu_ctx_create= cuCtxCreate_v2;
-dl_fn->cu_ctx_pop_current = cuCtxPopCurrent_v2;
-dl_fn->cu_ctx_destroy = cuCtxDestroy_v2;
+AVCudaFunctions* api = avpriv_load_cuda();
+if (!api) {
+av_log(avctx, AV_LOG_FATAL, "Failed loading CUDA library\n");
+return 0;
+}
+
+dl_fn->cu_init = api->cuInit;
+dl_fn->cu_device_get_count = api->cuDeviceGetCount;
+dl_fn->cu_device_get= api->cuDeviceGet;
+dl_fn->cu_device_get_name = api->cuDeviceGetName;
+dl_fn->cu_device_compute_capability = api->cuDeviceComputeCapability;
+dl_fn->cu_ctx_create= api->cuCtxCreate;
+dl_fn->cu_ctx_pop_current = api->cuCtxPopCurrent;
+dl_fn->cu_ctx_destroy = api->cuCtxDestroy;
return 1;
#else
diff --git a/libavfilter/vf_hwupload_cuda.c b/libavfilter/vf_hwupload_cuda.c
index c1c..f78e219 100644
--- a/libavfilter/vf_hwupload_cuda.c
+++ b/libavfilter/vf_hwupload_cuda.c
@@ -19,6 +19,7 @@
#include "libavutil/buffer.h"
#include "libavutil/hwcontext.h"
#include "libavutil/hwcontext_cuda.h"
+#include "libavutil/cuda_api.h"
#include "libavutil/log.h"
#include "libavutil/opt.h"
@@ -29,6 +30,7 @@
typedef struct CudaUploadContext {
const AVClass *class;
+AVCudaFunctions *api;
int device_idx;
AVBufferRef *
[FFmpeg-devel] [PATCH] ffserver: fixed deallocation bug in build_feed_streams
In ffserver.c:build_feed_streams(), the streams pointer is only
correctly reset before deallocation when there is no error.
This may cause ffserver to crash, because stream lives in static
memory, not the heap.
The patch duplicates the behaviour of the non-error case.
>From 00c9203f0349dbae6e701104d5a7f6c4e6fa0159 Mon Sep 17 00:00:00 2001
From: Gregor Riepl
Date: Tue, 24 May 2016 15:17:22 +0200
Subject: [PATCH] ffserver: fixed deallocation bug in build_feed_streams
Signed-off-by: Gregor Riepl
---
ffserver.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ffserver.c b/ffserver.c
index b5bd8f8..1a27583 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -3863,6 +3863,8 @@ drop:
if (avformat_write_header(s, NULL) < 0) {
http_log("Container doesn't support the required parameters\n");
avio_closep(&s->pb);
+s->streams = NULL;
+s->nb_streams = 0;
avformat_free_context(s);
goto bail;
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On 5/18/2016 5:33 PM, Paul B Mahol wrote: > Hi, > > I want to propose to have an FFmpeg IRC meeting on > the Saturday of the next week, Saturday May 28, > UTC 17. > > Candidate topics of the day: > - Code of Conduct and policy around it > - technical development issues > - misc topics > > Feel free to propose other topics. > > Best regards. This has gotten Clement's explicit confirmation and Michael's implicit after eight days. With mine now that'd be three. We're only two days away from the proposed date. If nobody else confirms, maybe we should postpone it while we poke more people to confirm their participation? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On Thu, May 26, 2016, at 12:43 PM, James Almer wrote: > > This has gotten Clement's explicit confirmation and Michael's implicit > after eight days. With mine now that'd be three. > We're only two days away from the proposed date. If nobody else confirms, > maybe we should postpone it while we poke more people to confirm their > participation? I won't be able to make it on Saturday (I'm going on a kayak fishing trip). If it is rescheduled I will try to attend, but feel free to hold the meeting on Saturday without me if you decided to stay on schedule. Lou ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On 5/26/16, James Almer wrote: > On 5/18/2016 5:33 PM, Paul B Mahol wrote: >> Hi, >> >> I want to propose to have an FFmpeg IRC meeting on >> the Saturday of the next week, Saturday May 28, >> UTC 17. >> >> Candidate topics of the day: >> - Code of Conduct and policy around it >> - technical development issues >> - misc topics >> >> Feel free to propose other topics. >> >> Best regards. > > This has gotten Clement's explicit confirmation and Michael's implicit > after eight days. With mine now that'd be three. > We're only two days away from the proposed date. If nobody else confirms, > maybe we should postpone it while we poke more people to confirm their > participation? I do not think that is valid reason to postpone, if anybody wants to join he/she will join. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On 5/26/16, Lou Logan wrote: > On Thu, May 26, 2016, at 12:43 PM, James Almer wrote: >> >> This has gotten Clement's explicit confirmation and Michael's implicit >> after eight days. With mine now that'd be three. >> We're only two days away from the proposed date. If nobody else confirms, >> maybe we should postpone it while we poke more people to confirm their >> participation? > > I won't be able to make it on Saturday (I'm going on a kayak fishing > trip). If it is rescheduled I will try to attend, but feel free to hold > the meeting on Saturday without me if you decided to stay on schedule. You could told that immediately, it would be rescheduled, now is too late IMHO. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffserver: fixed deallocation bug in build_feed_streams
On Thu, May 26, 2016 at 08:29:56PM +0200, Gregor Riepl wrote: > In ffserver.c:build_feed_streams(), the streams pointer is only > correctly reset before deallocation when there is no error. > > This may cause ffserver to crash, because stream lives in static > memory, not the heap. > > The patch duplicates the behaviour of the non-error case. > ffserver.c |2 ++ > 1 file changed, 2 insertions(+) > 510c4bb249dcb8fd621a1fb1b94a8b43c1e8e11b > 0001-ffserver-fixed-deallocation-bug-in-build_feed_stream.patch > From 00c9203f0349dbae6e701104d5a7f6c4e6fa0159 Mon Sep 17 00:00:00 2001 > From: Gregor Riepl > Date: Tue, 24 May 2016 15:17:22 +0200 > Subject: [PATCH] ffserver: fixed deallocation bug in build_feed_streams > > Signed-off-by: Gregor Riepl applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On Thu, May 26, 2016 at 10:48 PM, Paul B Mahol wrote: > On 5/26/16, James Almer wrote: >> On 5/18/2016 5:33 PM, Paul B Mahol wrote: >>> Hi, >>> >>> I want to propose to have an FFmpeg IRC meeting on >>> the Saturday of the next week, Saturday May 28, >>> UTC 17. >>> >>> Candidate topics of the day: >>> - Code of Conduct and policy around it >>> - technical development issues >>> - misc topics >>> >>> Feel free to propose other topics. >>> >>> Best regards. >> >> This has gotten Clement's explicit confirmation and Michael's implicit >> after eight days. With mine now that'd be three. >> We're only two days away from the proposed date. If nobody else confirms, >> maybe we should postpone it while we poke more people to confirm their >> participation? > > I do not think that is valid reason to postpone, if anybody wants to > join he/she will join. Holding a meeting where noone is present is also not really a valid strategy. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On 5/26/2016 7:56 PM, Hendrik Leppkes wrote: > On Thu, May 26, 2016 at 10:48 PM, Paul B Mahol wrote: >> On 5/26/16, James Almer wrote: >>> On 5/18/2016 5:33 PM, Paul B Mahol wrote: Hi, I want to propose to have an FFmpeg IRC meeting on the Saturday of the next week, Saturday May 28, UTC 17. Candidate topics of the day: - Code of Conduct and policy around it - technical development issues - misc topics Feel free to propose other topics. Best regards. >>> >>> This has gotten Clement's explicit confirmation and Michael's implicit >>> after eight days. With mine now that'd be three. >>> We're only two days away from the proposed date. If nobody else confirms, >>> maybe we should postpone it while we poke more people to confirm their >>> participation? >> >> I do not think that is valid reason to postpone, if anybody wants to >> join he/she will join. > > Holding a meeting where noone is present is also not really a valid strategy. > > - Hendrik If not enough people are present no decisions will be made. Worst case scenario, nothing is discussed either and the meeting is re-scheduled in the hopes people actually confirm their presence this time around. In any case, we still have two days so confirmations from those that haven't yet done it are very welcome. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters
On Wed, May 25, 2016 at 02:18:38PM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, May 25, 2016 at 1:24 PM, James Almer wrote: > > > On 5/25/2016 1:56 PM, Jon Toohill wrote: > > > --- > > > libavformat/mp3dec.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c > > > index 3725d67..192f5ef 100644 > > > --- a/libavformat/mp3dec.c > > > +++ b/libavformat/mp3dec.c > > > @@ -234,6 +234,8 @@ static void mp3_parse_info_tag(AVFormatContext *s, > > AVStream *st, > > > > > > mp3->start_pad = v>>12; > > > mp3-> end_pad = v&4095; > > > +st->codecpar->initial_padding = mp3->start_pad; > > > +st->codecpar->trailing_padding = mp3->end_pad; > > > > Every other format so far is using the AV_PKT_DATA_SKIP_SAMPLES side data > > to > > discard samples from the last packet/frame. See matroska and ogg demuxers, > > currently used for Opus only. > > > > The trailing_padding AVCodecParameters element was added after the above > > was > > designed. To be honest i can't say if we should replace one with the other > > or find a way to keep both, and seeing how AVCodecParameters hasn't made it > > to a release yet, we're still on time to choose. > > > I agree having 1 is better than having 2. I can't technically comment on > which one is better/easier/*. mp3 supports AV_PKT_DATA_SKIP_SAMPLES since FFmpeg 2.5 ogg opus sets codecpar->initial_padding like this patch would so does dtshddec and matroskadec AV_PKT_DATA_SKIP_SAMPLES is not a substitute for setting trailing_padding because with AV_PKT_DATA_SKIP_SAMPLES the trailing_padding only becomes available at the end of the stream also theres nothing wrong with AV_PKT_DATA_SKIP_SAMPLES, its local information for the current packet and there may indeed be cases like with concatenated streams where there are packets in the middle with discarding. So the 2 AVCodecParameters fields are not a substitute for AV_PKT_DATA_SKIP_SAMPLES also for encoding AV_PKT_DATA_SKIP_SAMPLES does not work with some formats the trailing_padding is needed to be known when writing the header the patch does look like a reasonable step to me but i might be missing something [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters
On 5/26/2016 11:05 PM, Michael Niedermayer wrote: > On Wed, May 25, 2016 at 02:18:38PM -0400, Ronald S. Bultje wrote: >> Hi, >> >> On Wed, May 25, 2016 at 1:24 PM, James Almer wrote: >> >>> On 5/25/2016 1:56 PM, Jon Toohill wrote: --- libavformat/mp3dec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c index 3725d67..192f5ef 100644 --- a/libavformat/mp3dec.c +++ b/libavformat/mp3dec.c @@ -234,6 +234,8 @@ static void mp3_parse_info_tag(AVFormatContext *s, >>> AVStream *st, mp3->start_pad = v>>12; mp3-> end_pad = v&4095; +st->codecpar->initial_padding = mp3->start_pad; +st->codecpar->trailing_padding = mp3->end_pad; >>> >>> Every other format so far is using the AV_PKT_DATA_SKIP_SAMPLES side data >>> to >>> discard samples from the last packet/frame. See matroska and ogg demuxers, >>> currently used for Opus only. >>> >>> The trailing_padding AVCodecParameters element was added after the above >>> was >>> designed. To be honest i can't say if we should replace one with the other >>> or find a way to keep both, and seeing how AVCodecParameters hasn't made it >>> to a release yet, we're still on time to choose. >> >> >> I agree having 1 is better than having 2. I can't technically comment on >> which one is better/easier/*. > > mp3 supports AV_PKT_DATA_SKIP_SAMPLES since FFmpeg 2.5 > ogg opus sets codecpar->initial_padding like this patch would > so does dtshddec and matroskadec > > AV_PKT_DATA_SKIP_SAMPLES is not a substitute for setting > trailing_padding because with AV_PKT_DATA_SKIP_SAMPLES the > trailing_padding only becomes available at the end of the stream > > also theres nothing wrong with AV_PKT_DATA_SKIP_SAMPLES, its local > information for the current packet and there may indeed be cases > like with concatenated streams where there are packets in the middle > with discarding. So the 2 AVCodecParameters fields are not a substitute > for AV_PKT_DATA_SKIP_SAMPLES > Fine with me, then. I assumed both both were pretty much made for the same purpose and to cover the same use cases. > also for encoding AV_PKT_DATA_SKIP_SAMPLES does not work with some > formats the trailing_padding is needed to be known when writing the > header The one format i know should be using AV_PKT_DATA_SKIP_SAMPLES the same way as ogg and matroska is mpegts. Probably also mp4. At least for Opus the mpegts muxer reads the value from the last packet the encoder or demuxer sends its way and writes it to the output file, but the mpegts demuxer is apparently none the wiser because the opus parser just discards this information. > > the patch does look like a reasonable step to me but i might be > missing something ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/mp3dec: pass Xing gapless metadata to AVCodecParameters
On Wed, May 25, 2016 at 09:56:59AM -0700, Jon Toohill wrote:
> ---
> libavformat/mp3dec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 3725d67..192f5ef 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -234,6 +234,8 @@ static void mp3_parse_info_tag(AVFormatContext *s,
> AVStream *st,
>
> mp3->start_pad = v>>12;
> mp3-> end_pad = v&4095;
> +st->codecpar->initial_padding = mp3->start_pad;
> +st->codecpar->trailing_padding = mp3->end_pad;
> st->start_skip_samples = mp3->start_pad + 528 + 1;
> if (mp3->frames) {
> st->first_discard_sample = -mp3->end_pad + 528 + 1 + mp3->frames
> * (int64_t)spf;
is the 528 + 1 difference intended to start_skip_samples/first_discard_sample
?
mp3enc stores par->initial_padding - 528 - 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Tee improvement - discussion
Hi Nicolas, On 05/26/2016 12:09 PM, Nicolas George wrote: But the "stick everything in threads" approach is flawed. Just think about what will happen if the actual muxer is blocking on a write while the application, seeing non-blocking behaviour, wants to close it: how do you kill the blocked write? Regards If I understand it correctly, I think this will be handled quite smoothy - you don't have to kill the blocked write, the application has to call write_trailer anyway before closing the muxer, so I guess this is the place where tee will wait for the muxer's pending write operation to finish. So application will know, that after call to write_trailer all operations are finished. Regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
