Re: [FFmpeg-devel] [PATCH] lavf/http: implement directory listing callbacks for Apache
On Fri, Aug 21, 2015 at 01:17:20AM +0200, Mariusz Szczepańczyk wrote:
> On Thu, Aug 20, 2015 at 11:59 PM, Ganesh Ajjanagadde
> wrote:
>
> > On Thu, Aug 20, 2015 at 5:48 PM, Mariusz Szczepańczyk
> > wrote:
> > > On Thu, Aug 20, 2015 at 11:38 PM, Ganesh Ajjanagadde
> > > wrote:
> > >
> > >> On Thu, Aug 20, 2015 at 5:32 PM, Mariusz Szczepańczyk
> > >> wrote:
> > >> > ---
> > >> > configure | 3 +
> > >> > libavformat/http.c | 194
> > >> +
> > >> > 2 files changed, 197 insertions(+)
> > >> >
> > >> > diff --git a/configure b/configure
> > >> > index e67ddf6..401e041 100755
> > >> > --- a/configure
> > >> > +++ b/configure
> > >> > @@ -265,6 +265,7 @@ External library support:
> > >> >--enable-libxcb-shm enable X11 grabbing shm communication
> > >> [autodetect]
> > >> >--enable-libxcb-xfixes enable X11 grabbing mouse rendering
> > >> [autodetect]
> > >> >--enable-libxcb-shapeenable X11 grabbing shape rendering
> > >> [autodetect]
> > >> > + --enable-libxml2 enable HTML parsing via libxml2 [no]
> > >> >--enable-libxvid enable Xvid encoding via xvidcore,
> > >> > native MPEG-4/Xvid encoder exists [no]
> > >> >--enable-libzmq enable message passing via libzmq [no]
> > >> > @@ -1428,6 +1429,7 @@ EXTERNAL_LIBRARY_LIST="
> > >> > libxcb_shm
> > >> > libxcb_shape
> > >> > libxcb_xfixes
> > >> > +libxml2
> > >> > libxvid
> > >> > libzmq
> > >> > libzvbi
> > >> > @@ -5309,6 +5311,7 @@ enabled libx265 && require_pkg_config
> > >> x265 x265.h x265_api_get &&
> > >> > { check_cpp_condition x265.h "X265_BUILD
> > >> >= 57" ||
> > >> > die "ERROR: libx265 version must be >=
> > >> 57."; }
> > >> > enabled libxavs && require libxavs xavs.h
> > xavs_encoder_encode
> > >> -lxavs
> > >> > +enabled libxml2 && require_pkg_config libxml-2.0
> > >> libxml/parser.h xmlInitParser
> > >> > enabled libxvid && require libxvid xvid.h xvid_global
> > >> -lxvidcore
> > >> > enabled libzmq&& require_pkg_config libzmq zmq.h
> > zmq_ctx_new
> > >> > enabled libzvbi && require libzvbi libzvbi.h
> > vbi_decoder_new
> > >> -lzvbi
> > >> > diff --git a/libavformat/http.c b/libavformat/http.c
> > >> > index 1eb716b..df45958 100644
> > >> > --- a/libavformat/http.c
> > >> > +++ b/libavformat/http.c
> > >> > @@ -21,6 +21,10 @@
> > >> >
> > >> > #include "config.h"
> > >> >
> > >> > +#if CONFIG_LIBXML2
> > >> > +#include
> > >> > +#endif /* CONFIG_LIBXML2 */
> > >> > +
> > >> > #if CONFIG_ZLIB
> > >> > #include
> > >> > #endif /* CONFIG_ZLIB */
> > >> > @@ -54,6 +58,16 @@ typedef enum {
> > >> > FINISH
> > >> > }HandshakeState;
> > >> >
> > >> > +typedef struct AVIODirEntryQueueNode {
> > >> > +struct AVIODirEntry *entry;
> > >> > +struct AVIODirEntryQueueNode *next;
> > >> > +} AVIODirEntryQueueNode;
> > >> > +
> > >> > +typedef struct AVIODirEntryQueue {
> > >> > +struct AVIODirEntryQueueNode *front;
> > >> > +struct AVIODirEntryQueueNode *rear;
> > >> > +} AVIODirEntryQueue;
> > >> > +
> > >> > typedef struct HTTPContext {
> > >> > const AVClass *class;
> > >> > URLContext *hd;
> > >> > @@ -70,6 +84,7 @@ typedef struct HTTPContext {
> > >> > char *mime_type;
> > >> > char *user_agent;
> > >> > char *content_type;
> > >> > +char *server;
> > >> > /* Set if the server correctly handles Connection: close and will
> > >> close
> > >> > * the connection after feeding us the content. */
> > >> > int willclose;
> > >> > @@ -111,6 +126,11 @@ typedef struct HTTPContext {
> > >> > int is_multi_client;
> > >> > HandshakeState handshake_step;
> > >> > int is_connected_server;
> > >> > +#if CONFIG_LIBXML2
> > >> > +htmlParserCtxtPtr html_parser;
> > >> > +AVIODirEntryQueue *entry_queue;
> > >> > +AVIODirEntry *entry;
> > >> > +#endif /* CONFIG_LIBXML2 */
> > >> > } HTTPContext;
> > >> >
> > >> > #define OFFSET(x) offsetof(HTTPContext, x)
> > >> > @@ -808,6 +828,8 @@ static int process_line(URLContext *h, char *line,
> > >> int line_count,
> > >> > if (!strcmp(p, "close"))
> > >> > s->willclose = 1;
> > >> > } else if (!av_strcasecmp(tag, "Server")) {
> > >> > +av_free(s->server);
> > >> > +s->server = av_strdup(p);
> > >> > if (!av_strcasecmp(p, "AkamaiGHost")) {
> > >> > s->is_akamai = 1;
> > >> > } else if (!av_strncasecmp(p, "MediaGateway", 12)) {
> > >> > @@ -1409,6 +1431,7 @@ static int http_close(URLContext *h)
> > >> > if (s->hd)
> > >> > ffurl_closep(&s->hd);
> > >> > av_dict_free(&s->chained_options);
> > >> > +av_freep(&s->server);
> > >> > return ret;
> > >> > }
> > >> >
> > >> > @@ -1471,6 +1494,167 @@ st
Re: [FFmpeg-devel] [libav-devel] [PATCH 4/6] avcodec: delay removal of avcodec_*_frame
On Sat, Aug 8, 2015 at 1:37 PM, Andreas Cadhalpun wrote: > They are still widely used and have been deprecated for less than two years. are we talking about ad0c9f2? if so, it's dated 2012-10-08, so almost three years. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/http: implement directory listing callbacks for Apache
On Fri, Aug 21, 2015 at 01:17:20AM +0200, Mariusz Szczepańczyk wrote:
[...]
> +static int http_open_dir(URLContext *h)
> +{
> +HTTPContext *s = h->priv_data;
> +xmlSAXHandler handlers = {};
> +int ret;
> +
> +if (ret = http_open(h, h->filename, 0, NULL) < 0)
> +goto fail;
missing ()
[...]
--
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] MP4 muxer, HEVC issues
On Fri, Aug 21, 2015 at 09:47:14AM +0300, Arthur Grant wrote:
> I found two HEVC specific issues in the MP4 muxer.
>
> 1) File libavformat\hevc.c, hvcc_parse_pps()
> pps_slice_chroma_qp_offsets_present_flag is missing
>
> -
> /*
> * weighted_pred_flag u(1)
> * weighted_bipred_flag u(1)
> * transquant_bypass_enabled_flag u(1)
> */
> skip_bits(gb, 3);
> -
>
> Should be
>
> -
> /*
> * pps_slice_chroma_qp_offsets_present_flag u(1)
> * weighted_pred_flag u(1)
> * weighted_bipred_flag u(1)
> * transquant_bypass_enabled_flag u(1)
> */
> skip_bits(gb, 4);
> -
>
> 2) File libavformat\hevc.c, hvcc_parse_sps()
>
> -
> for (i = 0; i < get_ue_golomb_long(gb); i++) { // num_long_term_ref_pics_sps
> -
>
> Is not correct. get_ue_golomb_long(gb) is evaluated multiple times.
Fixed
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: warn if GCC 4.2 is being used
On Mon, Aug 24, 2015 at 2:49 AM, Carl Eugen Hoyos wrote: > Ganesh Ajjanagadde gmail.com> writes: > >> +if [ "$first" = true ] && $_cc -dumpversion | grep -q '^4\.2'; then > > Will this not trigger for 4.4.2? No. Here is a test: echo "4.4.2" | grep '^4\.2' vs echo "4.2" | grep '^4\.2'. The (-q) is for suppressing output, only yielding the exit code. The reason it works is because '^' matches the beginning of a line, not the beginning after a punctuation character. > >> +warn "$gcc_version does not build ffmpeg correctly. >> Please do not use GCC 4.2!" >> +warn "See Ticket #1464 for more details." > > Please make this something like: > "gcc 4.2 is outdated and may miscompile FFmpeg, > please use a newer compiler." > > Fate passes with some patched versions and it > works with Apple's ppc compiler (gcc 4.2). Will change, but will keep the Ticket message as it sounds useful. Thanks. > > Thank you, Carl Eugen > > ___ > 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: warn if GCC 4.2 is being used
The wiki, Ticket1464, and Ticket3970 warn about the usage of GCC 4.2.
This fixes Ticket3970.
Signed-off-by: Ganesh Ajjanagadde
---
configure | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index e67ddf6..04a36e7 100755
--- a/configure
+++ b/configure
@@ -3544,6 +3544,7 @@ tms470_flags(){
probe_cc(){
pfx=$1
_cc=$2
+first=$3
unset _type _ident _cc_c _cc_e _cc_o _flags _cflags
unset _ld_o _ldflags _ld_lib _ld_path
@@ -3569,6 +3570,10 @@ probe_cc(){
if ! $_cc -dumpversion | grep -q '^2\.'; then
_depflags='-MMD -MF $(@:.o=.d) -MT $@'
fi
+if [ "$first" = true ] && $_cc -dumpversion | grep -q '^4\.2'; then
+warn "gcc 4.2 is outdated and may miscompile FFmpeg. Please use a
newer compiler."
+warn "See https://trac.ffmpeg.org/ticket/1464 for more details."
+fi
_cflags_speed='-O3'
_cflags_size='-Os'
elif $_cc --version 2>/dev/null | grep -q ^icc; then
@@ -3731,7 +3736,7 @@ set_ccvars(){
fi
}
-probe_cc cc "$cc"
+probe_cc cc "$cc" "true"
cflags_filter=$_flags_filter
cflags_speed=$_cflags_speed
cflags_size=$_cflags_size
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: warn if GCC 4.2 is being used
Le septidi 7 fructidor, an CCXXIII, Ganesh Ajjanagadde a écrit : > >> +if [ "$first" = true ] && $_cc -dumpversion | grep -q '^4\.2'; then > The (-q) is for suppressing output, only yielding the exit code. > The reason it works is because '^' matches the beginning of a line, > not the beginning after a punctuation character. I did not follow the rest of the thread, but I would suggest to avoid forking external processes whenever possible: case "$($_cc -dumpversion) in 4.2*) ...;; esac Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: warn if GCC 4.2 is being used
On Mon, Aug 24, 2015 at 8:20 AM, Nicolas George wrote: > Le septidi 7 fructidor, an CCXXIII, Ganesh Ajjanagadde a écrit : >> >> +if [ "$first" = true ] && $_cc -dumpversion | grep -q '^4\.2'; then > >> The (-q) is for suppressing output, only yielding the exit code. >> The reason it works is because '^' matches the beginning of a line, >> not the beginning after a punctuation character. > > I did not follow the rest of the thread, but I would suggest to avoid > forking external processes whenever possible: > > case "$($_cc -dumpversion) in > 4.2*) ...;; > esac Thanks for pointing this out. Note there is another instance as well right above (in fact, that is where I got the idea). There may be more as well. I could change both of them (and maybe more) in a separate patch (I prefer this), or change this one for this patch itself, and fix others separately. > > 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] [PATCH 02/10] aacenc: Add missing ff_ prefixes
On Sat, Aug 22, 2015 at 4:51 AM, Nicolas George wrote: > Le quintidi 5 fructidor, an CCXXIII, Claudio Freire a écrit : > > They were included in the symbol table but only as local, the > libavcodec.v > > file makes sure to make everything not explicitly mentioned for export > > local. > > > > Though it's possible that it depends on the compiler version? > > It depends on the kind of library: libavcodec.v affects shared objects, but > not static libraries. Static libraries are just an indexed archive of > object > files, the "exported" symbols are exactly the non-static ones. > Ah, that clears things up. Thanks for the explanation :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mjpegenc: remove non mod 16 check, theres a amv file that is not mod 16 == 0
From: Michael Niedermayer
See Ticket 4770
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegenc.c |9 -
1 file changed, 9 deletions(-)
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index ee0b16e..ae0c8cb 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -228,15 +228,6 @@ static int amv_encode_picture(AVCodecContext *avctx,
AVPacket *pkt,
if(s->avctx->flags & CODEC_FLAG_EMU_EDGE)
return AVERROR(EINVAL);
-if ((avctx->height & 15) && avctx->strict_std_compliance >
FF_COMPLIANCE_UNOFFICIAL) {
-av_log(avctx, AV_LOG_ERROR,
- "Heights which are not a multiple of 16 might fail with some
decoders, "
- "use vstrict=-1 / -strict -1 to use %d anyway.\n",
avctx->height);
-av_log(avctx, AV_LOG_WARNING, "If you have a device that plays AMV
videos, please test if videos "
- "with such heights work with it and report your findings to
ffmpeg-devel@ffmpeg.org\n");
-return AVERROR_EXPERIMENTAL;
-}
-
pic = av_frame_clone(pic_arg);
if (!pic)
return AVERROR(ENOMEM);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mjpegenc: remove non mod 16 check, theres a amv file that is not mod 16 == 0
On Mon, Aug 24, 2015 at 8:18 PM, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> See Ticket 4770
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mjpegenc.c |9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
> index ee0b16e..ae0c8cb 100644
> --- a/libavcodec/mjpegenc.c
> +++ b/libavcodec/mjpegenc.c
> @@ -228,15 +228,6 @@ static int amv_encode_picture(AVCodecContext *avctx,
> AVPacket *pkt,
> if(s->avctx->flags & CODEC_FLAG_EMU_EDGE)
> return AVERROR(EINVAL);
>
> -if ((avctx->height & 15) && avctx->strict_std_compliance >
> FF_COMPLIANCE_UNOFFICIAL) {
> -av_log(avctx, AV_LOG_ERROR,
> - "Heights which are not a multiple of 16 might fail with some
> decoders, "
> - "use vstrict=-1 / -strict -1 to use %d anyway.\n",
> avctx->height);
> -av_log(avctx, AV_LOG_WARNING, "If you have a device that plays AMV
> videos, please test if videos "
> - "with such heights work with it and report your findings to
> ffmpeg-devel@ffmpeg.org\n");
> -return AVERROR_EXPERIMENTAL;
> -}
> -
> pic = av_frame_clone(pic_arg);
> if (!pic)
> return AVERROR(ENOMEM);
Other than a sample without comment, is there actually any info which
device is capable of playing these?
Otherwise it might still be wise to require explicitly forcing this to
be enabled.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add tests for vectorscope filter
Signed-off-by: Paul B Mahol --- tests/fate/filter-video.mak | 15 +++ tests/ref/fate/filter-vectorscope_color | 4 tests/ref/fate/filter-vectorscope_color2 | 4 tests/ref/fate/filter-vectorscope_color3 | 4 tests/ref/fate/filter-vectorscope_gray | 4 tests/ref/fate/filter-vectorscope_xy | 4 6 files changed, 35 insertions(+) create mode 100644 tests/ref/fate/filter-vectorscope_color create mode 100644 tests/ref/fate/filter-vectorscope_color2 create mode 100644 tests/ref/fate/filter-vectorscope_color3 create mode 100644 tests/ref/fate/filter-vectorscope_gray create mode 100644 tests/ref/fate/filter-vectorscope_xy diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 8aa4198..3be299d 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -123,6 +123,21 @@ fate-filter-waveform_envelope: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf waveform FATE_FILTER_VSYNTH-$(CONFIG_WAVEFORM_FILTER) += fate-filter-waveform_uv fate-filter-waveform_uv: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf waveform=c=6 -flags +bitexact -sws_flags +accurate_rnd+bitexact +FATE_FILTER_VSYNTH-$(CONFIG_VECTORSCOPE_FILTER) += fate-filter-vectorscope_gray +fate-filter-vectorscope_gray: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf vectorscope=gray -flags +bitexact -sws_flags +accurate_rnd+bitexact -vframes 3 + +FATE_FILTER_VSYNTH-$(CONFIG_VECTORSCOPE_FILTER) += fate-filter-vectorscope_color +fate-filter-vectorscope_color: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf vectorscope=color -flags +bitexact -sws_flags +accurate_rnd+bitexact -vframes 3 + +FATE_FILTER_VSYNTH-$(CONFIG_VECTORSCOPE_FILTER) += fate-filter-vectorscope_color2 +fate-filter-vectorscope_color2: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf vectorscope=color2 -flags +bitexact -sws_flags +accurate_rnd+bitexact -vframes 3 + +FATE_FILTER_VSYNTH-$(CONFIG_VECTORSCOPE_FILTER) += fate-filter-vectorscope_color3 +fate-filter-vectorscope_color3: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf vectorscope=color3 -flags +bitexact -sws_flags +accurate_rnd+bitexact -vframes 3 + +FATE_FILTER_VSYNTH-$(CONFIG_VECTORSCOPE_FILTER) += fate-filter-vectorscope_xy +fate-filter-vectorscope_xy: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf vectorscope=x=0:y=1 -flags +bitexact -sws_flags +accurate_rnd+bitexact -vframes 3 + FATE_FILTER_VSYNTH-$(CONFIG_MERGEPLANES_FILTER) += fate-filter-mergeplanes fate-filter-mergeplanes: tests/data/filtergraphs/mergeplanes fate-filter-mergeplanes: CMD = framecrc -c:v pgmyuv -i $(SRC) -c:v pgmyuv -i $(SRC) -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/mergeplanes diff --git a/tests/ref/fate/filter-vectorscope_color b/tests/ref/fate/filter-vectorscope_color new file mode 100644 index 000..40165b6 --- /dev/null +++ b/tests/ref/fate/filter-vectorscope_color @@ -0,0 +1,4 @@ +#tb 0: 1/25 +0, 0, 0,1, 196608, 0x9d705c63 +0, 1, 1,1, 196608, 0x9fbf6f2c +0, 2, 2,1, 196608, 0x257b7290 diff --git a/tests/ref/fate/filter-vectorscope_color2 b/tests/ref/fate/filter-vectorscope_color2 new file mode 100644 index 000..be69443 --- /dev/null +++ b/tests/ref/fate/filter-vectorscope_color2 @@ -0,0 +1,4 @@ +#tb 0: 1/25 +0, 0, 0,1, 196608, 0x9bfcfae5 +0, 1, 1,1, 196608, 0x1ac6fcbf +0, 2, 2,1, 196608, 0x31cb1088 diff --git a/tests/ref/fate/filter-vectorscope_color3 b/tests/ref/fate/filter-vectorscope_color3 new file mode 100644 index 000..f297efd --- /dev/null +++ b/tests/ref/fate/filter-vectorscope_color3 @@ -0,0 +1,4 @@ +#tb 0: 1/25 +0, 0, 0,1, 196608, 0x6e698770 +0, 1, 1,1, 196608, 0x374d74a7 +0, 2, 2,1, 196608, 0x3d817143 diff --git a/tests/ref/fate/filter-vectorscope_gray b/tests/ref/fate/filter-vectorscope_gray new file mode 100644 index 000..ed41cc0 --- /dev/null +++ b/tests/ref/fate/filter-vectorscope_gray @@ -0,0 +1,4 @@ +#tb 0: 1/25 +0, 0, 0,1, 196608, 0x8e4171e2 +0, 1, 1,1, 196608, 0xf3d371e2 +0, 2, 2,1, 196608, 0xb9cb71e2 diff --git a/tests/ref/fate/filter-vectorscope_xy b/tests/ref/fate/filter-vectorscope_xy new file mode 100644 index 000..6a4b8f8 --- /dev/null +++ b/tests/ref/fate/filter-vectorscope_xy @@ -0,0 +1,4 @@ +#tb 0: 1/25 +0, 0, 0,1, 196608, 0xa0939af1 +0, 1, 1,1, 196608, 0x43699af1 +0, 2, 2,1, 196608, 0x69a19af1 -- 1.7.11.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] configure: do not fork off grep subprocess in probe_cc
grep is not required for the functionality in this instance.
This avoids an unnecessary fork, and also avoids a duplicated dumpversion call.
Furthermore, it also corrects behavior when no minor version number is present,
see e.g
https://github.com/joyent/node/pull/25671.
Signed-off-by: Ganesh Ajjanagadde
---
configure | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index e67ddf6..f92b526 100755
--- a/configure
+++ b/configure
@@ -3566,9 +3566,9 @@ probe_cc(){
gcc_pkg_ver=$(expr "$gcc_version" : '[^ ]* \(([^)]*)\)')
gcc_ext_ver=$(expr "$gcc_version" : ".*$gcc_pkg_ver $gcc_basever
\\(.*\\)")
_ident=$(cleanws "gcc $gcc_basever $gcc_pkg_ver $gcc_ext_ver")
-if ! $_cc -dumpversion | grep -q '^2\.'; then
-_depflags='-MMD -MF $(@:.o=.d) -MT $@'
-fi
+case $gcc_basever in
+2*) _depflags='-MMD -MF $(@:.o=.d) -MT $@' ;;
+esac
_cflags_speed='-O3'
_cflags_size='-Os'
elif $_cc --version 2>/dev/null | grep -q ^icc; then
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] configure: warn if GCC 4.2 is being used
The wiki, Ticket1464, and Ticket3970 warn about the usage of GCC 4.2.
This fixes Ticket3970.
Signed-off-by: Ganesh Ajjanagadde
---
configure | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index f92b526..7d14461 100755
--- a/configure
+++ b/configure
@@ -3544,6 +3544,7 @@ tms470_flags(){
probe_cc(){
pfx=$1
_cc=$2
+first=$3
unset _type _ident _cc_c _cc_e _cc_o _flags _cflags
unset _ld_o _ldflags _ld_lib _ld_path
@@ -3569,6 +3570,13 @@ probe_cc(){
case $gcc_basever in
2*) _depflags='-MMD -MF $(@:.o=.d) -MT $@' ;;
esac
+if [ "$first" = true ]; then
+case $gcc_basever in
+4.2*)
+warn "gcc 4.2 is outdated and may miscompile FFmpeg. Please
use a newer compiler."
+warn "See https://trac.ffmpeg.org/ticket/1464 for more
details." ;;
+esac
+fi
_cflags_speed='-O3'
_cflags_size='-Os'
elif $_cc --version 2>/dev/null | grep -q ^icc; then
@@ -3731,7 +3739,7 @@ set_ccvars(){
fi
}
-probe_cc cc "$cc"
+probe_cc cc "$cc" "true"
cflags_filter=$_flags_filter
cflags_speed=$_cflags_speed
cflags_size=$_cflags_size
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: warn if GCC 4.2 is being used
On Mon, Aug 24, 2015 at 8:28 AM, Ganesh Ajjanagadde wrote: > On Mon, Aug 24, 2015 at 8:20 AM, Nicolas George wrote: >> Le septidi 7 fructidor, an CCXXIII, Ganesh Ajjanagadde a écrit : >>> >> +if [ "$first" = true ] && $_cc -dumpversion | grep -q '^4\.2'; then >> >>> The (-q) is for suppressing output, only yielding the exit code. >>> The reason it works is because '^' matches the beginning of a line, >>> not the beginning after a punctuation character. >> >> I did not follow the rest of the thread, but I would suggest to avoid >> forking external processes whenever possible: >> >> case "$($_cc -dumpversion) in >> 4.2*) ...;; >> esac > > Thanks for pointing this out. > Note there is another instance as well right above (in fact, that is > where I got the idea). > There may be more as well. > I could change both of them (and maybe more) in a separate patch (I > prefer this), > or change this one for this patch itself, and fix others separately. I could not find any other obvious instances of an unnecessary grep. As such, I have sent out a 2 patch series, first to improve existing check, and second for the 4.2 warning. > >> >> 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
[FFmpeg-devel] Changing media formats mid stream
I've run into the case today where (if we understand it correctly) you setup a directshow graph, it advertises media types, then when you "start" the graph, it actually calls through and says "here's your *real* media type". Does ffmpeg internals have any concept of or support for a "changing media type" at runtime? (any other suggestions for how to handle this if it doesn't?) Cheers! -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mjpegenc: remove non mod 16 check, theres a amv file that is not mod 16 == 0
On Mon, Aug 24, 2015 at 08:46:38PM +0200, Hendrik Leppkes wrote:
> On Mon, Aug 24, 2015 at 8:18 PM, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > See Ticket 4770
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/mjpegenc.c |9 -
> > 1 file changed, 9 deletions(-)
> >
> > diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
> > index ee0b16e..ae0c8cb 100644
> > --- a/libavcodec/mjpegenc.c
> > +++ b/libavcodec/mjpegenc.c
> > @@ -228,15 +228,6 @@ static int amv_encode_picture(AVCodecContext *avctx,
> > AVPacket *pkt,
> > if(s->avctx->flags & CODEC_FLAG_EMU_EDGE)
> > return AVERROR(EINVAL);
> >
> > -if ((avctx->height & 15) && avctx->strict_std_compliance >
> > FF_COMPLIANCE_UNOFFICIAL) {
> > -av_log(avctx, AV_LOG_ERROR,
> > - "Heights which are not a multiple of 16 might fail with
> > some decoders, "
> > - "use vstrict=-1 / -strict -1 to use %d anyway.\n",
> > avctx->height);
> > -av_log(avctx, AV_LOG_WARNING, "If you have a device that plays AMV
> > videos, please test if videos "
> > - "with such heights work with it and report your findings to
> > ffmpeg-devel@ffmpeg.org\n");
> > -return AVERROR_EXPERIMENTAL;
> > -}
> > -
> > pic = av_frame_clone(pic_arg);
> > if (!pic)
> > return AVERROR(ENOMEM);
>
> Other than a sample without comment, is there actually any info which
> device is capable of playing these?
> Otherwise it might still be wise to require explicitly forcing this to
> be enabled.
i dont know, thats also why i posted this patch, to get some feedback
and oppinons if this should just be dropped or something else
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Changing media formats mid stream
On Mon, Aug 24, 2015 at 02:09:28PM -0600, Roger Pack wrote: > I've run into the case today where (if we understand it correctly) you > setup a directshow graph, it advertises media types, then when you > "start" the graph, it actually calls through and says "here's your > *real* media type". > Does ffmpeg internals have any concept of or support for a "changing > media type" at runtime? (any other suggestions for how to handle this > if it doesn't?) do i understand correctly that the type at read_header() stage is wrong but the type later at read_packet() stage is correct ? if that is the case, you can just wait with setting the type till it is reliably known. [...] -- 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] Changing media formats mid stream
I did a dirty little hack to attempt to fix it. Don't call the dshow_add_device() just in build time, but run the graph and sleep() a bit, then call dshow_add_device() at the end of the dshow_read_header(). Sadly, it does not work, it does not goes beyond the dshow "chit-chat" between filters/pins. After ctrl+c however the right codec stats are displayed... Regards, Máté On Mon, Aug 24, 2015 at 10:29 PM, Michael Niedermayer < mich...@niedermayer.cc> wrote: > On Mon, Aug 24, 2015 at 02:09:28PM -0600, Roger Pack wrote: > > I've run into the case today where (if we understand it correctly) you > > setup a directshow graph, it advertises media types, then when you > > "start" the graph, it actually calls through and says "here's your > > *real* media type". > > Does ffmpeg internals have any concept of or support for a "changing > > media type" at runtime? (any other suggestions for how to handle this > > if it doesn't?) > > do i understand correctly that the type at read_header() stage is > wrong but the type later at read_packet() stage is correct ? > if that is the case, you can just wait with setting the type till it > is reliably known. > > [...] > -- > 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 > > ___ > 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] FFmpegs future and resigning as leader
On 7/31/15, Michael Niedermayer wrote: > Hi all > > Ive been in FFmepg since 14 years and been the leader since 11 years > and i feel that iam not the best person for the leader position. > I had hoped for a long time that the fork situation would resolve and > both sides somehow merging back into one team. All the Libav developers > joining FFmpeg again. But even now as the last distributions are > preparing to remove Libav, still theres no hint of that happening. > Maybe even the opposite. > > The community is split and its very difficult to be the leader when > one is on one side of this split and the other tries everything to > push me out > > I hope my resignation will make it easier for the teams to find back > together and avoid a more complete split which would otherwise be > the result sooner or later as the trees diverge and merging all > improvments becomes too difficult for me to do. > > also before my resignation, i offer all maintainers who dont yet have, > direct write access as i likely will not comb through the ML anymore > or not as frequently to apply patches, please send me your public SSH > key if you are de facto maintaining or working on some part of FFmpeg > or are listed in MAINTAINERs. > > If people want to continue merges from libav, someone else will have > to do these. Indeed i fully admit the work and pressure caused by > the merges is a main reason for my resignation. Hey thanks sooo much for your work on FFmpeg over the years. I'll admit it's one of the few communities that actually has felt maintained (mostly by yourself). I also understand that leading is lonely work. It always is unfortunately... I guess most of the decision making will be decided in person or something like that [?] Once there's general concensus around what to do I will follow it, please post an announcement or something :) > FFmpeg belongs to the FFmpeg developers and the FFmpeg community! > > will i ever return ? ... i might ..., if theres a nice and friendly > environment, no hostile forks or at least none i have to interact with. > But i will certainly not return as leader, this is not really a role > i ever truly liked, more one i ended up with. OK so I take this to mean that even if the general concensus was "let's just keep them split, and quit the merges from libav" you would still step down at this point? (I guess my real question is "what's the major objective? To reunify, or to make things more amenable to Michael?" My assumption is that it's to reunify the community?) I will also admit my one other concern: that without Michael there won't be enough active leadership *total* to "fix all the annoying bugs" and everything. I.e. it will just become a worse muck. But if the hope is that the guys at libav have enough time/energy to do it all then the community as a whole would benefit, agree. Glancing randomly at https://lists.libav.org/pipermail/libav-devel/2015-August/thread.html It appears that most active on the mailing list is Luca Barbato and Anton Khirnov and Martin Storsjö(?) though I don't know much about it I'm sure there are others lurking. I suppose though if we combined forces between the FFmpeg people together with them it might be enough leadership. Or at least easier than it is now [?] and definitely less duplication of effort. So possibly a net win. I'll admit one of the thoughts I had for "recombining" was (cough) basically directing new patches to libav, then somebody [michael? not as a committer, just contributor] going back through the last 4 years of commits and trying to get them committed to libav. Fun fun (not really--just a lot of work). And possibly not an option dunno. > Especially as somehow "leader" is being interpreted by everyone as > "the guy who does all work noone else does, and takes all > responsibility noone else wants to take" > > am i still available for consulting jobs releated to FFmpeg? > yes, of course i cant gurantee it for the very distant future but > currently yes. And in the very distant future, its a maybe, so just > ask if theres something ... > > what about root, git admin roles, ...? > Well iam happy to pass them on to whoever the community chooses and > trusts. But please be very carefull who you choose! > until someone else is choosen i can continue doing the basic things > like security updates and opening git accounts, aka theres no urgency > in choosing someone, rather please choose wise than quick. > > what about GSoC? I agreed to mentor and admin that and i will of > course finish that for this summer. I may or may not be available > in future FFmpeg GSoCs. > > If you now think "ohh god what should i do, michael resigned" > very simple, FFmpeg is yours, that is everyones. try your best to > make FFmpeg be the best. > Post patches, review patches, apply patches, discuss code and design. > Report bugs, bisect, debug and fix bugs, add features, help users. > Do friendly merges, and if you like do hostile merges. > Its al
Re: [FFmpeg-devel] Changing media formats mid stream
Oops, forgot to mention, in dshow_pin.c the libAVPin_QueryAccept() have to be edited to almost the same as libAVPin_ReceiveConnection() just without the pin management. On Mon, Aug 24, 2015 at 10:44 PM, Máté Sebők wrote: > I did a dirty little hack to attempt to fix it. > Don't call the dshow_add_device() just in build time, but run the graph > and sleep() a bit, then call dshow_add_device() at the end of the > dshow_read_header(). > > Sadly, it does not work, it does not goes beyond the dshow "chit-chat" > between filters/pins. > > After ctrl+c however the right codec stats are displayed... > > Regards, > Máté > > > On Mon, Aug 24, 2015 at 10:29 PM, Michael Niedermayer < > mich...@niedermayer.cc> wrote: > >> On Mon, Aug 24, 2015 at 02:09:28PM -0600, Roger Pack wrote: >> > I've run into the case today where (if we understand it correctly) you >> > setup a directshow graph, it advertises media types, then when you >> > "start" the graph, it actually calls through and says "here's your >> > *real* media type". >> > Does ffmpeg internals have any concept of or support for a "changing >> > media type" at runtime? (any other suggestions for how to handle this >> > if it doesn't?) >> >> do i understand correctly that the type at read_header() stage is >> wrong but the type later at read_packet() stage is correct ? >> if that is the case, you can just wait with setting the type till it >> is reliably known. >> >> [...] >> -- >> 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 >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] checkasm: Fix floating point arguments on 64-bit Windows
--- tests/checkasm/x86/checkasm.asm | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/tests/checkasm/x86/checkasm.asm b/tests/checkasm/x86/checkasm.asm index da19aa2..5f3def9 100644 --- a/tests/checkasm/x86/checkasm.asm +++ b/tests/checkasm/x86/checkasm.asm @@ -103,16 +103,20 @@ cglobal checked_call, 2,15,16,max_args*8+8 mov [rsp+(i-6)*8], r9 %assign i i+1 %endrep -%else +%else ; WIN64 %assign i 4 %rep max_args-4 mov r9, [rsp+stack_offset+(i+7)*8] mov [rsp+i*8], r9 %assign i i+1 %endrep -%endif -%if WIN64 +; Move possible floating-point arguments to the correct registers +movq m0, r0 +movq m1, r1 +movq m2, r2 +movq m3, r3 + %assign i 6 %rep 16-6 mova m %+ i, [x %+ i] -- 1.8.3.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpegs future and resigning as leader
On Mon, Aug 24, 2015 at 4:51 PM, Roger Pack wrote: > On 7/31/15, Michael Niedermayer wrote: >> Hi all >> >> Ive been in FFmepg since 14 years and been the leader since 11 years >> and i feel that iam not the best person for the leader position. >> I had hoped for a long time that the fork situation would resolve and >> both sides somehow merging back into one team. All the Libav developers >> joining FFmpeg again. But even now as the last distributions are >> preparing to remove Libav, still theres no hint of that happening. >> Maybe even the opposite. >> >> The community is split and its very difficult to be the leader when >> one is on one side of this split and the other tries everything to >> push me out >> >> I hope my resignation will make it easier for the teams to find back >> together and avoid a more complete split which would otherwise be >> the result sooner or later as the trees diverge and merging all >> improvments becomes too difficult for me to do. >> >> also before my resignation, i offer all maintainers who dont yet have, >> direct write access as i likely will not comb through the ML anymore >> or not as frequently to apply patches, please send me your public SSH >> key if you are de facto maintaining or working on some part of FFmpeg >> or are listed in MAINTAINERs. >> >> If people want to continue merges from libav, someone else will have >> to do these. Indeed i fully admit the work and pressure caused by >> the merges is a main reason for my resignation. > > Hey thanks sooo much for your work on FFmpeg over the years. I'll > admit it's one of the few communities that actually has felt > maintained (mostly by yourself). I also understand that leading is > lonely work. It always is unfortunately... > > I guess most of the decision making will be decided in person or > something like that [?] > Once there's general concensus around what to do I will follow it, > please post an announcement or something :) > >> FFmpeg belongs to the FFmpeg developers and the FFmpeg community! >> >> will i ever return ? ... i might ..., if theres a nice and friendly >> environment, no hostile forks or at least none i have to interact with. >> But i will certainly not return as leader, this is not really a role >> i ever truly liked, more one i ended up with. > > OK so I take this to mean that even if the general concensus was > "let's just keep them split, and quit the merges from libav" you would > still step down at this point? (I guess my real question is "what's > the major objective? To reunify, or to make things more amenable to > Michael?" My assumption is that it's to reunify the community?) > > I will also admit my one other concern: that without Michael there > won't be enough active leadership *total* to "fix all the annoying > bugs" and everything. I.e. it will just become a worse muck. But if > the hope is that the guys at libav have enough time/energy to do it > all then the community as a whole would benefit, agree. > > Glancing randomly at > https://lists.libav.org/pipermail/libav-devel/2015-August/thread.html > It appears that most active on the mailing list is > Luca Barbato and Anton Khirnov and Martin Storsjö(?) > though I don't know much about it I'm sure there are others lurking. > I suppose though if we combined forces between the FFmpeg people > together with them it might be enough leadership. Or at least easier > than it is now [?] and definitely less duplication of effort. So > possibly a net win. > > I'll admit one of the thoughts I had for "recombining" was (cough) > basically directing new patches to libav, then somebody [michael? not > as a committer, just contributor] going back through the last 4 years > of commits and trying to get them committed to libav. Fun fun (not > really--just a lot of work). And possibly not an option dunno. > >> Especially as somehow "leader" is being interpreted by everyone as >> "the guy who does all work noone else does, and takes all >> responsibility noone else wants to take" >> >> am i still available for consulting jobs releated to FFmpeg? >> yes, of course i cant gurantee it for the very distant future but >> currently yes. And in the very distant future, its a maybe, so just >> ask if theres something ... >> >> what about root, git admin roles, ...? >> Well iam happy to pass them on to whoever the community chooses and >> trusts. But please be very carefull who you choose! >> until someone else is choosen i can continue doing the basic things >> like security updates and opening git accounts, aka theres no urgency >> in choosing someone, rather please choose wise than quick. >> >> what about GSoC? I agreed to mentor and admin that and i will of >> course finish that for this summer. I may or may not be available >> in future FFmpeg GSoCs. >> >> If you now think "ohh god what should i do, michael resigned" >> very simple, FFmpeg is yours, that is everyones. try your best to >> make FFmpeg be the best. >> Post patches, review
Re: [FFmpeg-devel] [PATCH] avcodec/mjpegenc: remove non mod 16 check, theres a amv file that is not mod 16 == 0
On Mon, 24 Aug 2015 20:18:59 +0200
Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> See Ticket 4770
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mjpegenc.c |9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
> index ee0b16e..ae0c8cb 100644
> --- a/libavcodec/mjpegenc.c
> +++ b/libavcodec/mjpegenc.c
> @@ -228,15 +228,6 @@ static int amv_encode_picture(AVCodecContext *avctx,
> AVPacket *pkt,
> if(s->avctx->flags & CODEC_FLAG_EMU_EDGE)
> return AVERROR(EINVAL);
>
> -if ((avctx->height & 15) && avctx->strict_std_compliance >
> FF_COMPLIANCE_UNOFFICIAL) {
> -av_log(avctx, AV_LOG_ERROR,
> - "Heights which are not a multiple of 16 might fail with some
> decoders, "
> - "use vstrict=-1 / -strict -1 to use %d anyway.\n",
> avctx->height);
> -av_log(avctx, AV_LOG_WARNING, "If you have a device that plays AMV
> videos, please test if videos "
> - "with such heights work with it and report your findings to
> ffmpeg-devel@ffmpeg.org\n");
> -return AVERROR_EXPERIMENTAL;
> -}
> -
> pic = av_frame_clone(pic_arg);
> if (!pic)
> return AVERROR(ENOMEM);
I don't quite understand why decoding an AMV file (whatever that is)
requires a change in the mjpeg encoder?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add tests for vectorscope filter
On Mon, Aug 24, 2015 at 07:04:48PM +, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > tests/fate/filter-video.mak | 15 +++ > tests/ref/fate/filter-vectorscope_color | 4 > tests/ref/fate/filter-vectorscope_color2 | 4 > tests/ref/fate/filter-vectorscope_color3 | 4 > tests/ref/fate/filter-vectorscope_gray | 4 > tests/ref/fate/filter-vectorscope_xy | 4 > 6 files changed, 35 insertions(+) > create mode 100644 tests/ref/fate/filter-vectorscope_color > create mode 100644 tests/ref/fate/filter-vectorscope_color2 > create mode 100644 tests/ref/fate/filter-vectorscope_color3 > create mode 100644 tests/ref/fate/filter-vectorscope_gray > create mode 100644 tests/ref/fate/filter-vectorscope_xy LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mjpegenc: remove non mod 16 check, theres a amv file that is not mod 16 == 0
On Mon, Aug 24, 2015 at 11:08 PM, wm4 wrote:
> On Mon, 24 Aug 2015 20:18:59 +0200
> Michael Niedermayer wrote:
>
>> From: Michael Niedermayer
>>
>> See Ticket 4770
>>
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavcodec/mjpegenc.c |9 -
>> 1 file changed, 9 deletions(-)
>>
>> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
>> index ee0b16e..ae0c8cb 100644
>> --- a/libavcodec/mjpegenc.c
>> +++ b/libavcodec/mjpegenc.c
>> @@ -228,15 +228,6 @@ static int amv_encode_picture(AVCodecContext *avctx,
>> AVPacket *pkt,
>> if(s->avctx->flags & CODEC_FLAG_EMU_EDGE)
>> return AVERROR(EINVAL);
>>
>> -if ((avctx->height & 15) && avctx->strict_std_compliance >
>> FF_COMPLIANCE_UNOFFICIAL) {
>> -av_log(avctx, AV_LOG_ERROR,
>> - "Heights which are not a multiple of 16 might fail with some
>> decoders, "
>> - "use vstrict=-1 / -strict -1 to use %d anyway.\n",
>> avctx->height);
>> -av_log(avctx, AV_LOG_WARNING, "If you have a device that plays AMV
>> videos, please test if videos "
>> - "with such heights work with it and report your findings to
>> ffmpeg-devel@ffmpeg.org\n");
>> -return AVERROR_EXPERIMENTAL;
>> -}
>> -
>> pic = av_frame_clone(pic_arg);
>> if (!pic)
>> return AVERROR(ENOMEM);
>
> I don't quite understand why decoding an AMV file (whatever that is)
> requires a change in the mjpeg encoder?
It doesn't, but presumably the existence of other non-mod16 AMV files
has prompted the question if its maybe not that bad to create them.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 4/6] avcodec: delay removal of avcodec_*_frame
On 24.08.2015 12:09, Vittorio Giovara wrote: > On Sat, Aug 8, 2015 at 1:37 PM, Andreas Cadhalpun > wrote: >> They are still widely used and have been deprecated for less than two years. > > are we talking about ad0c9f2? if so, it's dated 2012-10-08, so almost > three years. No, we're talking about b9fb59d from 2013-11-09. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 20/20] Bump major versions of all libraries
On 24.08.2015 13:44, Vittorio Giovara wrote: > On Tue, Jul 28, 2015 at 6:54 PM, Luca Barbato wrote: >> On 28/07/15 15:41, Vittorio Giovara wrote: >>> On Tue, Jul 28, 2015 at 2:40 PM, Luca Barbato wrote: On 28/07/15 15:30, Vittorio Giovara wrote: > Signed-off-by: Vittorio Giovara > --- > doc/APIchanges | 14 +++--- > libavcodec/version.h| 6 +++--- > libavdevice/version.h | 4 ++-- > libavfilter/version.h | 4 ++-- > libavformat/version.h | 4 ++-- > libavresample/version.h | 4 ++-- > libavutil/version.h | 4 ++-- > libswscale/version.h| 2 +- > 8 files changed, 21 insertions(+), 21 deletions(-) > > I believe to see general consensus towards applying the set as is. There is no consensus for that. > I've added a skeleton to the wiki > (https://wiki.libav.org/Migration/12) so that we can properly document > the necessary changes before we release. Any help with that is of > course welcome. I have a work-in-progress API-porting-guide. > If no objections I'll push this set in the following days. Can you explain why you believe it makes any kind of sense to remove widely used APIs like FF_API_PIX_FMT/FF_API_AVCODEC_FRAME, while keeping completely useless ones like FF_API_MISSING_SAMPLE? I think it would be much more reasonable to keep the two I suggested, and instead remove most of those you intend to keep, because they are hardly used anywhere. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add tests for vectorscope filter
On 24.08.2015 21:04, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > tests/fate/filter-video.mak | 15 +++ > tests/ref/fate/filter-vectorscope_color | 4 > tests/ref/fate/filter-vectorscope_color2 | 4 > tests/ref/fate/filter-vectorscope_color3 | 4 > tests/ref/fate/filter-vectorscope_gray | 4 > tests/ref/fate/filter-vectorscope_xy | 4 > 6 files changed, 35 insertions(+) > create mode 100644 tests/ref/fate/filter-vectorscope_color > create mode 100644 tests/ref/fate/filter-vectorscope_color2 > create mode 100644 tests/ref/fate/filter-vectorscope_color3 > create mode 100644 tests/ref/fate/filter-vectorscope_gray > create mode 100644 tests/ref/fate/filter-vectorscope_xy > > diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak > index 8aa4198..3be299d 100644 > --- a/tests/fate/filter-video.mak > +++ b/tests/fate/filter-video.mak > @@ -123,6 +123,21 @@ fate-filter-waveform_envelope: CMD = framecrc -c:v > pgmyuv -i $(SRC) -vf waveform > FATE_FILTER_VSYNTH-$(CONFIG_WAVEFORM_FILTER) += fate-filter-waveform_uv > fate-filter-waveform_uv: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf > waveform=c=6 -flags +bitexact -sws_flags +accurate_rnd+bitexact I believe these would also need '-fflags +bitexact', when FF_API_LAVF_BITEXACT is disabled. Have you checked that? Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mux: Warn if the muxers bitexact flag is not set but it looks as if the user wants it set
On 24.08.2015 02:22, Michael Niedermayer wrote:
> is below diff better: ?
> iam quite unsure how to word this
>
> using the exact same system as FF_API_OLD_FILTER_OPTS is tricky as
> there is a semantic difference
> "codec->flags & AV_CODEC_FLAG_BITEXACT" is not deprecated as in
> FF_API_OLD_FILTER_OPTS
> Currently storing a bitexact stream in a container makes the
> container bitexact. with FF_API_LAVF_BITEXACT==0 this would no longer
> be the case and the user would have to explicitly switch the muxer
> into bitexact mode in addition to the encoder to get a bitexact
> result.
>
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -250,10 +250,17 @@ static int init_muxer(AVFormatContext *s, AVDictionary
> **options)
> (ret = av_opt_set_dict2(s->priv_data, &tmp, AV_OPT_SEARCH_CHILDREN))
> < 0)
> goto fail;
>
> +if (s->nb_streams && s->streams[0]->codec->flags &
> AV_CODEC_FLAG_BITEXACT) {
> +if (!(s->flags & AVFMT_FLAG_BITEXACT))
> +av_log(s, AV_LOG_WARNING, "Muxer bitexact flag is not set,
> please set AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n"
> +#if FF_API_LAVF_BITEXACT
> + "This will become mandatory with
> future API cleanup\n"
> +#endif
> +);
I'd prefer something like:
if (s->nb_streams && s->streams[0]->codec->flags & AV_CODEC_FLAG_BITEXACT) {
if (!(s->flags & AVFMT_FLAG_BITEXACT)) {
#if FF_API_LAVF_BITEXACT
av_log(s, AV_LOG_WARNING,
"Setting the AVFormatContext to bitexact mode, because "
"the AVCodecContext is in that mode. This behavior will "
"change in the future. To keep the current behavior, set "
"AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n");
s->flags |= AVFMT_FLAG_BITEXACT;
#else
av_log(s, AV_LOG_WARNING,
"The AVFormatContext is not in set to bitexact mode, only "
"the AVCodecContext. If this is not intended, set "
"AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n");
#endif
}
}
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add hstack & vstack filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 24 +
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/vf_stack.c | 255 +++
4 files changed, 283 insertions(+)
create mode 100644 libavfilter/vf_stack.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 2f7b0fa..7b52971 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6589,6 +6589,18 @@ Set the scaling dimension: @code{2} for @code{hq2x},
@code{3} for
Default is @code{3}.
@end table
+@section hstack
+Stack streams horizontally.
+
+All streams must be of same pixel format and of same height.
+
+The filter accept the following option:
+
+@table @option
+@item nb_inputs
+Set number of input streams. Default is 2.
+@end table
+
@section hue
Modify the hue and/or the saturation of the input.
@@ -10892,6 +10904,18 @@ vignette='PI/4+random(1)*PI/50':eval=frame
@end itemize
+@section vstack
+Stack streams vertically.
+
+All streams must be of same pixel format and of same width.
+
+The filter accept the following option:
+
+@table @option
+@item nb_inputs
+Set number of input streams. Default is 2.
+@end table
+
@section w3fdif
Deinterlace the input video ("w3fdif" stands for "Weston 3 Field
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index aa34d8b..e9cd9c6 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -153,6 +153,7 @@ OBJS-$(CONFIG_HISTEQ_FILTER) += vf_histeq.o
OBJS-$(CONFIG_HISTOGRAM_FILTER) += vf_histogram.o
OBJS-$(CONFIG_HQDN3D_FILTER) += vf_hqdn3d.o
OBJS-$(CONFIG_HQX_FILTER)+= vf_hqx.o
+OBJS-$(CONFIG_HSTACK_FILTER) += vf_stack.o
OBJS-$(CONFIG_HUE_FILTER)+= vf_hue.o
OBJS-$(CONFIG_IDET_FILTER) += vf_idet.o
OBJS-$(CONFIG_IL_FILTER) += vf_il.o
@@ -231,6 +232,7 @@ OBJS-$(CONFIG_VFLIP_FILTER) += vf_vflip.o
OBJS-$(CONFIG_VIDSTABDETECT_FILTER) += vidstabutils.o
vf_vidstabdetect.o
OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER) += vidstabutils.o
vf_vidstabtransform.o
OBJS-$(CONFIG_VIGNETTE_FILTER) += vf_vignette.o
+OBJS-$(CONFIG_VSTACK_FILTER)+= vf_stack.o
OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
OBJS-$(CONFIG_WAVEFORM_FILTER) += vf_waveform.o
OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 353a1dc..0a1bdfd 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -169,6 +169,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(HISTOGRAM, histogram, vf);
REGISTER_FILTER(HQDN3D, hqdn3d, vf);
REGISTER_FILTER(HQX,hqx,vf);
+REGISTER_FILTER(HSTACK, hstack, vf);
REGISTER_FILTER(HUE,hue,vf);
REGISTER_FILTER(IDET, idet, vf);
REGISTER_FILTER(IL, il, vf);
@@ -246,6 +247,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(VIDSTABDETECT, vidstabdetect, vf);
REGISTER_FILTER(VIDSTABTRANSFORM, vidstabtransform, vf);
REGISTER_FILTER(VIGNETTE, vignette, vf);
+REGISTER_FILTER(VSTACK, vstack, vf);
REGISTER_FILTER(W3FDIF, w3fdif, vf);
REGISTER_FILTER(WAVEFORM, waveform, vf);
REGISTER_FILTER(XBR,xbr,vf);
diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
new file mode 100644
index 000..a8062fc
--- /dev/null
+++ b/libavfilter/vf_stack.c
@@ -0,0 +1,255 @@
+/*
+ * Copyright (c) 2015 Paul B. Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct StackContext {
+const AVClass *class;
+const AVPixFmtDescriptor *desc;
+int nb_inputs;
+int is_vertical;
+int nb_planes;
+
+AVFrame **frames;
+} StackContext;
+
+static const enum AVPixelFormat p
Re: [FFmpeg-devel] [PATCH] fate: add tests for vectorscope filter
On 8/24/15, Andreas Cadhalpun wrote: > On 24.08.2015 21:04, Paul B Mahol wrote: >> Signed-off-by: Paul B Mahol >> --- >> tests/fate/filter-video.mak | 15 +++ >> tests/ref/fate/filter-vectorscope_color | 4 >> tests/ref/fate/filter-vectorscope_color2 | 4 >> tests/ref/fate/filter-vectorscope_color3 | 4 >> tests/ref/fate/filter-vectorscope_gray | 4 >> tests/ref/fate/filter-vectorscope_xy | 4 >> 6 files changed, 35 insertions(+) >> create mode 100644 tests/ref/fate/filter-vectorscope_color >> create mode 100644 tests/ref/fate/filter-vectorscope_color2 >> create mode 100644 tests/ref/fate/filter-vectorscope_color3 >> create mode 100644 tests/ref/fate/filter-vectorscope_gray >> create mode 100644 tests/ref/fate/filter-vectorscope_xy >> >> diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak >> index 8aa4198..3be299d 100644 >> --- a/tests/fate/filter-video.mak >> +++ b/tests/fate/filter-video.mak >> @@ -123,6 +123,21 @@ fate-filter-waveform_envelope: CMD = framecrc -c:v >> pgmyuv -i $(SRC) -vf waveform >> FATE_FILTER_VSYNTH-$(CONFIG_WAVEFORM_FILTER) += fate-filter-waveform_uv >> fate-filter-waveform_uv: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf >> waveform=c=6 -flags +bitexact -sws_flags +accurate_rnd+bitexact > > I believe these would also need '-fflags +bitexact', when > FF_API_LAVF_BITEXACT is > disabled. Have you checked that? I do not think that pgmyuv store any metadata. > > Best regards, > Andreas > ___ > 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/2] avformat/mux: Warn if the muxers bitexact flag is not set but it looks as if the user wants it set
On Tue, Aug 25, 2015 at 12:03:59AM +0200, Andreas Cadhalpun wrote:
> On 24.08.2015 02:22, Michael Niedermayer wrote:
> > is below diff better: ?
> > iam quite unsure how to word this
> >
> > using the exact same system as FF_API_OLD_FILTER_OPTS is tricky as
> > there is a semantic difference
> > "codec->flags & AV_CODEC_FLAG_BITEXACT" is not deprecated as in
> > FF_API_OLD_FILTER_OPTS
> > Currently storing a bitexact stream in a container makes the
> > container bitexact. with FF_API_LAVF_BITEXACT==0 this would no longer
> > be the case and the user would have to explicitly switch the muxer
> > into bitexact mode in addition to the encoder to get a bitexact
> > result.
> >
> > --- a/libavformat/mux.c
> > +++ b/libavformat/mux.c
> > @@ -250,10 +250,17 @@ static int init_muxer(AVFormatContext *s,
> > AVDictionary **options)
> > (ret = av_opt_set_dict2(s->priv_data, &tmp,
> > AV_OPT_SEARCH_CHILDREN)) < 0)
> > goto fail;
> >
> > +if (s->nb_streams && s->streams[0]->codec->flags &
> > AV_CODEC_FLAG_BITEXACT) {
> > +if (!(s->flags & AVFMT_FLAG_BITEXACT))
> > +av_log(s, AV_LOG_WARNING, "Muxer bitexact flag is not set,
> > please set AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n"
> > +#if FF_API_LAVF_BITEXACT
> > + "This will become mandatory with
> > future API cleanup\n"
> > +#endif
> > +);
>
> I'd prefer something like:
whatever people/you prefer,
please set Author to you, if you push
thx
> if (s->nb_streams && s->streams[0]->codec->flags &
> AV_CODEC_FLAG_BITEXACT) {
> if (!(s->flags & AVFMT_FLAG_BITEXACT)) {
> #if FF_API_LAVF_BITEXACT
> av_log(s, AV_LOG_WARNING,
>"Setting the AVFormatContext to bitexact mode, because "
>"the AVCodecContext is in that mode. This behavior will "
>"change in the future. To keep the current behavior, set "
>"AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n");
> s->flags |= AVFMT_FLAG_BITEXACT;
> #else
> av_log(s, AV_LOG_WARNING,
>"The AVFormatContext is not in set to bitexact mode, only "
>"the AVCodecContext. If this is not intended, set "
>"AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n");
> #endif
> }
> }
>
> Best regards,
> Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
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 1/2] configure: do not fork off grep subprocess in probe_cc
On Mon, Aug 24, 2015 at 03:38:18PM -0400, Ganesh Ajjanagadde wrote: > grep is not required for the functionality in this instance. > This avoids an unnecessary fork, and also avoids a duplicated dumpversion > call. > Furthermore, it also corrects behavior when no minor version number is > present, see e.g > https://github.com/joyent/node/pull/25671. > > Signed-off-by: Ganesh Ajjanagadde > --- > configure | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mux: Warn if the muxers bitexact flag is not set but it looks as if the user wants it set
On 25.08.2015 00:19, Michael Niedermayer wrote:
> On Tue, Aug 25, 2015 at 12:03:59AM +0200, Andreas Cadhalpun wrote:
>> On 24.08.2015 02:22, Michael Niedermayer wrote:
>>> is below diff better: ?
>>> iam quite unsure how to word this
>>>
>>> using the exact same system as FF_API_OLD_FILTER_OPTS is tricky as
>>> there is a semantic difference
>>> "codec->flags & AV_CODEC_FLAG_BITEXACT" is not deprecated as in
>>> FF_API_OLD_FILTER_OPTS
>>> Currently storing a bitexact stream in a container makes the
>>> container bitexact. with FF_API_LAVF_BITEXACT==0 this would no longer
>>> be the case and the user would have to explicitly switch the muxer
>>> into bitexact mode in addition to the encoder to get a bitexact
>>> result.
>>>
>>> --- a/libavformat/mux.c
>>> +++ b/libavformat/mux.c
>>> @@ -250,10 +250,17 @@ static int init_muxer(AVFormatContext *s,
>>> AVDictionary **options)
>>> (ret = av_opt_set_dict2(s->priv_data, &tmp,
>>> AV_OPT_SEARCH_CHILDREN)) < 0)
>>> goto fail;
>>>
>>> +if (s->nb_streams && s->streams[0]->codec->flags &
>>> AV_CODEC_FLAG_BITEXACT) {
>>> +if (!(s->flags & AVFMT_FLAG_BITEXACT))
>>> +av_log(s, AV_LOG_WARNING, "Muxer bitexact flag is not set,
>>> please set AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n"
>>> +#if FF_API_LAVF_BITEXACT
>>> + "This will become mandatory with
>>> future API cleanup\n"
>>> +#endif
>>> +);
>>
>> I'd prefer something like:
>
> whatever people/you prefer,
> please set Author to you, if you push
OK, attaching a proper patch.
I'll push that if nobody complains.
Best regards,
Andreas
>From 67f20f0a4eb918f7f7911f620cd024043fd44d7a Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Tue, 25 Aug 2015 00:37:04 +0200
Subject: [PATCH] mux: warn if the encoders bitexact flag is set, but not the
muxers
Based-on-patch-by: Michael Niedermayer
Signed-off-by: Andreas Cadhalpun
---
libavformat/mux.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 81c4676..8d5867c 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -250,10 +250,23 @@ static int init_muxer(AVFormatContext *s, AVDictionary **options)
(ret = av_opt_set_dict2(s->priv_data, &tmp, AV_OPT_SEARCH_CHILDREN)) < 0)
goto fail;
+if (s->nb_streams && s->streams[0]->codec->flags & AV_CODEC_FLAG_BITEXACT) {
+if (!(s->flags & AVFMT_FLAG_BITEXACT)) {
#if FF_API_LAVF_BITEXACT
-if (s->nb_streams && s->streams[0]->codec->flags & AV_CODEC_FLAG_BITEXACT)
-s->flags |= AVFMT_FLAG_BITEXACT;
+av_log(s, AV_LOG_WARNING,
+ "Setting the AVFormatContext to bitexact mode, because "
+ "the AVCodecContext is in that mode. This behavior will "
+ "change in the future. To keep the current behavior, set "
+ "AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n");
+s->flags |= AVFMT_FLAG_BITEXACT;
+#else
+av_log(s, AV_LOG_WARNING,
+ "The AVFormatContext is not in set to bitexact mode, only "
+ "the AVCodecContext. If this is not intended, set "
+ "AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n");
#endif
+}
+}
// some sanity checks
if (s->nb_streams == 0 && !(of->flags & AVFMT_NOSTREAMS)) {
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add tests for vectorscope filter
On 25.08.2015 00:13, Paul B Mahol wrote: > On 8/24/15, Andreas Cadhalpun wrote: >> On 24.08.2015 21:04, Paul B Mahol wrote: >>> Signed-off-by: Paul B Mahol >>> --- >>> tests/fate/filter-video.mak | 15 +++ >>> tests/ref/fate/filter-vectorscope_color | 4 >>> tests/ref/fate/filter-vectorscope_color2 | 4 >>> tests/ref/fate/filter-vectorscope_color3 | 4 >>> tests/ref/fate/filter-vectorscope_gray | 4 >>> tests/ref/fate/filter-vectorscope_xy | 4 >>> 6 files changed, 35 insertions(+) >>> create mode 100644 tests/ref/fate/filter-vectorscope_color >>> create mode 100644 tests/ref/fate/filter-vectorscope_color2 >>> create mode 100644 tests/ref/fate/filter-vectorscope_color3 >>> create mode 100644 tests/ref/fate/filter-vectorscope_gray >>> create mode 100644 tests/ref/fate/filter-vectorscope_xy >>> >>> diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak >>> index 8aa4198..3be299d 100644 >>> --- a/tests/fate/filter-video.mak >>> +++ b/tests/fate/filter-video.mak >>> @@ -123,6 +123,21 @@ fate-filter-waveform_envelope: CMD = framecrc -c:v >>> pgmyuv -i $(SRC) -vf waveform >>> FATE_FILTER_VSYNTH-$(CONFIG_WAVEFORM_FILTER) += fate-filter-waveform_uv >>> fate-filter-waveform_uv: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf >>> waveform=c=6 -flags +bitexact -sws_flags +accurate_rnd+bitexact >> >> I believe these would also need '-fflags +bitexact', when >> FF_API_LAVF_BITEXACT is >> disabled. Have you checked that? > > I do not think that pgmyuv store any metadata. Actually you don't even have to set '-flags +bitexact', because framecrc does that anyway. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Changing media formats mid stream
On Mon, Aug 24, 2015 at 10:55:07PM +0200, Máté Sebők wrote: > Oops, forgot to mention, in dshow_pin.c the libAVPin_QueryAccept() have to > be edited to almost the same as libAVPin_ReceiveConnection() just without > the pin management. maybe roger or others can help, i dont have a windows box here nor do i really know dshow > > On Mon, Aug 24, 2015 at 10:44 PM, Máté Sebők wrote: > > > I did a dirty little hack to attempt to fix it. > > Don't call the dshow_add_device() just in build time, but run the graph > > and sleep() a bit, then call dshow_add_device() at the end of the > > dshow_read_header(). > > > > Sadly, it does not work, it does not goes beyond the dshow "chit-chat" > > between filters/pins. > > > > After ctrl+c however the right codec stats are displayed... > > > > Regards, > > Máté > > > > > > On Mon, Aug 24, 2015 at 10:29 PM, Michael Niedermayer < > > mich...@niedermayer.cc> wrote: > > > >> On Mon, Aug 24, 2015 at 02:09:28PM -0600, Roger Pack wrote: > >> > I've run into the case today where (if we understand it correctly) you > >> > setup a directshow graph, it advertises media types, then when you > >> > "start" the graph, it actually calls through and says "here's your > >> > *real* media type". > >> > Does ffmpeg internals have any concept of or support for a "changing > >> > media type" at runtime? (any other suggestions for how to handle this > >> > if it doesn't?) > >> > >> do i understand correctly that the type at read_header() stage is > >> wrong but the type later at read_packet() stage is correct ? > >> if that is the case, you can just wait with setting the type till it > >> is reliably known. > >> > >> [...] > >> -- > >> 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 > >> > >> ___ > >> 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 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/file: check for dirent.h support
On Fri, Aug 21, 2015 at 02:18:34AM +0200, Mariusz Szczepańczyk wrote: > On Thu, Jun 25, 2015 at 12:09 PM, Michael Niedermayer > wrote: > > > On Wed, Jun 24, 2015 at 03:25:18AM +0200, Mariusz Szczepańczyk wrote: > > > On Tue, Jun 23, 2015 at 8:34 PM, Michael Niedermayer > > > wrote: > > > > > > > On Mon, Jun 22, 2015 at 12:01:33AM +0200, Mariusz Szczepańczyk wrote: > > > > > --- > > > > > configure | 2 ++ > > > > > libavformat/file.c | 34 ++ > > > > > 2 files changed, 36 insertions(+) > > > > > > > > this and the previous patch fails to build > > > > > > > > make distclean ; ./configure --disable-sdl && make -j12 > > > > > > > > libavformat/file.c: In function ‘file_read_dir’: > > > > libavformat/file.c:302:10: error: ‘DT_FIFO’ undeclared (first use in > > this > > > > function) > > > > libavformat/file.c:302:10: note: each undeclared identifier is reported > > > > only once for each function it appears in > > > > libavformat/file.c:305:10: error: ‘DT_CHR’ undeclared (first use in > > this > > > > function) > > > > libavformat/file.c:308:10: error: ‘DT_DIR’ undeclared (first use in > > this > > > > function) > > > > libavformat/file.c:311:10: error: ‘DT_BLK’ undeclared (first use in > > this > > > > function) > > > > libavformat/file.c:314:10: error: ‘DT_REG’ undeclared (first use in > > this > > > > function) > > > > libavformat/file.c:317:10: error: ‘DT_LNK’ undeclared (first use in > > this > > > > function) > > > > libavformat/file.c:320:10: error: ‘DT_SOCK’ undeclared (first use in > > this > > > > function) > > > > libavformat/file.c:323:10: error: ‘DT_UNKNOWN’ undeclared (first use in > > > > this function) > > > > make: *** [libavformat/file.o] Error 1 > > > > make: *** Waiting for unfinished jobs > > > > > > > > sdl disable is needed to reproduce as sdls pkgcnonfig adds > > > > GNU_SOURCE i suspect > > > > > > > > > > Added contraint on _GNU_SOURCE and now it compiles fine on my linux in > > both > > > cases (with or without sdl). > > > > The code probably should #ifdef DT_... like DT_FIFO > > also are both variants needed ? > > are there systems lacking some of the S_IS*() ? or is there some > > disadvantage in their use ? (i dont know, just asking ...) > > > > testing for _GNU_SOURCE is not correct, nothing gurantees that the > > compiler or headers know or react to _GNU_SOURCE > > > > Yet another try. > > Completely removed reliance on DT_* and added definitions for some S_* that > can be missing. > configure |2 + > libavformat/file.c | 80 > ++--- > 2 files changed, 54 insertions(+), 28 deletions(-) > 47af9bc90efe51f1d94455bdf7e3eafaec6e61e2 > 0002-lavf-file-check-for-dirent.h-support.patch > From 820bd4aa5b064861935f8ef9e37a19bf459620c8 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Mariusz=20Szczepa=C5=84czyk?= > Date: Mon, 29 Jun 2015 00:13:43 +0200 > Subject: [PATCH 2/2] lavf/file: check for dirent.h support both patches applied thanks [...] -- 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
[FFmpeg-devel] [PATCH] avcodec/vdpau: fix compilation of mpeg1/mpeg4/vc1 decoders when h264 is disabled
Signed-off-by: James Almer
---
Untested as i don't have a vdpau system.
See
http://fate.ffmpeg.org/report.cgi?time=20150823144028&slot=x86_64-archlinux-gcc-random
libavcodec/vdpau.c | 44 +++-
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 7cb8ad2..b530466 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -358,7 +358,25 @@ int ff_vdpau_add_buffer(struct vdpau_picture_context
*pic_ctx,
/* Obsolete non-hwaccel VDPAU support below... */
-#if CONFIG_H264_VDPAU_DECODER && FF_API_VDPAU
+#if FF_API_VDPAU
+void ff_vdpau_add_data_chunk(uint8_t *data, const uint8_t *buf, int buf_size)
+{
+struct vdpau_render_state *render = (struct vdpau_render_state*)data;
+assert(render);
+
+render->bitstream_buffers= av_fast_realloc(
+render->bitstream_buffers,
+&render->bitstream_buffers_allocated,
+sizeof(*render->bitstream_buffers)*(render->bitstream_buffers_used + 1)
+);
+
+render->bitstream_buffers[render->bitstream_buffers_used].struct_version
= VDP_BITSTREAM_BUFFER_VERSION;
+render->bitstream_buffers[render->bitstream_buffers_used].bitstream
= buf;
+render->bitstream_buffers[render->bitstream_buffers_used].bitstream_bytes
= buf_size;
+render->bitstream_buffers_used++;
+}
+
+#if CONFIG_H264_VDPAU_DECODER
void ff_vdpau_h264_set_reference_frames(H264Context *h)
{
struct vdpau_render_state *render, *render_ref;
@@ -427,23 +445,6 @@ void ff_vdpau_h264_set_reference_frames(H264Context *h)
}
}
-void ff_vdpau_add_data_chunk(uint8_t *data, const uint8_t *buf, int buf_size)
-{
-struct vdpau_render_state *render = (struct vdpau_render_state*)data;
-assert(render);
-
-render->bitstream_buffers= av_fast_realloc(
-render->bitstream_buffers,
-&render->bitstream_buffers_allocated,
-sizeof(*render->bitstream_buffers)*(render->bitstream_buffers_used + 1)
-);
-
-render->bitstream_buffers[render->bitstream_buffers_used].struct_version
= VDP_BITSTREAM_BUFFER_VERSION;
-render->bitstream_buffers[render->bitstream_buffers_used].bitstream
= buf;
-render->bitstream_buffers[render->bitstream_buffers_used].bitstream_bytes
= buf_size;
-render->bitstream_buffers_used++;
-}
-
void ff_vdpau_h264_picture_start(H264Context *h)
{
struct vdpau_render_state *render;
@@ -506,7 +507,7 @@ void ff_vdpau_h264_picture_complete(H264Context *h)
}
#endif /* CONFIG_H264_VDPAU_DECODER */
-#if (CONFIG_MPEG_VDPAU_DECODER || CONFIG_MPEG1_VDPAU_DECODER) && FF_API_VDPAU
+#if CONFIG_MPEG_VDPAU_DECODER || CONFIG_MPEG1_VDPAU_DECODER
void ff_vdpau_mpeg_picture_complete(MpegEncContext *s, const uint8_t *buf,
int buf_size, int slice_count)
{
@@ -565,7 +566,7 @@ void ff_vdpau_mpeg_picture_complete(MpegEncContext *s,
const uint8_t *buf,
}
#endif /* CONFIG_MPEG_VDPAU_DECODER || CONFIG_MPEG1_VDPAU_DECODER */
-#if CONFIG_VC1_VDPAU_DECODER && FF_API_VDPAU
+#if CONFIG_VC1_VDPAU_DECODER
void ff_vdpau_vc1_decode_picture(MpegEncContext *s, const uint8_t *buf,
int buf_size)
{
@@ -636,7 +637,7 @@ void ff_vdpau_vc1_decode_picture(MpegEncContext *s, const
uint8_t *buf,
}
#endif /* (CONFIG_VC1_VDPAU_DECODER */
-#if CONFIG_MPEG4_VDPAU_DECODER && FF_API_VDPAU
+#if CONFIG_MPEG4_VDPAU_DECODER
void ff_vdpau_mpeg4_decode_picture(Mpeg4DecContext *ctx, const uint8_t *buf,
int buf_size)
{
@@ -692,6 +693,7 @@ void ff_vdpau_mpeg4_decode_picture(Mpeg4DecContext *ctx,
const uint8_t *buf,
render->bitstream_buffers_used = 0;
}
#endif /* CONFIG_MPEG4_VDPAU_DECODER */
+#endif /* FF_API_VDPAU */
int av_vdpau_get_profile(AVCodecContext *avctx, VdpDecoderProfile *profile)
{
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/file: check for dirent.h support
On 24/08/15 10:02 PM, Michael Niedermayer wrote: > On Fri, Aug 21, 2015 at 02:18:34AM +0200, Mariusz Szczepańczyk wrote: >> On Thu, Jun 25, 2015 at 12:09 PM, Michael Niedermayer >> wrote: >> >>> On Wed, Jun 24, 2015 at 03:25:18AM +0200, Mariusz Szczepańczyk wrote: On Tue, Jun 23, 2015 at 8:34 PM, Michael Niedermayer wrote: > On Mon, Jun 22, 2015 at 12:01:33AM +0200, Mariusz Szczepańczyk wrote: >> --- >> configure | 2 ++ >> libavformat/file.c | 34 ++ >> 2 files changed, 36 insertions(+) > > this and the previous patch fails to build > > make distclean ; ./configure --disable-sdl && make -j12 > > libavformat/file.c: In function ‘file_read_dir’: > libavformat/file.c:302:10: error: ‘DT_FIFO’ undeclared (first use in >>> this > function) > libavformat/file.c:302:10: note: each undeclared identifier is reported > only once for each function it appears in > libavformat/file.c:305:10: error: ‘DT_CHR’ undeclared (first use in >>> this > function) > libavformat/file.c:308:10: error: ‘DT_DIR’ undeclared (first use in >>> this > function) > libavformat/file.c:311:10: error: ‘DT_BLK’ undeclared (first use in >>> this > function) > libavformat/file.c:314:10: error: ‘DT_REG’ undeclared (first use in >>> this > function) > libavformat/file.c:317:10: error: ‘DT_LNK’ undeclared (first use in >>> this > function) > libavformat/file.c:320:10: error: ‘DT_SOCK’ undeclared (first use in >>> this > function) > libavformat/file.c:323:10: error: ‘DT_UNKNOWN’ undeclared (first use in > this function) > make: *** [libavformat/file.o] Error 1 > make: *** Waiting for unfinished jobs > > sdl disable is needed to reproduce as sdls pkgcnonfig adds > GNU_SOURCE i suspect > Added contraint on _GNU_SOURCE and now it compiles fine on my linux in >>> both cases (with or without sdl). >>> >>> The code probably should #ifdef DT_... like DT_FIFO >>> also are both variants needed ? >>> are there systems lacking some of the S_IS*() ? or is there some >>> disadvantage in their use ? (i dont know, just asking ...) >>> >>> testing for _GNU_SOURCE is not correct, nothing gurantees that the >>> compiler or headers know or react to _GNU_SOURCE >>> >> >> Yet another try. >> >> Completely removed reliance on DT_* and added definitions for some S_* that >> can be missing. > >> configure |2 + >> libavformat/file.c | 80 >> ++--- >> 2 files changed, 54 insertions(+), 28 deletions(-) >> 47af9bc90efe51f1d94455bdf7e3eafaec6e61e2 >> 0002-lavf-file-check-for-dirent.h-support.patch >> From 820bd4aa5b064861935f8ef9e37a19bf459620c8 Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?Mariusz=20Szczepa=C5=84czyk?= >> Date: Mon, 29 Jun 2015 00:13:43 +0200 >> Subject: [PATCH 2/2] lavf/file: check for dirent.h support > > both patches applied > > thanks This broke mingw-w64 (x86_32 and x86_64) and mingw32. http://fate.ffmpeg.org/report.cgi?time=20150825040408&slot=x86_32-mingw-w64-dll-windows-native http://fate.ffmpeg.org/report.cgi?time=20150822201317&slot=x86_64-freebsd10-mingw32 http://fate.ffmpeg.org/report.cgi?time=20150825012347&slot=x86_64-mingw-w64-windows-native /src/libavformat/file.c: In function 'file_read_dir': /src/libavformat/file.c:289:9: error: implicit declaration of function 'lstat' [-Werror=implicit-function-declaration] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
