Re: [FFmpeg-devel] [PATCH 1/4] lavc/internal: add FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM

[Matthieu Bouron]

On Sun, Nov 08, 2015 at 08:21:14PM +0100, Michael Niedermayer wrote:
> On Sun, Nov 08, 2015 at 06:17:49PM +0100, Matthieu Bouron wrote:
> > On Tue, Nov 3, 2015 at 9:02 PM, Michael Niedermayer 
> > wrote:
> > 
> > > On Mon, Nov 02, 2015 at 11:45:05AM +0100, Matthieu Bouron wrote:
> > > > From: Matthieu Bouron 
> > > >
> > > > Codec supporting FF_CODEC_SKIP_FRAME_FILL must still extract and fill
> > > > their parameters into AVCodecContext while honoring the skip_frame
> > > > flag.
> > > > ---
> > > >  libavcodec/internal.h | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > > > index 0abe17f..a023d1a 100644
> > > > --- a/libavcodec/internal.h
> > > > +++ b/libavcodec/internal.h
> > > > @@ -53,6 +53,11 @@
> > > >   * from the input AVPacket.
> > > >   */
> > > >  #define FF_CODEC_CAP_SETS_PKT_DTS   (1 << 2)
> > > > +/**
> > > > + * Codec still extract and fill its parameters even if the skip_frame
> > > > + * parameter is honored.
> > >
> > > iam not sure about the english grammer here sounds a bit odd but
> > > otherwise the patch LGTM
> > >
> > 
> > If you have a better sentence or someone else does, I would be happy to
> > update the current one before i push the patch.
> 
> maybe something like:
> The decoder extracts and fills its parameters even if the frame is
> skiped due to the skip_frame setting

Pushed, thanks (and sorry for the delay).

> 
> 
> > 
> > Matthieu
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> No snowflake in an avalanche ever feels responsible. -- Voltaire



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavc/pngdec: set FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM capability

[Matthieu Bouron]

On Tue, Nov 03, 2015 at 09:28:09PM +0100, Michael Niedermayer wrote:
> On Mon, Nov 02, 2015 at 11:45:08AM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > ---
> >  libavcodec/pngdec.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> LGTM

Pushed, thanks.

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mpegvideo: clear overread in clear_context

[Andreas Cadhalpun]

On 15.11.2015 03:16, Michael Niedermayer wrote:
> On Sat, Nov 14, 2015 at 11:00:55PM +0100, Andreas Cadhalpun wrote:
>> Otherwise the h263p decoder can try to copy overread bytes, even though
>> buffer is NULL.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/mpegvideo.c | 1 +
>>  1 file changed, 1 insertion(+)
> 
> LGTM

Pushed.

Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] lavc/mjpegdec: set FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM capability

[Matthieu Bouron]

On Tue, Nov 03, 2015 at 09:27:29PM +0100, Michael Niedermayer wrote:
> On Mon, Nov 02, 2015 at 11:45:07AM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > ---
> >  libavcodec/mjpegdec.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> LGTM

Pushed, thanks.

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

[Hendrik Leppkes]

On Sun, Nov 15, 2015 at 9:51 AM, Muhammad Faiz  wrote:
> add AV_PKT_FLAG_FRAME
> add av_packet_encode_frame()
> add av_packet_decode_frame()
> add av_packet_get_frame()
>
> use pointer to AVFrame instead
> properly padded with AV_INPUT_BUFFER_PADDING_SIZE
>
> modify wrapped_avframe encoder
> implement wrapped_avframe decoder
> implement wrapped_avframe_audio encoder/decoder
>
> fix avformat/yuv4mpegenc to use av_packet_get_frame()
>
> patch attached
>

We already have 3 different API approaches to pass AVFrames as
AVPackets, we really don't need any more.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffmpeg: fix overriding packet duration warning

[Muhammad Faiz]

no warning when packet duration is valid

patch attached
From 789e9f0e93a246fd820401e6c298835bf40dc0c3 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Sun, 15 Nov 2015 15:25:43 +0700
Subject: [PATCH] ffmpeg: fix overriding packet duration warning

no warning when packet duration is valid
---
 ffmpeg.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 3341777..5b9e38e 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -673,10 +673,11 @@ static void write_frame(AVFormatContext *s, AVPacket 
*pkt, OutputStream *ost)
 }
 
 if (ost->frame_rate.num && ost->is_cfr) {
-if (pkt->duration > 0)
+int64_t new_duration = av_rescale_q(1, av_inv_q(ost->frame_rate),
+ost->st->time_base);
+if (pkt->duration > 0 && pkt->duration != new_duration)
 av_log(NULL, AV_LOG_WARNING, "Overriding packet duration by 
frame rate, this should not happen\n");
-pkt->duration = av_rescale_q(1, av_inv_q(ost->frame_rate),
- ost->st->time_base);
+pkt->duration = new_duration;
 }
 }
 
-- 
1.8.3.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

[Muhammad Faiz]

On Sun, Nov 15, 2015 at 4:24 PM, Hendrik Leppkes  wrote:
> On Sun, Nov 15, 2015 at 9:51 AM, Muhammad Faiz  wrote:
>> add AV_PKT_FLAG_FRAME
>> add av_packet_encode_frame()
>> add av_packet_decode_frame()
>> add av_packet_get_frame()
>>
>> use pointer to AVFrame instead
>> properly padded with AV_INPUT_BUFFER_PADDING_SIZE
>>
>> modify wrapped_avframe encoder
>> implement wrapped_avframe decoder
>> implement wrapped_avframe_audio encoder/decoder
>>
>> fix avformat/yuv4mpegenc to use av_packet_get_frame()
>>
>> patch attached
>>
>
> We already have 3 different API approaches to pass AVFrames as
> AVPackets, we really don't need any more.

What are they?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 3/3] ffplay: fix memory calculation

[Muhammad Faiz]

approximately compute memory size on wrapped_avframe packet

patch attached
From 148239aa55382bc68d26764a778fb7982d6d Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Sun, 15 Nov 2015 09:21:29 +0700
Subject: [PATCH v2 3/3] ffplay: fix memory calculation

approximately compute memory size on wrapped_avframe packet
---
 ffplay.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index 2c1817e..a3e2c25 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -395,6 +395,24 @@ int64_t get_valid_channel_layout(int64_t channel_layout, 
int channels)
 
 static void free_picture(Frame *vp);
 
+static int get_packet_memory_size(AVPacket *pkt)
+{
+const AVFrame *frame = av_packet_get_frame(pkt);
+int k, size = pkt->size;
+
+if (frame) {
+for (k = 0; k < AV_NUM_DATA_POINTERS; k++) {
+if (frame->buf[k])
+size += frame->buf[k]->size;
+}
+
+for (k = 0; k < frame->nb_extended_buf; k++)
+size += frame->extended_buf[k]->size;
+}
+
+return size;
+}
+
 static int packet_queue_put_private(PacketQueue *q, AVPacket *pkt)
 {
 MyAVPacketList *pkt1;
@@ -417,7 +435,7 @@ static int packet_queue_put_private(PacketQueue *q, 
AVPacket *pkt)
 q->last_pkt->next = pkt1;
 q->last_pkt = pkt1;
 q->nb_packets++;
-q->size += pkt1->pkt.size + sizeof(*pkt1);
+q->size += get_packet_memory_size(>pkt) + sizeof(*pkt1);
 /* XXX: should duplicate packet data in DV case */
 SDL_CondSignal(q->cond);
 return 0;
@@ -528,7 +546,7 @@ static int packet_queue_get(PacketQueue *q, AVPacket *pkt, 
int block, int *seria
 if (!q->first_pkt)
 q->last_pkt = NULL;
 q->nb_packets--;
-q->size -= pkt1->pkt.size + sizeof(*pkt1);
+q->size -= get_packet_memory_size(>pkt) + sizeof(*pkt1);
 *pkt = pkt1->pkt;
 if (serial)
 *serial = pkt1->serial;
-- 
1.8.3.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/3] ffplay: fix memory calculation

[Muhammad Faiz]

On Sun, Nov 15, 2015 at 3:54 PM, Muhammad Faiz  wrote:
> approximately compute memory size on wrapped_avframe packet
>
> patch attached

I'm sorry, patch not attached.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

[Muhammad Faiz]

add AV_PKT_FLAG_FRAME
add av_packet_encode_frame()
add av_packet_decode_frame()
add av_packet_get_frame()

use pointer to AVFrame instead
properly padded with AV_INPUT_BUFFER_PADDING_SIZE

modify wrapped_avframe encoder
implement wrapped_avframe decoder
implement wrapped_avframe_audio encoder/decoder

fix avformat/yuv4mpegenc to use av_packet_get_frame()

patch attached
From ae6b2c45faac830636602a696925566db03541a2 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Sun, 15 Nov 2015 12:06:12 +0700
Subject: [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

add AV_PKT_FLAG_FRAME
add av_packet_encode_frame()
add av_packet_decode_frame()
add av_packet_get_frame()

use pointer to AVFrame instead
properly padded with AV_INPUT_BUFFER_PADDING_SIZE

modify wrapped_avframe encoder
implement wrapped_avframe decoder
implement wrapped_avframe_audio encoder/decoder

fix avformat/yuv4mpegenc to use av_packet_get_frame()
---
 doc/APIchanges   |  5 +++
 libavcodec/Makefile  |  3 ++
 libavcodec/allcodecs.c   |  3 +-
 libavcodec/avcodec.h | 29 
 libavcodec/avpacket.c| 63 ++-
 libavcodec/codec_desc.c  |  7 
 libavcodec/version.h |  2 +-
 libavcodec/wrapped_avframe.c | 78 ++--
 libavformat/yuv4mpegenc.c|  5 +--
 9 files changed, 173 insertions(+), 22 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 14b96ce..9efd44e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2015-11-15 - lavc 57.16.100 - avcodec.h
+  Add AV_PKT_FLAG_FRAME.
+  Add av_packet_encode_frame(), av_packet_decode_frame(),
+  and av_packet_get_frame().
+
 2015-10-29 - lavc 57.12.100 / 57.8.0 - avcodec.h
   xx - Deprecate av_free_packet(). Use av_packet_unref() as replacement,
it resets the packet in a more consistent way.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 68a573f..65d8621 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -577,7 +577,10 @@ OBJS-$(CONFIG_WMV2_ENCODER)+= wmv2enc.o wmv2.o 
\
   msmpeg4.o msmpeg4enc.o msmpeg4data.o
 OBJS-$(CONFIG_WNV1_DECODER)+= wnv1.o
 OBJS-$(CONFIG_WS_SND1_DECODER) += ws-snd1.o
+OBJS-$(CONFIG_WRAPPED_AVFRAME_DECODER) += wrapped_avframe.o
 OBJS-$(CONFIG_WRAPPED_AVFRAME_ENCODER) += wrapped_avframe.o
+OBJS-$(CONFIG_WRAPPED_AVFRAME_AUDIO_DECODER) += wrapped_avframe.o
+OBJS-$(CONFIG_WRAPPED_AVFRAME_AUDIO_ENCODER) += wrapped_avframe.o
 OBJS-$(CONFIG_XAN_DPCM_DECODER)+= dpcm.o
 OBJS-$(CONFIG_XAN_WC3_DECODER) += xan.o
 OBJS-$(CONFIG_XAN_WC4_DECODER) += xxan.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 9f60d7c..836fd20 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -342,7 +342,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(VP9,   vp9);
 REGISTER_DECODER(VQA,   vqa);
 REGISTER_DECODER(WEBP,  webp);
-REGISTER_ENCODER(WRAPPED_AVFRAME,   wrapped_avframe);
+REGISTER_ENCDEC (WRAPPED_AVFRAME,   wrapped_avframe);
 REGISTER_ENCDEC (WMV1,  wmv1);
 REGISTER_ENCDEC (WMV2,  wmv2);
 REGISTER_DECODER(WMV3,  wmv3);
@@ -446,6 +446,7 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (WMAV1, wmav1);
 REGISTER_ENCDEC (WMAV2, wmav2);
 REGISTER_DECODER(WMAVOICE,  wmavoice);
+REGISTER_ENCDEC (WRAPPED_AVFRAME_AUDIO, wrapped_avframe_audio);
 REGISTER_DECODER(WS_SND1,   ws_snd1);
 REGISTER_DECODER(XMA1,  xma1);
 REGISTER_DECODER(XMA2,  xma2);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 1af17ed..a318dc5 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -550,6 +550,7 @@ enum AVCodecID {
 * stream (only used by libavformat) */
 AV_CODEC_ID_FFMETADATA = 0x21000,   ///< Dummy codec for streams 
containing only metadata information.
 AV_CODEC_ID_WRAPPED_AVFRAME = 0x21001, ///< Passthrough codec, AVFrames 
wrapped in AVPacket
+AV_CODEC_ID_WRAPPED_AVFRAME_AUDIO = 0x21002,
 };
 
 /**
@@ -1442,6 +1443,7 @@ typedef struct AVPacket {
 } AVPacket;
 #define AV_PKT_FLAG_KEY 0x0001 ///< The packet contains a keyframe
 #define AV_PKT_FLAG_CORRUPT 0x0002 ///< The packet content is corrupted
+#define AV_PKT_FLAG_FRAME   0x0004 ///< The packet contains an AVFrame frame
 
 enum AVSideDataParamChangeFlags {
 AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
@@ -4103,6 +4105,33 @@ int av_packet_copy_props(AVPacket *dst, const AVPacket 
*src);
 void av_packet_rescale_ts(AVPacket *pkt, AVRational tb_src, AVRational tb_dst);
 
 /**
+ * Encode frame to packet.
+ *
+ * @param pkt destination packet
+ * @param frame source frame
+ * 

Re: [FFmpeg-devel] [PATCH 2/4] lavf/utils: avoid decoding a frame to get the codec parameters

[Matthieu Bouron]

On Mon, Nov 02, 2015 at 07:56:50AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Nov 2, 2015 at 5:45 AM, Matthieu Bouron 
> wrote:
> 
> > From: Matthieu Bouron 
> >
> > Avoid decoding a frame to get the codec parameters while the codec
> > supports FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM. This is particulary useful
> > to avoid decoding twice images (once in avformat_find_stream_info and
> > once when the actual decode is made).
> > ---
> >  libavformat/utils.c | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 5c4d452..ba62f2b 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -2695,6 +2695,8 @@ static int try_decode_frame(AVFormatContext *s,
> > AVStream *st, AVPacket *avpkt,
> >  AVFrame *frame = av_frame_alloc();
> >  AVSubtitle subtitle;
> >  AVPacket pkt = *avpkt;
> > +int do_skip_frame = 0;
> > +enum AVDiscard skip_frame;
> >
> >  if (!frame)
> >  return AVERROR(ENOMEM);
> > @@ -2733,6 +2735,12 @@ static int try_decode_frame(AVFormatContext *s,
> > AVStream *st, AVPacket *avpkt,
> >  goto fail;
> >  }
> >
> > +if (st->codec->codec->caps_internal &
> > FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) {
> > +do_skip_frame = 1;
> > +skip_frame = st->codec->skip_frame;
> > +st->codec->skip_frame = AVDISCARD_ALL;
> > +}
> > +
> >  while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
> > ret >= 0 &&
> > (!has_codec_parameters(st, NULL) ||
> > !has_decode_delay_been_guessed(st) ||
> > @@ -2768,6 +2776,10 @@ static int try_decode_frame(AVFormatContext *s,
> > AVStream *st, AVPacket *avpkt,
> >  ret = -1;
> >
> >  fail:
> > +if (do_skip_frame) {
> > +st->codec->skip_frame = skip_frame;
> > +}
> > +
> >  av_frame_free();
> >  return ret;
> >  }
> > --
> > 2.6.2
> 
> 
> I think we need an assert in the try_decode loop to ensure that it indeed
> did fill all the params. This is to prevent the case where someone adds a
> new "thing" to the list of things required for find_stream_info to succeed,
> and forgets to update the codecs.

While the codec_has_parameters function fits that role, it does not check
all codec parameters as they can be codec dependant.

I'm not sure if we can create a generic rule here for the same reason as
above, as the parameters set can be codec specific and maybe stream specific.

Having some fate test to cover this area seems to be another option but would
require to inspect all the relevant parameters of AVCodecContext depending
on the codec and a lot of different streams.

What do you think of this approach ?

Matthieu

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] hqx: correct type and size check of info_offset

[Andreas Cadhalpun]

It is used as size argument of ff_canopus_parse_info_tag, which uses it
as size argument to bytestream2_init, which only supports sizes up to
INT_MAX.
Changing it's type to unsigned simplifies the check.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/hqx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c
index 8060c7a..138d960 100644
--- a/libavcodec/hqx.c
+++ b/libavcodec/hqx.c
@@ -417,8 +417,8 @@ static int hqx_decode_frame(AVCodecContext *avctx, void 
*data,
 
 info_tag= AV_RL32(src);
 if (info_tag == MKTAG('I', 'N', 'F', 'O')) {
-int info_offset = AV_RL32(src + 4);
-if (info_offset > UINT32_MAX - 8 || info_offset + 8 > avpkt->size) {
+unsigned info_offset = AV_RL32(src + 4);
+if (info_offset > INT_MAX || info_offset + 8 > avpkt->size) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid INFO header offset: 0x%08"PRIX32" is too large.\n",
info_offset);
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [SURVEY] Summary of first 2015 survey

[Clément Bœsch]

Hi folks,

So the October/November 2015 FFmpeg survey ended, so as promised here is a
summary. It was planed for yesterday but due to some unfortunate national
issues it was kind of postponed to today...

We got 123 answers. I was expecting more but that's a start.

  35,54% (43) A developer using the FFmpeg API
  78,51% (95) An FFmpeg command line user
  19,83% (24) An FFmpeg developer (core developer or occasional contributor)
  5,79%   (7) A packager/distributor of FFmpeg
  23,97% (29) A user of applications using FFmpeg libraries (video players,
  converters, etc)

Note: the last entry was unfortunately added after we received about 50
answers, so it's inaccurate. Sorry about that.

I will give my personal analysis of the results, which may be incorrect. If
other developers want the full data, please ask me in the next days.

Numbers
===

You can find the graph of the results of the second question here:
http://imgur.com/4yKbmDv

... from which we can basically say that users are mostly looking for more
optimizations, bug fixes and documentation. Then comes stuff on which most
people seem to agree, such as testing, cleanups, and misc simple features.
People starts to slightly disagree on the higher level API.

It seems a majority of people are satisfied with API redesign & cleanups
(68.60%) with a tendency to request more of it (19%).

Concerning backports, users are also mostly satisfied with its level, and
surprisingly do not seem to agree that much regarding LTS. Maybe that
reveals an issue with the number of releases we do?

In the same spirit, the support for old API for longer is divided as well, but
this time the tendency goes in the direction of "please stop".

Text


The textual information was giving a lot of insight, thanks to everyone who
took the time to fill them up. Again, if a developer wants a real dump of
the exact user answers, please ask (I'm uncomfortable about publishing
"anonymous" personal answers publicly).

Here is a bulk dump summary of what I noted (look for "(xN)" entries):

API redesign cleanup


 - old cruft
 - mpegvideo dissection
 - don't unless absolutely necessary
 - remove dups
 - simplify process for transcode
 - better error info/doc
 - libavfilter redesign/extension
 - lavfi bpm analyzer
 - chromaprint muxer as a filter
 - crf mode compatible accross codecs (just like bitrate)
 - hwaccel and its interop with filters
 - continue codec context cleanup, refcount, and overall simplification of
   the api
 - more error feedback at cli level
 - high level api (event based?), i/o outside of ffmpeg
 - simpler api to user, more orthogonal, less error prone
 - improve avfilter and swscale
 - code "looks" bad
 - simplification, replace swscale, ffmpeg.c needs to do less things

API documentation
-

 - more explanations in the examples (x2)
 - pts/dts/timestamp calculation consistency accross examples (x4)
 - video only, audio only, audio+video in examples
 - examples with current api (x2)
 - "everything" (x3)
 - how it all fits together (x2)
 - more implications / assumptions of single functions (x2)
 - avcodec and swscale
 - indexing, seeking, parser api
 - hwaccel
 - better api documentation, aka not Doxygen but "where do i start",
   tutorial, ... (x2)
 - filter api, memory management
 - better examples
 - missing documentation in structures members & flags
 - internal documentation

CLI documentation
-

 - more real world examples (x9): crop image, cut a fragment of a movie,
   convert video frames to images, ...
 - filter examples with the cli (x2)
 - which [f]flags affect which codecs/formats
 - clear confusions between similar options such as -r vs -framerate
 - confusing complex filter doc
 - clarify overlap between ff and x264 options
 - codec specific options
 - sparse man page
 - many options explained without context/scenario (x2)
 - input device examples
 - codec usage examples
 - hwaccel options
 - navigation, doc hard to find (wiki vs official doc)
 - dvd
 - importance of location of arguments
 - using on handling multiple streams
 - tutorial/guide style doc (x2)
 - better faq

Misc comments
-

 - ts segmenting optim for hls
 - lts
 - more upstreaming
 - 2 phase dev cycle
 - more code examples (x2) with explanations
 - jack outdev, unified cd+dvd+bluray input
 - vc1 encoder
 - python binding
 - "Stop puking on the feet of your colleagues, guys!"
 - better ivtc and other fps handling features
 - better mannered development process
 - more developed ffplay (hwaccel, doc), mpts (?) options
 - friendlier user support
 - one official lts (in order to solve most of the api related changes)
 - answer more questions on "libav-devel"
 - stop dropping thing just because of "nobody is using it"
 - android support, hwaccel and relationship with filters/bufferpool/etc,
   high level support for adaptive bitrate streaming (bandwidth stream
   switch)
 - libav & ffmpeg merge (x2)
 - 

Re: [FFmpeg-devel] [PATCH] estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec

[Michael Niedermayer]

On Sun, Nov 15, 2015 at 01:58:50PM +0100, Rainer Hochecker wrote:
> I got a mpegts file with hevc that fails estimating duration. Increasing 
> number of
> retries fixes the issue.
> 
> Rainer
> 
> ---
>  libavformat/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- 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 2/2] ffserver_config: replace strtod by av_strtod and correct undefined behavior

[Ganesh Ajjanagadde]

On Sat, Nov 14, 2015 at 4:12 PM, Michael Niedermayer
 wrote:
> On Thu, Nov 12, 2015 at 09:46:05PM -0500, Ganesh Ajjanagadde wrote:
>> This uses av_strtod for added flexibility, and av_rint64_clip for ensuring 
>> that
>> no undefined behavior gets invoked.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  ffserver_config.c | 21 +
>>  1 file changed, 5 insertions(+), 16 deletions(-)
>>
>> diff --git a/ffserver_config.c b/ffserver_config.c
>> index 9fc1f00..443e71d 100644
>> --- a/ffserver_config.c
>> +++ b/ffserver_config.c
>> @@ -19,6 +19,7 @@
>>   */
>>
>>  #include 
>> +#include "libavutil/eval.h"
>>  #include "libavutil/opt.h"
>>  #include "libavutil/parseutils.h"
>>  #include "libavutil/avstring.h"
>> @@ -757,7 +758,7 @@ static int ffserver_parse_config_feed(FFServerConfig 
>> *config, const char *cmd,
>>  } else {
>>  WARNING("Truncate N syntax in configuration file is deprecated. 
>> "
>>  "Use Truncate alone with no arguments.\n");
>> -feed->truncate = strtod(arg, NULL);
>> +feed->truncate = av_rint64_clip(av_strtod(arg, NULL), INT_MIN, 
>> INT_MAX);
>>  }
>>  } else if (!av_strcasecmp(cmd, "FileMaxSize")) {
>>  char *p1;
>> @@ -765,22 +766,10 @@ static int ffserver_parse_config_feed(FFServerConfig 
>> *config, const char *cmd,
>>
>>  ffserver_get_arg(arg, sizeof(arg), p);
>>  p1 = arg;
>> -fsize = strtod(p1, );
>> -switch(av_toupper(*p1)) {
>> -case 'K':
>> -fsize *= 1024;
>> -break;
>> -case 'M':
>> -fsize *= 1024 * 1024;
>> -break;
>> -case 'G':
>> -fsize *= 1024 * 1024 * 1024;
>> -break;
>> -default:
>> +fsize = av_strtod(p1, );
>> +if (!fsize || fabs(fsize) == HUGE_VAL)
>>  ERROR("Invalid file size: '%s'\n", arg);
>> -break;
>> -}
>> -feed->feed_max_size = (int64_t)fsize;
>> +feed->feed_max_size = av_rint64_clip(fsize, INT64_MIN, INT64_MAX);
>
> i think these should be range checked and causing errors or warnings
> if they are out of range
>
> if the user asks for value X and we cant do that then we should tell
> the user that we cant.

The first one does not need to be, it is deprecated syntax and anyway
the only value it cares about is 0 versus nonzero.

The second one can be range checked. Honestly though, I do not favor
adding cruft like this for minimal gain since for all practical
usages, no one will pass a value >= 2^64 in absolute value. For me,
what is important is avoiding the undefined behavior. If you or others
still feel that they need to be range checked, will do so.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/faandct: use more accurate constants

[Ganesh Ajjanagadde]

On Fri, Nov 13, 2015 at 6:24 PM, Ganesh Ajjanagadde  wrote:
> On Fri, Nov 13, 2015 at 6:17 PM, Michael Niedermayer
>  wrote:
>> On Fri, Nov 13, 2015 at 11:42:31AM -0500, Ganesh Ajjanagadde wrote:
>>> This guarantees a "best effort precision".
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavcodec/faandct.c | 29 +
>>>  1 file changed, 13 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/libavcodec/faandct.c b/libavcodec/faandct.c
>>> index 473bc1d..c8ea328 100644
>>> --- a/libavcodec/faandct.c
>>> +++ b/libavcodec/faandct.c
>>> @@ -31,23 +31,20 @@
>>>
>>>  typedef float FLOAT;
>>>
>>> -//numbers generated by simple c code (not as accurate as they could be)
>>> -/*
>>> -for(i=0; i<8; i++){
>>> -printf("#define B%d %1.20llf\n", i, (long 
>>> double)1.0/(cosl(i*acosl(-1.0)/(long double)16.0)*sqrtl(2)));
>>> -}
>>> +/* numbers generated by arbitrary precision arithmetic followed by 
>>> truncation
>>> +to 36 fractional digits (enough for a 128-bit IEEE quad, see 
>>> /usr/include/math.h
>>> +for this approach). This guarantees a "best effort precision".
>>>  */
>>> -#define B0 1.
>>> -#define B1 0.72095982200694791383 // (cos(pi*1/16)sqrt(2))^-1
>>> -#define B2 0.76536686473017954350 // (cos(pi*2/16)sqrt(2))^-1
>>> -#define B3 0.85043009476725644878 // (cos(pi*3/16)sqrt(2))^-1
>>> -#define B4 1. // (cos(pi*4/16)sqrt(2))^-1
>>> -#define B5 1.27275858057283393842 // (cos(pi*5/16)sqrt(2))^-1
>>> -#define B6 1.84775906502257351242 // (cos(pi*6/16)sqrt(2))^-1
>>> -#define B7 3.62450978541155137218 // (cos(pi*7/16)sqrt(2))^-1
>>> -
>>> -
>>> -#define A1 0.70710678118654752438 // cos(pi*4/16)
>>> +#define B0 1.L
>>> +#define B1 0.720959822006947913789091890943021267L // 
>>> (cos(pi*1/16)sqrt(2))^-1
>>> +#define B2 0.765366864730179543456919968060797734L // 
>>> (cos(pi*2/16)sqrt(2))^-1
>>> +#define B3 0.850430094767256448766702844371412325L // 
>>> (cos(pi*3/16)sqrt(2))^-1
>>> +#define B4 1.L // 
>>> (cos(pi*4/16)sqrt(2))^-1
>>> +#define B5 1.272758580572833938461007018281767032L // 
>>> (cos(pi*5/16)sqrt(2))^-1
>>> +#define B6 1.847759065022573512256366378793576574L // 
>>> (cos(pi*6/16)sqrt(2))^-1
>>> +#define B7 3.624509785411551372409941227504289587L // 
>>> (cos(pi*7/16)sqrt(2))^-1
>>
>> iam not sure how portable x.yL is
>> otherwise should be ok
>
> Technically C89, see e.g
> http://port70.net/~nsz/c/c89/c89-draft.html#3.1.3.1, wikipedia, or
> http://en.cppreference.com/w/cpp/language/floating_literal.
> Nevertheless, will wait for comments especially from people who use
> Microsoft stuff.

Is portable, since recent commit by me a5202bc9 for the Bessel
function from boost has such a literal (line 118, swresample/resample)
and does not seem to have caused build failures anywhere. Actually,
there the L was an artifact left over from Boost and I will remove it.

Will push in light of this. Also will push the trivial removal of the
L leftover in swresample.

>
>>
>> [...]
>> --
>> 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
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[wm4]

On Sun, 15 Nov 2015 16:28:45 +0100
Nicolas George  wrote:

> Le quintidi 25 brumaire, an CCXXIV, wm4 a écrit :
> > Or even better, just delete ffserver.  
> 
> Please refrain from gratuitous flamebait.

It's one of those things that are at least half broken, barely
maintained, everyone dislikes, and many agree that they should be
removed (or at least rewritten). But they are not removed or fixed
anyway, because some devs are either emotionally attached to it, or
have this strange ideology of never removing anything. The duplicated
decoders/encoders/demuxers merged from Libav illustrate this nicely.

Sure, call it flamebait, but this doesn't change that something is VERY
WRONG here.

But I agree it's offtopic, especially since it has been assured that
not only ffserver needs the API functions at hand.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] configure+libm.h: add hypot emulation

[Michael Niedermayer]

On Sun, Nov 15, 2015 at 10:03:37AM -0500, Ganesh Ajjanagadde wrote:
> It is known that the naive sqrt(x*x + y*y) approach for computing the
> hypotenuse suffers from overflow and accuracy issues, see e.g
> http://www.johndcook.com/blog/2010/06/02/whats-so-hard-about-finding-a-hypotenuse/.
> This adds hypot support to FFmpeg, a C99 function.
> 
> On platforms without hypot, this patch does a reaonable workaround, that
> although not as accurate as GNU libm, is readable and does not suffer
> from the overflow issue. Improvements can be made separately.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  configure|  2 ++
>  libavutil/libm.h | 23 +++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/configure b/configure
> index d518b21..45df724 100755
> --- a/configure
> +++ b/configure
> @@ -1774,6 +1774,7 @@ MATH_FUNCS="
>  exp2
>  exp2f
>  expf
> +hypot
>  isinf
>  isnan
>  ldexpf
> @@ -5309,6 +5310,7 @@ disabled crystalhd || check_lib 
> libcrystalhd/libcrystalhd_if.h DtsCrystalHDVersi
>  
>  atan2f_args=2
>  copysign_args=2
> +hypot_args=2
>  ldexpf_args=2
>  powf_args=2
>  
> diff --git a/libavutil/libm.h b/libavutil/libm.h
> index 6c17b28..f7a2b41 100644
> --- a/libavutil/libm.h
> +++ b/libavutil/libm.h
> @@ -102,6 +102,29 @@ static av_always_inline av_const int isnan(float x)
>  }
>  #endif /* HAVE_ISNAN */
>  
> +#if !HAVE_HYPOT
> +#undef hypot
> +static inline av_const double hypot(double x, double y)
> +{
> +double ret, temp;
> +x = fabs(x);
> +y = fabs(y);
> +
> +if (isinf(x) || isinf(y))
> +return av_int2double(0x7ff0);

if either is NaN the result should be NaN i think
return x+y
might achive this

[...]
-- 
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] avutil: Move av_rint64_clip_* to internal.h

[Michael Niedermayer]

On Sun, Nov 15, 2015 at 10:24:52AM -0500, Ganesh Ajjanagadde wrote:
> On Sun, Nov 15, 2015 at 10:23 AM, wm4  wrote:
> > On Sun, 15 Nov 2015 10:20:41 -0500
> > Ganesh Ajjanagadde  wrote:
> >
> >> On Sat, Nov 14, 2015 at 9:01 PM, James Almer  wrote:
> >> > On 11/14/2015 10:48 PM, Michael Niedermayer wrote:
> >> >> From: Michael Niedermayer 
> >> >>
> >> >> This should avoid build failures on VS2012
> >> >> Feel free to changes this to a different solution
> >> >>
> >> >> Signed-off-by: Michael Niedermayer 
> >> >> ---
> >> >>  libavutil/common.h   |   39 ---
> >> >>  libavutil/internal.h |   40 
> >> >>  2 files changed, 40 insertions(+), 39 deletions(-)
> >> >>
> >> >> diff --git a/libavutil/common.h b/libavutil/common.h
> >> >> index 813fb37..6f0f582 100644
> >> >> --- a/libavutil/common.h
> >> >> +++ b/libavutil/common.h
> >> >> @@ -298,42 +298,6 @@ static av_always_inline av_const double 
> >> >> av_clipd_c(double a, double amin, double
> >> >>  else   return a;
> >> >>  }
> >> >>
> >> >> -/**
> >> >> - * Clip and convert a double value into the long long amin-amax range.
> >> >> - * This function is needed because conversion of floating point to 
> >> >> integers when
> >> >> - * it does not fit in the integer's representation does not 
> >> >> necessarily saturate
> >> >> - * correctly (usually converted to a cvttsd2si on x86) which saturates 
> >> >> numbers
> >> >> - * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
> >> >> undefined
> >> >> - * behavior, allowing this sort of mathematically bogus conversions. 
> >> >> This provides
> >> >> - * a safe alternative that is slower obviously but assures safety and 
> >> >> better
> >> >> - * mathematical behavior.
> >> >> - * @param a value to clip
> >> >> - * @param amin minimum value of the clip range
> >> >> - * @param amax maximum value of the clip range
> >> >> - * @return clipped value
> >> >> - */
> >> >> -static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
> >> >> int64_t amin, int64_t amax)
> >> >> -{
> >> >> -int64_t res;
> >> >> -#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && ASSERT_LEVEL 
> >> >> >= 2
> >> >> -if (amin > amax) abort();
> >> >> -#endif
> >> >> -// INT64_MAX+1,INT64_MIN are exactly representable as IEEE doubles
> >> >> -// do range checks first
> >> >> -if (a >=  9223372036854775808.0)
> >> >> -return amax;
> >> >> -if (a <= -9223372036854775808.0)
> >> >> -   return amin;
> >> >> -
> >> >> -// safe to call llrint and clip accordingly
> >> >> -res = llrint(a);
> >> >> -if (res > amax)
> >> >> -return amax;
> >> >> -if (res < amin)
> >> >> -return amin;
> >> >> -return res;
> >> >> -}
> >> >> -
> >> >>  /** Compute ceil(log2(x)).
> >> >>   * @param x value used to compute ceil(log2(x))
> >> >>   * @return computed ceiling of log2(x)
> >> >> @@ -547,9 +511,6 @@ static av_always_inline av_const int 
> >> >> av_popcount64_c(uint64_t x)
> >> >>  #ifndef av_clipd
> >> >>  #   define av_clipd av_clipd_c
> >> >>  #endif
> >> >> -#ifndef av_rint64_clip
> >> >> -#   define av_rint64_clip   av_rint64_clip_c
> >> >> -#endif
> >> >>  #ifndef av_popcount
> >> >>  #   define av_popcount  av_popcount_c
> >> >>  #endif
> >> >> diff --git a/libavutil/internal.h b/libavutil/internal.h
> >> >> index 5c2cd99..cb0c8cd 100644
> >> >> --- a/libavutil/internal.h
> >> >> +++ b/libavutil/internal.h
> >> >> @@ -257,6 +257,46 @@ void avpriv_request_sample(void *avc,
> >> >>  #endif
> >> >>
> >> >>  /**
> >> >> + * Clip and convert a double value into the long long amin-amax range.
> >> >> + * This function is needed because conversion of floating point to 
> >> >> integers when
> >> >> + * it does not fit in the integer's representation does not 
> >> >> necessarily saturate
> >> >> + * correctly (usually converted to a cvttsd2si on x86) which saturates 
> >> >> numbers
> >> >> + * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
> >> >> undefined
> >> >> + * behavior, allowing this sort of mathematically bogus conversions. 
> >> >> This provides
> >> >> + * a safe alternative that is slower obviously but assures safety and 
> >> >> better
> >> >> + * mathematical behavior.
> >> >> + * @param a value to clip
> >> >> + * @param amin minimum value of the clip range
> >> >> + * @param amax maximum value of the clip range
> >> >> + * @return clipped value
> >> >> + */
> >> >> +static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
> >> >> int64_t amin, int64_t amax)
> >> >
> >> > IMO rename it to avpriv_rint64_clip() or even ff_rint64_clip() since 
> >> > it's inlined
> >> > and not public/exported.
> >>
> >> Just noticed an issue: Ronald mentioned to me that ffserver and other
> >> such programs should not 

Re: [FFmpeg-devel] [PATCH 2/2] avutil/eval: change sqrt to hypot

[Ganesh Ajjanagadde]

On Sat, Nov 14, 2015 at 9:19 PM, Michael Niedermayer
 wrote:
> On Sat, Nov 14, 2015 at 12:11:20PM -0500, Ganesh Ajjanagadde wrote:
>> This improves the mathematical behavior of hypotenuse computation.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavutil/eval.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> if a hypot() function fallback is added this is ok
> otherwise the code as it is before this should be fine too in practice
> doubles have a quite large exponent range, half of that is still quite
> large

It is not just an issue of overflow, but also accuracy more generally.
I gave overflow as the most easily understood issue.
Concrete example:
1e-1, 1e-8
actual: 0.1004...
hypot: 0.100505151476
naive: 0.100519029264

I am pretty sure that the error can be far worse, e.g when bad underflow occurs.

There is a fallback, albeit the naive one which Paul does not like,
though I myself don't see why in light of your comment above.

Rewrote and posted updated version that although not as "perfect" as
GNU libm's, is better than a naive sqrt(x*x + y*y).

I admit it is a minor thing, on the lines of the log10 stuff, but I
posted it as it actually has a greater significance.
avutil/eval was used as an illustrative example.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 1
> "Used only once"- "Some unspecified defect prevented a second use"
> "In good condition" - "Can be repaird by experienced expert"
> "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
>
> ___
> 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] [PATCHv2] configure+libm.h: add hypot emulation

[Ganesh Ajjanagadde]

It is known that the naive sqrt(x*x + y*y) approach for computing the
hypotenuse suffers from overflow and accuracy issues, see e.g
http://www.johndcook.com/blog/2010/06/02/whats-so-hard-about-finding-a-hypotenuse/.
This adds hypot support to FFmpeg, a C99 function.

On platforms without hypot, this patch does a reaonable workaround, that
although not as accurate as GNU libm, is readable and does not suffer
from the overflow issue. Improvements can be made separately.

Signed-off-by: Ganesh Ajjanagadde 
---
 configure|  2 ++
 libavutil/libm.h | 23 +++
 2 files changed, 25 insertions(+)

diff --git a/configure b/configure
index d518b21..45df724 100755
--- a/configure
+++ b/configure
@@ -1774,6 +1774,7 @@ MATH_FUNCS="
 exp2
 exp2f
 expf
+hypot
 isinf
 isnan
 ldexpf
@@ -5309,6 +5310,7 @@ disabled crystalhd || check_lib 
libcrystalhd/libcrystalhd_if.h DtsCrystalHDVersi
 
 atan2f_args=2
 copysign_args=2
+hypot_args=2
 ldexpf_args=2
 powf_args=2
 
diff --git a/libavutil/libm.h b/libavutil/libm.h
index 6c17b28..f7a2b41 100644
--- a/libavutil/libm.h
+++ b/libavutil/libm.h
@@ -102,6 +102,29 @@ static av_always_inline av_const int isnan(float x)
 }
 #endif /* HAVE_ISNAN */
 
+#if !HAVE_HYPOT
+#undef hypot
+static inline av_const double hypot(double x, double y)
+{
+double ret, temp;
+x = fabs(x);
+y = fabs(y);
+
+if (isinf(x) || isinf(y))
+return av_int2double(0x7ff0);
+if (x == 0 || y == 0)
+return x + y;
+if (x < y) {
+temp = x;
+x = y;
+y = temp;
+}
+
+y = y/x;
+return x*sqrt(1 + y*y);
+}
+#endif /* HAVE_HYPOT */
+
 #if !HAVE_LDEXPF
 #undef ldexpf
 #define ldexpf(x, exp) ((float)ldexp(x, exp))
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 10:23 AM, wm4  wrote:
> On Sun, 15 Nov 2015 10:20:41 -0500
> Ganesh Ajjanagadde  wrote:
>
>> On Sat, Nov 14, 2015 at 9:01 PM, James Almer  wrote:
>> > On 11/14/2015 10:48 PM, Michael Niedermayer wrote:
>> >> From: Michael Niedermayer 
>> >>
>> >> This should avoid build failures on VS2012
>> >> Feel free to changes this to a different solution
>> >>
>> >> Signed-off-by: Michael Niedermayer 
>> >> ---
>> >>  libavutil/common.h   |   39 ---
>> >>  libavutil/internal.h |   40 
>> >>  2 files changed, 40 insertions(+), 39 deletions(-)
>> >>
>> >> diff --git a/libavutil/common.h b/libavutil/common.h
>> >> index 813fb37..6f0f582 100644
>> >> --- a/libavutil/common.h
>> >> +++ b/libavutil/common.h
>> >> @@ -298,42 +298,6 @@ static av_always_inline av_const double 
>> >> av_clipd_c(double a, double amin, double
>> >>  else   return a;
>> >>  }
>> >>
>> >> -/**
>> >> - * Clip and convert a double value into the long long amin-amax range.
>> >> - * This function is needed because conversion of floating point to 
>> >> integers when
>> >> - * it does not fit in the integer's representation does not necessarily 
>> >> saturate
>> >> - * correctly (usually converted to a cvttsd2si on x86) which saturates 
>> >> numbers
>> >> - * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
>> >> undefined
>> >> - * behavior, allowing this sort of mathematically bogus conversions. 
>> >> This provides
>> >> - * a safe alternative that is slower obviously but assures safety and 
>> >> better
>> >> - * mathematical behavior.
>> >> - * @param a value to clip
>> >> - * @param amin minimum value of the clip range
>> >> - * @param amax maximum value of the clip range
>> >> - * @return clipped value
>> >> - */
>> >> -static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
>> >> int64_t amin, int64_t amax)
>> >> -{
>> >> -int64_t res;
>> >> -#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && ASSERT_LEVEL 
>> >> >= 2
>> >> -if (amin > amax) abort();
>> >> -#endif
>> >> -// INT64_MAX+1,INT64_MIN are exactly representable as IEEE doubles
>> >> -// do range checks first
>> >> -if (a >=  9223372036854775808.0)
>> >> -return amax;
>> >> -if (a <= -9223372036854775808.0)
>> >> -   return amin;
>> >> -
>> >> -// safe to call llrint and clip accordingly
>> >> -res = llrint(a);
>> >> -if (res > amax)
>> >> -return amax;
>> >> -if (res < amin)
>> >> -return amin;
>> >> -return res;
>> >> -}
>> >> -
>> >>  /** Compute ceil(log2(x)).
>> >>   * @param x value used to compute ceil(log2(x))
>> >>   * @return computed ceiling of log2(x)
>> >> @@ -547,9 +511,6 @@ static av_always_inline av_const int 
>> >> av_popcount64_c(uint64_t x)
>> >>  #ifndef av_clipd
>> >>  #   define av_clipd av_clipd_c
>> >>  #endif
>> >> -#ifndef av_rint64_clip
>> >> -#   define av_rint64_clip   av_rint64_clip_c
>> >> -#endif
>> >>  #ifndef av_popcount
>> >>  #   define av_popcount  av_popcount_c
>> >>  #endif
>> >> diff --git a/libavutil/internal.h b/libavutil/internal.h
>> >> index 5c2cd99..cb0c8cd 100644
>> >> --- a/libavutil/internal.h
>> >> +++ b/libavutil/internal.h
>> >> @@ -257,6 +257,46 @@ void avpriv_request_sample(void *avc,
>> >>  #endif
>> >>
>> >>  /**
>> >> + * Clip and convert a double value into the long long amin-amax range.
>> >> + * This function is needed because conversion of floating point to 
>> >> integers when
>> >> + * it does not fit in the integer's representation does not necessarily 
>> >> saturate
>> >> + * correctly (usually converted to a cvttsd2si on x86) which saturates 
>> >> numbers
>> >> + * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
>> >> undefined
>> >> + * behavior, allowing this sort of mathematically bogus conversions. 
>> >> This provides
>> >> + * a safe alternative that is slower obviously but assures safety and 
>> >> better
>> >> + * mathematical behavior.
>> >> + * @param a value to clip
>> >> + * @param amin minimum value of the clip range
>> >> + * @param amax maximum value of the clip range
>> >> + * @return clipped value
>> >> + */
>> >> +static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
>> >> int64_t amin, int64_t amax)
>> >
>> > IMO rename it to avpriv_rint64_clip() or even ff_rint64_clip() since it's 
>> > inlined
>> > and not public/exported.
>>
>> Just noticed an issue: Ronald mentioned to me that ffserver and other
>> such programs should not use internal API. This therefore needs to be
>> exported somehow.
>
> If only ffserver needs it, implement it there?
>
> Or even better, just delete ffserver.

I have repeated this many times in the past, but ffserver was given as
a mere illustration. cmdutils.c also needs it, and there are likely
more such 

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[wm4]

On Sun, 15 Nov 2015 10:20:41 -0500
Ganesh Ajjanagadde  wrote:

> On Sat, Nov 14, 2015 at 9:01 PM, James Almer  wrote:
> > On 11/14/2015 10:48 PM, Michael Niedermayer wrote:  
> >> From: Michael Niedermayer 
> >>
> >> This should avoid build failures on VS2012
> >> Feel free to changes this to a different solution
> >>
> >> Signed-off-by: Michael Niedermayer 
> >> ---
> >>  libavutil/common.h   |   39 ---
> >>  libavutil/internal.h |   40 
> >>  2 files changed, 40 insertions(+), 39 deletions(-)
> >>
> >> diff --git a/libavutil/common.h b/libavutil/common.h
> >> index 813fb37..6f0f582 100644
> >> --- a/libavutil/common.h
> >> +++ b/libavutil/common.h
> >> @@ -298,42 +298,6 @@ static av_always_inline av_const double 
> >> av_clipd_c(double a, double amin, double
> >>  else   return a;
> >>  }
> >>
> >> -/**
> >> - * Clip and convert a double value into the long long amin-amax range.
> >> - * This function is needed because conversion of floating point to 
> >> integers when
> >> - * it does not fit in the integer's representation does not necessarily 
> >> saturate
> >> - * correctly (usually converted to a cvttsd2si on x86) which saturates 
> >> numbers
> >> - * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
> >> undefined
> >> - * behavior, allowing this sort of mathematically bogus conversions. This 
> >> provides
> >> - * a safe alternative that is slower obviously but assures safety and 
> >> better
> >> - * mathematical behavior.
> >> - * @param a value to clip
> >> - * @param amin minimum value of the clip range
> >> - * @param amax maximum value of the clip range
> >> - * @return clipped value
> >> - */
> >> -static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
> >> int64_t amin, int64_t amax)
> >> -{
> >> -int64_t res;
> >> -#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 
> >> 2
> >> -if (amin > amax) abort();
> >> -#endif
> >> -// INT64_MAX+1,INT64_MIN are exactly representable as IEEE doubles
> >> -// do range checks first
> >> -if (a >=  9223372036854775808.0)
> >> -return amax;
> >> -if (a <= -9223372036854775808.0)
> >> -   return amin;
> >> -
> >> -// safe to call llrint and clip accordingly
> >> -res = llrint(a);
> >> -if (res > amax)
> >> -return amax;
> >> -if (res < amin)
> >> -return amin;
> >> -return res;
> >> -}
> >> -
> >>  /** Compute ceil(log2(x)).
> >>   * @param x value used to compute ceil(log2(x))
> >>   * @return computed ceiling of log2(x)
> >> @@ -547,9 +511,6 @@ static av_always_inline av_const int 
> >> av_popcount64_c(uint64_t x)
> >>  #ifndef av_clipd
> >>  #   define av_clipd av_clipd_c
> >>  #endif
> >> -#ifndef av_rint64_clip
> >> -#   define av_rint64_clip   av_rint64_clip_c
> >> -#endif
> >>  #ifndef av_popcount
> >>  #   define av_popcount  av_popcount_c
> >>  #endif
> >> diff --git a/libavutil/internal.h b/libavutil/internal.h
> >> index 5c2cd99..cb0c8cd 100644
> >> --- a/libavutil/internal.h
> >> +++ b/libavutil/internal.h
> >> @@ -257,6 +257,46 @@ void avpriv_request_sample(void *avc,
> >>  #endif
> >>
> >>  /**
> >> + * Clip and convert a double value into the long long amin-amax range.
> >> + * This function is needed because conversion of floating point to 
> >> integers when
> >> + * it does not fit in the integer's representation does not necessarily 
> >> saturate
> >> + * correctly (usually converted to a cvttsd2si on x86) which saturates 
> >> numbers
> >> + * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
> >> undefined
> >> + * behavior, allowing this sort of mathematically bogus conversions. This 
> >> provides
> >> + * a safe alternative that is slower obviously but assures safety and 
> >> better
> >> + * mathematical behavior.
> >> + * @param a value to clip
> >> + * @param amin minimum value of the clip range
> >> + * @param amax maximum value of the clip range
> >> + * @return clipped value
> >> + */
> >> +static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
> >> int64_t amin, int64_t amax)  
> >
> > IMO rename it to avpriv_rint64_clip() or even ff_rint64_clip() since it's 
> > inlined
> > and not public/exported.  
> 
> Just noticed an issue: Ronald mentioned to me that ffserver and other
> such programs should not use internal API. This therefore needs to be
> exported somehow.

If only ffserver needs it, implement it there?

Or even better, just delete ffserver.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 11:00 AM, Michael Niedermayer
 wrote:
> On Sun, Nov 15, 2015 at 10:24:52AM -0500, Ganesh Ajjanagadde wrote:
>> On Sun, Nov 15, 2015 at 10:23 AM, wm4  wrote:
>> > On Sun, 15 Nov 2015 10:20:41 -0500
>> > Ganesh Ajjanagadde  wrote:
>> >
>> >> On Sat, Nov 14, 2015 at 9:01 PM, James Almer  wrote:
>> >> > On 11/14/2015 10:48 PM, Michael Niedermayer wrote:
>> >> >> From: Michael Niedermayer 
>> >> >>
>> >> >> This should avoid build failures on VS2012
>> >> >> Feel free to changes this to a different solution
>> >> >>
>> >> >> Signed-off-by: Michael Niedermayer 
>> >> >> ---
>> >> >>  libavutil/common.h   |   39 ---
>> >> >>  libavutil/internal.h |   40 
>> >> >>  2 files changed, 40 insertions(+), 39 deletions(-)
>> >> >>
>> >> >> diff --git a/libavutil/common.h b/libavutil/common.h
>> >> >> index 813fb37..6f0f582 100644
>> >> >> --- a/libavutil/common.h
>> >> >> +++ b/libavutil/common.h
>> >> >> @@ -298,42 +298,6 @@ static av_always_inline av_const double 
>> >> >> av_clipd_c(double a, double amin, double
>> >> >>  else   return a;
>> >> >>  }
>> >> >>
>> >> >> -/**
>> >> >> - * Clip and convert a double value into the long long amin-amax range.
>> >> >> - * This function is needed because conversion of floating point to 
>> >> >> integers when
>> >> >> - * it does not fit in the integer's representation does not 
>> >> >> necessarily saturate
>> >> >> - * correctly (usually converted to a cvttsd2si on x86) which 
>> >> >> saturates numbers
>> >> >> - * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
>> >> >> undefined
>> >> >> - * behavior, allowing this sort of mathematically bogus conversions. 
>> >> >> This provides
>> >> >> - * a safe alternative that is slower obviously but assures safety and 
>> >> >> better
>> >> >> - * mathematical behavior.
>> >> >> - * @param a value to clip
>> >> >> - * @param amin minimum value of the clip range
>> >> >> - * @param amax maximum value of the clip range
>> >> >> - * @return clipped value
>> >> >> - */
>> >> >> -static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
>> >> >> int64_t amin, int64_t amax)
>> >> >> -{
>> >> >> -int64_t res;
>> >> >> -#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && 
>> >> >> ASSERT_LEVEL >= 2
>> >> >> -if (amin > amax) abort();
>> >> >> -#endif
>> >> >> -// INT64_MAX+1,INT64_MIN are exactly representable as IEEE doubles
>> >> >> -// do range checks first
>> >> >> -if (a >=  9223372036854775808.0)
>> >> >> -return amax;
>> >> >> -if (a <= -9223372036854775808.0)
>> >> >> -   return amin;
>> >> >> -
>> >> >> -// safe to call llrint and clip accordingly
>> >> >> -res = llrint(a);
>> >> >> -if (res > amax)
>> >> >> -return amax;
>> >> >> -if (res < amin)
>> >> >> -return amin;
>> >> >> -return res;
>> >> >> -}
>> >> >> -
>> >> >>  /** Compute ceil(log2(x)).
>> >> >>   * @param x value used to compute ceil(log2(x))
>> >> >>   * @return computed ceiling of log2(x)
>> >> >> @@ -547,9 +511,6 @@ static av_always_inline av_const int 
>> >> >> av_popcount64_c(uint64_t x)
>> >> >>  #ifndef av_clipd
>> >> >>  #   define av_clipd av_clipd_c
>> >> >>  #endif
>> >> >> -#ifndef av_rint64_clip
>> >> >> -#   define av_rint64_clip   av_rint64_clip_c
>> >> >> -#endif
>> >> >>  #ifndef av_popcount
>> >> >>  #   define av_popcount  av_popcount_c
>> >> >>  #endif
>> >> >> diff --git a/libavutil/internal.h b/libavutil/internal.h
>> >> >> index 5c2cd99..cb0c8cd 100644
>> >> >> --- a/libavutil/internal.h
>> >> >> +++ b/libavutil/internal.h
>> >> >> @@ -257,6 +257,46 @@ void avpriv_request_sample(void *avc,
>> >> >>  #endif
>> >> >>
>> >> >>  /**
>> >> >> + * Clip and convert a double value into the long long amin-amax range.
>> >> >> + * This function is needed because conversion of floating point to 
>> >> >> integers when
>> >> >> + * it does not fit in the integer's representation does not 
>> >> >> necessarily saturate
>> >> >> + * correctly (usually converted to a cvttsd2si on x86) which 
>> >> >> saturates numbers
>> >> >> + * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
>> >> >> undefined
>> >> >> + * behavior, allowing this sort of mathematically bogus conversions. 
>> >> >> This provides
>> >> >> + * a safe alternative that is slower obviously but assures safety and 
>> >> >> better
>> >> >> + * mathematical behavior.
>> >> >> + * @param a value to clip
>> >> >> + * @param amin minimum value of the clip range
>> >> >> + * @param amax maximum value of the clip range
>> >> >> + * @return clipped value
>> >> >> + */
>> >> >> +static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
>> >> >> int64_t amin, int64_t amax)
>> >> >
>> >> > IMO rename it to 

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[wm4]

On Sun, 15 Nov 2015 11:10:23 -0500
Ganesh Ajjanagadde  wrote:

> On Sun, Nov 15, 2015 at 11:00 AM, Michael Niedermayer
>  wrote:
> > On Sun, Nov 15, 2015 at 10:24:52AM -0500, Ganesh Ajjanagadde wrote:  
> >> On Sun, Nov 15, 2015 at 10:23 AM, wm4  wrote:  
> >> > On Sun, 15 Nov 2015 10:20:41 -0500
> >> > Ganesh Ajjanagadde  wrote:
> >> >  
> >> >> On Sat, Nov 14, 2015 at 9:01 PM, James Almer  wrote: 
> >> >>  
> >> >> > On 11/14/2015 10:48 PM, Michael Niedermayer wrote:  
> >> >> >> From: Michael Niedermayer 
> >> >> >>
> >> >> >> This should avoid build failures on VS2012
> >> >> >> Feel free to changes this to a different solution
> >> >> >>
> >> >> >> Signed-off-by: Michael Niedermayer 
> >> >> >> ---
> >> >> >>  libavutil/common.h   |   39 ---
> >> >> >>  libavutil/internal.h |   40 
> >> >> >>  2 files changed, 40 insertions(+), 39 deletions(-)
> >> >> >>
> >> >> >> diff --git a/libavutil/common.h b/libavutil/common.h
> >> >> >> index 813fb37..6f0f582 100644
> >> >> >> --- a/libavutil/common.h
> >> >> >> +++ b/libavutil/common.h
> >> >> >> @@ -298,42 +298,6 @@ static av_always_inline av_const double 
> >> >> >> av_clipd_c(double a, double amin, double
> >> >> >>  else   return a;
> >> >> >>  }
> >> >> >>
> >> >> >> -/**
> >> >> >> - * Clip and convert a double value into the long long amin-amax 
> >> >> >> range.
> >> >> >> - * This function is needed because conversion of floating point to 
> >> >> >> integers when
> >> >> >> - * it does not fit in the integer's representation does not 
> >> >> >> necessarily saturate
> >> >> >> - * correctly (usually converted to a cvttsd2si on x86) which 
> >> >> >> saturates numbers
> >> >> >> - * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
> >> >> >> undefined
> >> >> >> - * behavior, allowing this sort of mathematically bogus 
> >> >> >> conversions. This provides
> >> >> >> - * a safe alternative that is slower obviously but assures safety 
> >> >> >> and better
> >> >> >> - * mathematical behavior.
> >> >> >> - * @param a value to clip
> >> >> >> - * @param amin minimum value of the clip range
> >> >> >> - * @param amax maximum value of the clip range
> >> >> >> - * @return clipped value
> >> >> >> - */
> >> >> >> -static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
> >> >> >> int64_t amin, int64_t amax)
> >> >> >> -{
> >> >> >> -int64_t res;
> >> >> >> -#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && 
> >> >> >> ASSERT_LEVEL >= 2
> >> >> >> -if (amin > amax) abort();
> >> >> >> -#endif
> >> >> >> -// INT64_MAX+1,INT64_MIN are exactly representable as IEEE 
> >> >> >> doubles
> >> >> >> -// do range checks first
> >> >> >> -if (a >=  9223372036854775808.0)
> >> >> >> -return amax;
> >> >> >> -if (a <= -9223372036854775808.0)
> >> >> >> -   return amin;
> >> >> >> -
> >> >> >> -// safe to call llrint and clip accordingly
> >> >> >> -res = llrint(a);
> >> >> >> -if (res > amax)
> >> >> >> -return amax;
> >> >> >> -if (res < amin)
> >> >> >> -return amin;
> >> >> >> -return res;
> >> >> >> -}
> >> >> >> -
> >> >> >>  /** Compute ceil(log2(x)).
> >> >> >>   * @param x value used to compute ceil(log2(x))
> >> >> >>   * @return computed ceiling of log2(x)
> >> >> >> @@ -547,9 +511,6 @@ static av_always_inline av_const int 
> >> >> >> av_popcount64_c(uint64_t x)
> >> >> >>  #ifndef av_clipd
> >> >> >>  #   define av_clipd av_clipd_c
> >> >> >>  #endif
> >> >> >> -#ifndef av_rint64_clip
> >> >> >> -#   define av_rint64_clip   av_rint64_clip_c
> >> >> >> -#endif
> >> >> >>  #ifndef av_popcount
> >> >> >>  #   define av_popcount  av_popcount_c
> >> >> >>  #endif
> >> >> >> diff --git a/libavutil/internal.h b/libavutil/internal.h
> >> >> >> index 5c2cd99..cb0c8cd 100644
> >> >> >> --- a/libavutil/internal.h
> >> >> >> +++ b/libavutil/internal.h
> >> >> >> @@ -257,6 +257,46 @@ void avpriv_request_sample(void *avc,
> >> >> >>  #endif
> >> >> >>
> >> >> >>  /**
> >> >> >> + * Clip and convert a double value into the long long amin-amax 
> >> >> >> range.
> >> >> >> + * This function is needed because conversion of floating point to 
> >> >> >> integers when
> >> >> >> + * it does not fit in the integer's representation does not 
> >> >> >> necessarily saturate
> >> >> >> + * correctly (usually converted to a cvttsd2si on x86) which 
> >> >> >> saturates numbers
> >> >> >> + * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
> >> >> >> undefined
> >> >> >> + * behavior, allowing this sort of mathematically bogus 
> >> >> >> conversions. This provides
> >> >> >> + * a safe alternative that is slower obviously but assures safety 
> >> >> >> and better
> >> >> >> + * mathematical behavior.
> >> >> 

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[James Almer]

On 11/15/2015 12:20 PM, Ganesh Ajjanagadde wrote:
> On Sat, Nov 14, 2015 at 9:01 PM, James Almer  wrote:
>> On 11/14/2015 10:48 PM, Michael Niedermayer wrote:
>>> From: Michael Niedermayer 
>>>
>>> This should avoid build failures on VS2012
>>> Feel free to changes this to a different solution
>>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavutil/common.h   |   39 ---
>>>  libavutil/internal.h |   40 
>>>  2 files changed, 40 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/libavutil/common.h b/libavutil/common.h
>>> index 813fb37..6f0f582 100644
>>> --- a/libavutil/common.h
>>> +++ b/libavutil/common.h
>>> @@ -298,42 +298,6 @@ static av_always_inline av_const double 
>>> av_clipd_c(double a, double amin, double
>>>  else   return a;
>>>  }
>>>
>>> -/**
>>> - * Clip and convert a double value into the long long amin-amax range.
>>> - * This function is needed because conversion of floating point to 
>>> integers when
>>> - * it does not fit in the integer's representation does not necessarily 
>>> saturate
>>> - * correctly (usually converted to a cvttsd2si on x86) which saturates 
>>> numbers
>>> - * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
>>> undefined
>>> - * behavior, allowing this sort of mathematically bogus conversions. This 
>>> provides
>>> - * a safe alternative that is slower obviously but assures safety and 
>>> better
>>> - * mathematical behavior.
>>> - * @param a value to clip
>>> - * @param amin minimum value of the clip range
>>> - * @param amax maximum value of the clip range
>>> - * @return clipped value
>>> - */
>>> -static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
>>> int64_t amin, int64_t amax)
>>> -{
>>> -int64_t res;
>>> -#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
>>> -if (amin > amax) abort();
>>> -#endif
>>> -// INT64_MAX+1,INT64_MIN are exactly representable as IEEE doubles
>>> -// do range checks first
>>> -if (a >=  9223372036854775808.0)
>>> -return amax;
>>> -if (a <= -9223372036854775808.0)
>>> -   return amin;
>>> -
>>> -// safe to call llrint and clip accordingly
>>> -res = llrint(a);
>>> -if (res > amax)
>>> -return amax;
>>> -if (res < amin)
>>> -return amin;
>>> -return res;
>>> -}
>>> -
>>>  /** Compute ceil(log2(x)).
>>>   * @param x value used to compute ceil(log2(x))
>>>   * @return computed ceiling of log2(x)
>>> @@ -547,9 +511,6 @@ static av_always_inline av_const int 
>>> av_popcount64_c(uint64_t x)
>>>  #ifndef av_clipd
>>>  #   define av_clipd av_clipd_c
>>>  #endif
>>> -#ifndef av_rint64_clip
>>> -#   define av_rint64_clip   av_rint64_clip_c
>>> -#endif
>>>  #ifndef av_popcount
>>>  #   define av_popcount  av_popcount_c
>>>  #endif
>>> diff --git a/libavutil/internal.h b/libavutil/internal.h
>>> index 5c2cd99..cb0c8cd 100644
>>> --- a/libavutil/internal.h
>>> +++ b/libavutil/internal.h
>>> @@ -257,6 +257,46 @@ void avpriv_request_sample(void *avc,
>>>  #endif
>>>
>>>  /**
>>> + * Clip and convert a double value into the long long amin-amax range.
>>> + * This function is needed because conversion of floating point to 
>>> integers when
>>> + * it does not fit in the integer's representation does not necessarily 
>>> saturate
>>> + * correctly (usually converted to a cvttsd2si on x86) which saturates 
>>> numbers
>>> + * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
>>> undefined
>>> + * behavior, allowing this sort of mathematically bogus conversions. This 
>>> provides
>>> + * a safe alternative that is slower obviously but assures safety and 
>>> better
>>> + * mathematical behavior.
>>> + * @param a value to clip
>>> + * @param amin minimum value of the clip range
>>> + * @param amax maximum value of the clip range
>>> + * @return clipped value
>>> + */
>>> +static av_always_inline av_const int64_t av_rint64_clip_c(double a, 
>>> int64_t amin, int64_t amax)
>>
>> IMO rename it to avpriv_rint64_clip() or even ff_rint64_clip() since it's 
>> inlined
>> and not public/exported.
> 
> Just noticed an issue: Ronald mentioned to me that ffserver and other
> such programs should not use internal API. This therefore needs to be
> exported somehow.

This is an inline function in a header. ffprobe already includes a few
internal headers.
What it should ideally not use is exported but not public API.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[Ganesh Ajjanagadde]

On Sat, Nov 14, 2015 at 9:01 PM, James Almer  wrote:
> On 11/14/2015 10:48 PM, Michael Niedermayer wrote:
>> From: Michael Niedermayer 
>>
>> This should avoid build failures on VS2012
>> Feel free to changes this to a different solution
>>
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavutil/common.h   |   39 ---
>>  libavutil/internal.h |   40 
>>  2 files changed, 40 insertions(+), 39 deletions(-)
>>
>> diff --git a/libavutil/common.h b/libavutil/common.h
>> index 813fb37..6f0f582 100644
>> --- a/libavutil/common.h
>> +++ b/libavutil/common.h
>> @@ -298,42 +298,6 @@ static av_always_inline av_const double 
>> av_clipd_c(double a, double amin, double
>>  else   return a;
>>  }
>>
>> -/**
>> - * Clip and convert a double value into the long long amin-amax range.
>> - * This function is needed because conversion of floating point to integers 
>> when
>> - * it does not fit in the integer's representation does not necessarily 
>> saturate
>> - * correctly (usually converted to a cvttsd2si on x86) which saturates 
>> numbers
>> - * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
>> undefined
>> - * behavior, allowing this sort of mathematically bogus conversions. This 
>> provides
>> - * a safe alternative that is slower obviously but assures safety and better
>> - * mathematical behavior.
>> - * @param a value to clip
>> - * @param amin minimum value of the clip range
>> - * @param amax maximum value of the clip range
>> - * @return clipped value
>> - */
>> -static av_always_inline av_const int64_t av_rint64_clip_c(double a, int64_t 
>> amin, int64_t amax)
>> -{
>> -int64_t res;
>> -#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
>> -if (amin > amax) abort();
>> -#endif
>> -// INT64_MAX+1,INT64_MIN are exactly representable as IEEE doubles
>> -// do range checks first
>> -if (a >=  9223372036854775808.0)
>> -return amax;
>> -if (a <= -9223372036854775808.0)
>> -   return amin;
>> -
>> -// safe to call llrint and clip accordingly
>> -res = llrint(a);
>> -if (res > amax)
>> -return amax;
>> -if (res < amin)
>> -return amin;
>> -return res;
>> -}
>> -
>>  /** Compute ceil(log2(x)).
>>   * @param x value used to compute ceil(log2(x))
>>   * @return computed ceiling of log2(x)
>> @@ -547,9 +511,6 @@ static av_always_inline av_const int 
>> av_popcount64_c(uint64_t x)
>>  #ifndef av_clipd
>>  #   define av_clipd av_clipd_c
>>  #endif
>> -#ifndef av_rint64_clip
>> -#   define av_rint64_clip   av_rint64_clip_c
>> -#endif
>>  #ifndef av_popcount
>>  #   define av_popcount  av_popcount_c
>>  #endif
>> diff --git a/libavutil/internal.h b/libavutil/internal.h
>> index 5c2cd99..cb0c8cd 100644
>> --- a/libavutil/internal.h
>> +++ b/libavutil/internal.h
>> @@ -257,6 +257,46 @@ void avpriv_request_sample(void *avc,
>>  #endif
>>
>>  /**
>> + * Clip and convert a double value into the long long amin-amax range.
>> + * This function is needed because conversion of floating point to integers 
>> when
>> + * it does not fit in the integer's representation does not necessarily 
>> saturate
>> + * correctly (usually converted to a cvttsd2si on x86) which saturates 
>> numbers
>> + * > INT64_MAX to INT64_MIN. The standard marks such conversions as 
>> undefined
>> + * behavior, allowing this sort of mathematically bogus conversions. This 
>> provides
>> + * a safe alternative that is slower obviously but assures safety and better
>> + * mathematical behavior.
>> + * @param a value to clip
>> + * @param amin minimum value of the clip range
>> + * @param amax maximum value of the clip range
>> + * @return clipped value
>> + */
>> +static av_always_inline av_const int64_t av_rint64_clip_c(double a, int64_t 
>> amin, int64_t amax)
>
> IMO rename it to avpriv_rint64_clip() or even ff_rint64_clip() since it's 
> inlined
> and not public/exported.

Just noticed an issue: Ronald mentioned to me that ffserver and other
such programs should not use internal API. This therefore needs to be
exported somehow.

>
>> +{
>> +int64_t res;
>> +#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && ASSERT_LEVEL >= 2
>> +if (amin > amax) abort();
>> +#endif
>> +// INT64_MAX+1,INT64_MIN are exactly representable as IEEE doubles
>> +// do range checks first
>> +if (a >=  9223372036854775808.0)
>> +return amax;
>> +if (a <= -9223372036854775808.0)
>> +   return amin;
>> +
>> +// safe to call llrint and clip accordingly
>> +res = llrint(a);
>> +if (res > amax)
>> +return amax;
>> +if (res < amin)
>> +return amin;
>> +return res;
>> +}
>> +
>> +#ifndef av_rint64_clip
>> +#   define av_rint64_clip   av_rint64_clip_c
>> +#endif
>
> No need for this chunk.
>
>> +
>> +/**
>>   * A wrapper for 

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/faandct: use more accurate constants

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 10:10 AM, Ganesh Ajjanagadde  wrote:
> On Fri, Nov 13, 2015 at 6:24 PM, Ganesh Ajjanagadde  wrote:
>> On Fri, Nov 13, 2015 at 6:17 PM, Michael Niedermayer
>>  wrote:
>>> On Fri, Nov 13, 2015 at 11:42:31AM -0500, Ganesh Ajjanagadde wrote:
 This guarantees a "best effort precision".

 Signed-off-by: Ganesh Ajjanagadde 
 ---
  libavcodec/faandct.c | 29 +
  1 file changed, 13 insertions(+), 16 deletions(-)

 diff --git a/libavcodec/faandct.c b/libavcodec/faandct.c
 index 473bc1d..c8ea328 100644
 --- a/libavcodec/faandct.c
 +++ b/libavcodec/faandct.c
 @@ -31,23 +31,20 @@

  typedef float FLOAT;

 -//numbers generated by simple c code (not as accurate as they could be)
 -/*
 -for(i=0; i<8; i++){
 -printf("#define B%d %1.20llf\n", i, (long 
 double)1.0/(cosl(i*acosl(-1.0)/(long double)16.0)*sqrtl(2)));
 -}
 +/* numbers generated by arbitrary precision arithmetic followed by 
 truncation
 +to 36 fractional digits (enough for a 128-bit IEEE quad, see 
 /usr/include/math.h
 +for this approach). This guarantees a "best effort precision".
  */
 -#define B0 1.
 -#define B1 0.72095982200694791383 // (cos(pi*1/16)sqrt(2))^-1
 -#define B2 0.76536686473017954350 // (cos(pi*2/16)sqrt(2))^-1
 -#define B3 0.85043009476725644878 // (cos(pi*3/16)sqrt(2))^-1
 -#define B4 1. // (cos(pi*4/16)sqrt(2))^-1
 -#define B5 1.27275858057283393842 // (cos(pi*5/16)sqrt(2))^-1
 -#define B6 1.84775906502257351242 // (cos(pi*6/16)sqrt(2))^-1
 -#define B7 3.62450978541155137218 // (cos(pi*7/16)sqrt(2))^-1
 -
 -
 -#define A1 0.70710678118654752438 // cos(pi*4/16)
 +#define B0 1.L
 +#define B1 0.720959822006947913789091890943021267L // 
 (cos(pi*1/16)sqrt(2))^-1
 +#define B2 0.765366864730179543456919968060797734L // 
 (cos(pi*2/16)sqrt(2))^-1
 +#define B3 0.850430094767256448766702844371412325L // 
 (cos(pi*3/16)sqrt(2))^-1
 +#define B4 1.L // 
 (cos(pi*4/16)sqrt(2))^-1
 +#define B5 1.272758580572833938461007018281767032L // 
 (cos(pi*5/16)sqrt(2))^-1
 +#define B6 1.847759065022573512256366378793576574L // 
 (cos(pi*6/16)sqrt(2))^-1
 +#define B7 3.624509785411551372409941227504289587L // 
 (cos(pi*7/16)sqrt(2))^-1
>>>
>>> iam not sure how portable x.yL is
>>> otherwise should be ok
>>
>> Technically C89, see e.g
>> http://port70.net/~nsz/c/c89/c89-draft.html#3.1.3.1, wikipedia, or
>> http://en.cppreference.com/w/cpp/language/floating_literal.
>> Nevertheless, will wait for comments especially from people who use
>> Microsoft stuff.
>
> Is portable, since recent commit by me a5202bc9 for the Bessel
> function from boost has such a literal (line 118, swresample/resample)
> and does not seem to have caused build failures anywhere. Actually,
> there the L was an artifact left over from Boost and I will remove it.
>
> Will push in light of this. Also will push the trivial removal of the
> L leftover in swresample.

pushed both, thanks.

>
>>
>>>
>>> [...]
>>> --
>>> 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
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[Nicolas George]

Le quintidi 25 brumaire, an CCXXIV, wm4 a écrit :
> Or even better, just delete ffserver.

Please refrain from gratuitous flamebait.

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] avutil: Move av_rint64_clip_* to internal.h

[Clément Bœsch]

On Sun, Nov 15, 2015 at 10:24:52AM -0500, Ganesh Ajjanagadde wrote:
[...]
> >> > IMO rename it to avpriv_rint64_clip() or even ff_rint64_clip() since 
> >> > it's inlined
> >> > and not public/exported.
> >>
> >> Just noticed an issue: Ronald mentioned to me that ffserver and other
> >> such programs should not use internal API. This therefore needs to be
> >> exported somehow.
> >
> > If only ffserver needs it, implement it there?
> >
> > Or even better, just delete ffserver.
> 
> I have repeated this many times in the past, but ffserver was given as
> a mere illustration. cmdutils.c also needs it

cmdutils.c has the same problem as any ff tool; it should not use internal
API.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/faandct: use typedef instead of #define

[Ganesh Ajjanagadde]

On Fri, Nov 13, 2015 at 12:05 PM, Ganesh Ajjanagadde  wrote:
> On Fri, Nov 13, 2015 at 11:58 AM, Nicolas George  wrote:
>> Le tridi 23 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>>> See e.g 
>>> https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
>>> for rationale.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavcodec/faandct.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Any reason not to just replace FLOAT with float and be done?
>
> Assumed Michael kept it open in case we wish to transition to double
> precision, in which case diff would be smaller. If float is all we
> want for the foreseeable future, will change on your lines.

@Michael: are you fine with replacing all FLOAT with float?

>
>>
>> Regards,
>>
>> --
>>   Nicolas George
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] configure+libm.h: add hypot emulation

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 10:56 AM, Michael Niedermayer
 wrote:
> On Sun, Nov 15, 2015 at 10:03:37AM -0500, Ganesh Ajjanagadde wrote:
>> It is known that the naive sqrt(x*x + y*y) approach for computing the
>> hypotenuse suffers from overflow and accuracy issues, see e.g
>> http://www.johndcook.com/blog/2010/06/02/whats-so-hard-about-finding-a-hypotenuse/.
>> This adds hypot support to FFmpeg, a C99 function.
>>
>> On platforms without hypot, this patch does a reaonable workaround, that
>> although not as accurate as GNU libm, is readable and does not suffer
>> from the overflow issue. Improvements can be made separately.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  configure|  2 ++
>>  libavutil/libm.h | 23 +++
>>  2 files changed, 25 insertions(+)
>>
>> diff --git a/configure b/configure
>> index d518b21..45df724 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1774,6 +1774,7 @@ MATH_FUNCS="
>>  exp2
>>  exp2f
>>  expf
>> +hypot
>>  isinf
>>  isnan
>>  ldexpf
>> @@ -5309,6 +5310,7 @@ disabled crystalhd || check_lib 
>> libcrystalhd/libcrystalhd_if.h DtsCrystalHDVersi
>>
>>  atan2f_args=2
>>  copysign_args=2
>> +hypot_args=2
>>  ldexpf_args=2
>>  powf_args=2
>>
>> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> index 6c17b28..f7a2b41 100644
>> --- a/libavutil/libm.h
>> +++ b/libavutil/libm.h
>> @@ -102,6 +102,29 @@ static av_always_inline av_const int isnan(float x)
>>  }
>>  #endif /* HAVE_ISNAN */
>>
>> +#if !HAVE_HYPOT
>> +#undef hypot
>> +static inline av_const double hypot(double x, double y)
>> +{
>> +double ret, temp;
>> +x = fabs(x);
>> +y = fabs(y);
>> +
>> +if (isinf(x) || isinf(y))
>> +return av_int2double(0x7ff0);
>
> if either is NaN the result should be NaN i think
> return x+y
> might achive this

No, quoting the man page/standard:
   If x or y is an infinity, positive infinity is returned.

   If x or y is a NaN, and the other argument is not an infinity,
a NaN is returned.

The inf case is handled first because of this.
Otherwise, NaN will anyway propagate and taint the result.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

[wm4]

On Sun, 15 Nov 2015 15:51:30 +0700
Muhammad Faiz  wrote:

> From ae6b2c45faac830636602a696925566db03541a2 Mon Sep 17 00:00:00 2001
> From: Muhammad Faiz 
> Date: Sun, 15 Nov 2015 12:06:12 +0700
> Subject: [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket
> 
> add AV_PKT_FLAG_FRAME
> add av_packet_encode_frame()
> add av_packet_decode_frame()
> add av_packet_get_frame()
> 
> use pointer to AVFrame instead
> properly padded with AV_INPUT_BUFFER_PADDING_SIZE
> 
> modify wrapped_avframe encoder
> implement wrapped_avframe decoder
> implement wrapped_avframe_audio encoder/decoder
> 
> fix avformat/yuv4mpegenc to use av_packet_get_frame()
> ---
>  doc/APIchanges   |  5 +++
>  libavcodec/Makefile  |  3 ++
>  libavcodec/allcodecs.c   |  3 +-
>  libavcodec/avcodec.h | 29 
>  libavcodec/avpacket.c| 63 ++-
>  libavcodec/codec_desc.c  |  7 
>  libavcodec/version.h |  2 +-
>  libavcodec/wrapped_avframe.c | 78 
> ++--
>  libavformat/yuv4mpegenc.c|  5 +--
>  9 files changed, 173 insertions(+), 22 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 14b96ce..9efd44e 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,11 @@ libavutil: 2015-08-28
>  
>  API changes, most recent first:
>  
> +2015-11-15 - lavc 57.16.100 - avcodec.h
> +  Add AV_PKT_FLAG_FRAME.
> +  Add av_packet_encode_frame(), av_packet_decode_frame(),
> +  and av_packet_get_frame().
> +
>  2015-10-29 - lavc 57.12.100 / 57.8.0 - avcodec.h
>xx - Deprecate av_free_packet(). Use av_packet_unref() as replacement,
> it resets the packet in a more consistent way.
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 68a573f..65d8621 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -577,7 +577,10 @@ OBJS-$(CONFIG_WMV2_ENCODER)+= wmv2enc.o 
> wmv2.o \
>msmpeg4.o msmpeg4enc.o 
> msmpeg4data.o
>  OBJS-$(CONFIG_WNV1_DECODER)+= wnv1.o
>  OBJS-$(CONFIG_WS_SND1_DECODER) += ws-snd1.o
> +OBJS-$(CONFIG_WRAPPED_AVFRAME_DECODER) += wrapped_avframe.o
>  OBJS-$(CONFIG_WRAPPED_AVFRAME_ENCODER) += wrapped_avframe.o
> +OBJS-$(CONFIG_WRAPPED_AVFRAME_AUDIO_DECODER) += wrapped_avframe.o
> +OBJS-$(CONFIG_WRAPPED_AVFRAME_AUDIO_ENCODER) += wrapped_avframe.o
>  OBJS-$(CONFIG_XAN_DPCM_DECODER)+= dpcm.o
>  OBJS-$(CONFIG_XAN_WC3_DECODER) += xan.o
>  OBJS-$(CONFIG_XAN_WC4_DECODER) += xxan.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 9f60d7c..836fd20 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -342,7 +342,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(VP9,   vp9);
>  REGISTER_DECODER(VQA,   vqa);
>  REGISTER_DECODER(WEBP,  webp);
> -REGISTER_ENCODER(WRAPPED_AVFRAME,   wrapped_avframe);
> +REGISTER_ENCDEC (WRAPPED_AVFRAME,   wrapped_avframe);
>  REGISTER_ENCDEC (WMV1,  wmv1);
>  REGISTER_ENCDEC (WMV2,  wmv2);
>  REGISTER_DECODER(WMV3,  wmv3);
> @@ -446,6 +446,7 @@ void avcodec_register_all(void)
>  REGISTER_ENCDEC (WMAV1, wmav1);
>  REGISTER_ENCDEC (WMAV2, wmav2);
>  REGISTER_DECODER(WMAVOICE,  wmavoice);
> +REGISTER_ENCDEC (WRAPPED_AVFRAME_AUDIO, wrapped_avframe_audio);
>  REGISTER_DECODER(WS_SND1,   ws_snd1);
>  REGISTER_DECODER(XMA1,  xma1);
>  REGISTER_DECODER(XMA2,  xma2);
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 1af17ed..a318dc5 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -550,6 +550,7 @@ enum AVCodecID {
>  * stream (only used by libavformat) */
>  AV_CODEC_ID_FFMETADATA = 0x21000,   ///< Dummy codec for streams 
> containing only metadata information.
>  AV_CODEC_ID_WRAPPED_AVFRAME = 0x21001, ///< Passthrough codec, AVFrames 
> wrapped in AVPacket
> +AV_CODEC_ID_WRAPPED_AVFRAME_AUDIO = 0x21002,
>  };
>  
>  /**
> @@ -1442,6 +1443,7 @@ typedef struct AVPacket {
>  } AVPacket;
>  #define AV_PKT_FLAG_KEY 0x0001 ///< The packet contains a keyframe
>  #define AV_PKT_FLAG_CORRUPT 0x0002 ///< The packet content is corrupted
> +#define AV_PKT_FLAG_FRAME   0x0004 ///< The packet contains an AVFrame frame

I'd prefer something more "neutral", like a name that indicates that
the packet was constructed from verified data (as opposed to being read
plainly from a file).

>  
>  enum AVSideDataParamChangeFlags {
>  AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
> @@ -4103,6 +4105,33 @@ int av_packet_copy_props(AVPacket *dst, const AVPacket 
> *src);
>  void av_packet_rescale_ts(AVPacket *pkt, AVRational tb_src, AVRational 
> tb_dst);
>  
>  /**
> + * 

Re: [FFmpeg-devel] [PATCH 2/4] lavf/utils: avoid decoding a frame to get the codec parameters

[Ronald S. Bultje]

Hi,

On Sun, Nov 15, 2015 at 4:49 AM, Matthieu Bouron 
wrote:

> On Mon, Nov 02, 2015 at 07:56:50AM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Mon, Nov 2, 2015 at 5:45 AM, Matthieu Bouron <
> matthieu.bou...@gmail.com>
> > wrote:
> >
> > > From: Matthieu Bouron 
> > >
> > > Avoid decoding a frame to get the codec parameters while the codec
> > > supports FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM. This is particulary useful
> > > to avoid decoding twice images (once in avformat_find_stream_info and
> > > once when the actual decode is made).
> > > ---
> > >  libavformat/utils.c | 12 
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > > index 5c4d452..ba62f2b 100644
> > > --- a/libavformat/utils.c
> > > +++ b/libavformat/utils.c
> > > @@ -2695,6 +2695,8 @@ static int try_decode_frame(AVFormatContext *s,
> > > AVStream *st, AVPacket *avpkt,
> > >  AVFrame *frame = av_frame_alloc();
> > >  AVSubtitle subtitle;
> > >  AVPacket pkt = *avpkt;
> > > +int do_skip_frame = 0;
> > > +enum AVDiscard skip_frame;
> > >
> > >  if (!frame)
> > >  return AVERROR(ENOMEM);
> > > @@ -2733,6 +2735,12 @@ static int try_decode_frame(AVFormatContext *s,
> > > AVStream *st, AVPacket *avpkt,
> > >  goto fail;
> > >  }
> > >
> > > +if (st->codec->codec->caps_internal &
> > > FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) {
> > > +do_skip_frame = 1;
> > > +skip_frame = st->codec->skip_frame;
> > > +st->codec->skip_frame = AVDISCARD_ALL;
> > > +}
> > > +
> > >  while ((pkt.size > 0 || (!pkt.data && got_picture)) &&
> > > ret >= 0 &&
> > > (!has_codec_parameters(st, NULL) ||
> > > !has_decode_delay_been_guessed(st) ||
> > > @@ -2768,6 +2776,10 @@ static int try_decode_frame(AVFormatContext *s,
> > > AVStream *st, AVPacket *avpkt,
> > >  ret = -1;
> > >
> > >  fail:
> > > +if (do_skip_frame) {
> > > +st->codec->skip_frame = skip_frame;
> > > +}
> > > +
> > >  av_frame_free();
> > >  return ret;
> > >  }
> > > --
> > > 2.6.2
> >
> >
> > I think we need an assert in the try_decode loop to ensure that it indeed
> > did fill all the params. This is to prevent the case where someone adds a
> > new "thing" to the list of things required for find_stream_info to
> succeed,
> > and forgets to update the codecs.
>
> While the codec_has_parameters function fits that role, it does not check
> all codec parameters as they can be codec dependant.
>
> I'm not sure if we can create a generic rule here for the same reason as
> above, as the parameters set can be codec specific and maybe stream
> specific.
>
> Having some fate test to cover this area seems to be another option but
> would
> require to inspect all the relevant parameters of AVCodecContext depending
> on the codec and a lot of different streams.


I don't care about _which_ parameters were filled. The goal of this option
is only directly to fill parameters, but the purpose goes far beyond that.
The indirect goal of this change is to _not_ call try_decode_frame() for
certain image codecs. Whether they do that by dancing on the table or by
filling AVCodecContext parameters when a special flag is set, is merely an
implementation detail.

I want the test to confirm that we did not call try_decode_frame() when the
skip-flag was set. It seems easiest to me that we check that by adding a
one-line assert, for example inside try_decode_frame, that checks that the
flag does not apply to this codec, right? If the assert triggers, clearly
something broke, and either the flag should be removed, or the check before
starting try_decode_frame fixed.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 11:19 AM, wm4  wrote:
> On Sun, 15 Nov 2015 11:10:23 -0500
> Ganesh Ajjanagadde  wrote:
>
>> On Sun, Nov 15, 2015 at 11:00 AM, Michael Niedermayer
>>  wrote:
>> > On Sun, Nov 15, 2015 at 10:24:52AM -0500, Ganesh Ajjanagadde wrote:
>> >> On Sun, Nov 15, 2015 at 10:23 AM, wm4  wrote:
>> >> > On Sun, 15 Nov 2015 10:20:41 -0500
>> >> > Ganesh Ajjanagadde  wrote:
>> >> >
>> >> >> On Sat, Nov 14, 2015 at 9:01 PM, James Almer  wrote:
>> >> >> > On 11/14/2015 10:48 PM, Michael Niedermayer wrote:
>> >> >> >> From: Michael Niedermayer 
>> >> >> >>
>> >> >> >> This should avoid build failures on VS2012
>> >> >> >> Feel free to changes this to a different solution
>> >> >> >>
>> >> >> >> Signed-off-by: Michael Niedermayer 
>> >> >> >> ---
>> >> >> >>  libavutil/common.h   |   39 ---
>> >> >> >>  libavutil/internal.h |   40 
>> >> >> >> 
>> >> >> >>  2 files changed, 40 insertions(+), 39 deletions(-)
>> >> >> >>
>> >> >> >> diff --git a/libavutil/common.h b/libavutil/common.h
>> >> >> >> index 813fb37..6f0f582 100644
>> >> >> >> --- a/libavutil/common.h
>> >> >> >> +++ b/libavutil/common.h
>> >> >> >> @@ -298,42 +298,6 @@ static av_always_inline av_const double 
>> >> >> >> av_clipd_c(double a, double amin, double
>> >> >> >>  else   return a;
>> >> >> >>  }
>> >> >> >>
>> >> >> >> -/**
>> >> >> >> - * Clip and convert a double value into the long long amin-amax 
>> >> >> >> range.
>> >> >> >> - * This function is needed because conversion of floating point to 
>> >> >> >> integers when
>> >> >> >> - * it does not fit in the integer's representation does not 
>> >> >> >> necessarily saturate
>> >> >> >> - * correctly (usually converted to a cvttsd2si on x86) which 
>> >> >> >> saturates numbers
>> >> >> >> - * > INT64_MAX to INT64_MIN. The standard marks such conversions 
>> >> >> >> as undefined
>> >> >> >> - * behavior, allowing this sort of mathematically bogus 
>> >> >> >> conversions. This provides
>> >> >> >> - * a safe alternative that is slower obviously but assures safety 
>> >> >> >> and better
>> >> >> >> - * mathematical behavior.
>> >> >> >> - * @param a value to clip
>> >> >> >> - * @param amin minimum value of the clip range
>> >> >> >> - * @param amax maximum value of the clip range
>> >> >> >> - * @return clipped value
>> >> >> >> - */
>> >> >> >> -static av_always_inline av_const int64_t av_rint64_clip_c(double 
>> >> >> >> a, int64_t amin, int64_t amax)
>> >> >> >> -{
>> >> >> >> -int64_t res;
>> >> >> >> -#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && 
>> >> >> >> ASSERT_LEVEL >= 2
>> >> >> >> -if (amin > amax) abort();
>> >> >> >> -#endif
>> >> >> >> -// INT64_MAX+1,INT64_MIN are exactly representable as IEEE 
>> >> >> >> doubles
>> >> >> >> -// do range checks first
>> >> >> >> -if (a >=  9223372036854775808.0)
>> >> >> >> -return amax;
>> >> >> >> -if (a <= -9223372036854775808.0)
>> >> >> >> -   return amin;
>> >> >> >> -
>> >> >> >> -// safe to call llrint and clip accordingly
>> >> >> >> -res = llrint(a);
>> >> >> >> -if (res > amax)
>> >> >> >> -return amax;
>> >> >> >> -if (res < amin)
>> >> >> >> -return amin;
>> >> >> >> -return res;
>> >> >> >> -}
>> >> >> >> -
>> >> >> >>  /** Compute ceil(log2(x)).
>> >> >> >>   * @param x value used to compute ceil(log2(x))
>> >> >> >>   * @return computed ceiling of log2(x)
>> >> >> >> @@ -547,9 +511,6 @@ static av_always_inline av_const int 
>> >> >> >> av_popcount64_c(uint64_t x)
>> >> >> >>  #ifndef av_clipd
>> >> >> >>  #   define av_clipd av_clipd_c
>> >> >> >>  #endif
>> >> >> >> -#ifndef av_rint64_clip
>> >> >> >> -#   define av_rint64_clip   av_rint64_clip_c
>> >> >> >> -#endif
>> >> >> >>  #ifndef av_popcount
>> >> >> >>  #   define av_popcount  av_popcount_c
>> >> >> >>  #endif
>> >> >> >> diff --git a/libavutil/internal.h b/libavutil/internal.h
>> >> >> >> index 5c2cd99..cb0c8cd 100644
>> >> >> >> --- a/libavutil/internal.h
>> >> >> >> +++ b/libavutil/internal.h
>> >> >> >> @@ -257,6 +257,46 @@ void avpriv_request_sample(void *avc,
>> >> >> >>  #endif
>> >> >> >>
>> >> >> >>  /**
>> >> >> >> + * Clip and convert a double value into the long long amin-amax 
>> >> >> >> range.
>> >> >> >> + * This function is needed because conversion of floating point to 
>> >> >> >> integers when
>> >> >> >> + * it does not fit in the integer's representation does not 
>> >> >> >> necessarily saturate
>> >> >> >> + * correctly (usually converted to a cvttsd2si on x86) which 
>> >> >> >> saturates numbers
>> >> >> >> + * > INT64_MAX to INT64_MIN. The standard marks such conversions 
>> >> >> >> as undefined
>> >> >> >> + * behavior, allowing this sort of mathematically bogus 
>> >> >> >> 

Re: [FFmpeg-devel] [PATCHv2] configure+libm.h: add hypot emulation

[Michael Niedermayer]

On Sun, Nov 15, 2015 at 11:01:58AM -0500, Ganesh Ajjanagadde wrote:
> On Sun, Nov 15, 2015 at 10:56 AM, Michael Niedermayer
>  wrote:
> > On Sun, Nov 15, 2015 at 10:03:37AM -0500, Ganesh Ajjanagadde wrote:
> >> It is known that the naive sqrt(x*x + y*y) approach for computing the
> >> hypotenuse suffers from overflow and accuracy issues, see e.g
> >> http://www.johndcook.com/blog/2010/06/02/whats-so-hard-about-finding-a-hypotenuse/.
> >> This adds hypot support to FFmpeg, a C99 function.
> >>
> >> On platforms without hypot, this patch does a reaonable workaround, that
> >> although not as accurate as GNU libm, is readable and does not suffer
> >> from the overflow issue. Improvements can be made separately.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  configure|  2 ++
> >>  libavutil/libm.h | 23 +++
> >>  2 files changed, 25 insertions(+)
> >>
> >> diff --git a/configure b/configure
> >> index d518b21..45df724 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -1774,6 +1774,7 @@ MATH_FUNCS="
> >>  exp2
> >>  exp2f
> >>  expf
> >> +hypot
> >>  isinf
> >>  isnan
> >>  ldexpf
> >> @@ -5309,6 +5310,7 @@ disabled crystalhd || check_lib 
> >> libcrystalhd/libcrystalhd_if.h DtsCrystalHDVersi
> >>
> >>  atan2f_args=2
> >>  copysign_args=2
> >> +hypot_args=2
> >>  ldexpf_args=2
> >>  powf_args=2
> >>
> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
> >> index 6c17b28..f7a2b41 100644
> >> --- a/libavutil/libm.h
> >> +++ b/libavutil/libm.h
> >> @@ -102,6 +102,29 @@ static av_always_inline av_const int isnan(float x)
> >>  }
> >>  #endif /* HAVE_ISNAN */
> >>
> >> +#if !HAVE_HYPOT
> >> +#undef hypot
> >> +static inline av_const double hypot(double x, double y)
> >> +{
> >> +double ret, temp;
> >> +x = fabs(x);
> >> +y = fabs(y);
> >> +
> >> +if (isinf(x) || isinf(y))
> >> +return av_int2double(0x7ff0);
> >
> > if either is NaN the result should be NaN i think
> > return x+y
> > might achive this
> 
> No, quoting the man page/standard:
>If x or y is an infinity, positive infinity is returned.
> 
>If x or y is a NaN, and the other argument is not an infinity,
> a NaN is returned.

indeed, the spec says thats how it should be.

this is not what i expected though and renders the function
problematic in practice IMHO.
For example a big use of NaN is to detect errors.
One does a big complicated computation and if at the end the result is
NaN or +-Inf then one knows there was something wrong in it.
if NaN is infective then any computation that returns it can reliably
be detected. These exceptions in C like hypot() break this.
1/hypot(x,y) should be NaN if either x or y was NaN

also mathematically its wrong to ignore a NaN argument
consider
hypot(sqrt(-x), sqrt(x)) for x->infinite

of course theres nothing we can or should do about hypot() its defined
in C as it is defined but its something one should be aware of if
one expects that NaNs can be used as a reliable means to detect
NaNs from intermediate steps of a complicated calculation

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: fix overriding packet duration warning

[Michael Niedermayer]

On Sun, Nov 15, 2015 at 04:04:42PM +0700, Muhammad Faiz wrote:
> no warning when packet duration is valid
> 
> patch attached

> From 789e9f0e93a246fd820401e6c298835bf40dc0c3 Mon Sep 17 00:00:00 2001
> From: Muhammad Faiz 
> Date: Sun, 15 Nov 2015 15:25:43 +0700
> Subject: [PATCH] ffmpeg: fix overriding packet duration warning
> 
> no warning when packet duration is valid
> ---
>  ffmpeg.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 3341777..5b9e38e 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -673,10 +673,11 @@ static void write_frame(AVFormatContext *s, AVPacket 
> *pkt, OutputStream *ost)
>  }
>  
>  if (ost->frame_rate.num && ost->is_cfr) {
> -if (pkt->duration > 0)
> +int64_t new_duration = av_rescale_q(1, av_inv_q(ost->frame_rate),
> +ost->st->time_base);
> +if (pkt->duration > 0 && pkt->duration != new_duration)
>  av_log(NULL, AV_LOG_WARNING, "Overriding packet duration by 
> frame rate, this should not happen\n");
> -pkt->duration = av_rescale_q(1, av_inv_q(ost->frame_rate),
> - ost->st->time_base);
> +pkt->duration = new_duration;

does it work to leave the duration instead of overriding if its
already set ?
i mean the new cfr duration code is certainly not correct for many
common cases (like 24000/1001 framerates at a 90khz timebase) so
overriding things by it if something else already set a (more correct?)
duration might be a bad idea

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- 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 v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

[wm4]

On Sun, 15 Nov 2015 12:22:57 +0100
Hendrik Leppkes  wrote:

> On Sun, Nov 15, 2015 at 10:40 AM, Muhammad Faiz  wrote:
> > On Sun, Nov 15, 2015 at 4:24 PM, Hendrik Leppkes  
> > wrote:  
> >> On Sun, Nov 15, 2015 at 9:51 AM, Muhammad Faiz  wrote:  
> >>> add AV_PKT_FLAG_FRAME
> >>> add av_packet_encode_frame()
> >>> add av_packet_decode_frame()
> >>> add av_packet_get_frame()
> >>>
> >>> use pointer to AVFrame instead
> >>> properly padded with AV_INPUT_BUFFER_PADDING_SIZE
> >>>
> >>> modify wrapped_avframe encoder
> >>> implement wrapped_avframe decoder
> >>> implement wrapped_avframe_audio encoder/decoder
> >>>
> >>> fix avformat/yuv4mpegenc to use av_packet_get_frame()
> >>>
> >>> patch attached
> >>>  
> >>
> >> We already have 3 different API approaches to pass AVFrames as
> >> AVPackets, we really don't need any more.  
> >
> > What are they?  
> 
> - The deprecated AVFMT_RAWPICTURE deal, which was a giant hack and is
> luckily leaving us eventually.
> - The "uncoded frame" API introduced in ffmpeg a while ago
> - And now the wrapped_avframe dealy
> 

These should all be replaced with wrapped avframe. (The uncoded frame
API should be deprecated.)

> We really don't need more public API functions to deal with this
> stuff, its already confusing enough as it is.
> Use one of the existing ways to do what you want to do, but don't
> introduce new public API that just exists for lavd/lavfi, where a
> filter pretends to be a "demuxer".

And some other places. ffmpeg.c, where encoding to a raw and writing
to a null output would make fate slower, and y4m, which would become
slower as well.

> Its unlikely to ever be useful outside of this use-case. Public API
> needs to be considered carefully, because once it exists, its here to
> stay.

Agreed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

[Hendrik Leppkes]

On Sun, Nov 15, 2015 at 10:40 AM, Muhammad Faiz  wrote:
> On Sun, Nov 15, 2015 at 4:24 PM, Hendrik Leppkes  wrote:
>> On Sun, Nov 15, 2015 at 9:51 AM, Muhammad Faiz  wrote:
>>> add AV_PKT_FLAG_FRAME
>>> add av_packet_encode_frame()
>>> add av_packet_decode_frame()
>>> add av_packet_get_frame()
>>>
>>> use pointer to AVFrame instead
>>> properly padded with AV_INPUT_BUFFER_PADDING_SIZE
>>>
>>> modify wrapped_avframe encoder
>>> implement wrapped_avframe decoder
>>> implement wrapped_avframe_audio encoder/decoder
>>>
>>> fix avformat/yuv4mpegenc to use av_packet_get_frame()
>>>
>>> patch attached
>>>
>>
>> We already have 3 different API approaches to pass AVFrames as
>> AVPackets, we really don't need any more.
>
> What are they?

- The deprecated AVFMT_RAWPICTURE deal, which was a giant hack and is
luckily leaving us eventually.
- The "uncoded frame" API introduced in ffmpeg a while ago
- And now the wrapped_avframe dealy

We really don't need more public API functions to deal with this
stuff, its already confusing enough as it is.
Use one of the existing ways to do what you want to do, but don't
introduce new public API that just exists for lavd/lavfi, where a
filter pretends to be a "demuxer".

Its unlikely to ever be useful outside of this use-case. Public API
needs to be considered carefully, because once it exists, its here to
stay.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec

[Rainer Hochecker]

I got a mpegts file with hevc that fails estimating duration. Increasing number 
of
retries fixes the issue.

Rainer

---
 libavformat/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 251b2c6..f8ddaf7 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2463,7 +2463,7 @@ static void 
estimate_timings_from_bit_rate(AVFormatContext *ic)
 }
 
 #define DURATION_MAX_READ_SIZE 25LL
-#define DURATION_MAX_RETRY 4
+#define DURATION_MAX_RETRY 6
 
 /* only usable for MPEG-PS streams */
 static void estimate_timings_from_pts(AVFormatContext *ic, int64_t old_offset)
-- 
2.5.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 2/3] avdevice/lavfi: use wrapped_avframe

[Muhammad Faiz]

use wrapped_avframe on both audio and video

remove metadata because it already exists in
the underlying AVFrame

patch attached
From cd288bce6b433f1e3cbdd29a06e5d6247f7bf33e Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Sun, 15 Nov 2015 09:09:39 +0700
Subject: [PATCH v2 2/3] avdevice/lavfi: use wrapped_avframe

use wrapped_avframe on both audio and video

remove metadata because it already exists in
the underlying AVFrame
---
 libavdevice/lavfi.c   | 63 ++-
 libavdevice/version.h |  2 +-
 2 files changed, 8 insertions(+), 57 deletions(-)

diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index 3453b4d..943aec1 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -311,28 +311,20 @@ av_cold static int lavfi_read_header(AVFormatContext 
*avctx)
 st->codec->codec_type = link->type;
 avpriv_set_pts_info(st, 64, link->time_base.num, link->time_base.den);
 if (link->type == AVMEDIA_TYPE_VIDEO) {
-st->codec->codec_id   = AV_CODEC_ID_RAWVIDEO;
+st->codec->codec_id   = AV_CODEC_ID_WRAPPED_AVFRAME;
 st->codec->pix_fmt= link->format;
 st->codec->time_base  = link->time_base;
 st->codec->width  = link->w;
 st->codec->height = link->h;
 st   ->sample_aspect_ratio =
 st->codec->sample_aspect_ratio = link->sample_aspect_ratio;
-avctx->probesize = FFMAX(avctx->probesize,
- link->w * link->h *
- 
av_get_padded_bits_per_pixel(av_pix_fmt_desc_get(link->format)) *
- 30);
 } else if (link->type == AVMEDIA_TYPE_AUDIO) {
-st->codec->codec_id= av_get_pcm_codec(link->format, -1);
+st->codec->codec_id= AV_CODEC_ID_WRAPPED_AVFRAME_AUDIO;
 st->codec->channels= avfilter_link_get_channels(link);
 st->codec->sample_fmt  = link->format;
 st->codec->sample_rate = link->sample_rate;
 st->codec->time_base   = link->time_base;
 st->codec->channel_layout = link->channel_layout;
-if (st->codec->codec_id == AV_CODEC_ID_NONE)
-av_log(avctx, AV_LOG_ERROR,
-   "Could not find PCM codec for sample format %s.\n",
-   av_get_sample_fmt_name(link->format));
 }
 }
 
@@ -381,10 +373,7 @@ static int lavfi_read_packet(AVFormatContext *avctx, 
AVPacket *pkt)
 double min_pts = DBL_MAX;
 int stream_idx, min_pts_sink_idx = 0;
 AVFrame *frame = lavfi->decoded_frame;
-AVPicture pict;
-AVDictionary *frame_metadata;
 int ret, i;
-int size = 0;
 
 if (lavfi->subcc_packet.size) {
 *pkt = lavfi->subcc_packet;
@@ -429,45 +418,10 @@ static int lavfi_read_packet(AVFormatContext *avctx, 
AVPacket *pkt)
 av_buffersink_get_frame_flags(lavfi->sinks[min_pts_sink_idx], frame, 0);
 stream_idx = lavfi->sink_stream_map[min_pts_sink_idx];
 
-if (frame->width /* FIXME best way of testing a video */) {
-size = avpicture_get_size(frame->format, frame->width, frame->height);
-if ((ret = av_new_packet(pkt, size)) < 0)
-return ret;
-
-memcpy(pict.data, frame->data, 4*sizeof(frame->data[0]));
-memcpy(pict.linesize, frame->linesize, 4*sizeof(frame->linesize[0]));
-
-avpicture_layout(, frame->format, frame->width, frame->height,
- pkt->data, size);
-} else if (av_frame_get_channels(frame) /* FIXME test audio */) {
-size = frame->nb_samples * av_get_bytes_per_sample(frame->format) *
-   av_frame_get_channels(frame);
-if ((ret = av_new_packet(pkt, size)) < 0)
-return ret;
-memcpy(pkt->data, frame->data[0], size);
-}
-
-frame_metadata = av_frame_get_metadata(frame);
-if (frame_metadata) {
-uint8_t *metadata;
-AVDictionaryEntry *e = NULL;
-AVBPrint meta_buf;
-
-av_bprint_init(_buf, 0, AV_BPRINT_SIZE_UNLIMITED);
-while ((e = av_dict_get(frame_metadata, "", e, 
AV_DICT_IGNORE_SUFFIX))) {
-av_bprintf(_buf, "%s", e->key);
-av_bprint_chars(_buf, '\0', 1);
-av_bprintf(_buf, "%s", e->value);
-av_bprint_chars(_buf, '\0', 1);
-}
-if (!av_bprint_is_complete(_buf) ||
-!(metadata = av_packet_new_side_data(pkt, 
AV_PKT_DATA_STRINGS_METADATA,
- meta_buf.len))) {
-av_bprint_finalize(_buf, NULL);
-return AVERROR(ENOMEM);
-}
-memcpy(metadata, meta_buf.str, meta_buf.len);
-av_bprint_finalize(_buf, NULL);
+if ((ret = av_packet_encode_frame(pkt, frame)) < 0) {
+av_frame_unref(frame);
+av_packet_unref(pkt);
+return ret;
 }
 
 if ((ret = 

[FFmpeg-devel] [PATCH v2 3/3] ffplay: fix memory calculation

[Muhammad Faiz]

approximately compute memory size on wrapped_avframe packet

patch attached
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [SURVEY] Summary of first 2015 survey

[Paul B Mahol]

On 11/15/15, compn  wrote:
> On Sun, 15 Nov 2015 15:19:05 +0100
> Clement Boesch  wrote:
>
>> Hi folks,
>>
>> So the October/November 2015 FFmpeg survey ended, so as promised here
>> is a summary. It was planed for yesterday but due to some unfortunate
>> national issues it was kind of postponed to today...
>
> great work. thanks everyone who took the time to fill out the survey.
>
>> Misc comments
>> -
>>  - more developed ffplay (hwaccel, doc), mpts (?) options
>
> are we going to focus on ffplay to reinvent the media player wheel when
> there is vlc and mplayer? i'm not against it, just asking. i know
> ffplay is used somewhat on android, is that the biggest market for
> ffplay?

mplayer is dead, it even does not add new codecs that ffmpeg have support for.

Use mpv, it have support for new codecs automatically.

>
>>  - android support, hwaccel and relationship with
>> filters/bufferpool/etc, high level support for adaptive bitrate
>> streaming (bandwidth stream switch)
>
> if someone wants to help devs with android support, may i suggest the
> following:
>
> 1. locate all android and iphone and other embedded device forks
> 2. diff those forks to current ffmpeg git master
> 3. submit the diffs or links to the diffs/repo on ffmpeg-devel list.
>
> just organizing this would help. you dont have to be a programmer to do
> this.
>
> 4. test patches against git master on android / iphone / etc to make
> sure it works. possibly with fate test. testing just means make sure it
> builds and decodes sample files bitexact (if possible).
>
> example projects: ffmpeg4ios and ffmpeg4android and rockbox.
> especially rockbox has fixed-point decoders that were originally based
> on libavcodec. but also there are changes to shrink memory and stack
> usage.
>
> even talking to the devs of these projects may encourage them to
> submit or maybe even merge changes.
>
> or if you have android / ios or other embedded devices running linux,
> making those ssh accessible to devs will help us test builds and bugs.
>
> -compn
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [SURVEY] Summary of first 2015 survey

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 1:50 PM, compn  wrote:
> On Sun, 15 Nov 2015 15:19:05 +0100
> Clément Bœsch  wrote:
>
>> Hi folks,
>>
>> So the October/November 2015 FFmpeg survey ended, so as promised here
>> is a summary. It was planed for yesterday but due to some unfortunate
>> national issues it was kind of postponed to today...
>
> great work. thanks everyone who took the time to fill out the survey.
>
>> Misc comments
>> -
>>  - more developed ffplay (hwaccel, doc), mpts (?) options
>
> are we going to focus on ffplay to reinvent the media player wheel when
> there is vlc and mplayer? i'm not against it, just asking. i know
> ffplay is used somewhat on android, is that the biggest market for
> ffplay?

I personally use ffplay exclusively for media playback. On the other
hand, I have not focused on it much and will not in the future. I also
believe focusing on it is not productive for the same reasons as you
point out here. If one goes strictly by client usage, I suspect the
ffmpeg CLI and libavcodec are the two most important things.
In hindsight, we should have included this in our poll - some kind of
ranking between different libs and utilities.

Also, I think this will take care of itself naturally: most devs here
are not very interested in it.
As for why someone would use it on Android, no idea - VLC for instance
has a very capable Android client that is FOSS and uses a minimal set
of permissions - they are one of the few Android apps who actually
remove permissions in a new release :).
[...]

__
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/avio_internal: add av_warn_unused_result to ffio_ensure_seekback

[Michael Niedermayer]

On Sun, Nov 15, 2015 at 01:13:43PM -0500, Ganesh Ajjanagadde wrote:
> This will trigger a few warnings that need to be fixed, as this function
> can return AVERROR(ENOMEM).
> 
> --
> Inspired by a patch sent by Paul for the IVR demuxer.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/avio_internal.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/avio_internal.h b/libavformat/avio_internal.h
> index ad50567..655f38a 100644
> --- a/libavformat/avio_internal.h
> +++ b/libavformat/avio_internal.h
> @@ -102,6 +102,7 @@ int ffio_set_buf_size(AVIOContext *s, int buf_size);
>   * within the current pos and pos+buf_size is possible.
>   * Once the stream position moves outside this window this guarantee is lost.
>   */
> +av_warn_unused_result
>  int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size);

LGTM

(would be ideal to fix the cases that would result in warnings before
 pushing this)

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat: add IVR demuxer

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---

Frames/slices that ends in middle of packet do not currently work.
I have no idea why, so looking for help.
Different .R1M variant is not supported, working on it... but if you know
how to fix it speak up.
Useless comments/reviews are ignored.

---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/rmdec.c  | 284 +--
 3 files changed, 252 insertions(+), 34 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 1a03e0c..1645438 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -228,6 +228,7 @@ OBJS-$(CONFIG_ISS_DEMUXER)   += iss.o
 OBJS-$(CONFIG_IV8_DEMUXER)   += iv8.o
 OBJS-$(CONFIG_IVF_DEMUXER)   += ivfdec.o
 OBJS-$(CONFIG_IVF_MUXER) += ivfenc.o
+OBJS-$(CONFIG_IVR_DEMUXER)   += rmdec.o rm.o rmsipr.o
 OBJS-$(CONFIG_JACOSUB_DEMUXER)   += jacosubdec.o subtitles.o
 OBJS-$(CONFIG_JACOSUB_MUXER) += jacosubenc.o rawenc.o
 OBJS-$(CONFIG_JV_DEMUXER)+= jvdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 8b8d9f2..cc637df 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -169,6 +169,7 @@ void av_register_all(void)
 REGISTER_DEMUXER (ISS,  iss);
 REGISTER_DEMUXER (IV8,  iv8);
 REGISTER_MUXDEMUX(IVF,  ivf);
+REGISTER_DEMUXER (IVR,  ivr);
 REGISTER_MUXDEMUX(JACOSUB,  jacosub);
 REGISTER_DEMUXER (JV,   jv);
 REGISTER_MUXER   (LATM, latm);
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 4ec78ef..f9c8b4f 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -488,6 +488,47 @@ static int rm_read_header_old(AVFormatContext *s)
 return rm_read_audio_stream_info(s, s->pb, st, st->priv_data, 1);
 }
 
+static int rm_read_multi(AVFormatContext *s, AVIOContext *pb,
+ AVStream *st, char *mime)
+{
+int number_of_streams = avio_rb16(pb);
+int number_of_mdpr;
+int i, ret;
+unsigned size2;
+for (i = 0; i 0) {
+st2 = avformat_new_stream(s, NULL);
+if (!st2) {
+ret = AVERROR(ENOMEM);
+return ret;
+}
+st2->id = st->id + (i<<16);
+st2->codec->bit_rate = st->codec->bit_rate;
+st2->start_time = st->start_time;
+st2->duration   = st->duration;
+st2->codec->codec_type = AVMEDIA_TYPE_DATA;
+st2->priv_data = ff_rm_alloc_rmstream();
+if (!st2->priv_data)
+return AVERROR(ENOMEM);
+} else
+st2 = st;
+
+size2 = avio_rb32(pb);
+ret = ff_rm_read_mdpr_codecdata(s, s->pb, st2, st2->priv_data,
+size2, mime);
+if (ret < 0)
+return ret;
+}
+return 0;
+}
+
 static int rm_read_header(AVFormatContext *s)
 {
 RMDemuxContext *rm = s->priv_data;
@@ -579,40 +620,9 @@ static int rm_read_header(AVFormatContext *s)
 ffio_ensure_seekback(pb, 4);
 v = avio_rb32(pb);
 if (v == MKBETAG('M', 'L', 'T', 'I')) {
-int number_of_streams = avio_rb16(pb);
-int number_of_mdpr;
-int i;
-unsigned size2;
-for (i = 0; i 0) {
-st2 = avformat_new_stream(s, NULL);
-if (!st2) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-st2->id = st->id + (i<<16);
-st2->codec->bit_rate = st->codec->bit_rate;
-st2->start_time = st->start_time;
-st2->duration   = st->duration;
-st2->codec->codec_type = AVMEDIA_TYPE_DATA;
-st2->priv_data = ff_rm_alloc_rmstream();
-if (!st2->priv_data)
-return AVERROR(ENOMEM);
-} else
-st2 = st;
-
-size2 = avio_rb32(pb);
-if 

Re: [FFmpeg-devel] [PATCH] avformat: add IVR demuxer

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 12:29 PM, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>
> Frames/slices that ends in middle of packet do not currently work.
> I have no idea why, so looking for help.
> Different .R1M variant is not supported, working on it... but if you know
> how to fix it speak up.
> Useless comments/reviews are ignored.

Below is a review based on examination and not testing. Don't know if
it is "useless".

>
> ---
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/rmdec.c  | 284 
> +--
>  3 files changed, 252 insertions(+), 34 deletions(-)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 1a03e0c..1645438 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -228,6 +228,7 @@ OBJS-$(CONFIG_ISS_DEMUXER)   += iss.o
>  OBJS-$(CONFIG_IV8_DEMUXER)   += iv8.o
>  OBJS-$(CONFIG_IVF_DEMUXER)   += ivfdec.o
>  OBJS-$(CONFIG_IVF_MUXER) += ivfenc.o
> +OBJS-$(CONFIG_IVR_DEMUXER)   += rmdec.o rm.o rmsipr.o
>  OBJS-$(CONFIG_JACOSUB_DEMUXER)   += jacosubdec.o subtitles.o
>  OBJS-$(CONFIG_JACOSUB_MUXER) += jacosubenc.o rawenc.o
>  OBJS-$(CONFIG_JV_DEMUXER)+= jvdec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 8b8d9f2..cc637df 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -169,6 +169,7 @@ void av_register_all(void)
>  REGISTER_DEMUXER (ISS,  iss);
>  REGISTER_DEMUXER (IV8,  iv8);
>  REGISTER_MUXDEMUX(IVF,  ivf);
> +REGISTER_DEMUXER (IVR,  ivr);
>  REGISTER_MUXDEMUX(JACOSUB,  jacosub);
>  REGISTER_DEMUXER (JV,   jv);
>  REGISTER_MUXER   (LATM, latm);
> diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
> index 4ec78ef..f9c8b4f 100644
> --- a/libavformat/rmdec.c
> +++ b/libavformat/rmdec.c
> @@ -488,6 +488,47 @@ static int rm_read_header_old(AVFormatContext *s)
>  return rm_read_audio_stream_info(s, s->pb, st, st->priv_data, 1);
>  }
>
> +static int rm_read_multi(AVFormatContext *s, AVIOContext *pb,
> + AVStream *st, char *mime)
> +{
> +int number_of_streams = avio_rb16(pb);
> +int number_of_mdpr;
> +int i, ret;
> +unsigned size2;

uint32_t size2 - you use it to read 32 bits.

> +for (i = 0; i +avio_rb16(pb);
> +number_of_mdpr = avio_rb16(pb);
> +if (number_of_mdpr != 1) {
> +avpriv_request_sample(s, "MLTI with multiple (%d) MDPR", 
> number_of_mdpr);
> +}
> +for (i = 0; i < number_of_mdpr; i++) {
> +AVStream *st2;
> +if (i > 0) {
> +st2 = avformat_new_stream(s, NULL);
> +if (!st2) {
> +ret = AVERROR(ENOMEM);
> +return ret;
> +}

simple return AVERROR(ENOMEM) suffices for thos. However, you might
want a goto fail, since you will need to free st2 if
ff_rm_alloc_rmstream below fails.

> +st2->id = st->id + (i<<16);
> +st2->codec->bit_rate = st->codec->bit_rate;
> +st2->start_time = st->start_time;
> +st2->duration   = st->duration;
> +st2->codec->codec_type = AVMEDIA_TYPE_DATA;
> +st2->priv_data = ff_rm_alloc_rmstream();
> +if (!st2->priv_data)
> +return AVERROR(ENOMEM);
> +} else
> +st2 = st;
> +
> +size2 = avio_rb32(pb);
> +ret = ff_rm_read_mdpr_codecdata(s, s->pb, st2, st2->priv_data,
> +size2, mime);
> +if (ret < 0)
> +return ret;
> +}
> +return 0;
> +}
> +
>  static int rm_read_header(AVFormatContext *s)
>  {
>  RMDemuxContext *rm = s->priv_data;
> @@ -579,40 +620,9 @@ static int rm_read_header(AVFormatContext *s)
>  ffio_ensure_seekback(pb, 4);
>  v = avio_rb32(pb);
>  if (v == MKBETAG('M', 'L', 'T', 'I')) {
> -int number_of_streams = avio_rb16(pb);
> -int number_of_mdpr;
> -int i;
> -unsigned size2;
> -for (i = 0; i -avio_rb16(pb);
> -number_of_mdpr = avio_rb16(pb);
> -if (number_of_mdpr != 1) {
> -avpriv_request_sample(s, "MLTI with multiple (%d) MDPR", 
> number_of_mdpr);
> -}
> -for (i = 0; i < number_of_mdpr; i++) {
> -AVStream *st2;
> -if (i > 0) {
> -st2 = avformat_new_stream(s, NULL);
> -if (!st2) {
> -ret = AVERROR(ENOMEM);
> -goto fail;
> -}
> -

[FFmpeg-devel] [PATCH] mxfdec: check edit_rate also for physical_track

[Andreas Cadhalpun]

Previously only the edit_rate of material_track was checked.
If it's negative, it causes assertion failures in av_rescale_rnd.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/mxfdec.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 99c8fed..429f46a 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1776,6 +1776,16 @@ static int mxf_parse_physical_source_package(MXFContext 
*mxf, MXFTrack *source_t
 continue;
 }
 
+if (physical_track->edit_rate.num <= 0 ||
+physical_track->edit_rate.den <= 0) {
+av_log(mxf->fc, AV_LOG_WARNING,
+   "Invalid edit rate (%d/%d) found on structural"
+   " component #%d, defaulting to 25/1\n",
+   physical_track->edit_rate.num,
+   physical_track->edit_rate.den, i);
+physical_track->edit_rate = (AVRational){25, 1};
+}
+
 for (k = 0; k < 
physical_track->sequence->structural_components_count; k++) {
 if (!(mxf_tc = mxf_resolve_timecode_component(mxf, 
_track->sequence->structural_components_refs[k])))
 continue;
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] fate: add concat demuxer tests

[Marton Balint]

On Fri, 13 Nov 2015, Nicolas George wrote:


Le decadi 20 brumaire, an CCXXIV, Marton Balint a écrit :

Signed-off-by: Marton Balint 
---
 tests/Makefile |   1 +
 tests/extended.ffconcat| 114 
 tests/fate-run.sh  |  20 +++
 tests/fate/concatdec.mak   |  21 +++
 tests/ref/fate/concat-demuxer-extended-lavf-mxf|   1 +
 .../ref/fate/concat-demuxer-extended-lavf-mxf_d10  |   1 +
 tests/ref/fate/concat-demuxer-simple1-lavf-mxf | 124 +
 tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10 |  82 +++
 tests/ref/fate/concat-demuxer-simple2-lavf-ts  | 151 +
 tests/simple1.ffconcat |  12 ++
 tests/simple2.ffconcat |  19 +++
 11 files changed, 546 insertions(+)
 create mode 100644 tests/extended.ffconcat
 create mode 100644 tests/fate/concatdec.mak
 create mode 100644 tests/ref/fate/concat-demuxer-extended-lavf-mxf
 create mode 100644 tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
 create mode 100644 tests/ref/fate/concat-demuxer-simple1-lavf-mxf
 create mode 100644 tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10
 create mode 100644 tests/ref/fate/concat-demuxer-simple2-lavf-ts
 create mode 100644 tests/simple1.ffconcat
 create mode 100644 tests/simple2.ffconcat


The parts I understand look fine to me, but I can not really comment on the
gmake black magic.


Thanks, applied with updated ref files for mxf.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/avio_internal: add av_warn_unused_result to ffio_ensure_seekback

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 3:04 PM, Michael Niedermayer
 wrote:
> On Sun, Nov 15, 2015 at 01:13:43PM -0500, Ganesh Ajjanagadde wrote:
>> This will trigger a few warnings that need to be fixed, as this function
>> can return AVERROR(ENOMEM).
>>
>> --
>> Inspired by a patch sent by Paul for the IVR demuxer.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavformat/avio_internal.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavformat/avio_internal.h b/libavformat/avio_internal.h
>> index ad50567..655f38a 100644
>> --- a/libavformat/avio_internal.h
>> +++ b/libavformat/avio_internal.h
>> @@ -102,6 +102,7 @@ int ffio_set_buf_size(AVIOContext *s, int buf_size);
>>   * within the current pos and pos+buf_size is possible.
>>   * Once the stream position moves outside this window this guarantee is 
>> lost.
>>   */
>> +av_warn_unused_result
>>  int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size);
>
> LGTM
>
> (would be ideal to fix the cases that would result in warnings before
>  pushing this)

True. Will submit separate patch later, and once that is oked, will push.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Democracy is the form of government in which you can choose your dictator
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] fate: add concat demuxer tests

[Hendrik Leppkes]

On Sun, Nov 15, 2015 at 7:33 PM, Marton Balint  wrote:
>
> On Fri, 13 Nov 2015, Nicolas George wrote:
>
>> Le decadi 20 brumaire, an CCXXIV, Marton Balint a écrit :
>>>
>>> Signed-off-by: Marton Balint 
>>> ---
>>>  tests/Makefile |   1 +
>>>  tests/extended.ffconcat| 114
>>> 
>>>  tests/fate-run.sh  |  20 +++
>>>  tests/fate/concatdec.mak   |  21 +++
>>>  tests/ref/fate/concat-demuxer-extended-lavf-mxf|   1 +
>>>  .../ref/fate/concat-demuxer-extended-lavf-mxf_d10  |   1 +
>>>  tests/ref/fate/concat-demuxer-simple1-lavf-mxf | 124
>>> +
>>>  tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10 |  82 +++
>>>  tests/ref/fate/concat-demuxer-simple2-lavf-ts  | 151
>>> +
>>>  tests/simple1.ffconcat |  12 ++
>>>  tests/simple2.ffconcat |  19 +++
>>>  11 files changed, 546 insertions(+)
>>>  create mode 100644 tests/extended.ffconcat
>>>  create mode 100644 tests/fate/concatdec.mak
>>>  create mode 100644 tests/ref/fate/concat-demuxer-extended-lavf-mxf
>>>  create mode 100644 tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
>>>  create mode 100644 tests/ref/fate/concat-demuxer-simple1-lavf-mxf
>>>  create mode 100644 tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10
>>>  create mode 100644 tests/ref/fate/concat-demuxer-simple2-lavf-ts
>>>  create mode 100644 tests/simple1.ffconcat
>>>  create mode 100644 tests/simple2.ffconcat
>>
>>
>> The parts I understand look fine to me, but I can not really comment on
>> the
>> gmake black magic.
>
>
> Thanks, applied with updated ref files for mxf.
>

All these tests are failing on all Windows FATE systems we have, both
GCC/Mingw and MSVC.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/aviobuf: Improve readability of aviobuf

[Bryan Huh]

No functional changes in this commit, mostly adding comments for
improved readability. Also minor re-arrangements of variables.
---
 libavformat/avio.h|   47 +++
 libavformat/aviobuf.c |   16 +---
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/libavformat/avio.h b/libavformat/avio.h
index 06dd7f5..abe13b2 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -122,6 +122,53 @@ typedef struct AVIOContext {
  * to any av_opt_* functions in that case.
  */
 const AVClass *av_class;
+
+/*
+ * The following shows the relationship between buffer, buf_ptr, buf_end, 
buf_size,
+ * and pos, when reading and when writing (since AVIOContext is used for 
both):
+ *
+ 
**
+ *   READING
+ 
**
+ *
+ *|  buffer_size  |
+ *|---|
+ *|   |
+ *
+ * buffer  buf_ptr   buf_end
+ *+---+---+
+ *|/ / / / / / / /|/ / / / / / /| |
+ *  read buffer:  |/ / consumed / | to be read /| |
+ *|/ / / / / / / /|/ / / / / / /| |
+ *+---+---+
+ *
+ * pos
+ *  
+---+-+
+ *  input file: |   |  
   |
+ *  
+---+-+
+ *
+ *
+ 
**
+ *   WRITING
+ 
**
+ *
+ *  |  buffer_size 
 |
+ *  
|---|
+ *  |  
 |
+ *
+ *   buffer  buf_ptr 
buf_end
+ *  
+---+---+
+ *  |/ / / / / / / / / /|  
 |
+ *  write buffer:   | / to be flushed / |  
 |
+ *  |/ / / / / / / / / /|  
 |
+ *  
+---+---+
+ *
+ * pos
+ *   
+--+---+
+ *  output file: |  |  
 |
+ *   
+--+---+
+ *
+ */
 unsigned char *buffer;  /**< Start of the buffer. */
 int buffer_size;/**< Maximum buffer size */
 unsigned char *buf_ptr; /**< Current position in the buffer */
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 1b3d5f5..c2aa8dc 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -213,6 +213,7 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int 
whence)
 return AVERROR(EINVAL);
 
 buffer_size = s->buf_end - s->buffer;
+// pos is the absolute position that the beginning of s->buffer 
corresponds to in the file
 pos = s->pos - (s->write_flag ? 0 : buffer_size);
 
 if (whence != SEEK_CUR && whence != SEEK_SET)
@@ -227,13 +228,13 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int 
whence)
 if (offset < 0)
 return AVERROR(EINVAL);
 
-offset1 = offset - pos;
+offset1 = offset - pos; // "offset1" is the relative offset from the 
beginning of s->buffer
 if (!s->must_flush && (!s->direct || !s->seek) &&
 offset1 >= 0 && offset1 <= buffer_size - s->write_flag) {
 /* can do the seek inside the buffer */
 s->buf_ptr = s->buffer + offset1;
 } else if ((!s->seekable ||
-   offset1 <= s->buf_end + s->short_seek_threshold - s->buffer) &&
+   offset1 <= buffer_size + s->short_seek_threshold) &&
!s->write_flag && offset1 >= 0 &&
(!s->direct || !s->seek) &&
   (whence != SEEK_END || force)) {
@@ -241,7 +242,7 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int 
whence)
 

[FFmpeg-devel] [PATCH] avformat/mp3dec, rmdec: check return value of ffio_ensure_seekback

[Ganesh Ajjanagadde]

ffio_ensure_seekback can fail due to e.g ENOMEM. This return value is
propagated here, and all usage in the codebase now has its return value
checked.

A potential memory leak in mp3_read_header is also fixed via a goto
fail.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavformat/mp3dec.c | 12 +---
 libavformat/rmdec.c  |  3 ++-
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 32ca00c..9fefe2d 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -373,18 +373,20 @@ static int mp3_read_header(AVFormatContext *s)
 
 ret = ff_replaygain_export(st, s->metadata);
 if (ret < 0)
-return ret;
+goto fail;
 
 off = avio_tell(s->pb);
 for (i = 0; i < 64 * 1024; i++) {
 uint32_t header, header2;
 int frame_size;
 if (!(i&1023))
-ffio_ensure_seekback(s->pb, i + 1024 + 4);
+if ((ret = ffio_ensure_seekback(s->pb, i + 1024 + 4)) < 0)
+goto fail;
 frame_size = check(s->pb, off + i, );
 if (frame_size > 0) {
 avio_seek(s->pb, off, SEEK_SET);
-ffio_ensure_seekback(s->pb, i + 1024 + frame_size + 4);
+if ((ret = ffio_ensure_seekback(s->pb, i + 1024 + frame_size + 4)) 
< 0)
+goto fail;
 if (check(s->pb, off + i + frame_size, ) >= 0 &&
 (header & SAME_HEADER_MASK) == (header2 & SAME_HEADER_MASK))
 {
@@ -402,6 +404,10 @@ static int mp3_read_header(AVFormatContext *s)
 
 /* the parameters will be extracted from the compressed bitstream */
 return 0;
+
+fail:
+ff_free_stream(s, st);
+return ret;
 }
 
 #define MP3_PACKET_SIZE 1024
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 4ec78ef..d6e820e 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -576,7 +576,8 @@ static int rm_read_header(AVFormatContext *s)
 size = avio_rb32(pb);
 codec_pos = avio_tell(pb);
 
-ffio_ensure_seekback(pb, 4);
+if ((ret = ffio_ensure_seekback(pb, 4)) < 0)
+goto fail;
 v = avio_rb32(pb);
 if (v == MKBETAG('M', 'L', 'T', 'I')) {
 int number_of_streams = avio_rb16(pb);
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] fate: fix concat demuxer tests on msys/cygwin by using relative paths

[Marton Balint]

Signed-off-by: Marton Balint 
---
 tests/fate-run.sh| 2 +-
 tests/fate/concatdec.mak | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 38dc334..6d46158 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -251,7 +251,7 @@ gapless(){
 
 concat(){
 template=$1
-sample=$(target_path $2)
+sample=$2
 mode=$3
 extra_args=$4
 
diff --git a/tests/fate/concatdec.mak b/tests/fate/concatdec.mak
index 7bb202b..988559d 100644
--- a/tests/fate/concatdec.mak
+++ b/tests/fate/concatdec.mak
@@ -7,15 +7,15 @@ FATE_CONCAT_DEMUXER_EXTENDED_LAVF-$(call ENCDEC2, MPEG2VIDEO, 
PCM_S16LE, MXF)  +
 FATE_CONCAT_DEMUXER_EXTENDED_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF)  
+= mxf_d10
 
 $(foreach D,$(FATE_CONCAT_DEMUXER_SIMPLE1_LAVF-yes),$(eval 
fate-concat-demuxer-simple1-lavf-$(D): ffprobe$(PROGSSUF)$(EXESUF) 
fate-lavf-$(D)))
-$(foreach D,$(FATE_CONCAT_DEMUXER_SIMPLE1_LAVF-yes),$(eval 
fate-concat-demuxer-simple1-lavf-$(D): CMD = concat 
$(SRC_PATH)/tests/simple1.ffconcat tests/data/lavf/lavf.$(D)))
+$(foreach D,$(FATE_CONCAT_DEMUXER_SIMPLE1_LAVF-yes),$(eval 
fate-concat-demuxer-simple1-lavf-$(D): CMD = concat 
$(SRC_PATH)/tests/simple1.ffconcat ../lavf/lavf.$(D)))
 FATE_CONCAT_DEMUXER-$(CONFIG_CONCAT_DEMUXER) += 
$(FATE_CONCAT_DEMUXER_SIMPLE1_LAVF-yes:%=fate-concat-demuxer-simple1-lavf-%)
 
 $(foreach D,$(FATE_CONCAT_DEMUXER_SIMPLE2_LAVF-yes),$(eval 
fate-concat-demuxer-simple2-lavf-$(D): ffprobe$(PROGSSUF)$(EXESUF) 
fate-lavf-$(D)))
-$(foreach D,$(FATE_CONCAT_DEMUXER_SIMPLE2_LAVF-yes),$(eval 
fate-concat-demuxer-simple2-lavf-$(D): CMD = concat 
$(SRC_PATH)/tests/simple2.ffconcat tests/data/lavf/lavf.$(D)))
+$(foreach D,$(FATE_CONCAT_DEMUXER_SIMPLE2_LAVF-yes),$(eval 
fate-concat-demuxer-simple2-lavf-$(D): CMD = concat 
$(SRC_PATH)/tests/simple2.ffconcat ../lavf/lavf.$(D)))
 FATE_CONCAT_DEMUXER-$(CONFIG_CONCAT_DEMUXER) += 
$(FATE_CONCAT_DEMUXER_SIMPLE2_LAVF-yes:%=fate-concat-demuxer-simple2-lavf-%)
 
 $(foreach D,$(FATE_CONCAT_DEMUXER_EXTENDED_LAVF-yes),$(eval 
fate-concat-demuxer-extended-lavf-$(D): ffprobe$(PROGSSUF)$(EXESUF) 
fate-lavf-$(D)))
-$(foreach D,$(FATE_CONCAT_DEMUXER_EXTENDED_LAVF-yes),$(eval 
fate-concat-demuxer-extended-lavf-$(D): CMD = concat 
$(SRC_PATH)/tests/extended.ffconcat tests/data/lavf/lavf.$(D) md5))
+$(foreach D,$(FATE_CONCAT_DEMUXER_EXTENDED_LAVF-yes),$(eval 
fate-concat-demuxer-extended-lavf-$(D): CMD = concat 
$(SRC_PATH)/tests/extended.ffconcat ../lavf/lavf.$(D) md5))
 FATE_CONCAT_DEMUXER-$(CONFIG_CONCAT_DEMUXER) += 
$(FATE_CONCAT_DEMUXER_EXTENDED_LAVF-yes:%=fate-concat-demuxer-extended-lavf-%)
 
 FATE-$(CONFIG_FFPROBE) += $(FATE_CONCAT_DEMUXER-yes)
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] fate: fix concat demuxer extended tests on windows

[Marton Balint]

Line endings do matter to md5sum...

Signed-off-by: Marton Balint 
---
 tests/fate-run.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 6d46158..966cbe2 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -262,7 +262,7 @@ concat(){
 awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
 
 if [ "$mode" = "md5" ]; then
-  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags keepside 
-safe 0 $extra_args $concatfile > $packetfile
+  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags keepside 
-safe 0 $extra_args $concatfile | sed 's/\r//g' > $packetfile
   do_md5sum $packetfile
 else
   run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -of 
compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/all: handle ff_formats_unref correctly

[Ganesh Ajjanagadde]

Recent commits 6aaac24d72a7da631173209841a3944fcb4a3309 and
3835554bf8ed78539a3492c239f979c0ab03a15f made progress towards cleaning
up usage of the formats API, and in particular fixed possible NULL pointer
dereferences.

This commit addresses the issue of possible resource leaks when one call
fails and the others don't.

Fixes: CID 1338330, 1338329, 1338327, 1338326.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/af_channelmap.c |  7 +--
 libavfilter/vf_alphamerge.c |  7 +--
 libavfilter/vf_overlay.c| 30 +-
 3 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/libavfilter/af_channelmap.c b/libavfilter/af_channelmap.c
index 9e95a98..45000d0 100644
--- a/libavfilter/af_channelmap.c
+++ b/libavfilter/af_channelmap.c
@@ -296,8 +296,11 @@ static int channelmap_query_formats(AVFilterContext *ctx)
 (ret = ff_set_common_formats (ctx , 
ff_planar_sample_fmts() )) < 0 ||
 (ret = ff_set_common_samplerates (ctx , 
ff_all_samplerates())) < 0 ||
 (ret = ff_channel_layouts_ref(layouts , 
>inputs[0]->out_channel_layouts)) < 0 ||
-(ret = ff_channel_layouts_ref(channel_layouts , 
>outputs[0]->in_channel_layouts)) < 0)
-return ret;
+(ret = ff_channel_layouts_ref(channel_layouts , 
>outputs[0]->in_channel_layouts)) < 0) {
+ff_channel_layouts_unref(_layouts);
+ff_channel_layouts_unref();
+return ret;
+}
 
 return 0;
 }
diff --git a/libavfilter/vf_alphamerge.c b/libavfilter/vf_alphamerge.c
index 8a1ca22..dcb7f6c 100644
--- a/libavfilter/vf_alphamerge.c
+++ b/libavfilter/vf_alphamerge.c
@@ -65,8 +65,11 @@ static int query_formats(AVFilterContext *ctx)
 return AVERROR(ENOMEM);
 if ((ret = ff_formats_ref(main_formats , >inputs[0]->out_formats)) < 
0 ||
 (ret = ff_formats_ref(alpha_formats, >inputs[1]->out_formats)) < 
0 ||
-(ret = ff_formats_ref(main_formats , >outputs[0]->in_formats)) < 
0)
-return ret;
+(ret = ff_formats_ref(main_formats , >outputs[0]->in_formats)) < 
0) {
+ff_formats_unref(_formats);
+ff_formats_unref(_formats);
+return ret;
+}
 return 0;
 }
 
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index 3c61731..4873775 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -252,23 +252,31 @@ static int query_formats(AVFilterContext *ctx)
 switch (s->format) {
 case OVERLAY_FORMAT_YUV420:
 if (!(main_formats= ff_make_format_list(main_pix_fmts_yuv420)) ||
-!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv420)))
-return AVERROR(ENOMEM);
+!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv420))) 
{
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 break;
 case OVERLAY_FORMAT_YUV422:
 if (!(main_formats= ff_make_format_list(main_pix_fmts_yuv422)) ||
-!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv422)))
-return AVERROR(ENOMEM);
+!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv422))) 
{
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 break;
 case OVERLAY_FORMAT_YUV444:
 if (!(main_formats= ff_make_format_list(main_pix_fmts_yuv444)) ||
-!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv444)))
-return AVERROR(ENOMEM);
+!(overlay_formats = ff_make_format_list(overlay_pix_fmts_yuv444))) 
{
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 break;
 case OVERLAY_FORMAT_RGB:
 if (!(main_formats= ff_make_format_list(main_pix_fmts_rgb)) ||
-!(overlay_formats = ff_make_format_list(overlay_pix_fmts_rgb)))
-return AVERROR(ENOMEM);
+!(overlay_formats = ff_make_format_list(overlay_pix_fmts_rgb))) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 break;
 default:
 av_assert0(0);
@@ -277,9 +285,13 @@ static int query_formats(AVFilterContext *ctx)
 if ((ret = ff_formats_ref(main_formats   , >inputs[MAIN]->out_formats 
  )) < 0 ||
 (ret = ff_formats_ref(overlay_formats, 
>inputs[OVERLAY]->out_formats)) < 0 ||
 (ret = ff_formats_ref(main_formats   , >outputs[MAIN]->in_formats 
  )) < 0)
-return ret;
+goto fail;
 
 return 0;
+fail:
+ff_formats_unref(_formats);
+ff_formats_unref(_formats);
+return ret;
 }
 
 static const enum AVPixelFormat alpha_pix_fmts[] = {
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mov: fix memory leak

[Ganesh Ajjanagadde]

Fixes: CID 1338328.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavformat/mov.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 38d3659..7ab2808 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -430,6 +430,7 @@ retry:
 if (snprintf(str, str_size_alloc, "%f", val) >= str_size_alloc) {
 av_log(c->fc, AV_LOG_ERROR,
"Failed to store the float32 number (%f) in string.\n", 
val);
+av_free(str);
 return AVERROR_INVALIDDATA;
 }
 } else {
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: Fixing typos and adding comments to fps code

[Michael Niedermayer]

On Sat, Nov 14, 2015 at 06:23:20PM -0800, Bryan Huh wrote:
> ---
>  ffmpeg.c |   16 
>  ffmpeg.h |2 +-
>  2 files changed, 9 insertions(+), 9 deletions(-)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: Simplify fps code related to delta0

[Michael Niedermayer]

On Sat, Nov 14, 2015 at 06:26:30PM -0800, Bryan Huh wrote:
> Small refactor of fps code for improved readability. In particular
> the "cor" variable was unnecessary and misleading because it would
> always be set to -delta0.
> ---
>  ffmpeg.c |   11 +--
>  1 files changed, 5 insertions(+), 6 deletions(-)

applied

thanks

[...]
-- 
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] ffmpeg: fix overriding packet duration warning

[Michael Niedermayer]

On Mon, Nov 16, 2015 at 12:26:28AM +0700, Muhammad Faiz wrote:
> On Sun, Nov 15, 2015 at 5:55 PM, Michael Niedermayer
>  wrote:
> > On Sun, Nov 15, 2015 at 04:04:42PM +0700, Muhammad Faiz wrote:
> >> no warning when packet duration is valid
> >>
> >> patch attached
> >
> >> From 789e9f0e93a246fd820401e6c298835bf40dc0c3 Mon Sep 17 00:00:00 2001
> >> From: Muhammad Faiz 
> >> Date: Sun, 15 Nov 2015 15:25:43 +0700
> >> Subject: [PATCH] ffmpeg: fix overriding packet duration warning
> >>
> >> no warning when packet duration is valid
> >> ---
> >>  ffmpeg.c | 7 ---
> >>  1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/ffmpeg.c b/ffmpeg.c
> >> index 3341777..5b9e38e 100644
> >> --- a/ffmpeg.c
> >> +++ b/ffmpeg.c
> >> @@ -673,10 +673,11 @@ static void write_frame(AVFormatContext *s, AVPacket 
> >> *pkt, OutputStream *ost)
> >>  }
> >>
> >>  if (ost->frame_rate.num && ost->is_cfr) {
> >> -if (pkt->duration > 0)
> >> +int64_t new_duration = av_rescale_q(1, 
> >> av_inv_q(ost->frame_rate),
> >> +ost->st->time_base);
> >> +if (pkt->duration > 0 && pkt->duration != new_duration)
> >>  av_log(NULL, AV_LOG_WARNING, "Overriding packet duration 
> >> by frame rate, this should not happen\n");
> >> -pkt->duration = av_rescale_q(1, av_inv_q(ost->frame_rate),
> >> - ost->st->time_base);
> >> +pkt->duration = new_duration;
> >
> > does it work to leave the duration instead of overriding if its
> > already set ?
> > i mean the new cfr duration code is certainly not correct for many
> > common cases (like 24000/1001 framerates at a 90khz timebase) so
> > overriding things by it if something else already set a (more correct?)
> > duration might be a bad idea
> 
> It just change warning message, when actually pkt->duration is equal
> to new_duration, no warning is generated. It does not change the
> previous behavior.
> 

> About overriding, don't ask me. I don't know for that. That is not from me.

yes but you seem t have found some cases where this code triggers
so i was wondering if you also saw cases where they differ and if
so what values in that case are more correct


> It is the previous behavior.

yes

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] ffserver_config: replace strtod by av_strtod and correct undefined behavior

[Michael Niedermayer]

On Sun, Nov 15, 2015 at 09:38:34AM -0500, Ganesh Ajjanagadde wrote:
> On Sat, Nov 14, 2015 at 4:12 PM, Michael Niedermayer
>  wrote:
> > On Thu, Nov 12, 2015 at 09:46:05PM -0500, Ganesh Ajjanagadde wrote:
> >> This uses av_strtod for added flexibility, and av_rint64_clip for ensuring 
> >> that
> >> no undefined behavior gets invoked.
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  ffserver_config.c | 21 +
> >>  1 file changed, 5 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/ffserver_config.c b/ffserver_config.c
> >> index 9fc1f00..443e71d 100644
> >> --- a/ffserver_config.c
> >> +++ b/ffserver_config.c
> >> @@ -19,6 +19,7 @@
> >>   */
> >>
> >>  #include 
> >> +#include "libavutil/eval.h"
> >>  #include "libavutil/opt.h"
> >>  #include "libavutil/parseutils.h"
> >>  #include "libavutil/avstring.h"
> >> @@ -757,7 +758,7 @@ static int ffserver_parse_config_feed(FFServerConfig 
> >> *config, const char *cmd,
> >>  } else {
> >>  WARNING("Truncate N syntax in configuration file is 
> >> deprecated. "
> >>  "Use Truncate alone with no arguments.\n");
> >> -feed->truncate = strtod(arg, NULL);
> >> +feed->truncate = av_rint64_clip(av_strtod(arg, NULL), 
> >> INT_MIN, INT_MAX);
> >>  }
> >>  } else if (!av_strcasecmp(cmd, "FileMaxSize")) {
> >>  char *p1;
> >> @@ -765,22 +766,10 @@ static int ffserver_parse_config_feed(FFServerConfig 
> >> *config, const char *cmd,
> >>
> >>  ffserver_get_arg(arg, sizeof(arg), p);
> >>  p1 = arg;
> >> -fsize = strtod(p1, );
> >> -switch(av_toupper(*p1)) {
> >> -case 'K':
> >> -fsize *= 1024;
> >> -break;
> >> -case 'M':
> >> -fsize *= 1024 * 1024;
> >> -break;
> >> -case 'G':
> >> -fsize *= 1024 * 1024 * 1024;
> >> -break;
> >> -default:
> >> +fsize = av_strtod(p1, );
> >> +if (!fsize || fabs(fsize) == HUGE_VAL)
> >>  ERROR("Invalid file size: '%s'\n", arg);
> >> -break;
> >> -}
> >> -feed->feed_max_size = (int64_t)fsize;
> >> +feed->feed_max_size = av_rint64_clip(fsize, INT64_MIN, INT64_MAX);
> >
> > i think these should be range checked and causing errors or warnings
> > if they are out of range
> >
> > if the user asks for value X and we cant do that then we should tell
> > the user that we cant.
> 
> The first one does not need to be, it is deprecated syntax and anyway
> the only value it cares about is 0 versus nonzero.
> 
> The second one can be range checked. Honestly though, I do not favor
> adding cruft like this for minimal gain since for all practical
> usages, no one will pass a value >= 2^64 in absolute value. For me,
> what is important is avoiding the undefined behavior. If you or others
> still feel that they need to be range checked, will do so.

i belive checking user input for validity is important
so the user knows if there is a problem and where it is instead of
just something not working
and its very hard to predict which check is not usefull
there are a wide array of possible typos, from missing wrong or
superflous seperators to all kinds of wrong chars, copy and paste
errors, mistakenly duplicated values, ...


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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] ffserver_config: replace strtod by av_strtod and correct undefined behavior

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 8:39 PM, Michael Niedermayer
 wrote:
> On Sun, Nov 15, 2015 at 09:38:34AM -0500, Ganesh Ajjanagadde wrote:
>> On Sat, Nov 14, 2015 at 4:12 PM, Michael Niedermayer
>>  wrote:
>> > On Thu, Nov 12, 2015 at 09:46:05PM -0500, Ganesh Ajjanagadde wrote:
>> >> This uses av_strtod for added flexibility, and av_rint64_clip for 
>> >> ensuring that
>> >> no undefined behavior gets invoked.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  ffserver_config.c | 21 +
>> >>  1 file changed, 5 insertions(+), 16 deletions(-)
>> >>
>> >> diff --git a/ffserver_config.c b/ffserver_config.c
>> >> index 9fc1f00..443e71d 100644
>> >> --- a/ffserver_config.c
>> >> +++ b/ffserver_config.c
>> >> @@ -19,6 +19,7 @@
>> >>   */
>> >>
>> >>  #include 
>> >> +#include "libavutil/eval.h"
>> >>  #include "libavutil/opt.h"
>> >>  #include "libavutil/parseutils.h"
>> >>  #include "libavutil/avstring.h"
>> >> @@ -757,7 +758,7 @@ static int ffserver_parse_config_feed(FFServerConfig 
>> >> *config, const char *cmd,
>> >>  } else {
>> >>  WARNING("Truncate N syntax in configuration file is 
>> >> deprecated. "
>> >>  "Use Truncate alone with no arguments.\n");
>> >> -feed->truncate = strtod(arg, NULL);
>> >> +feed->truncate = av_rint64_clip(av_strtod(arg, NULL), 
>> >> INT_MIN, INT_MAX);
>> >>  }
>> >>  } else if (!av_strcasecmp(cmd, "FileMaxSize")) {
>> >>  char *p1;
>> >> @@ -765,22 +766,10 @@ static int 
>> >> ffserver_parse_config_feed(FFServerConfig *config, const char *cmd,
>> >>
>> >>  ffserver_get_arg(arg, sizeof(arg), p);
>> >>  p1 = arg;
>> >> -fsize = strtod(p1, );
>> >> -switch(av_toupper(*p1)) {
>> >> -case 'K':
>> >> -fsize *= 1024;
>> >> -break;
>> >> -case 'M':
>> >> -fsize *= 1024 * 1024;
>> >> -break;
>> >> -case 'G':
>> >> -fsize *= 1024 * 1024 * 1024;
>> >> -break;
>> >> -default:
>> >> +fsize = av_strtod(p1, );
>> >> +if (!fsize || fabs(fsize) == HUGE_VAL)
>> >>  ERROR("Invalid file size: '%s'\n", arg);
>> >> -break;
>> >> -}
>> >> -feed->feed_max_size = (int64_t)fsize;
>> >> +feed->feed_max_size = av_rint64_clip(fsize, INT64_MIN, 
>> >> INT64_MAX);
>> >
>> > i think these should be range checked and causing errors or warnings
>> > if they are out of range
>> >
>> > if the user asks for value X and we cant do that then we should tell
>> > the user that we cant.
>>
>> The first one does not need to be, it is deprecated syntax and anyway
>> the only value it cares about is 0 versus nonzero.
>>
>> The second one can be range checked. Honestly though, I do not favor
>> adding cruft like this for minimal gain since for all practical
>> usages, no one will pass a value >= 2^64 in absolute value. For me,
>> what is important is avoiding the undefined behavior. If you or others
>> still feel that they need to be range checked, will do so.
>
> i belive checking user input for validity is important
> so the user knows if there is a problem and where it is instead of
> just something not working
> and its very hard to predict which check is not usefull
> there are a wide array of possible typos, from missing wrong or
> superflous seperators to all kinds of wrong chars, copy and paste
> errors, mistakenly duplicated values, ...

I am convinced of the checks. But the desired clip API is currently
unavailable as it is in avutil/internal. Will have to wait for a fix
for that before reposting...

>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/motion_vector: export subpel motion information

[Michael Niedermayer]

On Thu, Nov 12, 2015 at 03:03:33PM +0100, Clément Bœsch wrote:
> ---
>  libavcodec/mpegvideo.c | 36 +---
>  libavcodec/snowdec.c   |  4 
>  libavfilter/vf_codecview.c |  7 +--
>  libavutil/motion_vector.h  |  8 
>  libavutil/version.h|  2 +-
>  5 files changed, 39 insertions(+), 18 deletions(-)
> 
> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> index 96634ec..9ba1e09 100644
> --- a/libavcodec/mpegvideo.c
> +++ b/libavcodec/mpegvideo.c
> @@ -1556,15 +1556,21 @@ static void draw_arrow(uint8_t *buf, int sx, int sy, 
> int ex,
>  
>  static int add_mb(AVMotionVector *mb, uint32_t mb_type,
>int dst_x, int dst_y,
> -  int src_x, int src_y,
> +  int motion_x, int motion_y, int motion_shift,
>int direction)
>  {
>  mb->w = IS_8X8(mb_type) || IS_8X16(mb_type) ? 8 : 16;
>  mb->h = IS_8X8(mb_type) || IS_16X8(mb_type) ? 8 : 16;
> -mb->src_x = src_x;
> -mb->src_y = src_y;
> +
> +mb->motion_x = motion_x;
> +mb->motion_y = motion_y;
> +mb->motion_scale = 1;
> +mb->motion_shift = motion_shift;
> +
>  mb->dst_x = dst_x;
>  mb->dst_y = dst_y;
> +mb->src_x = dst_x + (motion_x >> motion_shift);
> +mb->src_y = dst_y + (motion_y >> motion_shift);
>  mb->source = direction ? 1 : -1;
>  mb->flags = 0; // XXX: does mb_type contain extra information that could 
> be exported here?
>  return 1;
> @@ -1603,43 +1609,43 @@ void ff_print_debug_info2(AVCodecContext *avctx, 
> AVFrame *pict, uint8_t *mbskip_
>  int sy = mb_y * 16 + 4 + 8 * (i >> 1);
>  int xy = (mb_x * 2 + (i & 1) +
>(mb_y * 2 + (i >> 1)) * mv_stride) << 
> (mv_sample_log2 - 1);
> -int mx = (motion_val[direction][xy][0] >> shift) 
> + sx;
> -int my = (motion_val[direction][xy][1] >> shift) 
> + sy;
> -mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx, my, direction);
> +int mx = motion_val[direction][xy][0];
> +int my = motion_val[direction][xy][1];
> +mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx, my, shift, direction);
>  }
>  } else if (IS_16X8(mb_type)) {
>  for (i = 0; i < 2; i++) {
>  int sx = mb_x * 16 + 8;
>  int sy = mb_y * 16 + 4 + 8 * i;
>  int xy = (mb_x * 2 + (mb_y * 2 + i) * mv_stride) 
> << (mv_sample_log2 - 1);
> -int mx = (motion_val[direction][xy][0] >> shift);
> -int my = (motion_val[direction][xy][1] >> shift);
> +int mx = motion_val[direction][xy][0];
> +int my = motion_val[direction][xy][1];
>  
>  if (IS_INTERLACED(mb_type))
>  my *= 2;
>  
> -mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx + sx, my + sy, direction);
> +mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx, my, shift, direction);
>  }
>  } else if (IS_8X16(mb_type)) {
>  for (i = 0; i < 2; i++) {
>  int sx = mb_x * 16 + 4 + 8 * i;
>  int sy = mb_y * 16 + 8;
>  int xy = (mb_x * 2 + i + mb_y * 2 * mv_stride) 
> << (mv_sample_log2 - 1);
> -int mx = motion_val[direction][xy][0] >> shift;
> -int my = motion_val[direction][xy][1] >> shift;
> +int mx = motion_val[direction][xy][0];
> +int my = motion_val[direction][xy][1];
>  
>  if (IS_INTERLACED(mb_type))
>  my *= 2;
>  
> -mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx + sx, my + sy, direction);
> +mbcount += add_mb(mvs + mbcount, mb_type, sx, 
> sy, mx, my, shift, direction);
>  }
>  } else {
>int sx = mb_x * 16 + 8;
>int sy = mb_y * 16 + 8;
>int xy = (mb_x + mb_y * mv_stride) << 
> mv_sample_log2;
> -  int mx = (motion_val[direction][xy][0]>>shift) + 
> sx;
> -  int my = (motion_val[direction][xy][1]>>shift) + 
> sy;
> -  mbcount += add_mb(mvs + mbcount, mb_type, sx, sy, 
> mx, my, direction);
> +  int mx = motion_val[direction][xy][0];
> +  

Re: [FFmpeg-devel] [PATCH] aac_fixed: fix overflow in sbr_sum_square_c

[Michael Niedermayer]

On Fri, Nov 13, 2015 at 10:32:47PM +0100, Andreas Cadhalpun wrote:
> On 13.11.2015 04:15, Michael Niedermayer wrote:
> > On Thu, Nov 12, 2015 at 08:43:42PM +0100, Andreas Cadhalpun wrote:
> >> Considering that the aac float decoder can decode such samples, I tend
> >> to think that the aac fixed decoder should be able to do that, too.
> > 
> > IMO this reasoning is flawed
> > 
> > if you write a float mpeg2 decoder and feed it a fuzzed file and
> > that decoder skips all checks then you can get  >16bit coefficients
> > as input to the IDCT.
> > Changing the fixed point IDCTs to work with 32x32 bit mutiplies
> > would not fix anything it would just make everything much slower
> > 
> > either way the authors of the fixed point aac decoder should
> > decide on what needs to be done, they implemented it and know this
> > code much better and why it scales the values as they are scaled ...
> 
> Yes, it would be great if they could comment on this.
> 
> >> If the FFmpeg aac encoder produces valid aac files then, yes, lots of
> >> overflows can happen with valid aac files.
> >> The decoder overflows even with a FATE sample.
> > 
> > i think this is something the authors of the decoder should look
> > into 
> 
> OK.
> 
> > also if there are overflows with fate samples why does this not
> > show up on any test on fate.ffmpeg.org ?
> 
> Because these samples aren't tested with the aac_fixed decoder:
>  * aac/ct_faac-adts.aac is only used to test the aac demuxer.
>  * aac/al07_96.mp4 is for some reason only tested with the aac decoder.
> 
> There the overflow happens on lines like:
> che->ch[0].ret[j] = 
> (int32_t)av_clipl_int32((int64_t)che->ch[0].ret[j]<<7)+0x8000;
> 

> I guess the +0x8000 was meant to be inside av_clipl_int32.

could be
also there was a different patch about a overflow in that
0729 11:58 Nedeljko Babic  (1.8K) [FFmpeg-devel] [PATCH] avcodec/aacdec_fixed: 
Fix integer overflow
that case was a bug elsewhere though

in that light, my first question, is, is the overflowing value used
(aka affects the decoder output) ?

[...]
-- 
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

[FFmpeg-devel] [PATCH] avformat/mov: remove redundant assignment

[Ganesh Ajjanagadde]

This is possibly undefined behavior based on sequence point rules, but I
have not studied the spec at that level of detail.

Fixes: CID 1338321.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7ab2808..0eb7272 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4936,7 +4936,7 @@ static int mov_seek_fragment(AVFormatContext *s, AVStream 
*st, int64_t timestamp
 
 for (i = 0; i < mov->fragment_index_count; i++) {
 if (mov->fragment_index_data[i]->track_id == st->id) {
-MOVFragmentIndex *index = index = mov->fragment_index_data[i];
+MOVFragmentIndex *index = mov->fragment_index_data[i];
 for (j = index->item_count - 1; j >= 0; j--) {
 if (index->items[j].time <= timestamp) {
 if (index->items[j].headers_read)
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] fate: fix concat demuxer extended tests on windows

[Michael Niedermayer]

On Mon, Nov 16, 2015 at 01:25:19AM +0100, Marton Balint wrote:
> Line endings do matter to md5sum...
> 
> Signed-off-by: Marton Balint 
> ---
>  tests/fate-run.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index 6d46158..966cbe2 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -262,7 +262,7 @@ concat(){
>  awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
>  
>  if [ "$mode" = "md5" ]; then
> -  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags 
> keepside -safe 0 $extra_args $concatfile > $packetfile
> +  run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -fflags 
> keepside -safe 0 $extra_args $concatfile | sed 's/\r//g' > $packetfile
>do_md5sum $packetfile
>  else
>run ffprobe${PROGSUF} -show_streams -show_packets -v 0 -of 
> compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
> -- 
> 2.6.2

the 2 patches fix fate on mingw32+64 here locally


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mpegtsenc: add vc-1 support to MPEG-TS muxer (ticket 2141)

[Michael Niedermayer]

On Thu, Nov 12, 2015 at 10:54:18PM +0100, Hagen Schmidt wrote:
> ---
>  libavformat/mpegtsenc.c | 10 ++
>  1 file changed, 10 insertions(+)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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] avcodec/faandct: use typedef instead of #define

[Michael Niedermayer]

On Sun, Nov 15, 2015 at 10:33:10AM -0500, Ganesh Ajjanagadde wrote:
> On Fri, Nov 13, 2015 at 12:05 PM, Ganesh Ajjanagadde  wrote:
> > On Fri, Nov 13, 2015 at 11:58 AM, Nicolas George  wrote:
> >> Le tridi 23 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> >>> See e.g 
> >>> https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
> >>> for rationale.
> >>>
> >>> Signed-off-by: Ganesh Ajjanagadde 
> >>> ---
> >>>  libavcodec/faandct.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> Any reason not to just replace FLOAT with float and be done?
> >
> > Assumed Michael kept it open in case we wish to transition to double
> > precision, in which case diff would be smaller. If float is all we
> > want for the foreseeable future, will change on your lines.
> 
> @Michael: are you fine with replacing all FLOAT with float?

having FLOAT allows easily switching it to double if someone wants
to test something with higher precission.
I dont know how useful that is, or how often it would be used or
if it will never be used

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/faandct: use typedef instead of #define

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 8:33 PM, Michael Niedermayer
 wrote:
> On Sun, Nov 15, 2015 at 10:33:10AM -0500, Ganesh Ajjanagadde wrote:
>> On Fri, Nov 13, 2015 at 12:05 PM, Ganesh Ajjanagadde  
>> wrote:
>> > On Fri, Nov 13, 2015 at 11:58 AM, Nicolas George  wrote:
>> >> Le tridi 23 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> >>> See e.g 
>> >>> https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
>> >>> for rationale.
>> >>>
>> >>> Signed-off-by: Ganesh Ajjanagadde 
>> >>> ---
>> >>>  libavcodec/faandct.c | 2 +-
>> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> Any reason not to just replace FLOAT with float and be done?
>> >
>> > Assumed Michael kept it open in case we wish to transition to double
>> > precision, in which case diff would be smaller. If float is all we
>> > want for the foreseeable future, will change on your lines.
>>
>> @Michael: are you fine with replacing all FLOAT with float?
>
> having FLOAT allows easily switching it to double if someone wants
> to test something with higher precission.
> I dont know how useful that is, or how often it would be used or
> if it will never be used

I myself am fine with either, but I want the #define gone. Unless
Nicolas objects strongly to the patch as is, will push.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 1
> "Used only once"- "Some unspecified defect prevented a second use"
> "In good condition" - "Can be repaird by experienced expert"
> "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [SURVEY] Summary of first 2015 survey

[Zhang Rui]

2015-11-16 2:50 GMT+08:00 compn :
> On Sun, 15 Nov 2015 15:19:05 +0100
> Clément Bœsch  wrote:
>
>> Hi folks,
>>
>> So the October/November 2015 FFmpeg survey ended, so as promised here
>> is a summary. It was planed for yesterday but due to some unfortunate
>> national issues it was kind of postponed to today...
>
> great work. thanks everyone who took the time to fill out the survey.
>
>> Misc comments
>> -
>>  - more developed ffplay (hwaccel, doc), mpts (?) options
>
> are we going to focus on ffplay to reinvent the media player wheel when
> there is vlc and mplayer? i'm not against it, just asking. i know
> ffplay is used somewhat on android, is that the biggest market for
> ffplay?

IMO, I'm not expecting ffplay to do everything as VLC, mpv does.
I think ffplay is the best and latest minimum example for media playback.

The most important thing is that it's a place where
FFmpeg developers show how to use FFmpeg in right way,
how to replace old API with new API, how to implement things
that should not be put into avformat/avcodec/avfilter.

For hwaccel, actually, I think there is more need to know
how to implement hwaccel in ffplay -- that is to say, using
public API of FFmpeg -- more than playback media
with ffplay's hwaccel feature. VLC and KODI both rewrite
new bit stream filter/convert for Android HW decoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2] configure+libm.h: add hypot emulation

[Ganesh Ajjanagadde]

On Sun, Nov 15, 2015 at 11:34 AM, Michael Niedermayer
 wrote:
> On Sun, Nov 15, 2015 at 11:01:58AM -0500, Ganesh Ajjanagadde wrote:
>> On Sun, Nov 15, 2015 at 10:56 AM, Michael Niedermayer
>>  wrote:
>> > On Sun, Nov 15, 2015 at 10:03:37AM -0500, Ganesh Ajjanagadde wrote:
>> >> It is known that the naive sqrt(x*x + y*y) approach for computing the
>> >> hypotenuse suffers from overflow and accuracy issues, see e.g
>> >> http://www.johndcook.com/blog/2010/06/02/whats-so-hard-about-finding-a-hypotenuse/.
>> >> This adds hypot support to FFmpeg, a C99 function.
>> >>
>> >> On platforms without hypot, this patch does a reaonable workaround, that
>> >> although not as accurate as GNU libm, is readable and does not suffer
>> >> from the overflow issue. Improvements can be made separately.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  configure|  2 ++
>> >>  libavutil/libm.h | 23 +++
>> >>  2 files changed, 25 insertions(+)
>> >>
>> >> diff --git a/configure b/configure
>> >> index d518b21..45df724 100755
>> >> --- a/configure
>> >> +++ b/configure
>> >> @@ -1774,6 +1774,7 @@ MATH_FUNCS="
>> >>  exp2
>> >>  exp2f
>> >>  expf
>> >> +hypot
>> >>  isinf
>> >>  isnan
>> >>  ldexpf
>> >> @@ -5309,6 +5310,7 @@ disabled crystalhd || check_lib 
>> >> libcrystalhd/libcrystalhd_if.h DtsCrystalHDVersi
>> >>
>> >>  atan2f_args=2
>> >>  copysign_args=2
>> >> +hypot_args=2
>> >>  ldexpf_args=2
>> >>  powf_args=2
>> >>
>> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> >> index 6c17b28..f7a2b41 100644
>> >> --- a/libavutil/libm.h
>> >> +++ b/libavutil/libm.h
>> >> @@ -102,6 +102,29 @@ static av_always_inline av_const int isnan(float x)
>> >>  }
>> >>  #endif /* HAVE_ISNAN */
>> >>
>> >> +#if !HAVE_HYPOT
>> >> +#undef hypot
>> >> +static inline av_const double hypot(double x, double y)
>> >> +{
>> >> +double ret, temp;
>> >> +x = fabs(x);
>> >> +y = fabs(y);
>> >> +
>> >> +if (isinf(x) || isinf(y))
>> >> +return av_int2double(0x7ff0);
>> >
>> > if either is NaN the result should be NaN i think
>> > return x+y
>> > might achive this
>>
>> No, quoting the man page/standard:
>>If x or y is an infinity, positive infinity is returned.
>>
>>If x or y is a NaN, and the other argument is not an infinity,
>> a NaN is returned.
>
> indeed, the spec says thats how it should be.
>
> this is not what i expected though and renders the function
> problematic in practice IMHO.
> For example a big use of NaN is to detect errors.
> One does a big complicated computation and if at the end the result is
> NaN or +-Inf then one knows there was something wrong in it.
> if NaN is infective then any computation that returns it can reliably
> be detected. These exceptions in C like hypot() break this.
> 1/hypot(x,y) should be NaN if either x or y was NaN
>
> also mathematically its wrong to ignore a NaN argument
> consider
> hypot(sqrt(-x), sqrt(x)) for x->infinite
>
> of course theres nothing we can or should do about hypot() its defined
> in C as it is defined but its something one should be aware of if
> one expects that NaNs can be used as a reliable means to detect
> NaNs from intermediate steps of a complicated calculation

Yes, I was extremely surprised myself, and you are right that it
defeats the NaN's purpose. Some day I may dig up the committee's
rationale for this, am curious. I doubt it was oversight, since they
are usually very careful about such things, and the defined behavior
is very specific suggesting deep thought.

Anyway, I do not take this as a formal ack yet. Hopefully we don't run
into Carl's weird debian thing that forced disabling fmax, fmin
emulation.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: Move av_rint64_clip_* to internal.h

[Michael Niedermayer]

On Sun, Nov 15, 2015 at 11:35:04AM -0500, Ganesh Ajjanagadde wrote:
> On Sun, Nov 15, 2015 at 11:19 AM, wm4  wrote:
> > On Sun, 15 Nov 2015 11:10:23 -0500
> > Ganesh Ajjanagadde  wrote:
> >
> >> On Sun, Nov 15, 2015 at 11:00 AM, Michael Niedermayer
> >>  wrote:
> >> > On Sun, Nov 15, 2015 at 10:24:52AM -0500, Ganesh Ajjanagadde wrote:
> >> >> On Sun, Nov 15, 2015 at 10:23 AM, wm4  wrote:
> >> >> > On Sun, 15 Nov 2015 10:20:41 -0500
> >> >> > Ganesh Ajjanagadde  wrote:
> >> >> >
> >> >> >> On Sat, Nov 14, 2015 at 9:01 PM, James Almer  
> >> >> >> wrote:
> >> >> >> > On 11/14/2015 10:48 PM, Michael Niedermayer wrote:
> >> >> >> >> From: Michael Niedermayer 
> >> >> >> >>
> >> >> >> >> This should avoid build failures on VS2012
> >> >> >> >> Feel free to changes this to a different solution
> >> >> >> >>
> >> >> >> >> Signed-off-by: Michael Niedermayer 
> >> >> >> >> ---
> >> >> >> >>  libavutil/common.h   |   39 
> >> >> >> >> ---
> >> >> >> >>  libavutil/internal.h |   40 
> >> >> >> >> 
> >> >> >> >>  2 files changed, 40 insertions(+), 39 deletions(-)
> >> >> >> >>
> >> >> >> >> diff --git a/libavutil/common.h b/libavutil/common.h
> >> >> >> >> index 813fb37..6f0f582 100644
> >> >> >> >> --- a/libavutil/common.h
> >> >> >> >> +++ b/libavutil/common.h
> >> >> >> >> @@ -298,42 +298,6 @@ static av_always_inline av_const double 
> >> >> >> >> av_clipd_c(double a, double amin, double
> >> >> >> >>  else   return a;
> >> >> >> >>  }
> >> >> >> >>
> >> >> >> >> -/**
> >> >> >> >> - * Clip and convert a double value into the long long amin-amax 
> >> >> >> >> range.
> >> >> >> >> - * This function is needed because conversion of floating point 
> >> >> >> >> to integers when
> >> >> >> >> - * it does not fit in the integer's representation does not 
> >> >> >> >> necessarily saturate
> >> >> >> >> - * correctly (usually converted to a cvttsd2si on x86) which 
> >> >> >> >> saturates numbers
> >> >> >> >> - * > INT64_MAX to INT64_MIN. The standard marks such conversions 
> >> >> >> >> as undefined
> >> >> >> >> - * behavior, allowing this sort of mathematically bogus 
> >> >> >> >> conversions. This provides
> >> >> >> >> - * a safe alternative that is slower obviously but assures 
> >> >> >> >> safety and better
> >> >> >> >> - * mathematical behavior.
> >> >> >> >> - * @param a value to clip
> >> >> >> >> - * @param amin minimum value of the clip range
> >> >> >> >> - * @param amax maximum value of the clip range
> >> >> >> >> - * @return clipped value
> >> >> >> >> - */
> >> >> >> >> -static av_always_inline av_const int64_t av_rint64_clip_c(double 
> >> >> >> >> a, int64_t amin, int64_t amax)
> >> >> >> >> -{
> >> >> >> >> -int64_t res;
> >> >> >> >> -#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && 
> >> >> >> >> ASSERT_LEVEL >= 2
> >> >> >> >> -if (amin > amax) abort();
> >> >> >> >> -#endif
> >> >> >> >> -// INT64_MAX+1,INT64_MIN are exactly representable as IEEE 
> >> >> >> >> doubles
> >> >> >> >> -// do range checks first
> >> >> >> >> -if (a >=  9223372036854775808.0)
> >> >> >> >> -return amax;
> >> >> >> >> -if (a <= -9223372036854775808.0)
> >> >> >> >> -   return amin;
> >> >> >> >> -
> >> >> >> >> -// safe to call llrint and clip accordingly
> >> >> >> >> -res = llrint(a);
> >> >> >> >> -if (res > amax)
> >> >> >> >> -return amax;
> >> >> >> >> -if (res < amin)
> >> >> >> >> -return amin;
> >> >> >> >> -return res;
> >> >> >> >> -}
> >> >> >> >> -
> >> >> >> >>  /** Compute ceil(log2(x)).
> >> >> >> >>   * @param x value used to compute ceil(log2(x))
> >> >> >> >>   * @return computed ceiling of log2(x)
> >> >> >> >> @@ -547,9 +511,6 @@ static av_always_inline av_const int 
> >> >> >> >> av_popcount64_c(uint64_t x)
> >> >> >> >>  #ifndef av_clipd
> >> >> >> >>  #   define av_clipd av_clipd_c
> >> >> >> >>  #endif
> >> >> >> >> -#ifndef av_rint64_clip
> >> >> >> >> -#   define av_rint64_clip   av_rint64_clip_c
> >> >> >> >> -#endif
> >> >> >> >>  #ifndef av_popcount
> >> >> >> >>  #   define av_popcount  av_popcount_c
> >> >> >> >>  #endif
> >> >> >> >> diff --git a/libavutil/internal.h b/libavutil/internal.h
> >> >> >> >> index 5c2cd99..cb0c8cd 100644
> >> >> >> >> --- a/libavutil/internal.h
> >> >> >> >> +++ b/libavutil/internal.h
> >> >> >> >> @@ -257,6 +257,46 @@ void avpriv_request_sample(void *avc,
> >> >> >> >>  #endif
> >> >> >> >>
> >> >> >> >>  /**
> >> >> >> >> + * Clip and convert a double value into the long long amin-amax 
> >> >> >> >> range.
> >> >> >> >> + * This function is needed because conversion of floating point 
> >> >> >> >> to integers when
> >> >> >> >> + * it does not fit in the integer's representation does not 
> >> >> >> >> 

[FFmpeg-devel] [PATCH] avformat/avio_internal: add av_warn_unused_result to ffio_ensure_seekback

[Ganesh Ajjanagadde]

This will trigger a few warnings that need to be fixed, as this function
can return AVERROR(ENOMEM).

--
Inspired by a patch sent by Paul for the IVR demuxer.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavformat/avio_internal.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/avio_internal.h b/libavformat/avio_internal.h
index ad50567..655f38a 100644
--- a/libavformat/avio_internal.h
+++ b/libavformat/avio_internal.h
@@ -102,6 +102,7 @@ int ffio_set_buf_size(AVIOContext *s, int buf_size);
  * within the current pos and pos+buf_size is possible.
  * Once the stream position moves outside this window this guarantee is lost.
  */
+av_warn_unused_result
 int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size);
 
 int ffio_limit(AVIOContext *s, int size);
-- 
2.6.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Hosting FFmpeg

[GAF]

If you are still looking for a hosting environment, I may be able to help. My 
ISP has a 10gig feeder, and an IBM SAN that can grow in 4TB increments.  Let me 
know if you are interested.

Regards,
Gregory A. Friedman, Owner
[AireBEam_CMYK_Ver_9-Original Pantone 295C-150x32]

Need Help: Chat with us at http://www.airebeam.com

AireBeam Broadband
Providers of FibAire Optic BroadbandSM
24x7x365 Customer Service: 520-233-7400
Cel: 1.520.483.8981
Fax: 1.520.844.8040
Web: http://www.airebeam.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: fix overriding packet duration warning

[Muhammad Faiz]

On Sun, Nov 15, 2015 at 5:55 PM, Michael Niedermayer
 wrote:
> On Sun, Nov 15, 2015 at 04:04:42PM +0700, Muhammad Faiz wrote:
>> no warning when packet duration is valid
>>
>> patch attached
>
>> From 789e9f0e93a246fd820401e6c298835bf40dc0c3 Mon Sep 17 00:00:00 2001
>> From: Muhammad Faiz 
>> Date: Sun, 15 Nov 2015 15:25:43 +0700
>> Subject: [PATCH] ffmpeg: fix overriding packet duration warning
>>
>> no warning when packet duration is valid
>> ---
>>  ffmpeg.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index 3341777..5b9e38e 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -673,10 +673,11 @@ static void write_frame(AVFormatContext *s, AVPacket 
>> *pkt, OutputStream *ost)
>>  }
>>
>>  if (ost->frame_rate.num && ost->is_cfr) {
>> -if (pkt->duration > 0)
>> +int64_t new_duration = av_rescale_q(1, 
>> av_inv_q(ost->frame_rate),
>> +ost->st->time_base);
>> +if (pkt->duration > 0 && pkt->duration != new_duration)
>>  av_log(NULL, AV_LOG_WARNING, "Overriding packet duration by 
>> frame rate, this should not happen\n");
>> -pkt->duration = av_rescale_q(1, av_inv_q(ost->frame_rate),
>> - ost->st->time_base);
>> +pkt->duration = new_duration;
>
> does it work to leave the duration instead of overriding if its
> already set ?
> i mean the new cfr duration code is certainly not correct for many
> common cases (like 24000/1001 framerates at a 90khz timebase) so
> overriding things by it if something else already set a (more correct?)
> duration might be a bad idea

It just change warning message, when actually pkt->duration is equal
to new_duration, no warning is generated. It does not change the
previous behavior.

About overriding, don't ask me. I don't know for that. That is not from me.
It is the previous behavior.

Thank's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

[Muhammad Faiz]

On Sun, Nov 15, 2015 at 6:38 PM, wm4  wrote:
> On Sun, 15 Nov 2015 15:51:30 +0700
> Muhammad Faiz  wrote:
>
>> From ae6b2c45faac830636602a696925566db03541a2 Mon Sep 17 00:00:00 2001
>> From: Muhammad Faiz 
>> Date: Sun, 15 Nov 2015 12:06:12 +0700
>> Subject: [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket
>>
>> add AV_PKT_FLAG_FRAME
>> add av_packet_encode_frame()
>> add av_packet_decode_frame()
>> add av_packet_get_frame()
>>
>> use pointer to AVFrame instead
>> properly padded with AV_INPUT_BUFFER_PADDING_SIZE
>>
>> modify wrapped_avframe encoder
>> implement wrapped_avframe decoder
>> implement wrapped_avframe_audio encoder/decoder
>>
>> fix avformat/yuv4mpegenc to use av_packet_get_frame()
>> ---
>>  doc/APIchanges   |  5 +++
>>  libavcodec/Makefile  |  3 ++
>>  libavcodec/allcodecs.c   |  3 +-
>>  libavcodec/avcodec.h | 29 
>>  libavcodec/avpacket.c| 63 ++-
>>  libavcodec/codec_desc.c  |  7 
>>  libavcodec/version.h |  2 +-
>>  libavcodec/wrapped_avframe.c | 78 
>> ++--
>>  libavformat/yuv4mpegenc.c|  5 +--
>>  9 files changed, 173 insertions(+), 22 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 14b96ce..9efd44e 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -15,6 +15,11 @@ libavutil: 2015-08-28
>>
>>  API changes, most recent first:
>>
>> +2015-11-15 - lavc 57.16.100 - avcodec.h
>> +  Add AV_PKT_FLAG_FRAME.
>> +  Add av_packet_encode_frame(), av_packet_decode_frame(),
>> +  and av_packet_get_frame().
>> +
>>  2015-10-29 - lavc 57.12.100 / 57.8.0 - avcodec.h
>>xx - Deprecate av_free_packet(). Use av_packet_unref() as replacement,
>> it resets the packet in a more consistent way.
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index 68a573f..65d8621 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -577,7 +577,10 @@ OBJS-$(CONFIG_WMV2_ENCODER)+= wmv2enc.o 
>> wmv2.o \
>>msmpeg4.o msmpeg4enc.o 
>> msmpeg4data.o
>>  OBJS-$(CONFIG_WNV1_DECODER)+= wnv1.o
>>  OBJS-$(CONFIG_WS_SND1_DECODER) += ws-snd1.o
>> +OBJS-$(CONFIG_WRAPPED_AVFRAME_DECODER) += wrapped_avframe.o
>>  OBJS-$(CONFIG_WRAPPED_AVFRAME_ENCODER) += wrapped_avframe.o
>> +OBJS-$(CONFIG_WRAPPED_AVFRAME_AUDIO_DECODER) += wrapped_avframe.o
>> +OBJS-$(CONFIG_WRAPPED_AVFRAME_AUDIO_ENCODER) += wrapped_avframe.o
>>  OBJS-$(CONFIG_XAN_DPCM_DECODER)+= dpcm.o
>>  OBJS-$(CONFIG_XAN_WC3_DECODER) += xan.o
>>  OBJS-$(CONFIG_XAN_WC4_DECODER) += xxan.o
>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>> index 9f60d7c..836fd20 100644
>> --- a/libavcodec/allcodecs.c
>> +++ b/libavcodec/allcodecs.c
>> @@ -342,7 +342,7 @@ void avcodec_register_all(void)
>>  REGISTER_DECODER(VP9,   vp9);
>>  REGISTER_DECODER(VQA,   vqa);
>>  REGISTER_DECODER(WEBP,  webp);
>> -REGISTER_ENCODER(WRAPPED_AVFRAME,   wrapped_avframe);
>> +REGISTER_ENCDEC (WRAPPED_AVFRAME,   wrapped_avframe);
>>  REGISTER_ENCDEC (WMV1,  wmv1);
>>  REGISTER_ENCDEC (WMV2,  wmv2);
>>  REGISTER_DECODER(WMV3,  wmv3);
>> @@ -446,6 +446,7 @@ void avcodec_register_all(void)
>>  REGISTER_ENCDEC (WMAV1, wmav1);
>>  REGISTER_ENCDEC (WMAV2, wmav2);
>>  REGISTER_DECODER(WMAVOICE,  wmavoice);
>> +REGISTER_ENCDEC (WRAPPED_AVFRAME_AUDIO, wrapped_avframe_audio);
>>  REGISTER_DECODER(WS_SND1,   ws_snd1);
>>  REGISTER_DECODER(XMA1,  xma1);
>>  REGISTER_DECODER(XMA2,  xma2);
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 1af17ed..a318dc5 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -550,6 +550,7 @@ enum AVCodecID {
>>  * stream (only used by libavformat) */
>>  AV_CODEC_ID_FFMETADATA = 0x21000,   ///< Dummy codec for streams 
>> containing only metadata information.
>>  AV_CODEC_ID_WRAPPED_AVFRAME = 0x21001, ///< Passthrough codec, AVFrames 
>> wrapped in AVPacket
>> +AV_CODEC_ID_WRAPPED_AVFRAME_AUDIO = 0x21002,
>>  };
>>
>>  /**
>> @@ -1442,6 +1443,7 @@ typedef struct AVPacket {
>>  } AVPacket;
>>  #define AV_PKT_FLAG_KEY 0x0001 ///< The packet contains a keyframe
>>  #define AV_PKT_FLAG_CORRUPT 0x0002 ///< The packet content is corrupted
>> +#define AV_PKT_FLAG_FRAME   0x0004 ///< The packet contains an AVFrame frame
>
> I'd prefer something more "neutral", like a name that indicates that
> the packet was constructed from verified data (as opposed to being read
> plainly from a file).

probably AV_PKT_FLAG_WRAPPED_AVFRAME

>
>>
>>  enum AVSideDataParamChangeFlags {
>>  

Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

[Muhammad Faiz]

On Sun, Nov 15, 2015 at 6:44 PM, wm4  wrote:
> On Sun, 15 Nov 2015 12:22:57 +0100
> Hendrik Leppkes  wrote:
>
>> On Sun, Nov 15, 2015 at 10:40 AM, Muhammad Faiz  wrote:
>> > On Sun, Nov 15, 2015 at 4:24 PM, Hendrik Leppkes  
>> > wrote:
>> >> On Sun, Nov 15, 2015 at 9:51 AM, Muhammad Faiz  wrote:
>> >>> add AV_PKT_FLAG_FRAME
>> >>> add av_packet_encode_frame()
>> >>> add av_packet_decode_frame()
>> >>> add av_packet_get_frame()
>> >>>
>> >>> use pointer to AVFrame instead
>> >>> properly padded with AV_INPUT_BUFFER_PADDING_SIZE
>> >>>
>> >>> modify wrapped_avframe encoder
>> >>> implement wrapped_avframe decoder
>> >>> implement wrapped_avframe_audio encoder/decoder
>> >>>
>> >>> fix avformat/yuv4mpegenc to use av_packet_get_frame()
>> >>>
>> >>> patch attached
>> >>>
>> >>
>> >> We already have 3 different API approaches to pass AVFrames as
>> >> AVPackets, we really don't need any more.
>> >
>> > What are they?
>>
>> - The deprecated AVFMT_RAWPICTURE deal, which was a giant hack and is
>> luckily leaving us eventually.
>> - The "uncoded frame" API introduced in ffmpeg a while ago
>> - And now the wrapped_avframe dealy
>>
>
> These should all be replaced with wrapped avframe. (The uncoded frame
> API should be deprecated.)
>
>> We really don't need more public API functions to deal with this
>> stuff, its already confusing enough as it is.
>> Use one of the existing ways to do what you want to do, but don't
>> introduce new public API that just exists for lavd/lavfi, where a
>> filter pretends to be a "demuxer".
>
> And some other places. ffmpeg.c, where encoding to a raw and writing
> to a null output would make fate slower, and y4m, which would become
> slower as well.
>
>> Its unlikely to ever be useful outside of this use-case. Public API
>> needs to be considered carefully, because once it exists, its here to
>> stay.
>
> Agreed.

If someone could make -filter_complex available in ffplay,
this hack in lavd/lavfi is unnecessary, instead we use -filter_complex
option.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [SURVEY] Summary of first 2015 survey

[compn]

On Sun, 15 Nov 2015 15:19:05 +0100
Clément Bœsch  wrote:

> Hi folks,
> 
> So the October/November 2015 FFmpeg survey ended, so as promised here
> is a summary. It was planed for yesterday but due to some unfortunate
> national issues it was kind of postponed to today...

great work. thanks everyone who took the time to fill out the survey.

> Misc comments
> -
>  - more developed ffplay (hwaccel, doc), mpts (?) options

are we going to focus on ffplay to reinvent the media player wheel when
there is vlc and mplayer? i'm not against it, just asking. i know
ffplay is used somewhat on android, is that the biggest market for
ffplay?

>  - android support, hwaccel and relationship with
> filters/bufferpool/etc, high level support for adaptive bitrate
> streaming (bandwidth stream switch)

if someone wants to help devs with android support, may i suggest the
following:

1. locate all android and iphone and other embedded device forks
2. diff those forks to current ffmpeg git master
3. submit the diffs or links to the diffs/repo on ffmpeg-devel list.

just organizing this would help. you dont have to be a programmer to do
this.

4. test patches against git master on android / iphone / etc to make
sure it works. possibly with fate test. testing just means make sure it
builds and decodes sample files bitexact (if possible).

example projects: ffmpeg4ios and ffmpeg4android and rockbox.
especially rockbox has fixed-point decoders that were originally based
on libavcodec. but also there are changes to shrink memory and stack
usage.

even talking to the devs of these projects may encourage them to
submit or maybe even merge changes.

or if you have android / ios or other embedded devices running linux,
making those ssh accessible to devs will help us test builds and bugs.

-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel