Re: [FFmpeg-devel] [PATCH 1/2] libavformat/flvenc: refactoring: extracted method for writing codec headers
On Thu, Jun 09, 2016 at 10:12:09PM -0400, Ivan wrote: > --- > libavformat/flvenc.c | 116 > --- > 1 file changed, 64 insertions(+), 52 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] libavformat/flvenc: support for codec configuration change mid stream
On Thu, Jun 09, 2016 at 10:12:10PM -0400, Ivan wrote: > --- > libavformat/flvenc.c | 13 + > 1 file changed, 13 insertions(+) applied This seems not tested by fate, so a fate test would be useful too thanks [...] -- 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] lavu/intmath.h: fix compilation with msvc10.
On Sat, Jun 11, 2016 at 12:00:35AM +1000, Matt Oliver wrote: > On 10 June 2016 at 05:30, Michael Niedermayer > wrote: > > > On Mon, Jun 06, 2016 at 05:11:34PM +1000, Matt Oliver wrote: > > > --- > > > libavutil/x86/intmath.h | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h > > > index f58b0d0..de177dd 100644 > > > --- a/libavutil/x86/intmath.h > > > +++ b/libavutil/x86/intmath.h > > > @@ -47,6 +47,7 @@ static av_always_inline av_const int > > ff_log2_x86(unsigned > > > int v) > > > # endif > > > # define ff_log2_16bit av_log2 > > > > > > +#if defined(_MSC_VER) && (_MSC_VER >= 1700) > > > # define ff_ctz(v) _tzcnt_u32(v) > > > > should this not be some configre based chec like > > CONFIG_TZCNT_U32 > > ? > > > > It could be but this is just checking for the availability of an intrinsic > used with msvc that is available for all msvc versions except 2010. So a > configure chck would just tell us what this code is doing anyway. Given > that this is msvc specific I didnt think it worth cluttering up configure > for such a rare usecase. Especially seeing as how we are not also checking > for all the gcc specific builtins or icl intrinsics used in this file and > in others and adding all those to configure would add considerable bloat. > So it can be added to configure if desired but for such a simple and msvc > specific case I would recommend not affecting other build chains by adding > it to configure. ok, i withdraw my comment [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] FFPlay on a HLS stream skips audio from time to time.
On Wed, 8 Jun 2016, Adrian Cruceru wrote: On Tue Jun 7 Marton Balint wrote: On Wed, 1 Jun 2016, Adrian Cruceru wrote: >/Hi, />//>/Patch is attached, />//>/Quick notes: />/- Playing HLS streams - FFPlay stalls a bit before each segment download />/- Stalls accumulate and FFPlay falls behind />/- We get log warning and segment skip. />//>/Fix: />/- Just make sure HLS is marked as a real time stream. / I guess using -infbuf fixes your usecase as well, right? Without -infbuf ffplay buffers 25 frames, so for 25 fps video content, if playing stops, this means that it is unable to acquire the first few packets of a new segment within 1 second. Is this really the case? Do you have a public test stream where this can be tested? Thanks, Marton Hi Marton, You are correct in both items: 1) "-infBuf" fixes the issue - the patch just adds code to avoid manually setting flag. 2) "unable to acquire first few packets" - yes, that's the case: - if download takes longer then the 25 frames then we skip a bit at each download. - the skips accumulate over time - the streaming server will eventually age out old frames and cause a full segment skip (as detailed in initial email). You can find some public streams here: http://www.addictradio.net/en/labs/ but takes a while to reproduce Let me know if I can help with any logs / if you want me to test out other patches or look into a different area for a fix Ok, so these are audio only HLS streams. That can cause smaller buffers, because audio frames can be shorter than 40ms, and ffplay buffering logic is based on the number of frames and not the duration of them. I will post a series of ffplay patches which will keep track of the total duration of the buffered packets. Could you please test that? I wonder if 1 second buffering time is enough, or for networked input we should use a larger one by default. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] ffplay: ensure that we buffer at least 1 second of content
In order to do that, we keep track of the total duration of packets in a packet
queue.
Signed-off-by: Marton Balint
---
ffplay.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ffplay.c b/ffplay.c
index 9f5b2a4..d32b023 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -117,6 +117,7 @@ typedef struct PacketQueue {
MyAVPacketList *first_pkt, *last_pkt;
int nb_packets;
int size;
+int64_t duration;
int abort_request;
int serial;
SDL_mutex *mutex;
@@ -417,6 +418,7 @@ static int packet_queue_put_private(PacketQueue *q,
AVPacket *pkt)
q->last_pkt = pkt1;
q->nb_packets++;
q->size += pkt1->pkt.size + sizeof(*pkt1);
+q->duration += pkt1->pkt.duration;
/* XXX: should duplicate packet data in DV case */
SDL_CondSignal(q->cond);
return 0;
@@ -478,6 +480,7 @@ static void packet_queue_flush(PacketQueue *q)
q->first_pkt = NULL;
q->nb_packets = 0;
q->size = 0;
+q->duration = 0;
SDL_UnlockMutex(q->mutex);
}
@@ -528,6 +531,7 @@ static int packet_queue_get(PacketQueue *q, AVPacket *pkt,
int block, int *seria
q->last_pkt = NULL;
q->nb_packets--;
q->size -= pkt1->pkt.size + sizeof(*pkt1);
+q->duration -= pkt1->pkt.duration;
*pkt = pkt1->pkt;
if (serial)
*serial = pkt1->serial;
@@ -2800,7 +2804,7 @@ static int stream_has_enough_packets(AVStream *st, int
stream_id, PacketQueue *q
return stream_id < 0 ||
queue->abort_request ||
(st->disposition & AV_DISPOSITION_ATTACHED_PIC) ||
- queue->nb_packets > MIN_FRAMES;
+ queue->nb_packets > MIN_FRAMES && (!queue->duration ||
av_q2d(st->time_base) * queue->duration > 1.0);
}
static int is_realtime(AVFormatContext *s)
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] ffplay: factorize checking if a stream needs additional packets
Signed-off-by: Marton Balint
---
ffplay.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index 11c5091..9f5b2a4 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2796,6 +2796,13 @@ static int decode_interrupt_cb(void *ctx)
return is->abort_request;
}
+static int stream_has_enough_packets(AVStream *st, int stream_id, PacketQueue
*queue) {
+return stream_id < 0 ||
+ queue->abort_request ||
+ (st->disposition & AV_DISPOSITION_ATTACHED_PIC) ||
+ queue->nb_packets > MIN_FRAMES;
+}
+
static int is_realtime(AVFormatContext *s)
{
if( !strcmp(s->iformat->name, "rtp")
@@ -3060,10 +3067,9 @@ static int read_thread(void *arg)
/* if the queue are full, no need to read more */
if (infinite_buffer<1 &&
(is->audioq.size + is->videoq.size + is->subtitleq.size >
MAX_QUEUE_SIZE
-|| ( (is->audioq .nb_packets > MIN_FRAMES || is->audio_stream
< 0 || is->audioq.abort_request)
-&& (is->videoq .nb_packets > MIN_FRAMES || is->video_stream
< 0 || is->videoq.abort_request
-|| (is->video_st->disposition &
AV_DISPOSITION_ATTACHED_PIC))
-&& (is->subtitleq.nb_packets > MIN_FRAMES ||
is->subtitle_stream < 0 || is->subtitleq.abort_request {
+|| (stream_has_enough_packets(is->audio_st, is->audio_stream,
&is->audioq) &&
+stream_has_enough_packets(is->video_st, is->video_stream,
&is->videoq) &&
+stream_has_enough_packets(is->subtitle_st,
is->subtitle_stream, &is->subtitleq {
/* wait 10 ms */
SDL_LockMutex(wait_mutex);
SDL_CondWaitTimeout(is->continue_read_thread, wait_mutex, 10);
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] MAINTAINERS cleanup
Hi the MAINTAINERs file contains a bunch of inaccurate and outdated entries. What should be done about this ? should we remove everyone who was inactive in FFmpeg (aka no commit/author since 2 years) as in git log --first-parent ... ? should we mark everyone above as inactive instead like "(inactive)" shuuld someone send mails to everyone and ask if they stil maintain the code they are listed for ? -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for vp9 in iso-bmff
Kongqun Yang gmail.com> writes: > Implemented according to the draft specification > "VP Codec ISO Media File Format Binding": How likely is it that the draft will be changed? You may require -strict -2 in your patch when writing files to make it more acceptable. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] MAINTAINERS cleanup
On Sat, Jun 11, 2016 at 12:57:13PM +0200, Michael Niedermayer wrote: > Hi > > the MAINTAINERs file contains a bunch of inaccurate and outdated > entries. > > What should be done about this ? > should we remove everyone who was inactive in FFmpeg > (aka no commit/author since 2 years) as in git log --first-parent ... ? > should we mark everyone above as inactive instead like "(inactive)" > > shuuld someone send mails to everyone and ask if they stil maintain > the code they are listed for ? > I'd say at most 30% of the file is still accurate, which means 70% of the file could be dropped. And then we'll see that it's so small the file is mostly irrelevant. Now I'd rather have the file used as a "community profile" to look for qualified people in the various area of the project; or said differently, keep only applications, misc areas, communication, generic parts entries. I feel like this file had for mission to be used as an argument to make sure people are indeed responsible for their code (as in "hey you're the maintainer of X, please review my patch"). Does it work? Did it in the past? -- lément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avdevice/decklink: add support for setting duplex mode
Signed-off-by: Marton Balint
---
configure | 3 ++-
doc/indevs.texi | 4
libavdevice/decklink_common.cpp | 37 +
libavdevice/decklink_common.h | 4
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 10 ++
libavdevice/decklink_dec_c.c| 4
7 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index a220fa1..ec2e5e6 100755
--- a/configure
+++ b/configure
@@ -5618,7 +5618,8 @@ enabled cuvid && { check_lib cuviddec.h
cuvidCreateDecoder -lnvcuvid
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; }
-enabled decklink && { check_header DeckLinkAPI.h || die "ERROR:
DeckLinkAPI.h header not found"; }
+enabled decklink && { { check_header DeckLinkAPI.h || die "ERROR:
DeckLinkAPI.h header not found"; } &&
+ { check_cpp_condition DeckLinkAPIVersion.h
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR: Decklink API
version must be >= 10.6.1."; } }
enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h
header not found"; }
enabled gmp && require2 gmp gmp.h mpz_export -lgmp
enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h
gnutls_global_init
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 3fb852b..479932a 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -251,6 +251,10 @@ To use this option, ffmpeg needs to be compiled with
@code{--enable-libzvbi}.
Defines number of audio channels to capture. Must be @samp{2}, @samp{8} or
@samp{16}.
Defaults to @samp{2}.
+@item duplex_mode
+Sets the decklink device duplex mode. Must be @samp{unset}, @samp{half} or
@samp{full}.
+Defaults to @samp{unset}.
+
@end table
@subsection Examples
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index ac7964c..24d0d09 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -111,6 +111,23 @@ int ff_decklink_set_format(AVFormatContext *avctx,
int i = 1;
HRESULT res;
+if (ctx->duplex_mode) {
+bool duplex_supported = false;
+
+if (ctx->attr->GetFlag(BMDDeckLinkSupportsDuplexModeConfiguration,
&duplex_supported) != S_OK)
+duplex_supported = false;
+
+if (duplex_supported) {
+res = ctx->cfg->SetInt(bmdDeckLinkConfigDuplexMode,
ctx->duplex_mode == 2 ? bmdDuplexModeFull : bmdDuplexModeHalf);
+if (res != S_OK)
+av_log(avctx, AV_LOG_WARNING, "Setting duplex mode failed.\n");
+else
+av_log(avctx, AV_LOG_VERBOSE, "Succesfully set duplex mode to
%s duplex.\n", ctx->duplex_mode == 2 ? "full" : "half");
+} else {
+av_log(avctx, AV_LOG_WARNING, "Unable to set duplex mode, because
it is not supported.\n");
+}
+}
+
if (direction == DIRECTION_IN) {
res = ctx->dli->GetDisplayModeIterator (&itermode);
} else {
@@ -239,3 +256,23 @@ int ff_decklink_list_formats(AVFormatContext *avctx,
decklink_direction_t direct
return 0;
}
+
+int ff_decklink_init_interfaces(AVFormatContext *avctx)
+{
+struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+
+if (ctx->dl->QueryInterface(IID_IDeckLinkConfiguration, (void
**)&ctx->cfg) != S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Could not get configuration interface for
'%s'\n", avctx->filename);
+return AVERROR_EXTERNAL;
+}
+
+if (ctx->dl->QueryInterface(IID_IDeckLinkAttributes, (void **)&ctx->attr)
!= S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Could not get attributes interaface for
'%s'\n", avctx->filename);
+ctx->cfg->Release();
+ctx->cfg = NULL;
+return AVERROR_EXTERNAL;
+}
+
+return 0;
+}
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index dff4fc1..3d8caad 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -44,6 +44,8 @@ struct decklink_ctx {
IDeckLink *dl;
IDeckLinkOutput *dlo;
IDeckLinkInput *dli;
+IDeckLinkConfiguration *cfg;
+IDeckLinkAttributes *attr;
decklink_output_callback *output_callback;
decklink_input_callback *input_callback;
@@ -77,6 +79,7 @@ struct decklink_ctx {
int list_formats;
int64_t teletext_lines;
double preroll;
+int duplex_mode;
int frames_preroll;
int frames_buffer;
@@ -105,5 +108,6 @@ int ff_decklink_set_format(AVFormatContext *avctx, int
width, int height, int tb
int ff_decklink_set_format(AVFormatContext *avctx, deckl
Re: [FFmpeg-devel] [RFC] Bugs and CC
Le tridi 23 prairial, an CCXXIV, Clement Boesch a écrit : > Same here. Me too. Something useful too would be to have the whole commit header in the comment when flagging a regression, instead of just "regression since ". That way, it is easier to notice we are responsible. Of course, this would mean slightly more work to mostly Carl Eugen, this is only a suggestion. 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] [RFC] BSF list API
Le primidi 21 prairial, an CCXXIV, Marton Balint a écrit : > My GSOC student Jan is working on improving the tee muxer, and as a side > project he is also working on converting the tee muxer to the new BSF API. > > I have checked his WIP patches, and it seems to me that developing some API > which we can use for BSF chains would be really useful not only for the tee > muxer, but for a lot of other places (e.g. ffmpeg.c) as well. I wholly agree. I thought I suggested it already. > Instead of adding a totally new API, I suggest to use a "container" > bitstream filter called 'list', which will instantiate the "child" bitstream > filters and pump the packets through them. > > Thanks to the N:M nature of the new BSF api, this should be achievable, and > we can completely hide for the API user if we are using a single bitstream > filter, or a chain (list) of several bitstream filters. I had the same idea, and it is not without merits, but I no longer think it is the best course to go. The main merit of the idea is to keep the API identical, and it is mostly useful for compatibility with the fork. Since this is no longer a primary goal, other considerations must prevail. As I observed benchmarking the null bsf, the overhead of a dummy bsf is not entirely negligible, mostly due to a few mallocs. Better avoid it if possible. Having a dedicated API, and more specifically a dedicated structure type, also makes for cleaner function calls for the functions that manipulate the list. > The mentioned 'list' bitstream filter could have an AVOption string > parameter called list which it can parse on init to create the bitstream > filter chain. The list string would follow the ffmpeg bsf list syntax: > filter1[=opt1=str1/opt2=str2][,filter2] For that, I say no: it must have a proper API. We can have a parsing functions for user-provided strings describing list of filters, but nowadays most filter lists are created by applications or the library, and for that we do not want a round-trip to a string with all the problems that entails (quoting, memory allocation or arbitrary limits), this kind of madness is already present in too many places. The API itself could be only: ret = av_bsf_list_append(list, filter, &ctx); The append functions returns the newly created filter, so we can set options on it if necessary. Then the filters are inited, either by calling av_bsf_init() on each of them or by having av_bsf_list_init_all(), either solutions has merits of its own. Note that this solution can work with a container filter too. I would prefer that list is its own dedicated type, maybe AVBSFList, but if it is an AVBSFContext, av_bsf_list_append() can assume it is a container filter and access its private structure. > The list bitstream filter with and empty list can also work as the null > bitstream filter already discussed on this mailing list. Or the other way around: the null bsf is only useful in order to use the same code path when there is nothing to do. If we replace the singe bsf API with a list API, then we do not need the null bsf at all. One of the benefit I see is that we can design the list API so that it does not cause the overhead I mentioned earlier. For that to work, it needs to take ownership of the AVPacket structure itself, not just its contents, but that does not seem to hard to achieve. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for vp9 in iso-bmff
On 6/10/2016 7:25 PM, Kongqun Yang wrote:
> Implemented according to the draft specification
> "VP Codec ISO Media File Format Binding":
> http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding
>
> Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91
> ---
> libavformat/Makefile | 2 +-
> libavformat/isom.c | 3 +
> libavformat/movenc.c | 15 +
> libavformat/vpx.c| 170
> +++
> libavformat/vpx.h| 33 ++
> 5 files changed, 222 insertions(+), 1 deletion(-)
> create mode 100644 libavformat/vpx.c
> create mode 100644 libavformat/vpx.h
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 6684ead..33d6027 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -276,7 +276,7 @@ OBJS-$(CONFIG_MM_DEMUXER)+= mm.o
> OBJS-$(CONFIG_MMF_DEMUXER) += mmf.o
> OBJS-$(CONFIG_MMF_MUXER) += mmf.o rawenc.o
> OBJS-$(CONFIG_MOV_DEMUXER) += mov.o mov_chan.o replaygain.o
> -OBJS-$(CONFIG_MOV_MUXER) += movenc.o avc.o hevc.o \
> +OBJS-$(CONFIG_MOV_MUXER) += movenc.o avc.o hevc.o vpx.o \
> movenchint.o mov_chan.o rtp.o \
> movenccenc.o rawutils.o
> OBJS-$(CONFIG_MP2_MUXER) += mp3enc.o rawenc.o id3v2enc.o
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index b1757e2..9a65268 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -59,6 +59,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
> { AV_CODEC_ID_AC3 , 0xA5 },
> { AV_CODEC_ID_EAC3, 0xA6 },
> { AV_CODEC_ID_DTS , 0xA9 }, /* mp4ra.org */
> +{ AV_CODEC_ID_VP9 , 0xC0 }, /* non standard, update when there
> is a standard value */
Muxing such files should absolutely require -strict experimental then.
[...]
> diff --git a/libavformat/vpx.c b/libavformat/vpx.c
> new file mode 100644
> index 000..5125187
> --- /dev/null
> +++ b/libavformat/vpx.c
> @@ -0,0 +1,170 @@
> +/*
> + * VPX helper functions for muxers
> + *
> + * Copyright (c) 2016 Google Inc.
> + * Copyright (c) 2016 KongQun Yang (kqy...@google.com)
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "vpx.h"
> +#include "libavutil/pixfmt.h"
> +
> +enum VpxColorSpace
> +{
> +VPX_COLOR_SPACE_UNSPECIFIED = 0,
> +VPX_COLOR_SPACE_BT601 = 1,
> +VPX_COLOR_SPACE_BT709 = 2,
> +VPX_COLOR_SPACE_SMPTE_170 = 3,
> +VPX_COLOR_SPACE_SMPTE_240 = 4,
> +VPX_COLOR_SPACE_BT2020_NCL = 5,
> +VPX_COLOR_SPACE_BT2020_CL = 6,
> +VPX_COLOR_SPACE_RGB = 7,
> +};
> +
> +static int get_vpx_color_space(enum AVColorSpace color_space)
> +{
> +switch (color_space) {
> +case AVCOL_SPC_RGB:
> +return VPX_COLOR_SPACE_RGB;
> +case AVCOL_SPC_BT709:
> +return VPX_COLOR_SPACE_BT709;
> +case AVCOL_SPC_SMPTE170M:
> +return VPX_COLOR_SPACE_SMPTE_170;
> +case AVCOL_SPC_SMPTE240M:
> +return VPX_COLOR_SPACE_SMPTE_240;
> +case AVCOL_SPC_BT2020_NCL:
> +return VPX_COLOR_SPACE_BT2020_NCL;
> +case AVCOL_SPC_BT2020_CL:
> +return VPX_COLOR_SPACE_BT2020_CL;
> +default:
> +return VPX_COLOR_SPACE_UNSPECIFIED;
> +}
> +}
Isn't the above duplicating code or structs from libavcodec? (either the
native vp9 decoder or the libvpx wrapper). If so, maybe it could be shared.
Same probably also goes for most of the stuff below.
> +
> +enum VPX_CHROMA_SUBSAMPLING
> +{
> +VPX_SUBSAMPLING_420_VERTICAL = 0,
> +VPX_SUBSAMPLING_420_COLLOCATED_WITH_LUMA = 1,
> +VPX_SUBSAMPLING_422 = 2,
> +VPX_SUBSAMPLING_444 = 3,
> +};
> +
> +static int get_vpx_chroma_subsampling(enum AVPixelFormat pixel_format,
> + enum AVChromaLocation chroma_location)
> +{
> +switch (pixel_format) {
> +case AV_PIX_FMT_YUV420P:
> +case AV_PIX_FMT_YUV420P10LE:
> +case AV_PIX_FMT_YUV420P10BE:
> +case AV_PIX_FMT_YUV420P12LE:
> +case AV_PIX_FMT_YUV420P12BE:
> +if (chroma_location == AVCHR
Re: [FFmpeg-devel] [RFC] MAINTAINERS cleanup
On Sat, Jun 11, 2016 at 01:55:01PM +0200, Clément Bœsch wrote: > On Sat, Jun 11, 2016 at 12:57:13PM +0200, Michael Niedermayer wrote: > > Hi > > > > the MAINTAINERs file contains a bunch of inaccurate and outdated > > entries. > > > > What should be done about this ? > > should we remove everyone who was inactive in FFmpeg > > (aka no commit/author since 2 years) as in git log --first-parent ... ? > > should we mark everyone above as inactive instead like "(inactive)" > > > > shuuld someone send mails to everyone and ask if they stil maintain > > the code they are listed for ? > > > > I'd say at most 30% of the file is still accurate, which means 70% of the > file could be dropped. And then we'll see that it's so small the file is > mostly irrelevant. > > Now I'd rather have the file used as a "community profile" to look for > qualified people in the various area of the project; or said differently, > keep only applications, misc areas, communication, generic parts entries. > > I feel like this file had for mission to be used as an argument to make > sure people are indeed responsible for their code (as in "hey you're the > maintainer of X, please review my patch"). Does it work? Did it in the > past? The file serves as the foundation of "who has/should have/needs git write access" and who has op on IRC (this works and worked) It serves as a list of arbiters case of disagreement (that wasnt used much at least not litterally) Without a MAINTAINERs file git write access and irc op could become more disputable I do like the unwritten? rule of "if you maintain some code you have the last word about it" "if you maintain some code you have git write access" "if someone disagrees about someone else maintaining then he better volunteers himself to do a better job" Now, if you look at the people who left FFmpeg over the years, i think in many if not most cases it involved prior conflicts with other developers over the area they worked on. so the idea of "if you maintain some code you have the last word about it" is IMO important, this doesnt strictly need a maintainers file of course. But many people work on what is fun for them, and while removing the file or chageing its meaning doesnt directly change that, i think we should be carefull to avoid creating a difference between the people actively working on the code and the ones being in charge about the code in question. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] MAINTAINERS cleanup
On 6/11/16, Michael Niedermayer wrote: > On Sat, Jun 11, 2016 at 01:55:01PM +0200, Clement Boesch wrote: >> On Sat, Jun 11, 2016 at 12:57:13PM +0200, Michael Niedermayer wrote: >> > Hi >> > >> > the MAINTAINERs file contains a bunch of inaccurate and outdated >> > entries. >> > >> > What should be done about this ? >> > should we remove everyone who was inactive in FFmpeg >> > (aka no commit/author since 2 years) as in git log --first-parent ... ? >> > should we mark everyone above as inactive instead like "(inactive)" >> > >> > shuuld someone send mails to everyone and ask if they stil maintain >> > the code they are listed for ? >> > >> >> I'd say at most 30% of the file is still accurate, which means 70% of the >> file could be dropped. And then we'll see that it's so small the file is >> mostly irrelevant. >> >> Now I'd rather have the file used as a "community profile" to look for >> qualified people in the various area of the project; or said differently, >> keep only applications, misc areas, communication, generic parts entries. >> >> I feel like this file had for mission to be used as an argument to make >> sure people are indeed responsible for their code (as in "hey you're the >> maintainer of X, please review my patch"). Does it work? Did it in the >> past? > > The file serves as the foundation of "who has/should have/needs > git write access" and who has op on IRC > (this works and worked) > > It serves as a list of arbiters case of disagreement > (that wasnt used much at least not litterally) > > Without a MAINTAINERs file git write access and irc op could become > more disputable > > I do like the unwritten? rule of > "if you maintain some code you have the last word about it" > "if you maintain some code you have git write access" > "if someone disagrees about someone else maintaining then he better > volunteers himself to do a better job" > > Now, if you look at the people who left FFmpeg over the years, i > think in many if not most cases it involved prior conflicts with other > developers over the area they worked on. > so the idea of > "if you maintain some code you have the last word about it" > is IMO important, this doesnt strictly need a maintainers file of > course. > But many people work on what is fun for them, and while removing the > file or chageing its meaning doesnt directly change that, i think we > should be carefull to avoid creating a difference between the people > actively working on the code and the ones being in charge about the > code in question. > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Dictatorship: All citizens are under surveillance, all their steps and > actions recorded, for the politicians to enforce control. > Democracy: All politicians are under surveillance, all their steps and > actions recorded, for the citizens to enforce control. > If this file is not going to be cleaned up it should be removed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_histogram: shortcuts for histogram options
On 6/11/16, Dave Rice wrote: > This patch adds some shortcuts for the histogram filter's options in a way > that is consistent with the waveform and vectorscope filter. > Dave Rice > > applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_histogram: indent histogram options
On 6/11/16, Dave Rice wrote: > Some indentation after the previous patch. > Dave Rice > applied ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add afade tes
On Sat, Jun 11, 2016 at 12:27:03PM +, Petru Rares Sincraian wrote: > > > Hi there, > > > Today I add a test for afade effect and acrossfade effect. acrossfade uses > afade, so I add in the same patch. I tested the test in x64 and x32 > architectures. > > > Regards, > Petru Rares. > fate/filter-audio.mak | 43 +++ > ref/fate/filter-acrossfade | 502 > > ref/fate/filter-afade-esin | 264 +++ > ref/fate/filter-afade-exp | 264 +++ > ref/fate/filter-afade-hsin | 264 +++ > ref/fate/filter-afade-ihsin | 264 +++ > ref/fate/filter-afade-iqsin | 264 +++ > ref/fate/filter-afade-log | 264 +++ > ref/fate/filter-afade-qsin | 264 +++ > 9 files changed, 2393 insertions(+) > 1b6e5829cd0bdc340c294c8594020cf23a1a1937 0001-fate-add-afade-test.patch > From 8fd5fe245e74ea8ee77e283ca6fc13b140bfa815 Mon Sep 17 00:00:00 2001 > From: Petru Rares Sincraian > Date: Sat, 11 Jun 2016 13:30:09 +0200 > Subject: [PATCH] fate: add afade test works on linux x86-32 and 64 on mingw32 filter-afade-ihsin fails --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/filter-afade-ihsin 2016-06-11 18:50:38.957187300 +0200 +++ tests/data/fate/filter-afade-ihsin 2016-06-11 19:16:22.381219816 +0200 @@ -24,7 +24,7 @@ 0, 18432, 18432, 1024, 4096, 0x968af12f 0, 19456, 19456, 1024, 4096, 0xb9540302 0, 20480, 20480, 1024, 4096, 0x88190846 -0, 21504, 21504, 1024, 4096, 0x47f5fa7f +0, 21504, 21504, 1024, 4096, 0x3907fa7d 0, 22528, 22528, 1024, 4096, 0x09e1e521 0, 23552, 23552, 1024, 4096, 0x92b8f3d5 0, 24576, 24576, 1024, 4096, 0x2b00f559 you can test that with ./configure --cc='i686-w64-mingw32-gcc' --arch=x86 --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --enable-gpl --target_exec=wine if you have wine and the same mingw cross compiler as i do (it might fail differently or not at all with others) its probably easiest to just drop filter-afade-ihsin [...] -- 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] Patch that adds timeline function for eq filter
On Wed, Jun 01, 2016 at 04:55:45AM +, Maxim Petrov wrote:
>
> vf_eq.c |1 +
> 1 file changed, 1 insertion(+)
> 30ab72e9b52283cc69755e0205bd8c2f0c133954
> 0001-Timeline-function-for-the-eq-filter.patch
> From 570b215c110b027badc41d1206b0ff6d4806a98f Mon Sep 17 00:00:00 2001
> From: Ilya87
^^
Is that name intended, instead of your full name ?
> Date: Wed, 1 Jun 2016 07:49:51 +0300
> Subject: [PATCH] Timeline function for the eq filter
>
> ---
> libavfilter/vf_eq.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
> index 0b929f3..5ecdb31 100644
> --- a/libavfilter/vf_eq.c
> +++ b/libavfilter/vf_eq.c
> @@ -385,4 +385,5 @@ AVFilter ff_vf_eq = {
> .query_formats = query_formats,
> .init= initialize,
> .uninit = uninit,
> +.flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
> };
> --
> 2.8.3
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add afade tes
On 6/11/2016 2:30 PM, Michael Niedermayer wrote: > On Sat, Jun 11, 2016 at 12:27:03PM +, Petru Rares Sincraian wrote: >> >> >> Hi there, >> >> >> Today I add a test for afade effect and acrossfade effect. acrossfade uses >> afade, so I add in the same patch. I tested the test in x64 and x32 >> architectures. >> >> >> Regards, >> Petru Rares. > >> fate/filter-audio.mak | 43 +++ >> ref/fate/filter-acrossfade | 502 >> >> ref/fate/filter-afade-esin | 264 +++ >> ref/fate/filter-afade-exp | 264 +++ >> ref/fate/filter-afade-hsin | 264 +++ >> ref/fate/filter-afade-ihsin | 264 +++ >> ref/fate/filter-afade-iqsin | 264 +++ >> ref/fate/filter-afade-log | 264 +++ >> ref/fate/filter-afade-qsin | 264 +++ >> 9 files changed, 2393 insertions(+) >> 1b6e5829cd0bdc340c294c8594020cf23a1a1937 0001-fate-add-afade-test.patch >> From 8fd5fe245e74ea8ee77e283ca6fc13b140bfa815 Mon Sep 17 00:00:00 2001 >> From: Petru Rares Sincraian >> Date: Sat, 11 Jun 2016 13:30:09 +0200 >> Subject: [PATCH] fate: add afade test > > works on linux x86-32 and 64 > > on mingw32 filter-afade-ihsin fails > > > > --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/filter-afade-ihsin > 2016-06-11 18:50:38.957187300 +0200 > +++ tests/data/fate/filter-afade-ihsin 2016-06-11 19:16:22.381219816 +0200 > @@ -24,7 +24,7 @@ > 0, 18432, 18432, 1024, 4096, 0x968af12f > 0, 19456, 19456, 1024, 4096, 0xb9540302 > 0, 20480, 20480, 1024, 4096, 0x88190846 > -0, 21504, 21504, 1024, 4096, 0x47f5fa7f > +0, 21504, 21504, 1024, 4096, 0x3907fa7d > 0, 22528, 22528, 1024, 4096, 0x09e1e521 > 0, 23552, 23552, 1024, 4096, 0x92b8f3d5 > 0, 24576, 24576, 1024, 4096, 0x2b00f559 > > you can test that with > ./configure --cc='i686-w64-mingw32-gcc' --arch=x86 --target-os=mingw32 > --cross-prefix=i686-w64-mingw32- --enable-gpl --target_exec=wine Can't reproduce this running the test natively on Windows. All of them succeed with both x86_64 and i686 builds. What GCC version and what mingw-w64 version are you using? GCC 5.4.0 and a relatively recent mingw-w64 trunk snapshot here. > if you have wine and the same mingw cross compiler as i do > (it might fail differently or not at all with others) > > its probably easiest to just drop filter-afade-ihsin > > > > [...] > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avformat/mux: do not call write_packet with a flush packet if header is not written
Signed-off-by: Marton Balint
---
libavformat/mux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index b1b65a1..f21b4dd 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -823,6 +823,11 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt)
if (!pkt) {
if (s->oformat->flags & AVFMT_ALLOW_FLUSH) {
+if (!s->internal->header_written) {
+ret = s->internal->write_header_ret ?
s->internal->write_header_ret : write_header_internal(s);
+if (ret < 0)
+return ret;
+}
ret = s->oformat->write_packet(s, NULL);
if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
avio_flush(s->pb);
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avformat/mux: call deinit if write_header fails
Docs clearly states that av_write_trailer should only be called if
avformat_write_header was successful, therefore we have to deinit if we return
failure.
Signed-off-by: Marton Balint
---
libavformat/mux.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 91388e3..bef230f 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -485,14 +485,14 @@ int avformat_write_header(AVFormatContext *s,
AVDictionary **options)
if (ret >= 0 && s->pb && s->pb->error < 0)
ret = s->pb->error;
if (ret < 0)
-return ret;
+goto fail;
if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
avio_flush(s->pb);
s->internal->header_written = 1;
}
if ((ret = init_pts(s)) < 0)
-return ret;
+goto fail;
if (s->avoid_negative_ts < 0) {
av_assert2(s->avoid_negative_ts == AVFMT_AVOID_NEG_TS_AUTO);
@@ -503,6 +503,11 @@ int avformat_write_header(AVFormatContext *s, AVDictionary
**options)
}
return 0;
+
+fail:
+if (s->oformat->deinit)
+s->oformat->deinit(s);
+return ret;
}
#define AV_PKT_FLAG_UNCODED_FRAME 0x2000
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avformat/mux: factorize header writing code
Signed-off-by: Marton Balint
---
libavformat/mux.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index bef230f..08ed940 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -473,6 +473,21 @@ static int init_pts(AVFormatContext *s)
return 0;
}
+static int write_header_internal(AVFormatContext *s)
+{
+if (s->oformat->write_header) {
+int ret = s->oformat->write_header(s);
+if (ret >= 0 && s->pb && s->pb->error < 0)
+ret = s->pb->error;
+if (ret < 0)
+return ret;
+if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
+avio_flush(s->pb);
+}
+s->internal->header_written = 1;
+return 0;
+}
+
int avformat_write_header(AVFormatContext *s, AVDictionary **options)
{
int ret = 0;
@@ -480,15 +495,10 @@ int avformat_write_header(AVFormatContext *s,
AVDictionary **options)
if ((ret = init_muxer(s, options)) < 0)
return ret;
-if (s->oformat->write_header && !s->oformat->check_bitstream) {
-ret = s->oformat->write_header(s);
-if (ret >= 0 && s->pb && s->pb->error < 0)
-ret = s->pb->error;
+if (!s->oformat->check_bitstream) {
+ret = write_header_internal(s);
if (ret < 0)
goto fail;
-if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
-avio_flush(s->pb);
-s->internal->header_written = 1;
}
if ((ret = init_pts(s)) < 0)
@@ -702,15 +712,10 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
did_split = av_packet_split_side_data(pkt);
-if (!s->internal->header_written && s->oformat->write_header) {
-ret = s->oformat->write_header(s);
-if (ret >= 0 && s->pb && s->pb->error < 0)
-ret = s->pb->error;
+if (!s->internal->header_written) {
+ret = write_header_internal(s);
if (ret < 0)
goto fail;
-if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
-avio_flush(s->pb);
-s->internal->header_written = 1;
}
if ((pkt->flags & AV_PKT_FLAG_UNCODED_FRAME)) {
@@ -1146,19 +1151,14 @@ int av_write_trailer(AVFormatContext *s)
goto fail;
}
-if (!s->internal->header_written && s->oformat->write_header) {
-ret = s->oformat->write_header(s);
-if (ret >= 0 && s->pb && s->pb->error < 0)
-ret = s->pb->error;
+if (!s->internal->header_written) {
+ret = write_header_internal(s);
if (ret < 0)
goto fail;
-if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
-avio_flush(s->pb);
-s->internal->header_written = 1;
}
fail:
-if ((s->internal->header_written || !s->oformat->write_header) &&
s->oformat->write_trailer)
+if (s->internal->header_written && s->oformat->write_trailer)
if (ret >= 0) {
ret = s->oformat->write_trailer(s);
} else {
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avformat/mux: do not call write_header multiple times if it fails the first time
Signed-off-by: Marton Balint
---
libavformat/internal.h | 1 +
libavformat/mux.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 40ba089..b6c2020 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -124,6 +124,7 @@ struct AVFormatInternal {
* Whether or not a header has already been written
*/
int header_written;
+int write_header_ret;
};
struct AVStreamInternal {
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 08ed940..b1b65a1 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -479,6 +479,7 @@ static int write_header_internal(AVFormatContext *s)
int ret = s->oformat->write_header(s);
if (ret >= 0 && s->pb && s->pb->error < 0)
ret = s->pb->error;
+s->internal->write_header_ret = ret;
if (ret < 0)
return ret;
if (s->flush_packets && s->pb && s->pb->error >= 0 && s->flags &
AVFMT_FLAG_FLUSH_PACKETS)
@@ -713,7 +714,7 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
did_split = av_packet_split_side_data(pkt);
if (!s->internal->header_written) {
-ret = write_header_internal(s);
+ret = s->internal->write_header_ret ? s->internal->write_header_ret :
write_header_internal(s);
if (ret < 0)
goto fail;
}
@@ -1152,7 +1153,7 @@ int av_write_trailer(AVFormatContext *s)
}
if (!s->internal->header_written) {
-ret = write_header_internal(s);
+ret = s->internal->write_header_ret ? s->internal->write_header_ret :
write_header_internal(s);
if (ret < 0)
goto fail;
}
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: relax opt_order limit
Hi, > Am 09.06.2016 um 03:33 schrieb Michael Niedermayer : > > Fixes: Ticket5297 > > Needs review by maintainer / author to check that this is ok and sufficient > --- > libavcodec/alsdec.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) I'll have a look but I need some more days to do so. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: check if source_package is NULL
On Tue, 31 May 2016, Marton Balint wrote:
Fixes ticket #5554.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f8cf922..9bf676c 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1914,7 +1914,7 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
break;
}
}
-if (!source_track || !component)
+if (!source_track || !component || !source_package)
continue;
if (!(source_track->sequence = mxf_resolve_strong_ref(mxf,
&source_track->sequence_ref, Sequence))) {
Ping.
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add afade tes
On Sat, Jun 11, 2016 at 03:32:40PM -0300, James Almer wrote: > On 6/11/2016 2:30 PM, Michael Niedermayer wrote: > > On Sat, Jun 11, 2016 at 12:27:03PM +, Petru Rares Sincraian wrote: > >> > >> > >> Hi there, > >> > >> > >> Today I add a test for afade effect and acrossfade effect. acrossfade uses > >> afade, so I add in the same patch. I tested the test in x64 and x32 > >> architectures. > >> > >> > >> Regards, > >> Petru Rares. > > > >> fate/filter-audio.mak | 43 +++ > >> ref/fate/filter-acrossfade | 502 > >> > >> ref/fate/filter-afade-esin | 264 +++ > >> ref/fate/filter-afade-exp | 264 +++ > >> ref/fate/filter-afade-hsin | 264 +++ > >> ref/fate/filter-afade-ihsin | 264 +++ > >> ref/fate/filter-afade-iqsin | 264 +++ > >> ref/fate/filter-afade-log | 264 +++ > >> ref/fate/filter-afade-qsin | 264 +++ > >> 9 files changed, 2393 insertions(+) > >> 1b6e5829cd0bdc340c294c8594020cf23a1a1937 0001-fate-add-afade-test.patch > >> From 8fd5fe245e74ea8ee77e283ca6fc13b140bfa815 Mon Sep 17 00:00:00 2001 > >> From: Petru Rares Sincraian > >> Date: Sat, 11 Jun 2016 13:30:09 +0200 > >> Subject: [PATCH] fate: add afade test > > > > works on linux x86-32 and 64 > > > > on mingw32 filter-afade-ihsin fails > > > > > > > > --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/filter-afade-ihsin > > 2016-06-11 18:50:38.957187300 +0200 > > +++ tests/data/fate/filter-afade-ihsin 2016-06-11 19:16:22.381219816 +0200 > > @@ -24,7 +24,7 @@ > > 0, 18432, 18432, 1024, 4096, 0x968af12f > > 0, 19456, 19456, 1024, 4096, 0xb9540302 > > 0, 20480, 20480, 1024, 4096, 0x88190846 > > -0, 21504, 21504, 1024, 4096, 0x47f5fa7f > > +0, 21504, 21504, 1024, 4096, 0x3907fa7d > > 0, 22528, 22528, 1024, 4096, 0x09e1e521 > > 0, 23552, 23552, 1024, 4096, 0x92b8f3d5 > > 0, 24576, 24576, 1024, 4096, 0x2b00f559 > > > > you can test that with > > ./configure --cc='i686-w64-mingw32-gcc' --arch=x86 --target-os=mingw32 > > --cross-prefix=i686-w64-mingw32- --enable-gpl --target_exec=wine > > Can't reproduce this running the test natively on Windows. All > of them succeed with both x86_64 and i686 builds. > > What GCC version and what mingw-w64 version are you using? > GCC 5.4.0 and a relatively recent mingw-w64 trunk snapshot > here. i686-w64-mingw32-gcc (GCC) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ii mingw-w64-i686-dev 3.0~svn5131-1 Development files for MinGW-w64 targeting Win32 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Handle tmp on Android as on Win32
Hi!
Attached patch fixes ticket #5620 for me (the OP did not provide a testcase).
Carl Eugen
From 4c9d1c6f9a8f166703dc0333b53f5dba8dc5b414 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 11 Jun 2016 22:41:18 +0200
Subject: [PATCH] lavu/file_open: Use current directory for temporary files
also on Android.
Fixes ticket #5620.
---
libavutil/file_open.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/file_open.c b/libavutil/file_open.c
index 6e58cc1..34070d9 100644
--- a/libavutil/file_open.c
+++ b/libavutil/file_open.c
@@ -134,7 +134,7 @@ int avpriv_tempfile(const char *prefix, char **filename,
int log_offset, void *l
#else
snprintf(*filename, len, "/tmp/%sXX", prefix);
fd = mkstemp(*filename);
-#ifdef _WIN32
+#if defined(_WIN32) || defined (__ANDROID__)
if (fd < 0) {
snprintf(*filename, len, "./%sXX", prefix);
fd = mkstemp(*filename);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Handle tmp on Android as on Win32
On Sat, Jun 11, 2016 at 10:44:18PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #5620 for me (the OP did not provide a testcase). > > Carl Eugen > file_open.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > b1aa303b23de1be50c57a8813ea8a16095fc93b1 > 0001-lavu-file_open-Use-current-directory-for-temporary-f.patch > From 4c9d1c6f9a8f166703dc0333b53f5dba8dc5b414 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Sat, 11 Jun 2016 22:41:18 +0200 > Subject: [PATCH] lavu/file_open: Use current directory for temporary files > also on Android. > > Fixes ticket #5620. > --- should be ok unless someone has a better solution [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/mux: do not call write_header multiple times if it fails the first time
On Sat, Jun 11, 2016 at 08:33:42PM +0200, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavformat/internal.h | 1 +
> libavformat/mux.c | 5 +++--
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 40ba089..b6c2020 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -124,6 +124,7 @@ struct AVFormatInternal {
> * Whether or not a header has already been written
> */
> int header_written;
> +int write_header_ret;
> };
>
> struct AVStreamInternal {
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index 08ed940..b1b65a1 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -479,6 +479,7 @@ static int write_header_internal(AVFormatContext *s)
> int ret = s->oformat->write_header(s);
> if (ret >= 0 && s->pb && s->pb->error < 0)
> ret = s->pb->error;
> +s->internal->write_header_ret = ret;
would
header_written = ret
be simpler ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avformat/mux: factorize header writing code
On Sat, Jun 11, 2016 at 08:33:41PM +0200, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavformat/mux.c | 44 ++-- > 1 file changed, 22 insertions(+), 22 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- 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]Handle tmp on Android as on Win32
Michael Niedermayer niedermayer.cc> writes: > > Fixes ticket #5620. > > --- > > should be ok Patch applied. > unless someone has a better solution I'll be happy to revert in that case... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for vp9 in iso-bmff
Hi,
On Sat, Jun 11, 2016 at 11:48 AM, James Almer wrote:
> > +enum VpxColorSpace
> > +{
> > +VPX_COLOR_SPACE_UNSPECIFIED = 0,
> > +VPX_COLOR_SPACE_BT601 = 1,
> > +VPX_COLOR_SPACE_BT709 = 2,
> > +VPX_COLOR_SPACE_SMPTE_170 = 3,
> > +VPX_COLOR_SPACE_SMPTE_240 = 4,
> > +VPX_COLOR_SPACE_BT2020_NCL = 5,
> > +VPX_COLOR_SPACE_BT2020_CL = 6,
> > +VPX_COLOR_SPACE_RGB = 7,
> > +};
> > +
> > +static int get_vpx_color_space(enum AVColorSpace color_space)
> > +{
> > +switch (color_space) {
> > +case AVCOL_SPC_RGB:
> > +return VPX_COLOR_SPACE_RGB;
> > +case AVCOL_SPC_BT709:
> > +return VPX_COLOR_SPACE_BT709;
> > +case AVCOL_SPC_SMPTE170M:
> > +return VPX_COLOR_SPACE_SMPTE_170;
> > +case AVCOL_SPC_SMPTE240M:
> > +return VPX_COLOR_SPACE_SMPTE_240;
> > +case AVCOL_SPC_BT2020_NCL:
> > +return VPX_COLOR_SPACE_BT2020_NCL;
> > +case AVCOL_SPC_BT2020_CL:
> > +return VPX_COLOR_SPACE_BT2020_CL;
> > +default:
> > +return VPX_COLOR_SPACE_UNSPECIFIED;
> > +}
> > +}
>
> Isn't the above duplicating code or structs from libavcodec? (either the
> native vp9 decoder or the libvpx wrapper). If so, maybe it could be shared.
>
> Same probably also goes for most of the stuff below.
>
I don't think so.
> > +static int get_bit_depth(enum AVPixelFormat pixel_format)
> > +{
> > + switch (pixel_format) {
> > + case AV_PIX_FMT_YUV420P:
> > + case AV_PIX_FMT_YUV422P:
> > + case AV_PIX_FMT_YUV444P:
> > + return 8;
> > + case AV_PIX_FMT_YUV420P10LE:
> > + case AV_PIX_FMT_YUV420P10BE:
> > + case AV_PIX_FMT_YUV422P10LE:
> > + case AV_PIX_FMT_YUV422P10BE:
> > + case AV_PIX_FMT_YUV444P10LE:
> > + case AV_PIX_FMT_YUV444P10BE:
> > + return 10;
> > + case AV_PIX_FMT_YUV420P12LE:
> > + case AV_PIX_FMT_YUV420P12BE:
> > + case AV_PIX_FMT_YUV422P12LE:
> > + case AV_PIX_FMT_YUV422P12BE:
> > + case AV_PIX_FMT_YUV444P12LE:
> > + case AV_PIX_FMT_YUV444P12BE:
> > + return 12;
> > + default:
> > + // Defaults to 8.
> > + av_log(NULL, AV_LOG_WARNING,
> > + "Unspecified or unrecognized bit depth. Assuming 8.");
> > + return 8;
> > + }
> > +}
>
> I'm fairly sure this is duplicating libavutil functionality. A function
> returning bit depth based on a AVPixelFormat argument sounds generic
> enough that plenty modules would use.
av_pix_fmt_desc_get(pixel_format)->comp[0].depth
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for vp9 in iso-bmff
Hi, On Fri, Jun 10, 2016 at 6:25 PM, Kongqun Yang wrote: > Implemented according to the draft specification > "VP Codec ISO Media File Format Binding": > > http://www.webmproject.org/vp9/#draft-vp-codec-iso-media-file-format-binding > > Change-Id: Iaa7ddf5524b17e8d79cd1923b26f096d6e91 > --- > libavformat/Makefile | 2 +- > libavformat/isom.c | 3 + > libavformat/movenc.c | 15 + > libavformat/vpx.c| 170 > +++ > libavformat/vpx.h| 33 ++ I don't particularly love the name "vpx.c" and "vpx.h", because they will make people think this is related to libvpx instead of just generic vp-something helpers. To prevent that, let's call it vpn. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Handle tmp on Android as on Win32
On Sat, Jun 11, 2016 at 11:21 PM, Carl Eugen Hoyos wrote: > Michael Niedermayer niedermayer.cc> writes: > >> > Fixes ticket #5620. >> > --- >> >> should be ok > > Patch applied. > >> unless someone has a better solution > > I'll be happy to revert in that case... > Maybe you should leave the patch at least a couple hours on the ML for people to actually be able to look at it, instead of asking to revert later. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] BSF list API
On Sat, 11 Jun 2016, Nicolas George wrote: Instead of adding a totally new API, I suggest to use a "container" bitstream filter called 'list', which will instantiate the "child" bitstream filters and pump the packets through them. Thanks to the N:M nature of the new BSF api, this should be achievable, and we can completely hide for the API user if we are using a single bitstream filter, or a chain (list) of several bitstream filters. I had the same idea, and it is not without merits, but I no longer think it is the best course to go. The main merit of the idea is to keep the API identical, and it is mostly useful for compatibility with the fork. Since this is no longer a primary goal, other considerations must prevail. As I observed benchmarking the null bsf, the overhead of a dummy bsf is not entirely negligible, mostly due to a few mallocs. Better avoid it if possible. Maybe I am missing something, but as far as I see the alloc is due to the alloc in ff_bsf_get_packet. We could create a similar function ff_bsf_get_packet2(AVBSFContext *ctx, AVPacket *pkt) which does not allocate a packet but simply moves the ref to pkt. Then this can be called with the output packet pointer, so no allocation will be requried. And this function can be used for performance sensitive places instead of the original. The mentioned 'list' bitstream filter could have an AVOption string parameter called list which it can parse on init to create the bitstream filter chain. The list string would follow the ffmpeg bsf list syntax: filter1[=opt1=str1/opt2=str2][,filter2] For that, I say no: it must have a proper API. We can have a parsing functions for user-provided strings describing list of filters, but nowadays most filter lists are created by applications or the library, and for that we do not want a round-trip to a string with all the problems that entails (quoting, memory allocation or arbitrary limits), this kind of madness is already present in too many places. The API itself could be only: ret = av_bsf_list_append(list, filter, &ctx); The append functions returns the newly created filter, so we can set options on it if necessary. Then the filters are inited, either by calling av_bsf_init() on each of them or by having av_bsf_list_init_all(), either solutions has merits of its own. Note that this solution can work with a container filter too. I would prefer that list is its own dedicated type, maybe AVBSFList, but if it is an AVBSFContext, av_bsf_list_append() can assume it is a container filter and access its private structure. I think we need to support both ways to configure the bsf list. What the tee muxer, or ffmpeg.c would use, is the text based configuration, therefore it's worth adding the capability of parsing such lists. So what we need, on top of what I proposed, is an additional API what you proposed (av_bsf_list_append), and which can be used to add filters to the list, after we allocated the list filter, but before we initialized it. This way the user can decide which configuration method - API based or text based - he will use. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/mux: do not call write_header multiple times if it fails the first time
On Sat, 11 Jun 2016, Michael Niedermayer wrote:
On Sat, Jun 11, 2016 at 08:33:42PM +0200, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavformat/internal.h | 1 +
libavformat/mux.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 40ba089..b6c2020 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -124,6 +124,7 @@ struct AVFormatInternal {
* Whether or not a header has already been written
*/
int header_written;
+int write_header_ret;
};
struct AVStreamInternal {
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 08ed940..b1b65a1 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -479,6 +479,7 @@ static int write_header_internal(AVFormatContext *s)
int ret = s->oformat->write_header(s);
if (ret >= 0 && s->pb && s->pb->error < 0)
ret = s->pb->error;
+s->internal->write_header_ret = ret;
would
header_written = ret
be simpler ?
I can change it, but I found it a little less readable.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Handle tmp on Android as on Win32
Hendrik Leppkes gmail.com> writes: [...] Sorry, I am not sure I understood: Do you want me to revert? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Handle tmp on Android as on Win32
On Sat, Jun 11, 2016 at 11:54 PM, Carl Eugen Hoyos wrote: > Hendrik Leppkes gmail.com> writes: > > [...] > > Sorry, I am not sure I understood: > Do you want me to revert? No, I want you to wait more then 30 minutes before pushing a patch in the future, especially if a comment asks for further thoughts. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add afade tes
On 6/11/2016 5:40 PM, Michael Niedermayer wrote: > On Sat, Jun 11, 2016 at 03:32:40PM -0300, James Almer wrote: >> On 6/11/2016 2:30 PM, Michael Niedermayer wrote: >>> On Sat, Jun 11, 2016 at 12:27:03PM +, Petru Rares Sincraian wrote: Hi there, Today I add a test for afade effect and acrossfade effect. acrossfade uses afade, so I add in the same patch. I tested the test in x64 and x32 architectures. Regards, Petru Rares. >>> fate/filter-audio.mak | 43 +++ ref/fate/filter-acrossfade | 502 ref/fate/filter-afade-esin | 264 +++ ref/fate/filter-afade-exp | 264 +++ ref/fate/filter-afade-hsin | 264 +++ ref/fate/filter-afade-ihsin | 264 +++ ref/fate/filter-afade-iqsin | 264 +++ ref/fate/filter-afade-log | 264 +++ ref/fate/filter-afade-qsin | 264 +++ 9 files changed, 2393 insertions(+) 1b6e5829cd0bdc340c294c8594020cf23a1a1937 0001-fate-add-afade-test.patch From 8fd5fe245e74ea8ee77e283ca6fc13b140bfa815 Mon Sep 17 00:00:00 2001 From: Petru Rares Sincraian Date: Sat, 11 Jun 2016 13:30:09 +0200 Subject: [PATCH] fate: add afade test >>> >>> works on linux x86-32 and 64 >>> >>> on mingw32 filter-afade-ihsin fails >>> >>> >>> >>> --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/filter-afade-ihsin >>> 2016-06-11 18:50:38.957187300 +0200 >>> +++ tests/data/fate/filter-afade-ihsin 2016-06-11 19:16:22.381219816 +0200 >>> @@ -24,7 +24,7 @@ >>> 0, 18432, 18432, 1024, 4096, 0x968af12f >>> 0, 19456, 19456, 1024, 4096, 0xb9540302 >>> 0, 20480, 20480, 1024, 4096, 0x88190846 >>> -0, 21504, 21504, 1024, 4096, 0x47f5fa7f >>> +0, 21504, 21504, 1024, 4096, 0x3907fa7d >>> 0, 22528, 22528, 1024, 4096, 0x09e1e521 >>> 0, 23552, 23552, 1024, 4096, 0x92b8f3d5 >>> 0, 24576, 24576, 1024, 4096, 0x2b00f559 >>> >>> you can test that with >>> ./configure --cc='i686-w64-mingw32-gcc' --arch=x86 --target-os=mingw32 >>> --cross-prefix=i686-w64-mingw32- --enable-gpl --target_exec=wine >> >> Can't reproduce this running the test natively on Windows. All >> of them succeed with both x86_64 and i686 builds. >> >> What GCC version and what mingw-w64 version are you using? >> GCC 5.4.0 and a relatively recent mingw-w64 trunk snapshot >> here. > > i686-w64-mingw32-gcc (GCC) 4.6.3 > Copyright (C) 2011 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > ii mingw-w64-i686-dev > 3.0~svn5131-1 > Development files for MinGW-w64 targeting Win32 Both are pretty old. Latest mingw-w64 version is 4.0 and 5.0 already has a release candidate. Wouldn't find it odd if afade is being miscompiled. In any case the test could be removed now, or maybe committed then removed after a day or two to see if other fate clients also complain about it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add afade tes
On Sat, Jun 11, 2016 at 07:28:56PM -0300, James Almer wrote: > On 6/11/2016 5:40 PM, Michael Niedermayer wrote: > > On Sat, Jun 11, 2016 at 03:32:40PM -0300, James Almer wrote: > >> On 6/11/2016 2:30 PM, Michael Niedermayer wrote: > >>> On Sat, Jun 11, 2016 at 12:27:03PM +, Petru Rares Sincraian wrote: > > > Hi there, > > > Today I add a test for afade effect and acrossfade effect. acrossfade > uses afade, so I add in the same patch. I tested the test in x64 and x32 > architectures. > > > Regards, > Petru Rares. > >>> > fate/filter-audio.mak | 43 +++ > ref/fate/filter-acrossfade | 502 > > ref/fate/filter-afade-esin | 264 +++ > ref/fate/filter-afade-exp | 264 +++ > ref/fate/filter-afade-hsin | 264 +++ > ref/fate/filter-afade-ihsin | 264 +++ > ref/fate/filter-afade-iqsin | 264 +++ > ref/fate/filter-afade-log | 264 +++ > ref/fate/filter-afade-qsin | 264 +++ > 9 files changed, 2393 insertions(+) > 1b6e5829cd0bdc340c294c8594020cf23a1a1937 0001-fate-add-afade-test.patch > From 8fd5fe245e74ea8ee77e283ca6fc13b140bfa815 Mon Sep 17 00:00:00 2001 > From: Petru Rares Sincraian > Date: Sat, 11 Jun 2016 13:30:09 +0200 > Subject: [PATCH] fate: add afade test > >>> > >>> works on linux x86-32 and 64 > >>> > >>> on mingw32 filter-afade-ihsin fails > >>> > >>> > >>> > >>> --- /home/michael/ffmpeg-git/ffmpeg/tests/ref/fate/filter-afade-ihsin > >>> 2016-06-11 18:50:38.957187300 +0200 > >>> +++ tests/data/fate/filter-afade-ihsin 2016-06-11 19:16:22.381219816 > >>> +0200 > >>> @@ -24,7 +24,7 @@ > >>> 0, 18432, 18432, 1024, 4096, 0x968af12f > >>> 0, 19456, 19456, 1024, 4096, 0xb9540302 > >>> 0, 20480, 20480, 1024, 4096, 0x88190846 > >>> -0, 21504, 21504, 1024, 4096, 0x47f5fa7f > >>> +0, 21504, 21504, 1024, 4096, 0x3907fa7d > >>> 0, 22528, 22528, 1024, 4096, 0x09e1e521 > >>> 0, 23552, 23552, 1024, 4096, 0x92b8f3d5 > >>> 0, 24576, 24576, 1024, 4096, 0x2b00f559 > >>> > >>> you can test that with > >>> ./configure --cc='i686-w64-mingw32-gcc' --arch=x86 --target-os=mingw32 > >>> --cross-prefix=i686-w64-mingw32- --enable-gpl --target_exec=wine > >> > >> Can't reproduce this running the test natively on Windows. All > >> of them succeed with both x86_64 and i686 builds. > >> > >> What GCC version and what mingw-w64 version are you using? > >> GCC 5.4.0 and a relatively recent mingw-w64 trunk snapshot > >> here. > > > > i686-w64-mingw32-gcc (GCC) 4.6.3 > > Copyright (C) 2011 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > ii mingw-w64-i686-dev > > 3.0~svn5131-1 > > Development files for MinGW-w64 targeting Win32 > > Both are pretty old. Latest mingw-w64 version is 4.0 and 5.0 > already has a release candidate. Wouldn't find it odd if afade > is being miscompiled. afade uses floats, it doesnt need to be miscompiled to fail the test [...] -- 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
[FFmpeg-devel] [PATCH] [RFC] libavformat/mpegts: Prevent wrapping of PTS & DTS
Presently the mpegts demuxer passes the timestamps from received packets
directly to the output AVPackets. 2^33 / 9
seconds is about 26.5 hours at which point applications start having a fit, and
that's assuming timestamps begin at time 0.
So here's a first revision of a patch to fix that issue.
Improvements possible:
* In its current form intended for continuous sources like over-the-air
receivers and multicast sources. When used on
files there will be problems with seeking.
* Constants such as 2^33 could be turned into macros for readability
>From d06a3bd39fc4f01b9ce6132d80634dd31be7b1aa Mon Sep 17 00:00:00 2001
From: DHE
Date: Mon, 30 May 2016 18:31:43 -0400
Subject: [PATCH] libavformat/mpegts: Prevent wrapping of PTS & DTS
---
libavformat/mpegts.c | 56
1 file changed, 48 insertions(+), 8 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 7d78c41..a4d6bce 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -237,6 +237,10 @@ typedef struct PESContext {
int extended_stream_id;
uint8_t stream_id;
int64_t pts, dts;
+/* for makings pts/dts consistent on long-running feeds */
+int64_t last_dts;
+unsigned int dts_wraps;
+
int64_t ts_packet_pos; /**< position of first TS packet of this PES packet */
uint8_t header[MAX_PES_HEADER_SIZE];
AVBufferRef *buffer;
@@ -341,6 +345,39 @@ static void set_pcr_pid(AVFormatContext *s, unsigned int programid, unsigned int
}
}
+static void fix_pts_dts(PESContext *pes) {
+int64_t currdts;
+
+if (pes->last_dts == AV_NOPTS_VALUE) {
+pes->last_dts = pes->dts;
+return;
+}
+
+// calculate the value we use for measurements against the last good value
+currdts = pes->dts + (1ULL << 33) * pes->dts_wraps;
+
+if (currdts < pes->last_dts) {
+/* While wrapping backwards should never happen unless we overflow, bad
+ * input does happen. Don't wrap if the reverse in timestamps is small.
+ * I have selected 9 (1 second) semi-arbitrarily.
+ */
+if ((pes->last_dts - currdts) < 9) {
+pes->last_dts = currdts;
+return;
+}
+currdts += 1ULL << 33;
+pes->dts_wraps++;
+av_log(pes->ts->stream, AV_LOG_INFO, "Stream timestamps wrapping\n");
+}
+
+pes->last_dts = pes->dts = currdts;
+
+// Now fix the pts in the much the same way. It is always true that dts <= pts
+pes->pts += (1ULL << 33) * pes->dts_wraps;
+while (pes->pts < pes->dts)
+pes->pts += 1ULL << 33;
+}
+
/**
* @brief discard_pid() decides if the pid is to be discarded according
* to caller's programs selection
@@ -1136,6 +1173,7 @@ skip:
pes->dts = ff_parse_pes_pts(r);
r += 5;
}
+fix_pts_dts(pes);
pes->extended_stream_id = -1;
if (flags & 0x01) { /* PES extension */
pes_ext = *r++;
@@ -1268,14 +1306,16 @@ static PESContext *add_pes_stream(MpegTSContext *ts, int pid, int pcr_pid)
pes = av_mallocz(sizeof(PESContext));
if (!pes)
return 0;
-pes->ts = ts;
-pes->stream = ts->stream;
-pes->pid = pid;
-pes->pcr_pid = pcr_pid;
-pes->state = MPEGTS_SKIP;
-pes->pts = AV_NOPTS_VALUE;
-pes->dts = AV_NOPTS_VALUE;
-tss = mpegts_open_pes_filter(ts, pid, mpegts_push_data, pes);
+pes->ts= ts;
+pes->stream= ts->stream;
+pes->pid = pid;
+pes->pcr_pid = pcr_pid;
+pes->state = MPEGTS_SKIP;
+pes->pts = AV_NOPTS_VALUE;
+pes->dts = AV_NOPTS_VALUE;
+pes->last_dts = AV_NOPTS_VALUE;
+pes->dts_wraps = 0;
+tss= mpegts_open_pes_filter(ts, pid, mpegts_push_data, pes);
if (!tss) {
av_free(pes);
return 0;
--
1.8.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libutvideo support
On 2/14/16, James Almer wrote: > On 2/14/2016 12:20 PM, Carl Eugen Hoyos wrote: >> James Almer gmail.com> writes: >> >>> How do you plan to get around the fact the only working >>> version of this library is an obscure outdated fork that >>> doesn't even compile on most OSes >> >> I am sorry, I did not realize this: >> On which system does it not compile? >> >> Carl Eugen > > Derek mentioned some forks don't build on linux, and Paul > mentioned other crashes. I'm still for removing this. I added 10-bit support to native decoder. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC] libavformat/mpegts: Prevent wrapping of PTS & DTS
On Sat, 11 Jun 2016, DeHackEd wrote: Presently the mpegts demuxer passes the timestamps from received packets directly to the output AVPackets. 2^33 / 9 seconds is about 26.5 hours at which point applications start having a fit, and that's assuming timestamps begin at time 0. So here's a first revision of a patch to fix that issue. Improvements possible: * In its current form intended for continuous sources like over-the-air receivers and multicast sources. When used on files there will be problems with seeking. * Constants such as 2^33 could be turned into macros for readability I think there is already an infrastructure for handling PTS wraparound when decoding, check AVStream->pts_wrap_behaviour. Or is this something else? Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC] libavformat/mpegts: Prevent wrapping of PTS & DTS
On 06/11/2016 08:19 PM, Marton Balint wrote: > > On Sat, 11 Jun 2016, DeHackEd wrote: > >> Presently the mpegts demuxer passes the timestamps from received packets >> directly to the output AVPackets. 2^33 / 9 >> seconds is about 26.5 hours at which point applications start having a fit, >> and that's assuming timestamps begin at >> time 0. >> >> So here's a first revision of a patch to fix that issue. >> >> Improvements possible: >> * In its current form intended for continuous sources like over-the-air >> receivers and multicast sources. When used on >> files there will be problems with seeking. >> * Constants such as 2^33 could be turned into macros for readability >> > > I think there is already an infrastructure for handling PTS wraparound when > decoding, check > AVStream->pts_wrap_behaviour. Or is this something else? The behaviour here is that when the DTS is less than its original value, it will be incremented by the wrap point -- 2^33 in this case. But that's all it does. If the timestamp comes back around to its original value, the effect stops and you get non-monotonic DTS values. In the mpegts case this means that regardless of the starting point of the timestamps you will get 26.5 hours before it breaks. > > Thanks, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swresample: add exact_rational option
give high quality resampling
as good as with linear_interp=on
as fast as without linear_interp=on
tested visually with ffplay
ffplay -f lavfi "aevalsrc='sin(1*t*t)', aresample=osr=48000,
showcqt=gamma=5"
ffplay -f lavfi "aevalsrc='sin(1*t*t)',
aresample=osr=48000:linear_interp=on, showcqt=gamma=5"
ffplay -f lavfi "aevalsrc='sin(1*t*t)',
aresample=osr=48000:exact_rational=on, showcqt=gamma=5"
slightly speed improvement
for fair comparison with -cpuflags 0
audio.wav is ~ 1 hour 44100 stereo 16bit wav file
ffmpeg -i audio.wav -af aresample=osr=48000 -f null -
old new
real13.498s 13.121s
user13.364s 12.987s
sys 0.131s 0.129s
linear_interp=on
old new
real23.035s 23.050s
user22.907s 22.917s
sys 0.119s 0.125s
exact_rational=on
real12.418s
user12.298s
sys 0.114s
possibility to decrease memory usage if soft compensation is ignored
patch attached
thank's
From d5625a6904fb28eef5ecc2f3b52501ca28610795 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz
Date: Sun, 12 Jun 2016 05:19:20 +0700
Subject: [PATCH] swresample: add exact_rational option
give high quality resampling
as good as with linear_interp=on
as fast as without linear_interp=on
tested visually with ffplay
ffplay -f lavfi "aevalsrc='sin(1*t*t)', aresample=osr=48000, showcqt=gamma=5"
ffplay -f lavfi "aevalsrc='sin(1*t*t)', aresample=osr=48000:linear_interp=on, showcqt=gamma=5"
ffplay -f lavfi "aevalsrc='sin(1*t*t)', aresample=osr=48000:exact_rational=on, showcqt=gamma=5"
slightly speed improvement
for fair comparison with -cpuflags 0
audio.wav is ~ 1 hour 44100 stereo 16bit wav file
ffmpeg -i audio.wav -af aresample=osr=48000 -f null -
old new
real13.498s 13.121s
user13.364s 12.987s
sys 0.131s 0.129s
linear_interp=on
old new
real23.035s 23.050s
user22.907s 22.917s
sys 0.119s 0.125s
exact_rational=on
real12.418s
user12.298s
sys 0.114s
possibility to decrease memory usage if soft compensation is ignored
Signed-off-by: Muhammad Faiz
---
libswresample/arm/resample_init.c | 15 ++
libswresample/options.c | 1 +
libswresample/resample.c| 41 +++--
libswresample/resample.h| 6 --
libswresample/resample_template.c | 30 +++
libswresample/soxr_resample.c | 2 +-
libswresample/swresample.c | 2 +-
libswresample/swresample_internal.h | 3 ++-
libswresample/version.h | 4 ++--
libswresample/x86/resample_init.c | 4
10 files changed, 78 insertions(+), 30 deletions(-)
diff --git a/libswresample/arm/resample_init.c b/libswresample/arm/resample_init.c
index 797c530..003fafd 100644
--- a/libswresample/arm/resample_init.c
+++ b/libswresample/arm/resample_init.c
@@ -44,11 +44,15 @@ static int ff_resample_common_##TYPE##_neon(ResampleContext *c, void *dest, cons
int dst_index;\
int index= c->index; \
int frac= c->frac;\
-int sample_index = index >> c->phase_shift; \
+int sample_index = 0; \
int x4_aligned_filter_length = c->filter_length & ~3; \
int x8_aligned_filter_length = c->filter_length & ~7; \
\
-index &= c->phase_mask; \
+while (index >= c->phase_count) { \
+sample_index++; \
+index -= c->phase_count; \
+} \
+ \
for (dst_index = 0; dst_index < n; dst_index++) { \
FELEM *filter = ((FELEM *) c->filter_bank) + c->filter_alloc * index; \
\
@@ -75,8 +79,11 @@ static int ff_resample_common_##TYPE##_neon(ResampleContext *c, void *dest, cons
frac -= c->src_incr; \
index++;
[FFmpeg-devel] [PATCH] lavf: add libopenmpt demuxer
---
configure| 4 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/libopenmpt.c | 185 +++
4 files changed, 191 insertions(+)
create mode 100644 libavformat/libopenmpt.c
diff --git a/configure b/configure
index 7c463a5..a74aaab 100755
--- a/configure
+++ b/configure
@@ -248,6 +248,7 @@ External library support:
--enable-libopencv enable video filtering via libopencv [no]
--enable-libopenh264 enable H.264 encoding via OpenH264 [no]
--enable-libopenjpeg enable JPEG 2000 de/encoding via OpenJPEG [no]
+ --enable-libopenmpt enable decoding tracked mod files via libopenmpt
[no]
--enable-libopus enable Opus de/encoding via libopus [no]
--enable-libpulseenable Pulseaudio input via libpulse [no]
--enable-librubberband enable rubberband needed for rubberband filter [no]
@@ -1495,6 +1496,7 @@ EXTERNAL_LIBRARY_LIST="
libopencv
libopenh264
libopenjpeg
+libopenmpt
libopus
libpulse
librtmp
@@ -2741,6 +2743,7 @@ libopencore_amrwb_decoder_deps="libopencore_amrwb"
libopenh264_encoder_deps="libopenh264"
libopenjpeg_decoder_deps="libopenjpeg"
libopenjpeg_encoder_deps="libopenjpeg"
+libopenmpt_demuxer_deps="libopenmpt"
libopus_decoder_deps="libopus"
libopus_encoder_deps="libopus"
libopus_encoder_select="audio_frame_queue"
@@ -5633,6 +5636,7 @@ enabled libopenjpeg && { check_lib
openjpeg-2.1/openjpeg.h opj_version -lo
check_lib openjpeg-1.5/openjpeg.h opj_version
-lopenjpeg -DOPJ_STATIC ||
check_lib openjpeg.h opj_version -lopenjpeg
-DOPJ_STATIC ||
die "ERROR: libopenjpeg not found"; }
+enabled libopenmpt&& require libopenmpt libopenmpt/libopenmpt.h
openmpt_module_create -lopenmpt -lstdc++
enabled libopus && require_pkg_config opus opus_multistream.h
opus_multistream_decoder_create
enabled libpulse && require_pkg_config libpulse pulse/pulseaudio.h
pa_context_new
enabled librtmp && require_pkg_config librtmp librtmp/rtmp.h
RTMP_Socket
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6684ead..233d4e0 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -521,6 +521,7 @@ OBJS-$(CONFIG_LIBGME_DEMUXER)+= libgme.o
OBJS-$(CONFIG_LIBMODPLUG_DEMUXER)+= libmodplug.o
OBJS-$(CONFIG_LIBNUT_DEMUXER)+= libnut.o
OBJS-$(CONFIG_LIBNUT_MUXER) += libnut.o
+OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
OBJS-$(CONFIG_LIBRTMP) += librtmp.o
OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o
OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ddf540c..de445b0 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -370,6 +370,7 @@ void av_register_all(void)
REGISTER_DEMUXER (LIBGME, libgme);
REGISTER_DEMUXER (LIBMODPLUG, libmodplug);
REGISTER_MUXDEMUX(LIBNUT, libnut);
+REGISTER_DEMUXER (LIBOPENMPT, libopenmpt);
initialized = 1;
}
diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
new file mode 100644
index 000..8c95c0a
--- /dev/null
+++ b/libavformat/libopenmpt.c
@@ -0,0 +1,185 @@
+/*
+ * Tracked MOD demuxer (libopenmpt)
+ * Copyright (c) 2016 Josh de Kock
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+* @file
+* libopenmpt demuxer
+*/
+
+#include
+#include "libavutil/avstring.h"
+#include "libavutil/eval.h"
+#include "libavutil/opt.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct OpenMPTContext {
+const AVClass *class;
+openmpt_module *module;
+
+int channels;
+double length;
+/* options */
+int sample_rate;
+} OpenMPTContext;
+
+#define OFFSET(x) offsetof(OpenMPTContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM
+#define D AV_OPT_FLAG_DECODING_PARAM
+static const AVOption options[] = {
+{"sample_rate", "set sample rate", OFFSET(sample_rate), AV_OPT_TYPE_INT,
{.i64 = 44100}, 1000, 99, A|D},
+{NULL}
+};
+
+static int probe_openmpt(AVProbeData *p)
+{
+if (p->buf_
Re: [FFmpeg-devel] [PATCH 3/4] avformat/mux: do not call write_header multiple times if it fails the first time
On Sat, Jun 11, 2016 at 11:54:31PM +0200, Marton Balint wrote:
>
>
> On Sat, 11 Jun 2016, Michael Niedermayer wrote:
>
> >On Sat, Jun 11, 2016 at 08:33:42PM +0200, Marton Balint wrote:
> >>Signed-off-by: Marton Balint
> >>---
> >> libavformat/internal.h | 1 +
> >> libavformat/mux.c | 5 +++--
> >> 2 files changed, 4 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/libavformat/internal.h b/libavformat/internal.h
> >>index 40ba089..b6c2020 100644
> >>--- a/libavformat/internal.h
> >>+++ b/libavformat/internal.h
> >>@@ -124,6 +124,7 @@ struct AVFormatInternal {
> >> * Whether or not a header has already been written
> >> */
> >> int header_written;
> >>+int write_header_ret;
> >> };
> >>
> >> struct AVStreamInternal {
> >>diff --git a/libavformat/mux.c b/libavformat/mux.c
> >>index 08ed940..b1b65a1 100644
> >>--- a/libavformat/mux.c
> >>+++ b/libavformat/mux.c
> >>@@ -479,6 +479,7 @@ static int write_header_internal(AVFormatContext *s)
> >> int ret = s->oformat->write_header(s);
> >> if (ret >= 0 && s->pb && s->pb->error < 0)
> >> ret = s->pb->error;
> >>+s->internal->write_header_ret = ret;
> >
> >would
> >header_written = ret
> >be simpler ?
>
> I can change it, but I found it a little less readable.
then better to leave it
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: check if source_package is NULL
On Tue, 2016-05-31 at 23:02 +0200, Marton Balint wrote:
> Fixes ticket #5554.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/mxfdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index f8cf922..9bf676c 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -1914,7 +1914,7 @@ static int
> mxf_parse_structural_metadata(MXFContext *mxf)
> break;
> }
> }
> -if (!source_track || !component)
> +if (!source_track || !component || !source_package)
> continue;
>
> if (!(source_track->sequence = mxf_resolve_strong_ref(mxf,
> &source_track->sequence_ref, Sequence))) {
Looks OK. Crashes are important
/Tomas
signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
