Re: [FFmpeg-devel] [PATCH 0/4] ffplay and lavd SDL2 set
On 14/09/2016 23:44, Thomas Volkert wrote: On 15.09.2016 00:27, Josh de Kock wrote: Hi, Resending this set with ffplay now having two versions, a SDL2 and a SDL1 version. I've integrated all comments up until now (hopefully). Josh Josh de Kock (3): lavd: Add SDL2 output device ffplay: make copy for SDL1 MAINTAINERS: update my entries Marton Balint (1): ffplay: add SDL2 support MAINTAINERS | 4 +- Makefile | 1 + configure | 35 ++- ffplay.c | 599 +++--- ffplay.c => ffplay_sdl1.c | 1 - Maintaining two versions of ffplay sounds as too much overhead to me. Is it not possible to add some more code abstraction or even some simple #ifdef constructs to support SDL1 as well as SDL2 in only one ffplay version in parallel? So, the actually used SDL version could be selected during the configure step. After some months, the (hopefully) deprecated SDL1 code could be dropped... Yes, it is quite a bit of unnecessary overhead, but it's much cleaner than #ifdeffery in a single source file. Also, to change ffplay.c for most fixes as you'd have to reflect the change on either side of the #ifdefs, so you don't gain anything from not splitting the sources. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/muxers: add flv muxer document into doc/muxers
2016-09-15 7:30 GMT+08:00 Lou Logan : > On Wed, 14 Sep 2016 10:25:01 +0800, Steven Liu wrote: > > > From eb8856c6296eedb97a903028a93b2b1b23c50c97 Mon Sep 17 00:00:00 2001 > > From: Steven Liu > > Date: Wed, 14 Sep 2016 10:20:51 +0800 > > Subject: [PATCH] doc/muxers: add flv muxer document into doc/muxers > > > > add flvflags aac_seq_header_detect and flvflags no_sequence_end document > > into doc/muxers > > > > Signed-off-by: Steven Liu > > --- > > doc/muxers.texi | 17 + > > 1 file changed, 17 insertions(+) > > > > diff --git a/doc/muxers.texi b/doc/muxers.texi > > index ccf8ea1..c8bd874 100644 > > --- a/doc/muxers.texi > > +++ b/doc/muxers.texi > > @@ -1047,6 +1047,23 @@ ffmpeg -i file.mpg -c copy \ > > -y out.ts > > @end example > > > > +@section flv > > + > > +flv muxer. > > Adobe Flash Video Format muxer. > > > +@subsection Options > > + > > +The muxer options are: > > This muxer accepts the following options: > > > +@table @option > > + > > +@item flvflags aac_seq_header_detect > > +If this flag is set, the muxer will put AAC sequence header based on > audio stream data. > > + > > +@item flvflags no_sequence_end > > +If this flag is set, the muxer will have no sequence end tag at the end > of flv. > > +@end table > > + > > Please refer to other flag type option examples for the proper > formatting (search "@table @samp"). > ___ > > Patch update 0001-doc-muxers-add-flv-muxer-document-into-doc-muxers.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] cuvid: Check for non 420 chroma formats - they aren't supported
Despite the video parser seeming to correctly handle 422 and 444
chroma formats, the video decoder fails miserably to actually
decode frames - even though no errors are ever returned; you just
get frames showing unintialized garbage.
Signed-off-by: Philip Langdale
---
libavcodec/cuvid.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 880a572..8f3efec 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -137,6 +137,12 @@ static int CUDAAPI cuvid_handle_video_sequence(void
*opaque, CUVIDEOFORMAT* form
return 0;
}
+if (format->chroma_format != cudaVideoChromaFormat_420) {
+av_log(avctx, AV_LOG_ERROR, "Chroma formats other than 420 are not
supported\n");
+ctx->internal_error = AVERROR(EINVAL);
+return 0;
+}
+
avctx->coded_width = format->coded_width;
avctx->coded_height = format->coded_height;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/2] cuvid: Misc improvements
A couple of cuvid improvements Philip Langdale (2): cuvid: Fully re-initialize the parser after a flush. cuvid: Check for non 420 chroma formats - they aren't supported libavcodec/cuvid.c | 16 1 file changed, 16 insertions(+) -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] cuvid: Fully re-initialize the parser after a flush.
I'm not really sure how this worked at all before, but we do need to
reinitalize the parser with the stream extradata.
Signed-off-by: Philip Langdale
---
libavcodec/cuvid.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 19a7772..880a572 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -706,6 +706,7 @@ static void cuvid_flush(AVCodecContext *avctx)
AVHWDeviceContext *device_ctx = (AVHWDeviceContext*)ctx->hwdevice->data;
AVCUDADeviceContext *device_hwctx = device_ctx->hwctx;
CUcontext dummy, cuda_ctx = device_hwctx->cuda_ctx;
+CUVIDSOURCEDATAPACKET seq_pkt = { 0, };
int ret;
ctx->ever_flushed = 1;
@@ -736,6 +737,15 @@ static void cuvid_flush(AVCodecContext *avctx)
if (ret < 0)
goto error;
+seq_pkt.payload = ctx->cuparse_ext.raw_seqhdr_data;
+seq_pkt.payload_size = ctx->cuparse_ext.format.seqhdr_data_length;
+
+if (seq_pkt.payload && seq_pkt.payload_size) {
+ret = CHECK_CU(cuvidParseVideoData(ctx->cuparser, &seq_pkt));
+if (ret < 0)
+goto error;
+}
+
ret = CHECK_CU(cuCtxPopCurrent(&dummy));
if (ret < 0)
goto error;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/muxers: add flv muxer document into doc/muxers
On Wed, 14 Sep 2016 10:25:01 +0800, Steven Liu wrote: > From eb8856c6296eedb97a903028a93b2b1b23c50c97 Mon Sep 17 00:00:00 2001 > From: Steven Liu > Date: Wed, 14 Sep 2016 10:20:51 +0800 > Subject: [PATCH] doc/muxers: add flv muxer document into doc/muxers > > add flvflags aac_seq_header_detect and flvflags no_sequence_end document > into doc/muxers > > Signed-off-by: Steven Liu > --- > doc/muxers.texi | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/doc/muxers.texi b/doc/muxers.texi > index ccf8ea1..c8bd874 100644 > --- a/doc/muxers.texi > +++ b/doc/muxers.texi > @@ -1047,6 +1047,23 @@ ffmpeg -i file.mpg -c copy \ > -y out.ts > @end example > > +@section flv > + > +flv muxer. Adobe Flash Video Format muxer. > +@subsection Options > + > +The muxer options are: This muxer accepts the following options: > +@table @option > + > +@item flvflags aac_seq_header_detect > +If this flag is set, the muxer will put AAC sequence header based on audio > stream data. > + > +@item flvflags no_sequence_end > +If this flag is set, the muxer will have no sequence end tag at the end of > flv. > +@end table > + Please refer to other flag type option examples for the proper formatting (search "@table @samp"). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/muxers: add hls_segment_size option document
On Wed, 14 Sep 2016 07:40:08 +0800, Steven Liu wrote:
> From 97ff17a17db5ecac295327281738f044239cf322 Mon Sep 17 00:00:00 2001
> From: Steven Liu
> Date: Wed, 14 Sep 2016 07:14:18 +0800
> Subject: [PATCH] doc/muxers: add hls_segment_size option document
>
> and make an sample introduce how to use hls_segment_size.
>
> Signed-off-by: LiuQi
> ---
> doc/muxers.texi | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index ccf8ea1..9b1f717 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -410,6 +410,17 @@ ffmpeg in.nut -hls_segment_filename 'file%03d.ts'
> out.m3u8
> This example will produce the playlist, @file{out.m3u8}, and segment files:
> @file{file000.ts}, @file{file001.ts}, @file{file002.ts}, etc.
>
> +@item hls_segment_size @var{max_seg_size}
Typically, the @var following the actual option name describes the data
type accepted by the option. @var{integer} makes more sense to me while
@var{max_seg_size} is more ambiguous.
> +Set the segments maximum size. Useful to reduce segment files numbers,
> packaging
> +some segment files in one file, and keep playlist segments as normal,
> +Support hls m3u8 @code{#EXT-X-BYTERANGE} in @code{#EXT-X-VERSION:4},
> +@var{max_seg_size} is used in bytes format:
I attempted to make your description easier to understand:
Set maximum size per segment media file (in bytes). Useful to reduce
the number of individual segment media files produced by combining
segments into one or more larger files. The resulting playlist will
support @code{#EXT-X-VERSION:4} and will specify segments using byte
ranges to refer to the proper location in the associated media file.
Note that this does not affect the number of segments in the
playlist, but the number of resulting media files that the segments
refer to.
Please correct me if any of this is incorrect.
> +@example
> +ffmpeg in.nut -hls_segment_size 200 out.m3u8
> +@end example
> +every segment files size is 200 bytes, and one segment file have some
> segments info
> +in @file{out.m3u8}.
As for the example description it can be simplified:
In this example each segment media file size will be roughly
200 bytes.
Note that this patch should not be applied unless/until "[PATCH]
avformat/hlsenc: refine EXT-X-BYTERANGE support for segments" is
applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] lavd: Add SDL2 output device
On 9/14/2016 7:27 PM, Josh de Kock wrote: > Acked-by: Michael Niedermayer > Signed-off-by: Josh de Kock > --- > configure| 28 +++- > libavdevice/Makefile | 1 + > libavdevice/alldevices.c | 1 + > libavdevice/sdl2.c | 377 > +++ > 4 files changed, 406 insertions(+), 1 deletion(-) > create mode 100644 libavdevice/sdl2.c > Missing changelog entry about SDL2 outdev. Also one for the ffplay SDL2 port in patch 3. > diff --git a/configure b/configure > index b11ca7f..6ef2410 100755 > --- a/configure > +++ b/configure > @@ -292,6 +292,7 @@ External library support: >--disable-schannel disable SChannel SSP, needed for TLS support on > Windows if openssl and gnutls are not used > [autodetect] >--disable-sdldisable sdl [autodetect] > + --disable-sdl2 disable sdl2 [autodetect] >--disable-securetransport disable Secure Transport, needed for TLS support > on OSX if openssl and gnutls are not used > [autodetect] >--enable-x11grab enable X11 grabbing (legacy) [no] > @@ -1548,6 +1549,7 @@ EXTERNAL_LIBRARY_LIST=" > openssl > schannel > sdl > +sdl2 > securetransport > videotoolbox > x11grab > @@ -2022,6 +2024,7 @@ HAVE_LIST=" > perl > pod2man > sdl > +sdl2 > section_data_rel_ro > texi2html > threads > @@ -2945,6 +2948,7 @@ pulse_outdev_deps="libpulse" > qtkit_indev_extralibs="-framework QTKit -framework Foundation -framework > QuartzCore" > qtkit_indev_select="qtkit" > sdl_outdev_deps="sdl" > +sdl2_outdev_deps="sdl2" > sndio_indev_deps="sndio_h" > sndio_outdev_deps="sndio_h" > v4l_indev_deps="linux_videodev_h" > @@ -5850,7 +5854,7 @@ if enabled gcrypt; then > fi > fi > > -if ! disabled sdl; then > +if ! disabled sdl && ! enabled sdl2; then SDL2 should be the default. Especially if ffplay's SDL1 version is going to be marked as deprecated and probably also removed next year. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] ffplay: add SDL2 support
On 9/14/2016 7:27 PM, Josh de Kock wrote: > diff --git a/ffplay_sdl1.c b/ffplay_sdl1.c > index adbe9cb..d698420 100644 > --- a/ffplay_sdl1.c > +++ b/ffplay_sdl1.c > @@ -23,7 +23,6 @@ > * simple media player based on the FFmpeg libraries > */ > > -#include "config.h" Why? It's needed below, and even if some other header pulls it in, there's no reason to remove it here. > #include > #include > #include ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/4] ffplay and lavd SDL2 set
On 9/14/2016 7:44 PM, Thomas Volkert wrote: > On 15.09.2016 00:27, Josh de Kock wrote: >> Hi, >> >> Resending this set with ffplay now having two versions, a SDL2 and a >> SDL1 version. I've integrated all comments up until now (hopefully). >> >> Josh >> >> Josh de Kock (3): >>lavd: Add SDL2 output device >>ffplay: make copy for SDL1 >>MAINTAINERS: update my entries >> >> Marton Balint (1): >>ffplay: add SDL2 support >> >> MAINTAINERS | 4 +- >> Makefile | 1 + >> configure | 35 ++- >> ffplay.c | 599 >> +++--- >> ffplay.c => ffplay_sdl1.c | 1 - >> > > Maintaining two versions of ffplay sounds as too much overhead to me. Is it > not possible to add some more code abstraction or even some simple #ifdef > constructs to support SDL1 as well as SDL2 in only one ffplay version in > parallel? > So, the actually used SDL version could be selected during the configure > step. After some months, the (hopefully) deprecated SDL1 code could be > dropped... > > Best regards, > Thomas. This is not two separate ffplay programs. It's exactly what you said except using two separate source files instead of #ifdeffery in a single source file. Look at patches 2 and 3 in the set. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/4] ffplay and lavd SDL2 set
On 15.09.2016 00:27, Josh de Kock wrote: Hi, Resending this set with ffplay now having two versions, a SDL2 and a SDL1 version. I've integrated all comments up until now (hopefully). Josh Josh de Kock (3): lavd: Add SDL2 output device ffplay: make copy for SDL1 MAINTAINERS: update my entries Marton Balint (1): ffplay: add SDL2 support MAINTAINERS | 4 +- Makefile | 1 + configure | 35 ++- ffplay.c | 599 +++--- ffplay.c => ffplay_sdl1.c | 1 - Maintaining two versions of ffplay sounds as too much overhead to me. Is it not possible to add some more code abstraction or even some simple #ifdef constructs to support SDL1 as well as SDL2 in only one ffplay version in parallel? So, the actually used SDL version could be selected during the configure step. After some months, the (hopefully) deprecated SDL1 code could be dropped... Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] MAINTAINERS: update my entries
Signed-off-by: Josh de Kock --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index f7e8298..52d8eed 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -24,7 +24,8 @@ ffmpeg: ffmpeg.c Michael Niedermayer ffplay: - ffplay.c Marton Balint + ffplay.c Marton Balint, Josh de Kock + ffplay_sdl1.c Josh de Kock ffprobe: ffprobe.c Stefano Sabatini @@ -285,6 +286,7 @@ libavdevice pulse_audio_enc.c Lukasz Marek qtkit.m Thilo Borgmann sdl Stefano Sabatini + sdl2.cJosh de Kock v4l2.cGiorgio Vazzana vfwcap.c Ramiro Polla xv.c Lukasz Marek -- 2.7.4 (Apple Git-66) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] ffplay: make copy for SDL1
Signed-off-by: Josh de Kock --- Makefile | 1 + ffplay.c | 5 + ffplay.c => ffplay_sdl1.c | 0 3 files changed, 6 insertions(+) copy ffplay.c => ffplay_sdl1.c (100%) diff --git a/Makefile b/Makefile index 8aa72fd..15ba3df 100644 --- a/Makefile +++ b/Makefile @@ -29,6 +29,7 @@ ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF)) $(foreach prog,$(AVBASENAMES),$(eval OBJS-$(prog) += cmdutils.o)) $(foreach prog,$(AVBASENAMES),$(eval OBJS-$(prog)-$(CONFIG_OPENCL) += cmdutils_opencl.o)) +OBJS-ffplay-$(HAVE_SDL) += ffplay_sdl1.o OBJS-ffmpeg += ffmpeg_opt.o ffmpeg_filter.o OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o OBJS-ffmpeg-$(CONFIG_LIBMFX) += ffmpeg_qsv.o diff --git a/ffplay.c b/ffplay.c index adbe9cb..67a17e0 100644 --- a/ffplay.c +++ b/ffplay.c @@ -24,6 +24,9 @@ */ #include "config.h" + +#if HAVE_SDL2 + #include #include #include @@ -3863,3 +3866,5 @@ int main(int argc, char **argv) return 0; } + +#endif diff --git a/ffplay.c b/ffplay_sdl1.c similarity index 100% copy from ffplay.c copy to ffplay_sdl1.c -- 2.7.4 (Apple Git-66) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] lavd: Add SDL2 output device
Acked-by: Michael Niedermayer
Signed-off-by: Josh de Kock
---
configure| 28 +++-
libavdevice/Makefile | 1 +
libavdevice/alldevices.c | 1 +
libavdevice/sdl2.c | 377 +++
4 files changed, 406 insertions(+), 1 deletion(-)
create mode 100644 libavdevice/sdl2.c
diff --git a/configure b/configure
index b11ca7f..6ef2410 100755
--- a/configure
+++ b/configure
@@ -292,6 +292,7 @@ External library support:
--disable-schannel disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used
[autodetect]
--disable-sdldisable sdl [autodetect]
+ --disable-sdl2 disable sdl2 [autodetect]
--disable-securetransport disable Secure Transport, needed for TLS support
on OSX if openssl and gnutls are not used
[autodetect]
--enable-x11grab enable X11 grabbing (legacy) [no]
@@ -1548,6 +1549,7 @@ EXTERNAL_LIBRARY_LIST="
openssl
schannel
sdl
+sdl2
securetransport
videotoolbox
x11grab
@@ -2022,6 +2024,7 @@ HAVE_LIST="
perl
pod2man
sdl
+sdl2
section_data_rel_ro
texi2html
threads
@@ -2945,6 +2948,7 @@ pulse_outdev_deps="libpulse"
qtkit_indev_extralibs="-framework QTKit -framework Foundation -framework
QuartzCore"
qtkit_indev_select="qtkit"
sdl_outdev_deps="sdl"
+sdl2_outdev_deps="sdl2"
sndio_indev_deps="sndio_h"
sndio_outdev_deps="sndio_h"
v4l_indev_deps="linux_videodev_h"
@@ -5850,7 +5854,7 @@ if enabled gcrypt; then
fi
fi
-if ! disabled sdl; then
+if ! disabled sdl && ! enabled sdl2; then
SDL_CONFIG="${cross_prefix}sdl-config"
if check_pkg_config sdl SDL_events.h SDL_PollEvent; then
check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 |
SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) >= 0x010201" $sdl_cflags &&
@@ -5876,6 +5880,27 @@ if ! disabled sdl; then
fi
enabled sdl && add_cflags $sdl_cflags && add_extralibs $sdl_libs
+if ! disabled sdl2 && ! enabled sdl; then
+SDL2_CONFIG="${cross_prefix}sdl2-config"
+if check_pkg_config sdl2 SDL_events.h SDL_PollEvent; then
+check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 |
SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) >= 0x020001" $sdl2_cflags &&
+check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 |
SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) < 0x020100" $sdl2_cflags &&
+enable sdl2
+else
+ if "${SDL2_CONFIG}" --version > /dev/null 2>&1; then
+sdl2_cflags=$("${SDL2_CONFIG}" --cflags)
+sdl2_libs=$("${SDL2_CONFIG}" --libs)
+check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 |
SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) >= 0x020001" $sdl2_cflags &&
+check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 |
SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) < 0x020100" $sdl2_cflags &&
+enable sdl2
+ fi
+fi
+if test $target_os = "mingw32"; then
+sdl2_libs="$sdl2_libs -mconsole"
+fi
+fi
+enabled sdl2 && add_cflags $sdl2_cflags && add_extralibs $sdl2_libs
+
disabled securetransport || { check_func SecIdentityCreate
"-Wl,-framework,CoreFoundation -Wl,-framework,Security" &&
check_lib2 "Security/SecureTransport.h Security/Security.h"
"SSLCreateContext SecItemImport" "-Wl,-framework,CoreFoundation
-Wl,-framework,Security" &&
enable securetransport; }
@@ -6480,6 +6505,7 @@ echo "network support ${network-no}"
echo "threading support ${thread_type-no}"
echo "safe bitstream reader ${safe_bitstream_reader-no}"
echo "SDL support ${sdl-no}"
+echo "SDL2 support ${sdl2-no}"
echo "opencl enabled${opencl-no}"
echo "JNI support ${jni-no}"
echo "texi2html enabled ${texi2html-no}"
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index 585827b..1c4b4d3 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -41,6 +41,7 @@ OBJS-$(CONFIG_PULSE_OUTDEV) += pulse_audio_enc.o
\
pulse_audio_common.o
OBJS-$(CONFIG_QTKIT_INDEV) += qtkit.o
OBJS-$(CONFIG_SDL_OUTDEV)+= sdl.o
+OBJS-$(CONFIG_SDL2_OUTDEV) += sdl2.o
OBJS-$(CONFIG_SNDIO_INDEV) += sndio_dec.o sndio.o
OBJS-$(CONFIG_SNDIO_OUTDEV) += sndio_enc.o sndio.o
OBJS-$(CONFIG_V4L2_INDEV)+= v4l2.o v4l2-common.o timefilter.o
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index 26aecf2..c0a9d9a 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -64,6 +64,7 @@ void avdevice_register_all(void)
REGISTER_INOUTDEV(PULSE,pulse);
REGISTER_INDEV (QTKIT,qtkit);
REGISTER_OUTDEV (SDL, sdl);
+REGISTER_OUTDEV (SDL2, sdl2);
REGISTER_INOUTDEV(SNDIO,sndio);
REGISTER_INOUTDEV(V4L2, v4l2);
//REGISTER_INDEV (
[FFmpeg-devel] [PATCH 3/4] ffplay: add SDL2 support
From: Marton Balint
Tested-by: James Almer (Windows, mingw-w64)
Signed-off-by: Josh de Kock
---
configure | 7 +-
ffplay.c | 594 --
ffplay_sdl1.c | 1 -
3 files changed, 250 insertions(+), 352 deletions(-)
diff --git a/configure b/configure
index 6ef2410..4641f42 100755
--- a/configure
+++ b/configure
@@ -3138,8 +3138,9 @@ ffmpeg_deps="avcodec avfilter avformat swresample"
ffmpeg_select="aformat_filter anull_filter atrim_filter format_filter
null_filter
setpts_filter trim_filter"
-ffplay_deps="avcodec avformat swscale swresample sdl"
-ffplay_libs='$sdl_libs'
+ffplay_deps="avcodec avformat swscale swresample"
+ffplay_deps_any="sdl sdl2"
+ffplay_libs='$sdl_libs $sdl2_libs'
ffplay_select="rdft crop_filter transpose_filter hflip_filter vflip_filter
rotate_filter"
ffprobe_deps="avcodec avformat"
ffserver_deps="avformat fork sarestart"
@@ -6665,7 +,7 @@ HOSTLD_O=$HOSTLD_O
TARGET_EXEC=$target_exec $target_exec_args
TARGET_PATH=$target_path
TARGET_SAMPLES=${target_samples:-\$(SAMPLES)}
-CFLAGS-ffplay=$sdl_cflags
+CFLAGS-ffplay=${sdl_cflags:-\$(sdl2_cflags)}
ZLIB=$($ldflags_filter -lz)
LIB_INSTALL_EXTRA_CMD=$LIB_INSTALL_EXTRA_CMD
EXTRALIBS=$extralibs
diff --git a/ffplay.c b/ffplay.c
index 67a17e0..f923a24 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -108,6 +108,8 @@ const int program_birth_year = 2003;
#define CURSOR_HIDE_DELAY 100
+#define USE_ONEPASS_SUBTITLE_RENDER 1
+
static unsigned sws_flags = SWS_BICUBIC;
typedef struct MyAVPacketList {
@@ -155,17 +157,17 @@ typedef struct Clock {
typedef struct Frame {
AVFrame *frame;
AVSubtitle sub;
-AVSubtitleRect **subrects; /* rescaled subtitle rectangles in yuva */
int serial;
double pts; /* presentation timestamp for the frame */
double duration; /* estimated duration of the frame */
int64_t pos; /* byte position of the frame in the input file */
-SDL_Overlay *bmp;
+SDL_Texture *bmp;
int allocated;
-int reallocate;
int width;
int height;
+int format;
AVRational sar;
+int uploaded;
} Frame;
typedef struct FrameQueue {
@@ -275,6 +277,8 @@ typedef struct VideoState {
FFTSample *rdft_data;
int xpos;
double last_vis_time;
+SDL_Texture *vis_texture;
+SDL_Texture *sub_texture;
int subtitle_stream;
AVStream *subtitle_st;
@@ -287,11 +291,8 @@ typedef struct VideoState {
AVStream *video_st;
PacketQueue videoq;
double max_frame_duration; // maximum duration of a frame - above
this, we consider the jump a timestamp discontinuity
-#if !CONFIG_AVFILTER
struct SwsContext *img_convert_ctx;
-#endif
struct SwsContext *sub_convert_ctx;
-SDL_Rect last_display_rect;
int eof;
char *filename;
@@ -316,8 +317,6 @@ typedef struct VideoState {
static AVInputFormat *file_iformat;
static const char *input_filename;
static const char *window_title;
-static int fs_screen_width;
-static int fs_screen_height;
static int default_width = 640;
static int default_height = 480;
static int screen_width = 0;
@@ -365,7 +364,8 @@ static AVPacket flush_pkt;
#define FF_ALLOC_EVENT (SDL_USEREVENT)
#define FF_QUIT_EVENT(SDL_USEREVENT + 2)
-static SDL_Surface *screen;
+static SDL_Window *window;
+static SDL_Renderer *renderer;
#if CONFIG_AVFILTER
static int opt_add_vfilter(void *optctx, const char *opt, const char *arg)
@@ -653,12 +653,6 @@ static void decoder_destroy(Decoder *d) {
static void frame_queue_unref_item(Frame *vp)
{
-int i;
-for (i = 0; i < vp->sub.num_rects; i++) {
-av_freep(&vp->subrects[i]->data[0]);
-av_freep(&vp->subrects[i]);
-}
-av_freep(&vp->subrects);
av_frame_unref(vp->frame);
avsubtitle_free(&vp->sub);
}
@@ -801,113 +795,47 @@ static void decoder_abort(Decoder *d, FrameQueue *fq)
packet_queue_flush(d->queue);
}
-static inline void fill_rectangle(SDL_Surface *screen,
- int x, int y, int w, int h, int color, int
update)
+static inline void fill_rectangle(int x, int y, int w, int h)
{
SDL_Rect rect;
rect.x = x;
rect.y = y;
rect.w = w;
rect.h = h;
-SDL_FillRect(screen, &rect, color);
-if (update && w > 0 && h > 0)
-SDL_UpdateRect(screen, x, y, w, h);
-}
-
-/* draw only the border of a rectangle */
-static void fill_border(int xleft, int ytop, int width, int height, int x, int
y, int w, int h, int color, int update)
-{
-int w1, w2, h1, h2;
-
-/* fill the background */
-w1 = x;
-if (w1 < 0)
-w1 = 0;
-w2 = width - (x + w);
-if (w2 < 0)
-w2 = 0;
-h1 = y;
-if (h1 < 0)
-h1 = 0;
-h2 = height - (y + h);
-if (h2 < 0)
-h2 = 0;
-fill_rectangle(screen,
- xleft, ytop,
- w1, height,
- color, update);
-fill_rectangl
[FFmpeg-devel] [PATCH 0/4] ffplay and lavd SDL2 set
Hi, Resending this set with ffplay now having two versions, a SDL2 and a SDL1 version. I've integrated all comments up until now (hopefully). Josh Josh de Kock (3): lavd: Add SDL2 output device ffplay: make copy for SDL1 MAINTAINERS: update my entries Marton Balint (1): ffplay: add SDL2 support MAINTAINERS | 4 +- Makefile | 1 + configure | 35 ++- ffplay.c | 599 +++--- ffplay.c => ffplay_sdl1.c | 1 - libavdevice/Makefile | 1 + libavdevice/alldevices.c | 1 + libavdevice/sdl2.c| 377 + 8 files changed, 665 insertions(+), 354 deletions(-) copy ffplay.c => ffplay_sdl1.c (99%) create mode 100644 libavdevice/sdl2.c -- 2.7.4 (Apple Git-66) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix target_level for EAC3.
ping.
On Fri, Sep 9, 2016 at 12:48 PM, Nikolas Bowe wrote:
> Currently when using target_level with EAC3 it produces silence. This
> small patch fixes target_level for decoding EAC3.
>
> Example:
> ffmpeg -y -i /tmp/test.wav -acodec eac3 -dialnorm -14 -ac 6 -b:a 384000
> /tmp/test.m2ts
> ffmpeg -y -target_level -24 -i /tmp/test.m2ts -acodec pcm_s16le -f
> matroska /tmp/out.mkv
> ffplay /tmp/out.mkv
> ---
> libavcodec/ac3.h | 2 +-
> libavcodec/ac3dec.c | 9 ++---
> libavcodec/ac3dec.h | 4
> libavcodec/eac3dec.c | 14 +++---
> 4 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/ac3.h b/libavcodec/ac3.h
> index 747f2f5..5c9c377 100644
> --- a/libavcodec/ac3.h
> +++ b/libavcodec/ac3.h
> @@ -87,7 +87,7 @@ typedef int16_t SHORTFLOAT;
> #define AC3_NORM(norm) (1.0f/(norm))
> #define AC3_MUL(a,b)((a) * (b))
> #define AC3_RANGE(x)(dynamic_range_tab[(x)])
> -#define AC3_HEAVY_RANGE(x) (heavy_dynamic_range_tab[(x)])
> +#define AC3_HEAVY_RANGE(x) (ff_ac3_heavy_dynamic_range_tab[(x)])
> #define AC3_DYNAMIC_RANGE(x)(powf(x, s->drc_scale))
> #define AC3_SPX_BLEND(x)(x)* (1.0f/32)
> #define AC3_DYNAMIC_RANGE1 1.0f
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index fac189b..a95c204 100644
> --- a/libavcodec/ac3dec.c
> +++ b/libavcodec/ac3dec.c
> @@ -63,9 +63,11 @@ static const uint8_t quantization_tab[16] = {
> 5, 6, 7, 8, 9, 10, 11, 12, 14, 16
> };
>
> +#if (!USE_FIXED)
> /** dynamic range table. converts codes to scale factors. */
> static float dynamic_range_tab[256];
> -static float heavy_dynamic_range_tab[256];
> +float ff_ac3_heavy_dynamic_range_tab[256];
> +#endif
>
> /** Adjustments in dB gain */
> static const float gain_levels[9] = {
> @@ -159,6 +161,7 @@ static av_cold void ac3_tables_init(void)
> b5_mantissas[i] = symmetric_dequant(i, 15);
> }
>
> +#if (!USE_FIXED)
> /* generate dynamic range table
> reference: Section 7.7.1 Dynamic Range Control */
> for (i = 0; i < 256; i++) {
> @@ -170,9 +173,9 @@ static av_cold void ac3_tables_init(void)
> reference: Section 7.7.2 Heavy Compression */
> for (i = 0; i < 256; i++) {
> int v = (i >> 4) - ((i >> 7) << 4) - 4;
> -heavy_dynamic_range_tab[i] = powf(2.0f, v) * ((i & 0xF) | 0x10);
> +ff_ac3_heavy_dynamic_range_tab[i] = powf(2.0f, v) * ((i & 0xF) |
> 0x10);
> }
> -
> +#endif
> }
>
> /**
> diff --git a/libavcodec/ac3dec.h b/libavcodec/ac3dec.h
> index c2b867e..6cd67c0 100644
> --- a/libavcodec/ac3dec.h
> +++ b/libavcodec/ac3dec.h
> @@ -260,4 +260,8 @@ static void
> ff_eac3_decode_transform_coeffs_aht_ch(AC3DecodeContext
> *s, int ch);
> */
> static void ff_eac3_apply_spectral_extension(AC3DecodeContext *s);
>
> +#if (!USE_FIXED)
> +extern float ff_ac3_heavy_dynamic_range_tab[256];
> +#endif
> +
> #endif /* AVCODEC_AC3DEC_H */
> diff --git a/libavcodec/eac3dec.c b/libavcodec/eac3dec.c
> index 47e5aa6..83a54bc 100644
> --- a/libavcodec/eac3dec.c
> +++ b/libavcodec/eac3dec.c
> @@ -339,9 +339,17 @@ static int ff_eac3_parse_header(AC3DecodeContext *s)
>
> /* volume control params */
> for (i = 0; i < (s->channel_mode ? 1 : 2); i++) {
> -skip_bits(gbc, 5); // skip dialog normalization
> -if (get_bits1(gbc)) {
> -skip_bits(gbc, 8); // skip compression gain word
> +s->dialog_normalization[i] = -get_bits(gbc, 5);
> +if (s->dialog_normalization[i] == 0) {
> +s->dialog_normalization[i] = -31;
> +}
> +if (s->target_level != 0) {
> +s->level_gain[i] = powf(2.0f,
> +(float)(s->target_level - s->dialog_normalization[i])/6.
> 0f);
> +}
> +s->compression_exists[i] = get_bits1(gbc);
> +if (s->compression_exists[i]) {
> +s->heavy_dynamic_range[i] = AC3_HEAVY_RANGE(get_bits(gbc, 8));
> }
> }
>
> --
> 2.8.0.rc3.226.g39d4020
>
>
--
Nikolas Bowe | SWE | nb...@google.com | 408-565-5137
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] vf_colorspace: Interpret unspecified color range as limited range
This is the assumption that is made in pixel format conversion do
throughout the code (in particular swscale and vf_colormatrix).
Signed-off-by: Vittorio Giovara
---
libavfilter/vf_colorspace.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index b9ecb5f..7e87cd8 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -522,6 +522,7 @@ static int get_range_off(int *off, int *y_rng, int *uv_rng,
enum AVColorRange rng, int depth)
{
switch (rng) {
+case AVCOL_RANGE_UNSPECIFIED:
case AVCOL_RANGE_MPEG:
*off = 16 << (depth - 8);
*y_rng = 219 << (depth - 8);
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] vf_colorspace: Add modern names for color range option
Hi,
On Wed, Sep 14, 2016 at 5:09 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:
> Allows to use values returned from API and from ffprobe directly.
>
> Signed-off-by: Vittorio Giovara
> ---
> libavfilter/vf_colorspace.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index 7e87cd8..b993928 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -1039,7 +1039,9 @@ static const AVOption colorspace_options[] = {
> { "range", "Output color range",
>OFFSET(user_rng), AV_OPT_TYPE_INT, { .i64 =
> AVCOL_RANGE_UNSPECIFIED },
>AVCOL_RANGE_UNSPECIFIED, AVCOL_RANGE_NB - 1, FLAGS, "rng" },
> +ENUM("tv", AVCOL_RANGE_MPEG, "rng"),
> ENUM("mpeg",AVCOL_RANGE_MPEG, "rng"),
> +ENUM("pc", AVCOL_RANGE_JPEG, "rng"),
> ENUM("jpeg",AVCOL_RANGE_JPEG, "rng"),
>
> { "primaries", "Output color primaries",
> --
> 2.9.3
OK, and pushed.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] vf_colorspace: Add modern names for color range option
Allows to use values returned from API and from ffprobe directly.
Signed-off-by: Vittorio Giovara
---
libavfilter/vf_colorspace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 7e87cd8..b993928 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -1039,7 +1039,9 @@ static const AVOption colorspace_options[] = {
{ "range", "Output color range",
OFFSET(user_rng), AV_OPT_TYPE_INT, { .i64 = AVCOL_RANGE_UNSPECIFIED },
AVCOL_RANGE_UNSPECIFIED, AVCOL_RANGE_NB - 1, FLAGS, "rng" },
+ENUM("tv", AVCOL_RANGE_MPEG, "rng"),
ENUM("mpeg",AVCOL_RANGE_MPEG, "rng"),
+ENUM("pc", AVCOL_RANGE_JPEG, "rng"),
ENUM("jpeg",AVCOL_RANGE_JPEG, "rng"),
{ "primaries", "Output color primaries",
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.
On Wed, Sep 14, 2016 at 12:20:52AM -0700, Sasi Inguva wrote: > On Tue, Sep 13, 2016 at 4:39 PM, Sasi Inguva wrote: > > > Sorry for the very late reply. I was busy with other things. > > > > On Sat, Sep 3, 2016 at 4:48 PM, Michael Niedermayer < > > mich...@niedermayer.cc> wrote: > > > >> On Sat, Sep 03, 2016 at 12:06:39PM -0700, Sasi Inguva wrote: > >> > Hi Michael, > >> > > >> > In fact from audacity I see that out-ingu.wav out-mp3.wav are almost > >> > equivalent, > >> > >> They do not match. (and that is alot more vissible if you scale the > >> time axis up a bit) > >> > >> You also dont use the existing API for handling initial padding/skip > >> And you didnt reply to this concern > >> its probably not that hard to fix that ... > >> instead of droping just at packet granularity you would set the stuff > >> for droping at sample granularity (too) > >> > > > > Yes. Looking at it more closely now, they don't matrch exactly and this is > > because as you said, number of samples to drop is not exactly multiple of > > number of packets. In that case we need to partially discard some samples > > of a packet. This can be done by using AV_PKT_SIDE_DATA_SKIP_SAMPLES. I > > can change the code to use this packet side data instead of discard packet > > flag, if it is ok. ok > > > > > >> > >> also maybe you missed my question about your oppinion on the correct > >> timestamp output: > >> "My first question is, entirely independant of the implementation from > >> the patches. What is the correct output ? (my primary focus is on > >> the timestamps)" > >> > >> Iam curious because to me the timestamps of the dropped packets look > >> wrong and id like to know your oppinion about this. Is this a > >> implementation issue (if so please explain) or is there some reason > >> independant of the implementation (if so please explain too) > >> > > > > The correct output according to me should be - we should show exactly the > > same presentation timestmap indicated by the MOV stts, ctts atoms, for the > > samples that fall inside the edits. As long as the PTS is according to what > > the edit and stts,ctts atoms say. I don't really have to worry about what > > the decoding timestamp for those packets should be (DTS might as well be > > AV_NOPTS_VALUE for all packets) . > > > > In the current implementation, we directly assign the timestamp in the > > AVIndex to pkt->dts . http://git.videolan.org/?p=ffmpeg.git;a=blob;f= > > libavformat/mov.c;h=6e80b93271a4f998af6ba1af795d7d7c5d67f5a1;hb=HEAD#l5332 > > . The implementation of the edit list code is such that, it needs to be > > filled with "linear monotonically increasing timestamps for the > > non-discarded packets " to have the samples denoted by the editlists to > > have linear monotonically increasing timestamps, in essence, to avoid a big > > gap between the presentation of the end of first edit list and the start of > > next edit list because of the discarded packets. > > > Hence while parsing a new edit list we bump down the index entry timestamp > > to (frame_duration + last non-discarded packet from previous edit list ) . > > And that's why we get non-monotonic timestamps as a whole in the > > AVIndexEntry . > > > > I think my wording is confusing here. Just clarifying . For one editlist/ > within one editlist, the AVIndexEntry samples pertaining to that edit, need > to be filled with "monotonic timestamps which increase in steps of their > corresponding 'stts' atom entries ", to achieve the correct presentation > timestamp for those samples. > > When we start parsing the next edit list entry, and start adding index > entries to AVIndexEntry we need to avoid a big gap between the presentation > of the end of first edit and the start of next edit, that might happen > because of the DISCARD packets added to the AVIndexEntry while parsing the > first edit. Hence we start adding index entries from a bumped down value > corresponding to (frame_duration + last non-discarded packet from previous > edit ) . And that's why we get non-monotonic timestamps as a whole in the > AVIndexEntry . > > > > Let us take an example of a file with two edit lists. First edit list > > ending on a B frame. This is what ffprobe -show_packet -pf compact looks > > like . Where 'D' stands for discarded frame. ( I've attached a 6th patch to > > ffprobe to achieve this formatting ). > > ./ffprobe -show_packets -print_format compact mov-2elist-bpyramid-1elist- > > ends-on-bref.mov > > . > > packet|codec_type=video|stream_index=0|pts=10752|pts_ > > time=0.875000|dts=8192|dts_time=0.67|duration=512| > > duration_time=0.041667|convergence_duration=N/A| > > convergence_duration_time=N/A|size=1281|pos=39546|flags=__ - Pframe > > packet|codec_type=video|stream_index=0|pts=9728|pts_ > > time=0.791667|dts=8704|dts_time=0.708333|duration=512| > > duration_time=0.041667|convergence_duration=N/A| > > convergence_duration_time=N/A|size=749|pos=40827|flags=__ - B pyramidal > > ref > > packet|
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
Hi, On Wed, Sep 14, 2016 at 1:46 PM, Carl Eugen Hoyos wrote: > 2016-09-14 19:21 GMT+02:00 Ronald S. Bultje : > > [...] > > >> I wondered if somebody can easily fix muxing / demuxing which > >> could be considered a nicer solution. > > > > You mean remuxing (with -c:a copy) of swf files? > > There (also) is an encoder... I have literally no idea what you're trying to tell me. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On 14/09/2016 20:07, James Almer wrote: [...] I'm fine with that if others are (Especially Marton and Josh, since they develop/maintain ffplay). It's a good compromise. But much like ffserver it should similarly be marked as deprecated and essentially unmaintained somewhere. I'm fine with this, I can help backport ffplay stuff to the SDL1 variant as well. I will resubmit the set like this: - SDL2 device added - ffplay renamed - ffplay (sdl2) added I will not submit the deprecation patches again until SDL1 is fully deprecated throughout ffmpeg. Please tell me if you have other suggestions. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: set missing pts for top/bottom field frames
On 9/14/16, Michael Niedermayer wrote:
> On Wed, Sep 14, 2016 at 04:42:59PM +0200, Paul B Mahol wrote:
>> Adopted from 4eb49fdde8f84d54a763cfb5d355527b525ee2bf revert.
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/h264_parser.c | 22 ++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
>> index 615884f..cf6c3d1 100644
>> --- a/libavcodec/h264_parser.c
>> +++ b/libavcodec/h264_parser.c
>> @@ -60,6 +60,7 @@ typedef struct H264ParseContext {
>> uint8_t parse_history[6];
>> int parse_history_count;
>> int parse_last_mb;
>> +int64_t reference_dts;
>> } H264ParseContext;
>>
>>
>> @@ -598,6 +599,26 @@ static int h264_parse(AVCodecParserContext *s,
>> s->flags &= PARSER_FLAG_COMPLETE_FRAMES;
>> }
>>
>> +if (s->dts_sync_point >= 0) {
>> +int64_t den = avctx->time_base.den * avctx->pkt_timebase.num;
>> +if (den > 0) {
>> +int64_t num = avctx->time_base.num *
>> avctx->pkt_timebase.den;
>
> overflows, needs this:
> @@ -600,9 +600,9 @@ static int h264_parse(AVCodecParserContext *s,
> }
>
> if (s->dts_sync_point >= 0) {
> -int64_t den = avctx->time_base.den * avctx->pkt_timebase.num;
> +int64_t den = avctx->time_base.den *
> (int64_t)avctx->pkt_timebase.num;
> if (den > 0) {
> -int64_t num = avctx->time_base.num * avctx->pkt_timebase.den;
> +int64_t num = avctx->time_base.num *
> (int64_t)avctx->pkt_timebase.den;
> if (s->dts != AV_NOPTS_VALUE) {
> // got DTS from the stream, update reference timestamp
> p->reference_dts = s->dts - s->dts_ref_dts_delta * num /
> den;
>
>
> LGTM otherwise
>
> thanks
Sorry, I completely forgot to do this in same patch, got sidetracked
with av_rescale.
Applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On Wed, Sep 14, 2016 at 04:07:50PM -0300, James Almer wrote: > On 9/14/2016 3:51 PM, Michael Niedermayer wrote: > > On Wed, Sep 14, 2016 at 06:00:00PM +0200, Carl Eugen Hoyos wrote: > >> 2016-09-14 17:54 GMT+02:00 Josh de Kock : > >>> We discussed this in IRC and thought that ffmpeg was a > >>> big enough library, and it switching to SDL2 may help > >>> distros to consider supporting SDL2 > >> > >> If this really were the only reason, I sincerely hope we > >> wouldn't even consider this patch. > >> > >> My question remains: What about Debian, Ubunut and > >> Fedora? Do they still have supported versions without > >> sdl2 2.0.1? > > > > ubuntu 12.04 LTS has SDL 1.2, no 2.0 > > Not even in the backports repository? Afaik that's how Debian > 7 ships SDL 2.0.0. no https://launchpad.net/ubuntu/precise/+source/libsdl2 also my 12.04 LTS box doesnt seem to have a sdl2 unless i did something dumb > > > its supported till 2017-04-26 > > That is also more or less the date when Debian 7 will be EOLed, > so it's a good time to fully drop SDL1 support. > > > > > should we keep old ffplay as a ffplay-sdl1 until then ? > > I'm fine with that if others are (Especially Marton and Josh, > since they develop/maintain ffplay). It's a good compromise. Id be happy too as i actually use ffplay on that old 12.04 box didnt realize previously that it doesnt have sdl2 i could upgrade the OS but i intended to actually replace by new hw just intel failing to inovate and produce faster CPUs since years delays it ... > > But much like ffserver it should similarly be marked as > deprecated and essentially unmaintained somewhere. yes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On 9/14/2016 3:51 PM, Michael Niedermayer wrote: > On Wed, Sep 14, 2016 at 06:00:00PM +0200, Carl Eugen Hoyos wrote: >> 2016-09-14 17:54 GMT+02:00 Josh de Kock : >>> We discussed this in IRC and thought that ffmpeg was a >>> big enough library, and it switching to SDL2 may help >>> distros to consider supporting SDL2 >> >> If this really were the only reason, I sincerely hope we >> wouldn't even consider this patch. >> >> My question remains: What about Debian, Ubunut and >> Fedora? Do they still have supported versions without >> sdl2 2.0.1? > > ubuntu 12.04 LTS has SDL 1.2, no 2.0 Not even in the backports repository? Afaik that's how Debian 7 ships SDL 2.0.0. > its supported till 2017-04-26 That is also more or less the date when Debian 7 will be EOLed, so it's a good time to fully drop SDL1 support. > > should we keep old ffplay as a ffplay-sdl1 until then ? I'm fine with that if others are (Especially Marton and Josh, since they develop/maintain ffplay). It's a good compromise. But much like ffserver it should similarly be marked as deprecated and essentially unmaintained somewhere. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 3/3] lavd: deprecate opengl outdev
Le nonidi 29 fructidor, an CCXXIV, Josh de Kock a écrit : > What is your attachment to the SDL1 library? None at all. You did not read me carefully at all. My attachment is to the OpenGL device. > Firstly, the OpenGL device doesn't have the best implementation, and lavd I am rather surprised. IIRC, Reimar was active on the list at the time it was implemented, I think he would have spotted problems like that. Can you elaborate? > really doesn't seem like the right place for this. You'd be better off > writing your own from scratch or using something like libmpv (which has a > proper renderer). That defeats the purpose of libavdevice. > Sorry, I'm not sure how you think the SDL device can be used without SDL. I think the OpenGL device can be used without SDL, please read carefully. OpenGL uses a global state, not a context parameter passed to each function. That means that part of an application can create and init the OpenGL context and other parts of the application can draw on it without any explicit communication between them. That is exactly what is meant for the device in lavd: the application creates and inits the context, then lavd generates OpenGL commands which are executed on the context. SDL is only used in this device as a convenience for simpler applications. 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 v3 3/3] lavd: deprecate opengl outdev
On 14/09/2016 18:53, Nicolas George wrote: Le sextidi 26 fructidor, an CCXXIV, Josh de Kock a écrit : This device depends on SDL which is deprecated. Signed-off-by: Josh de Kock Although your port of the code to SDL2 address my concern about deprecating without a replacement, I would be pained if this code were to be removed. What is your attachment to the SDL1 library? I still hope that lavd can become powerful and usable enough to serve as a base for applications, at least simple ones. (Actually, I have a simple music player running right now that does just that.) If that were to happen, OpenGL would be the figurehead of the video output part. Firstly, the OpenGL device doesn't have the best implementation, and lavd really doesn't seem like the right place for this. You'd be better off writing your own from scratch or using something like libmpv (which has a proper renderer). If I understand correctly, SDL is only used in this device to set up a window and a context in a cross-platform way. I even notice that the code can be used without SDL altogether if the applications handles the context and window itself. Sorry, I'm not sure how you think the SDL device can be used without SDL. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On Wed, Sep 14, 2016 at 06:00:00PM +0200, Carl Eugen Hoyos wrote: > 2016-09-14 17:54 GMT+02:00 Josh de Kock : > > We discussed this in IRC and thought that ffmpeg was a > > big enough library, and it switching to SDL2 may help > > distros to consider supporting SDL2 > > If this really were the only reason, I sincerely hope we > wouldn't even consider this patch. > > My question remains: What about Debian, Ubunut and > Fedora? Do they still have supported versions without > sdl2 2.0.1? ubuntu 12.04 LTS has SDL 1.2, no 2.0 its supported till 2017-04-26 should we keep old ffplay as a ffplay-sdl1 until then ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: VAAPI video processing filter
On 14/09/16 02:30, Jun Zhao wrote: > On 2016/9/14 6:06, Mark Thompson wrote: >> How about something like this, then? It adds a new filter to do the video >> processing, while leaving the scale filter as-is. > > Can we merge the vpp scale/the other vpp filters in one AVFilter, e,g > vf_postprocess_vaapi.c. > If we split the scale/the other vpp filters, I guess maybe have some > performance issue, > when merge the scale/the other vpp filters in one AVFilter, only once surface > copy , > > 1 input surface-> 1 output surface // once copy for > scale/de-noise/sharpness/... > > but if split them, it's will lead to twice surface copy in some case. > > 1 input surface -> 1 output surface -> 2 output surface // 1st copy for > scale, 2nd > // copy for the > other vaapi filters Can you share what driver/platform you are testing on and what commands you are using to get the result that the combined filter is faster? For example, I get (1080p H.264 input, current i965 on Skylake): [With the patch to vf_scale_vaapi] ./ffmpeg_g -y -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 'format=vaapi|nv12,hwupload,scale_vaapi=denoise=50:w=1280:h=720' -c:v h264_vaapi -qp 20 out.mp4 -> 225fps. [With the patch adding vf_process_vaapi] ./ffmpeg_g -y -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 'format=vaapi|nv12,hwupload,process_vaapi=denoise=50,scale_vaapi=w=1280:h=720' -c:v h264_vaapi -qp 20 out.mp4 -> 255fps. I'm not sure why the separate filters are actually faster here, but I was certainly expecting them to be about the same - since we haven't introduced any additional synchronisation points in either sequence, it should all be fully pipelined in the batch buffer rings from the decoder to the encoder output. I believe the argument about surfaces is specious because the combined case needs the same intermediates and therefore internally allocates temporary surfaces for them. Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] mpeg12dec fix up DVD caption handling
> yes, please resbmit the remaining patch/changes with any comments
> from everyone taken care of or with explanation why not
>
> thx
Here you go, squashed into one patch.
Sentences ending with a period have been capitalized and printf typecasts
removed (Moritz).
Jonathan Campbell
From 8d64027573588a62728faebba55d67c00a3d4e3f Mon Sep 17 00:00:00 2001
From: Jonathan Campbell
Date: Wed, 14 Sep 2016 10:57:04 -0700
Subject: [PATCH] Read cc words field-wise, limit to cc_count and support extra
field.
This code validates the cc words the same as the prior code this
replaced in case cc_count is too large. Field counting is used in case
caption source does not use the LSB to signal even/odd field.
---
libavcodec/mpeg12dec.c | 45 -
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index ca51c97..7c65f77 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2265,6 +2265,7 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
/* extract DVD CC data
*
* uint32_t user_data_start_code0x01B2(big endian)
+ * p[0] starts here -
* uint16_t user_identifier 0x4343 "CC"
* uint8_tuser_data_type_code 0x01
* uint8_tcaption_block_size 0xF8
@@ -2273,7 +2274,7 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
* bit 6caption_filler 0
* bit 5:1 caption_block_count number of caption blocks
(pairs of caption words = frames). Most DVDs use 15 per start of GOP.
* bit 0caption_extra_field_added 1=one additional caption word
- *
+ * p[5] starts here -
* struct caption_field_block {
* uint8_t
* bit 7:1 caption_filler 0x7F (all 1s)
@@ -2287,30 +2288,48 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
* Don't assume that the first caption word is the odd field. There do
exist MPEG files in the wild that start
* on the even field. There also exist DVDs in the wild that encode an
odd field count and the
* caption_extra_field_added/caption_odd_field_first bits change per
packet to allow that. */
-int cc_count = 0;
+int caption_block_count = p[4] & 0x3F; /* you can treat bits 5:0 as
number of fields */
+int cc_count = 0; /* number of caption fields */
int i;
-// There is a caption count field in the data, but it is often
-// incorrect. So count the number of captions present.
-for (i = 5; i + 6 <= buf_size && ((p[i] & 0xfe) == 0xfe); i += 6)
+
+for (i = 5; cc_count < caption_block_count && (i + 3) <= buf_size; i
+= 3) {
+if ((p[i] & 0xfe) != 0xfe) {
+av_log(avctx, AV_LOG_DEBUG, "cc_count is too large (%d > %d)
or junk data in DVD caption packet\n",caption_block_count,cc_count);
+break;
+}
+
cc_count++;
+}
+
// Transform the DVD format into A53 Part 4 format
if (cc_count > 0) {
av_freep(&s1->a53_caption);
-s1->a53_caption_size = cc_count * 6;
+s1->a53_caption_size = cc_count * 3;
s1->a53_caption = av_malloc(s1->a53_caption_size);
if (s1->a53_caption) {
-uint8_t field1 = !!(p[4] & 0x80);
+uint8_t field1 = (p[4] >> 7) & 1; /* caption_odd_field_first */
+uint8_t pfield = 0xFF; /* DVDs that don't use the
caption_field_odd bit always seem to leave it on */
uint8_t *cap = s1->a53_caption;
+
p += 5;
for (i = 0; i < cc_count; i++) {
-cap[0] = (p[0] == 0xff && field1) ? 0xfc : 0xfd;
+/* If the source actually uses the caption_odd_field bit,
then use that to determine the field.
+ * Else, toggle between fields to keep track for DVDs
where p[0] == 0xFF at all times. */
+if (p[0] != pfield)
+field1 = p[0] & 1; /* caption_field_odd */
+
+/* in A53 part 4, 0xFC = odd field, 0xFD = even field */
+cap[0] = field1 ? 0xFC : 0xFD;
cap[1] = p[1];
cap[2] = p[2];
-cap[3] = (p[3] == 0xff && !field1) ? 0xfc : 0xfd;
-cap[4] = p[4];
-cap[5] = p[5];
-cap += 6;
-p += 6;
+
+av_log(avctx, AV_LOG_DEBUG, "DVD CC field1=%u(%s)
0x%02x%02x prev=0x%02x cur=0x%02x\n",
+field1,field1?"odd":"even",cap[1],cap[2],pfield,p[0]);
+
+pfield = p[0];
+field1 ^= 1;
+cap += 3;
+
Re: [FFmpeg-devel] mpeg12dec fix up DVD caption handling
>> Would running git format-patch >patchfile work to submit it as one patch or >> do I need to squash it into one patch? >> >> Do I need to resubmit anything? > > yes, please resbmit the remaining patch/changes with any comments > from everyone taken care of or with explanation why not > > thx > > [...] Do you need me to resubmit the patches for the AC-3 consistent noise generation as well? Jonathan Campbell ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
Hi, On Wed, Sep 14, 2016 at 12:18 PM, Carl Eugen Hoyos wrote: > 2016-09-14 18:15 GMT+02:00 James Almer : > > > Configure failed to detect it > > configure requires 2.0.1 > > Carl Eugen (who wonders how Ronald tests...) ffmpeg (the tool), of course! :) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On Wed, 14 Sep 2016, Carl Eugen Hoyos wrote: 2016-09-14 18:15 GMT+02:00 James Almer : Configure failed to detect it configure requires 2.0.1 YUV texture updates require 2.0.1 as far as I remember. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 3/3] lavd: deprecate opengl outdev
Le sextidi 26 fructidor, an CCXXIV, Josh de Kock a écrit : > This device depends on SDL which is deprecated. > > Signed-off-by: Josh de Kock Although your port of the code to SDL2 address my concern about deprecating without a replacement, I would be pained if this code were to be removed. I still hope that lavd can become powerful and usable enough to serve as a base for applications, at least simple ones. (Actually, I have a simple music player running right now that does just that.) If that were to happen, OpenGL would be the figurehead of the video output part. If I understand correctly, SDL is only used in this device to set up a window and a context in a cross-platform way. I even notice that the code can be used without SDL altogether if the applications handles the context and window itself. The warning could be printed only when no_window is false, with the intent that the code not under "#if HAVE_SDL" is there to stay? 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]Fix NVENC HEVC Profiles
Updated patch with requested changes.
Thanks,
Yogender
On Wed, Sep 14, 2016 at 11:00 PM, Carl Eugen Hoyos
wrote:
> 2016-09-14 19:22 GMT+02:00 Yogender Kumar Gupta >:
> > This patch fixes HEVC profiles for 444 and 444-10 that should be rext
> > instead of main10.
>
> > +}
> > +else if (ctx->data_pix_fmt == AV_PIX_FMT_P010) {
>
> Please merge these lines.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
0001-Fix-NVENC-HEVC-Profiles.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
2016-09-14 19:21 GMT+02:00 Ronald S. Bultje : [...] >> I wondered if somebody can easily fix muxing / demuxing which >> could be considered a nicer solution. > > You mean remuxing (with -c:a copy) of swf files? There (also) is an encoder... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: set missing pts for top/bottom field frames
Hi! 2016-09-14 19:35 GMT+02:00 Paul B Mahol : > I see nothing wrong doing this in parser instead of in generic code. I am not saying there is anything wrong. I wanted to share my suspicion that this patch is a work-around for a bug that affects h.264 decoding in general. (And this suspicion may of course be wrong.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/6] lavc/qsv: Enable hwaccel qsv_vidmem.
ffmpeg_qsv.c | 636 +- libavcodec/qsv.h | 3 + libavcodec/qsv_internal.h | 2 + libavcodec/qsvdec.c | 5 +- libavcodec/qsvenc.c | 2 + 8 files changed, 649 insertions(+), 5 deletions(-) This is a giant patch that doesnt even begin to describe what it does. So, whats it good for? We can already do transcoding of video from QSV decoder to QSV encoder all in GPU memory without 600+ lines of new code. Admittedly it currently has a few issues, but those could be fixed, but why do we need 600 new lines of code? 1. In GPU level, all frames are processed in tiled mode (we called video memory mode) which cannot be read/write by cpu directly. The frame buffer should be allocated via vaCreateSurface. Any non-tiled memory must be copied to tiled memory when using GPU acceleration. The copying task is done by MediaSDK internally. 2. In current implementation, frame buffer is allocated by ffmpeg in linear mode (we called system memory) ; QSV deocder’s output and QSV encoder’s input are all set to video memory mode ( e.g. iopattern = MFX_IOPATTERN_OUT_SYSTEM_MEMORY in qsv decoder); so there are 2 memory copy processes in mediaSDK: one is copying from video_memory to system memory when output from HW decoder, another is copying from system memory to video memory when feeding to HW encoder. It will decrease transcoding performance greatly, especially for high resolution such as 1080 & 4K. 3. The patches are avoiding such additional memory copy when all modules in transcoding pipeline can be accelerated by GPU. To achieving it, iopattern must be set to video_memory, and an external allocator must be implemented as mediaSDK requirements, and set it to QSV codec. Most of the 600 lines in the patches are the code to implement the external allocator. At the same time, the patches also add some code to checking whether all modules in transcoding pipeline can be accelerated by GPU or not, so that transcoder can select video-memory or system-memory automatically. 4. As our test, the transcoding performance can be improved about 20% or more according to resolution with patches. And it can reach the performance which is declared in QSV specification. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: set missing pts for top/bottom field frames
On 9/14/16, Carl Eugen Hoyos wrote: > 2016-09-14 18:11 GMT+02:00 Paul B Mahol : >> On Wednesday, September 14, 2016, Carl Eugen Hoyos wrote: >> >>> 2016-09-14 16:42 GMT+02:00 Paul B Mahol : >>> > Adopted from 4eb49fdde8f84d54a763cfb5d355527b525ee2bf revert. >>> >>> I am of course not against this patch but wasn't the reason for the >>> old code in utils.c that our h264 parser has insufficiencies? >> >> Like what? Only h264 have those fields. Doing it outside of >> parser seems strange. > > I thought - and please correct me if this is wrong - that this code was > always (only?) needed because our h264 parser does not do what > the specification requires to correctly determine h264 timestamps. This code appears to be needed for field based h264 streams. The code that was reverted was added in 2009. and than there was no avctx->pkt_timebase. I see nothing wrong doing this in parser instead of in generic code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix NVENC HEVC Profiles
2016-09-14 19:22 GMT+02:00 Yogender Kumar Gupta :
> This patch fixes HEVC profiles for 444 and 444-10 that should be rext
> instead of main10.
> +}
> +else if (ctx->data_pix_fmt == AV_PIX_FMT_P010) {
Please merge these lines.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Fix NVENC HEVC Profiles
This patch fixes HEVC profiles for 444 and 444-10 that should be rext instead of main10. Thanks, Yogender 0001-Fix-NVENC-HEVC-Profiles.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
Hi, On Wed, Sep 14, 2016 at 12:29 PM, Carl Eugen Hoyos wrote: > Hi! > > 2016-09-14 18:05 GMT+02:00 Ronald S. Bultje : > > > > On Wed, Sep 14, 2016 at 12:01 PM, Carl Eugen Hoyos wrote: > > > >> 2016-09-12 12:52 GMT+02:00 Carl Eugen Hoyos : > >> > >> > Attached patch "fixes" ticket #5829, I am happy if a better > >> > solution can be found. > > > What makes you believe this is not the right solution? > > > As in: why was the rogue twocc ever added? > > I don't think we will be able to find out (or actually: I don't want to > share my suspicion). > I would love to hear. > I wondered if somebody can easily fix muxing / demuxing which > could be considered a nicer solution. You mean remuxing (with -c:a copy) of swf files? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Patch for SDK 7.0 for NVENC
2016-09-14 18:56 GMT+02:00 Yogender Kumar Gupta :
> Please let me know if anything else needs to be taken care of.
if (condition) {
do();
} else {
do2();
}
like everywhere else in FFmpeg (and on top of your patch).
+if (ctx->aq && ctx->temporalAQ)
+{
+av_log(avctx, AV_LOG_ERROR, "AQ and Temporal AQ are not
supported together\n");
+}
Printing the error is sufficient, neither return nor unsetting one of them?
Please do not top-post here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for fixing of nvenc.c compilation using msvc tools
I agree the change was not good, but since it was not compiling on my system using VS2013 I submitted this, but I hear that rather it may be an issue with my system as the code compiles well using VS2013 tools. I will retry at my end. On Wed, Sep 14, 2016 at 10:08 PM, Timo Rothenpieler wrote: > On 9/14/2016 3:43 PM, Yogender Kumar Gupta wrote: > > Attached is a patch for SDK 7_0 for NVENC. This adds other features > > available in SDK 7_0 as well as fixes an issue with HEVC profile > > > > I'd very much dislike applying this change. > It makes the list very hard to read. > While it could be re-arranged to look a bit more sane, I don't see the > point of changing this. > Any sane C-Compiler should not complain about this, and never did in all > my tests on various platforms and toolchains. > ___ > 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 mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Patch for Improved Log for NVENC
The existing logs have been improved to give a better idea of how what steps have been performed. Thanks, Yogender 0001-Improve-Log-for-NVENC.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Patch for SDK 7.0 for NVENC
I have made only changes specific to SDK_7_0 in the attached patch. Also generated the patch using format-patch. Please let me know if anything else needs to be taken care of. Thanks, Yogender On Wed, Sep 14, 2016 at 8:48 PM, Carl Eugen Hoyos wrote: > 2016-09-14 15:43 GMT+02:00 Yogender Kumar Gupta >: > > Attached is a patch for SDK 7_0 for NVENC. This adds other features > > available in SDK 7_0 as well as fixes an issue with HEVC profile > > The first two hunks do not match your description, please send a > separate patch for the log changes. > The positioning of braces should match the FFmpeg style. > > > as well as fixes an issue with HEVC profile > > I may misunderstand but this could also be separate patch. > > Patch made with git format-patch are preferred, Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > SDK_7_0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for fixing of nvenc.c compilation using msvc tools
On 9/14/2016 3:43 PM, Yogender Kumar Gupta wrote: > Attached is a patch for SDK 7_0 for NVENC. This adds other features > available in SDK 7_0 as well as fixes an issue with HEVC profile > I'd very much dislike applying this change. It makes the list very hard to read. While it could be re-arranged to look a bit more sane, I don't see the point of changing this. Any sane C-Compiler should not complain about this, and never did in all my tests on various platforms and toolchains. ___ 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] added expr evaluation to drawtext - fontsize
Any feedback on the most recent patch?
On Fri, Sep 9, 2016 at 5:26 PM, Brett Harrison
wrote:
> Here are the changes requested
>
> On Thu, Sep 8, 2016 at 8:50 AM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Tue, Sep 06, 2016 at 10:27:24AM -0700, Brett Harrison wrote:
>> > This patch addresses your concerns.
>> >
>> > On Fri, Sep 2, 2016 at 5:05 PM, Michael Niedermayer
>>
>> > wrote:
>> >
>> > > On Fri, Sep 02, 2016 at 03:31:21PM -0700, Brett Harrison wrote:
>> > > > Addressed the following concerns.
>> > > >
>> > > > ===
>> > > >
>> > > > >libavfilter/vf_drawtext.c: In function ‘update_fontsize’:
>> > > > >libavfilter/vf_drawtext.c:422:5: warning: ISO C90 forbids mixed
>> > > declarations and code [->Wdeclaration-after-statement]
>> > > >
>> > > > Fixed this.
>> > > >
>> > > > >also patch breaks:
>> > > > >./ffmpeg -i m.mpg -vf >drawtext=fontfile=/usr/share/
>> > > fonts/truetype/msttcorefonts/arial.ttf:text=a -f null -
>> > > >
>> > > > >[AVFilterGraph @ 0x37a6960] Error initializing filter 'drawtext'
>> with
>> > > args >'fontfile=/usr/share/fonts/truetype/msttcorefonts/arial.ttf
>> :text=a'
>> > > >
>> > > > This is fixed.
>> > > >
>> > > > ===
>> > > >
>> > > > >>* +av_log(ctx, AV_LOG_ERROR, "Font not open\n");
>> > > > *
>> > > > >I was wondering: Was does this message tell the user?
>> > > >
>> > > > I changed this error to read "Unable to initialize font". This
>> error
>> > > > should only be seen if set_fontsize() is called before the font is
>> > > > loaded. I don't think a user would be able to cause this because if
>> > > > the font fails to load ffmpeg would error out before this. It is a
>> > > > sanity check.
>> > > >
>> > > > ===
>> > > >
>> > > > For the concerns about multiple to many brackets on "if ((ret =
>> > > > update_fontsize(ctx)))",
>> > > >
>> > > > I removed the "ret =" part as I wasn't using the value anyway.
>> > > >
>> > > >
>> > > > On Fri, Sep 2, 2016 at 6:13 AM, Nicolas George
>> wrote:
>> > > >
>> > > > > Le septidi 17 fructidor, an CCXXIV, Moritz Barsnick a écrit :
>> > > > > > *Assuming* he means "assign update_fontsize()'s return value to
>> ret,
>> > > > > > and check whether ret is != 0", which would correspond to the
>> more
>> > > > > > verbose
>> > > > > > if ((ret = update_fontsize(ctx)) != 0) {
>> > > > > >
>> > > > > > is it sufficient to say:
>> > > > > > if (ret = update_fontsize(ctx)) {
>> > > > > >
>> > > > > > or is it required, or is it more readable or even desired by
>> "style
>> > > > > > guide" to say:
>> > > > > > if ((ret = update_fontsize(ctx))) {
>> > > > > > (to clarify it's a check of an assignment) - this is what Brett
>> used,
>> > > > >
>> > > > > Ah. Parentheses over the whole expression are always optional,
>> but in
>> > > this
>> > > > > particular case, there is a good reason:
>> > > > >
>> > > > > :4:1: warning: suggest parentheses around assignment used
>> as
>> > > truth
>> > > > > value [-Wparentheses]
>> > > > >
>> > > > > Forgetting to double the equal in a comparison is a common
>> mistake,
>> > > > > compilers detect it. But then you need a way of stating when it is
>> > > > > intentional.
>> > > > >
>> > > > > Regards,
>> > > > >
>> > > > > --
>> > > > > Nicolas George
>> > > > >
>> > > > > ___
>> > > > > ffmpeg-devel mailing list
>> > > > > ffmpeg-devel@ffmpeg.org
>> > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> > > > >
>> > > > >
>> > >
>> > > > vf_drawtext.c | 125 ++
>> > > +---
>> > > > 1 file changed, 112 insertions(+), 13 deletions(-)
>> > > > 311d60f04d959ddfd47ed8ea66d0f015725dd511
>> 0001-added-expr-evaluation-to-
>> > > drawtext-fontsize.patch
>> > > > From 665b3f1c458222d64a9ba4f1c71d343766ee9e6b Mon Sep 17 00:00:00
>> 2001
>> > > > From: Brett Harrison
>> > > > Date: Fri, 26 Aug 2016 14:29:34 -0700
>> > > > Subject: [PATCH] added expr evaluation to drawtext - fontsize
>> > > >
>> > > > ---
>> > > > libavfilter/vf_drawtext.c | 125 ++
>> > > +++-
>> > > > 1 file changed, 112 insertions(+), 13 deletions(-)
>> > > >
>> > > > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
>> > > > index 214aef0..a483679 100644
>> > > > --- a/libavfilter/vf_drawtext.c
>> > > > +++ b/libavfilter/vf_drawtext.c
>> > > > @@ -156,7 +156,10 @@ typedef struct DrawTextContext {
>> > > > int max_glyph_h;///< max glyph height
>> > > > int shadowx, shadowy;
>> > > > int borderw;///< border width
>> > > > +char *fontsize_expr;///< expression for fontsize
>> > > > +AVExpr *fontsize_pexpr; ///< parsed expressions for
>> fontsize
>> > > > unsigned int fontsize; ///< font size to use
>> > > > +unsigned int default_fontsize; ///< default font size to use
>> > > >
>> > > > short int draw_box; ///< draw box around text -
>> true o
Re: [FFmpeg-devel] [PATCH] Patch for SDK 7.0 for NVENC
On 9/14/2016 6:30 PM, Carl Eugen Hoyos wrote: > 2016-09-14 18:26 GMT+02:00 Timo Rothenpieler : >> On 9/14/2016 3:43 PM, Yogender Kumar Gupta wrote: >>> Attached is a patch for SDK 7_0 for NVENC. This adds other features >>> available in SDK 7_0 as well as fixes an issue with HEVC profile >>> >> >> I'd very much dislike applying this change. > > I suspect you answered the wrong thread;-) Indeed, will re-send. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On 9/14/2016 1:12 PM, Clément Bœsch wrote: > On Wed, Sep 14, 2016 at 05:34:05PM +0200, Carl Eugen Hoyos wrote: >> 2016-09-12 20:58 GMT+02:00 Josh de Kock : >>> From: Marton Balint >>> >>> Depends on the other SDL patches. >> >> This works fine on my antique desktop system (where an >> extra repository provides sdl2 2.0.3) but not on my laptop >> that I did not consider eol so far, it only has 2.0.0. >> > > According to semantic versioning (not sure if SDL follows it) 2.0.3 a bug > fix release for 2.0.x. So 2.0.0 is probably officially broken and the > maintainer might be doing a very poor job at maintaining his packages. Debian Stable has 2.0.2, Debian Testing has 2.0.4. It's Debian Old-Stable that apparently has 2.0.0, and may or may not get it updated before it's EOLed early next year. But then again, you shouldn't be using Old-Stable for a desktop environment. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Patch for SDK 7.0 for NVENC
2016-09-14 18:26 GMT+02:00 Timo Rothenpieler : > On 9/14/2016 3:43 PM, Yogender Kumar Gupta wrote: >> Attached is a patch for SDK 7_0 for NVENC. This adds other features >> available in SDK 7_0 as well as fixes an issue with HEVC profile >> > > I'd very much dislike applying this change. I suspect you answered the wrong thread;-) Carl Eugen (who agrees and wonders if there is a documentation issue) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
Hi! 2016-09-14 18:05 GMT+02:00 Ronald S. Bultje : > > On Wed, Sep 14, 2016 at 12:01 PM, Carl Eugen Hoyos wrote: > >> 2016-09-12 12:52 GMT+02:00 Carl Eugen Hoyos : >> >> > Attached patch "fixes" ticket #5829, I am happy if a better >> > solution can be found. > What makes you believe this is not the right solution? > As in: why was the rogue twocc ever added? I don't think we will be able to find out (or actually: I don't want to share my suspicion). I wondered if somebody can easily fix muxing / demuxing which could be considered a nicer solution. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Patch for SDK 7.0 for NVENC
On 9/14/2016 3:43 PM, Yogender Kumar Gupta wrote: > Attached is a patch for SDK 7_0 for NVENC. This adds other features > available in SDK 7_0 as well as fixes an issue with HEVC profile > I'd very much dislike applying this change. It makes the list very hard to read. While it could be re-arranged to look a bit more sane, I don't see the point of changing this. Any sane C-Compiler should not complain about this, and never did in all my tests on various platforms and toolchains. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Patch for SDK 7.0 for NVENC
2016-09-14 18:23 GMT+02:00 Timo Rothenpieler : > I'm not sure what target_quality is supposed to do Could it be that it moves the time-to-encode / quality-of-encoding slider? (just guessing, libvpx does this iirc) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6 1/3] lavd: Add SDL2 output device
2016-09-14 18:20 GMT+02:00 Josh de Kock :
> On 14/09/2016 17:17, Carl Eugen Hoyos wrote:
>>
>> 2016-09-11 23:14 GMT+02:00 Josh de Kock :
>>
>>> +{ AV_PIX_FMT_RGB24, SDL_PIXELFORMAT_RGB888 },
>>
>>> +{ AV_PIX_FMT_BGR24, SDL_PIXELFORMAT_BGR888 },
>>
>> Did you test them / why did you remove the comments that said
>> they do not work?
>>
> I assumed since no one complained they were correct.
Mhm.
> (The comments were just
> asking if they were correct mappings or not).
Please add the comments back and comment the lines away, I
get broken b/w output here and I have no idea what is wrong.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
Am 14.09.2016 18:00 schrieb "Carl Eugen Hoyos" : > > 2016-09-14 17:54 GMT+02:00 Josh de Kock : > > We discussed this in IRC and thought that ffmpeg was a > > big enough library, and it switching to SDL2 may help > > distros to consider supporting SDL2 > > If this really were the only reason, I sincerely hope we > wouldn't even consider this patch. > > My question remains: What about Debian, Ubunut and > Fedora? Do they still have supported versions without > sdl2 2.0.1? > Ubuntu and debian have 2.0.2 or newer in their oldest supported versions (ie. Debian stable and Ubuntu 14.04 LTS) Not sure where to check for fedora right now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Patch for SDK 7.0 for NVENC
On 9/14/2016 3:43 PM, Yogender Kumar Gupta wrote: > Attached is a patch for SDK 7_0 for NVENC. This adds other features > available in SDK 7_0 as well as fixes an issue with HEVC profile > What carl said. Also, a some of the added options are not used anywhere: zeroReorderDelay, enableNonRefP I'm not sure what target_quality is supposed to do, but constant quality vbr encodes already exist, exposed via global_quality. If it's some new rate-control mode, it has to be added as such. If the current way of doing constqp encoding is wrong, it has to be fixed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: set missing pts for top/bottom field frames
2016-09-14 18:11 GMT+02:00 Paul B Mahol : > On Wednesday, September 14, 2016, Carl Eugen Hoyos wrote: > >> 2016-09-14 16:42 GMT+02:00 Paul B Mahol : >> > Adopted from 4eb49fdde8f84d54a763cfb5d355527b525ee2bf revert. >> >> I am of course not against this patch but wasn't the reason for the >> old code in utils.c that our h264 parser has insufficiencies? > > Like what? Only h264 have those fields. Doing it outside of > parser seems strange. I thought - and please correct me if this is wrong - that this code was always (only?) needed because our h264 parser does not do what the specification requires to correctly determine h264 timestamps. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6 1/3] lavd: Add SDL2 output device
On 14/09/2016 17:17, Carl Eugen Hoyos wrote:
2016-09-11 23:14 GMT+02:00 Josh de Kock :
+{ AV_PIX_FMT_RGB24, SDL_PIXELFORMAT_RGB888 },
+{ AV_PIX_FMT_BGR24, SDL_PIXELFORMAT_BGR888 },
Did you test them / why did you remove the comments that said
they do not work?
I assumed since no one complained they were correct. (The comments were
just asking if they were correct mappings or not).
+{ AV_PIX_FMT_RGB0, SDL_PIXELFORMAT_RGBX },
+{ AV_PIX_FMT_BGR0, SDL_PIXELFORMAT_BGRX },
+{ AV_PIX_FMT_ARGB, SDL_PIXELFORMAT_ARGB },
+{ AV_PIX_FMT_RGBA, SDL_PIXELFORMAT_RGBA },
+{ AV_PIX_FMT_ABGR, SDL_PIXELFORMAT_ABGR },
+{ AV_PIX_FMT_BGRA, SDL_PIXELFORMAT_BGRA },
These are wrong afaict, I am happy to fix them after this gets
committed if you are less interested.
That would be much appreciated, I wasn't too sure about the mappings, so
if you could look over all of them that'd be great.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
2016-09-14 18:15 GMT+02:00 James Almer : > Configure failed to detect it configure requires 2.0.1 Carl Eugen (who wonders how Ronald tests...) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6 1/3] lavd: Add SDL2 output device
2016-09-11 23:14 GMT+02:00 Josh de Kock :
> +{ AV_PIX_FMT_RGB24, SDL_PIXELFORMAT_RGB888 },
> +{ AV_PIX_FMT_BGR24, SDL_PIXELFORMAT_BGR888 },
Did you test them / why did you remove the comments that said
they do not work?
> +{ AV_PIX_FMT_RGB0, SDL_PIXELFORMAT_RGBX },
> +{ AV_PIX_FMT_BGR0, SDL_PIXELFORMAT_BGRX },
> +{ AV_PIX_FMT_ARGB, SDL_PIXELFORMAT_ARGB },
> +{ AV_PIX_FMT_RGBA, SDL_PIXELFORMAT_RGBA },
> +{ AV_PIX_FMT_ABGR, SDL_PIXELFORMAT_ABGR },
> +{ AV_PIX_FMT_BGRA, SDL_PIXELFORMAT_BGRA },
These are wrong afaict, I am happy to fix them after this gets
committed if you are less interested.
I believe this is a very useful patch, thank you!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On 9/14/2016 1:00 PM, Carl Eugen Hoyos wrote: > 2016-09-14 17:54 GMT+02:00 Josh de Kock : >> We discussed this in IRC and thought that ffmpeg was a >> big enough library, and it switching to SDL2 may help >> distros to consider supporting SDL2 > > If this really were the only reason, I sincerely hope we > wouldn't even consider this patch. > > My question remains: What about Debian, Ubunut and > Fedora? Do they still have supported versions without > sdl2 2.0.1? Ubuntu has 2.0.2 as the oldest. Debian 7 (old-stable) seems to be at 2.0.0, but support for that release will be dropped in about six months, and it may nonetheless get updated with a point release before that. No idea about Fedora. What kind of error did you get with 2.0.0 that a point release seemingly fixes it? Configure failed to detect it, or ffplay just misbehaves? You could try to work with Josh on this and see if it can be solved. > > 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
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On Wed, Sep 14, 2016 at 05:34:05PM +0200, Carl Eugen Hoyos wrote: > 2016-09-12 20:58 GMT+02:00 Josh de Kock : > > From: Marton Balint > > > > Depends on the other SDL patches. > > This works fine on my antique desktop system (where an > extra repository provides sdl2 2.0.3) but not on my laptop > that I did not consider eol so far, it only has 2.0.0. > According to semantic versioning (not sure if SDL follows it) 2.0.3 a bug fix release for 2.0.x. So 2.0.0 is probably officially broken and the maintainer might be doing a very poor job at maintaining his packages. -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: set missing pts for top/bottom field frames
On Wednesday, September 14, 2016, Carl Eugen Hoyos wrote: > 2016-09-14 16:42 GMT+02:00 Paul B Mahol >: > > Adopted from 4eb49fdde8f84d54a763cfb5d355527b525ee2bf revert. > > I am of course not against this patch but wasn't the reason for the > old code in utils.c that our h264 parser has insufficiencies? > Like what? Only h264 have those fields. Doing it outside of parser seems strange. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
Hi, On Wed, Sep 14, 2016 at 12:04 PM, Carl Eugen Hoyos wrote: > 2016-09-14 17:59 GMT+02:00 Michael Niedermayer : > > On Wed, Sep 14, 2016 at 05:34:05PM +0200, Carl Eugen Hoyos wrote: > >> 2016-09-12 20:58 GMT+02:00 Josh de Kock : > >> > From: Marton Balint > >> > > >> > Depends on the other SDL patches. > >> > >> This works fine on my antique desktop system (where an > >> extra repository provides sdl2 2.0.3) but not on my laptop > >> that I did not consider eol so far, it only has 2.0.0. > > > > did it get autodetected and failed ? (it should not i think) > > was it forced enabled and then failed ? (maybe it should > > print an error if the sdl2 version is not recent enough) > > What I meant is: > On a system that I did not consider old before testing > this patch ffplay suddenly stops working making > FFmpeg development much harder. Is ffplay really that critical in testing ffmpeg? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On 9/14/2016 12:34 PM, Carl Eugen Hoyos wrote: > 2016-09-12 20:58 GMT+02:00 Josh de Kock : >> From: Marton Balint >> >> Depends on the other SDL patches. > > This works fine on my antique desktop system (where an > extra repository provides sdl2 2.0.3) but not on my laptop > that I did not consider eol so far, it only has 2.0.0. > > If a supported Linux distribution does not ship a sufficiently > recent sdl2, I am not sure if this is such a good idea. > Does the patch offer new functionality? https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186299.html Has a good summary of the advantages of SDL2. > > 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
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
Hi, On Wed, Sep 14, 2016 at 12:01 PM, Carl Eugen Hoyos wrote: > 2016-09-12 12:52 GMT+02:00 Carl Eugen Hoyos : > > > Attached patch "fixes" ticket #5829, I am happy if a better > > solution can be found. > > Ping. What makes you believe this is not the right solution? As in: why was the rogue twocc ever added? IMO patch is OK, and other rogue twoccs should be removed also, if they allow creating invalid and unplayable files (like vorbis in wav). Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
2016-09-14 17:59 GMT+02:00 Michael Niedermayer : > On Wed, Sep 14, 2016 at 05:34:05PM +0200, Carl Eugen Hoyos wrote: >> 2016-09-12 20:58 GMT+02:00 Josh de Kock : >> > From: Marton Balint >> > >> > Depends on the other SDL patches. >> >> This works fine on my antique desktop system (where an >> extra repository provides sdl2 2.0.3) but not on my laptop >> that I did not consider eol so far, it only has 2.0.0. > > did it get autodetected and failed ? (it should not i think) > was it forced enabled and then failed ? (maybe it should > print an error if the sdl2 version is not recent enough) What I meant is: On a system that I did not consider old before testing this patch ffplay suddenly stops working making FFmpeg development much harder. So my question is: Did I just miss how old this system of mine is or will we maybe stop supporting easy FFmpeg development on supported major Linux distributions if the patch gets applied? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/riff: Do not use a rogue twocc for adpcm_swf
2016-09-12 12:52 GMT+02:00 Carl Eugen Hoyos : > Attached patch "fixes" ticket #5829, I am happy if a better > solution can be found. Ping. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On Wed, Sep 14, 2016 at 05:34:05PM +0200, Carl Eugen Hoyos wrote: > 2016-09-12 20:58 GMT+02:00 Josh de Kock : > > From: Marton Balint > > > > Depends on the other SDL patches. > > This works fine on my antique desktop system (where an > extra repository provides sdl2 2.0.3) but not on my laptop > that I did not consider eol so far, it only has 2.0.0. did it get autodetected and failed ? (it should not i think) was it forced enabled and then failed ? (maybe it should print an error if the sdl2 version is not recent enough) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- 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] ffplay: convert ffplay to use SDL2
2016-09-14 17:54 GMT+02:00 Josh de Kock : > We discussed this in IRC and thought that ffmpeg was a > big enough library, and it switching to SDL2 may help > distros to consider supporting SDL2 If this really were the only reason, I sincerely hope we wouldn't even consider this patch. My question remains: What about Debian, Ubunut and Fedora? Do they still have supported versions without sdl2 2.0.1? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On 14/09/2016 16:34, Carl Eugen Hoyos wrote: [...] If a supported Linux distribution does not ship a sufficiently recent sdl2, I am not sure if this is such a good idea. Does the patch offer new functionality? It doesn't add any extra functionality, but SDL1 has been unmaintained for more than 4 years. We discussed this in IRC and thought that ffmpeg was a big enough library, and it switching to SDL2 may help distros to consider supporting SDL2, also taking into account the length of time SDL1 has been unmaintained. Another option is just to compile SDL2 from source. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc: Enable a53cc by default
2016-09-10 19:04 GMT+02:00 Michael Niedermayer : > On Fri, Sep 09, 2016 at 05:59:19PM +0200, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch enables saving closed caption by default if available. >> >> Please comment, Carl Eugen > >> libx264.c |2 +- >> qsvenc_h264.c |2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> 7df31837c63e8c6aa42ababbd988d518f49b6497 >> 0001-lavc-Enable-a53cc-by-default-for-x264-and-qsv_h264.patch >> From f8db342abefbe33b78a7291592eb542bc18b3d07 Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Fri, 9 Sep 2016 17:56:46 +0200 >> Subject: [PATCH] lavc: Enable a53cc by default for x264 and qsv_h264. > > LGTM but i do not really know a53 CC, so if someone else who knows > them replies, consider his reply to have overriden mine! Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c
Hi! 2016-09-08 19:34 GMT+02:00 Nicolas George : > Still, it is probably possible to do something faster than xcbgrab while > still correct: only allocate a new segment if the first one is still in use. Will you try this? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/webm_chunk: Option to specify HTTP header
2016-09-13 22:12 GMT+02:00 Vignesh Venkatasubramanian : > Add an option to specify HTTP header in the WebM Chunk Muxer > (this works the same way as the 'method' parameter in the HLS muxer). If it is the same option, why does it have another name? (If the new name is better, maybe update the hls muxer.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] calculation of probe score
2016-09-13 21:14 GMT+02:00 Dave Rice : > 1 aac,1 This is either random data with aac extension or random data that gets misdetected: I locally use a patch that avoids returning 1 from the aac probe function. > 1 flac,1 This is random data with flac extension but please test specifically. > 1 flac,13 Does this work? (I spent some time to implement it.) > 1 mpegvideo,12 You could test this one. > 5 swf,26 This is compressed and should probably not get a higher score. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: set missing pts for top/bottom field frames
On Wed, Sep 14, 2016 at 04:42:59PM +0200, Paul B Mahol wrote:
> Adopted from 4eb49fdde8f84d54a763cfb5d355527b525ee2bf revert.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/h264_parser.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
> index 615884f..cf6c3d1 100644
> --- a/libavcodec/h264_parser.c
> +++ b/libavcodec/h264_parser.c
> @@ -60,6 +60,7 @@ typedef struct H264ParseContext {
> uint8_t parse_history[6];
> int parse_history_count;
> int parse_last_mb;
> +int64_t reference_dts;
> } H264ParseContext;
>
>
> @@ -598,6 +599,26 @@ static int h264_parse(AVCodecParserContext *s,
> s->flags &= PARSER_FLAG_COMPLETE_FRAMES;
> }
>
> +if (s->dts_sync_point >= 0) {
> +int64_t den = avctx->time_base.den * avctx->pkt_timebase.num;
> +if (den > 0) {
> +int64_t num = avctx->time_base.num * avctx->pkt_timebase.den;
overflows, needs this:
@@ -600,9 +600,9 @@ static int h264_parse(AVCodecParserContext *s,
}
if (s->dts_sync_point >= 0) {
-int64_t den = avctx->time_base.den * avctx->pkt_timebase.num;
+int64_t den = avctx->time_base.den * (int64_t)avctx->pkt_timebase.num;
if (den > 0) {
-int64_t num = avctx->time_base.num * avctx->pkt_timebase.den;
+int64_t num = avctx->time_base.num *
(int64_t)avctx->pkt_timebase.den;
if (s->dts != AV_NOPTS_VALUE) {
// got DTS from the stream, update reference timestamp
p->reference_dts = s->dts - s->dts_ref_dts_delta * num / den;
LGTM otherwise
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] ffplay: convert ffplay to use SDL2
2016-09-12 20:58 GMT+02:00 Josh de Kock : > From: Marton Balint > > Depends on the other SDL patches. This works fine on my antique desktop system (where an extra repository provides sdl2 2.0.3) but not on my laptop that I did not consider eol so far, it only has 2.0.0. If a supported Linux distribution does not ship a sufficiently recent sdl2, I am not sure if this is such a good idea. Does the patch offer new functionality? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Patch for SDK 7.0 for NVENC
2016-09-14 15:43 GMT+02:00 Yogender Kumar Gupta : > Attached is a patch for SDK 7_0 for NVENC. This adds other features > available in SDK 7_0 as well as fixes an issue with HEVC profile The first two hunks do not match your description, please send a separate patch for the log changes. The positioning of braces should match the FFmpeg style. > as well as fixes an issue with HEVC profile I may misunderstand but this could also be separate patch. Patch made with git format-patch are preferred, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_parser: set missing pts for top/bottom field frames
2016-09-14 16:42 GMT+02:00 Paul B Mahol : > Adopted from 4eb49fdde8f84d54a763cfb5d355527b525ee2bf revert. I am of course not against this patch but wasn't the reason for the old code in utils.c that our h264 parser has insufficiencies? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for fixing of nvenc.c compilation using msvc tools
On Wed, Sep 14, 2016 at 12:45 PM, Matt Oliver wrote: > On 14 September 2016 at 20:22, Yogender Kumar Gupta < > yogender.gu...@gmail.com> wrote: > >> Currently libavcodec.c/nvenc.c is not compilable using MSVC tools. I am >> attaching a patch that fixes this issue. >> >> Thanks, >> Yogender >> > > What version of msvc are you using? 2015 and 2013 all work fine currently > so I assume this is with an older version. Since nvenc is currently enabled > by default then this should have been picked up by FATE (which currently > has not had this issue) and older versions of msvc rely on the c99 > converter which i would have thought should have properly handled that kind > of code. I can confirm that all my FATE stations do build the nvenc code, and as such it has been tested on MSVC 2012, 2013 and 2015, both x86 and x64. Something must be up with your setup if it doesn't build this. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/h264_parser: set missing pts for top/bottom field frames
Adopted from 4eb49fdde8f84d54a763cfb5d355527b525ee2bf revert.
Signed-off-by: Paul B Mahol
---
libavcodec/h264_parser.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 615884f..cf6c3d1 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -60,6 +60,7 @@ typedef struct H264ParseContext {
uint8_t parse_history[6];
int parse_history_count;
int parse_last_mb;
+int64_t reference_dts;
} H264ParseContext;
@@ -598,6 +599,26 @@ static int h264_parse(AVCodecParserContext *s,
s->flags &= PARSER_FLAG_COMPLETE_FRAMES;
}
+if (s->dts_sync_point >= 0) {
+int64_t den = avctx->time_base.den * avctx->pkt_timebase.num;
+if (den > 0) {
+int64_t num = avctx->time_base.num * avctx->pkt_timebase.den;
+if (s->dts != AV_NOPTS_VALUE) {
+// got DTS from the stream, update reference timestamp
+p->reference_dts = s->dts - s->dts_ref_dts_delta * num / den;
+} else if (p->reference_dts != AV_NOPTS_VALUE) {
+// compute DTS based on reference timestamp
+s->dts = p->reference_dts + s->dts_ref_dts_delta * num / den;
+}
+
+if (p->reference_dts != AV_NOPTS_VALUE && s->pts == AV_NOPTS_VALUE)
+s->pts = s->dts + s->pts_dts_delta * num / den;
+
+if (s->dts_sync_point > 0)
+p->reference_dts = s->dts; // new reference
+}
+}
+
*poutbuf = buf;
*poutbuf_size = buf_size;
return next;
@@ -655,6 +676,7 @@ static av_cold int init(AVCodecParserContext *s)
{
H264ParseContext *p = s->priv_data;
+p->reference_dts = AV_NOPTS_VALUE;
ff_h264dsp_init(&p->h264dsp, 8, 1);
return 0;
}
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: fix timebase error in avformat_seek_file()
On Wed, Sep 14, 2016 at 04:13:45PM +0800, Xinzheng Zhang wrote: > When there is only one stream and stream_index has not specified, > The ts has been transferd by the timebase of stream0 without modifying the > stream_index > In this condation it cause seek failure. > > --- > libavformat/utils.c | 1 + > 1 file changed, 1 insertion(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Patch for SDK 7.0 for NVENC
Attached is a patch for SDK 7_0 for NVENC. This adds other features available in SDK 7_0 as well as fixes an issue with HEVC profile sdk_7_0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/flvenc: add no_sequence_end flags for flvflags
On Wed, Sep 14, 2016 at 10:04:27AM +0800, Steven Liu wrote:
> 2016-09-14 10:00 GMT+08:00 Michael Niedermayer :
>
> > On Wed, Sep 14, 2016 at 09:42:48AM +0800, Steven Liu wrote:
> > > 2016-09-14 8:31 GMT+08:00 Michael Niedermayer :
> > >
> > > > On Tue, Sep 13, 2016 at 10:10:40PM +0800, Steven Liu wrote:
> > > > [...]
> > > > > flvenc.c | 18 +++---
> > > > > 1 file changed, 11 insertions(+), 7 deletions(-)
> > > > > 42fedcf3213941fce3f2c0a6ea879002e178fa75
> > 0002-avformat-flvenc-add-no_
> > > > sequence_end-flags-for-flvfla.patch
> > > > > From c0297aa790e72b14bd01fcb5862e66636bc43400 Mon Sep 17 00:00:00
> > 2001
> > > > > From: Steven Liu
> > > > > Date: Tue, 13 Sep 2016 22:03:59 +0800
> > > > > Subject: [PATCH 2/2] avformat/flvenc: add no_sequence_end flags for
> > > > flvflags
> > > > >
> > > > > when split flv file by flv format at first, and cat flvs file
> > > > > into one flv file, the flv sequence end is be used,
> > > > > then the whole flv have many flv sequence end TAG.
> > > > > this flags can give user an option to ignore write sequence end TAG
> > > > >
> > > > > Signed-off-by: Steven Liu
> > > > > ---
> > > > > libavformat/flvenc.c | 18 +++---
> > > > > 1 file changed, 11 insertions(+), 7 deletions(-)
> > > >
> > > > missing update to docs/
> > > >
> > > >
> > > > >
> > > > > diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> > > > > index a3623f8..9e95b8d 100644
> > > > > --- a/libavformat/flvenc.c
> > > > > +++ b/libavformat/flvenc.c
> > > > > @@ -63,6 +63,7 @@ static const AVCodecTag flv_audio_codec_ids[] = {
> > > > >
> > > > > typedef enum {
> > > > > FLV_AAC_SEQ_HEADER_DETECT = (1 << 0),
> > > > > +FLV_NO_SEQUENCE_END = (1 << 1),
> > > > > } FLVFlags;
> > > > >
> > > > > typedef struct FLVContext {
> > > > > @@ -527,13 +528,15 @@ static int flv_write_trailer(AVFormatContext
> > *s)
> > > > > FLVContext *flv = s->priv_data;
> > > > > int i;
> > > > >
> > > > > -/* Add EOS tag */
> > > > > -for (i = 0; i < s->nb_streams; i++) {
> > > > > -AVCodecParameters *par = s->streams[i]->codecpar;
> > > > > -FLVStreamContext *sc = s->streams[i]->priv_data;
> > > > > -if (par->codec_type == AVMEDIA_TYPE_VIDEO &&
> > > > > -(par->codec_id == AV_CODEC_ID_H264 || par->codec_id
> > ==
> > > > AV_CODEC_ID_MPEG4))
> > > > > -put_avc_eos_tag(pb, sc->last_ts);
> > > > > +if (flv->flags & FLV_NO_SEQUENCE_END == 0) {
> > > >
> > > > please add a (), that makes greping for order or precedenc bugs much
> > > > easier
> > > >
> > > > [...]
> > > >
> > >
> > > Hi Michael,
> > >
> > > I found the flvenc has no document in doc/muxers,
> > > can i update this patch first, and update the second for refine the
> > > flvenc doc?
> >
> > IIRC, ok
> >
> > patch update:
> check if the flvenc in no sequence mode, and give the debug message for it.
> flvenc.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
> 79653ec33e282a88ef8a951b6e08f63eac77704b
> 0001-avformat-flvenc-add-no_sequence_end-flags-for-flvfla.patch
> From 00e11d82f9e817d770f2761067bfa2229da96735 Mon Sep 17 00:00:00 2001
> From: Steven Liu
> Date: Wed, 14 Sep 2016 10:00:52 +0800
> Subject: [PATCH] avformat/flvenc: add no_sequence_end flags for flvflags
>
> when split flv file by flv format at first, and cat flvs file
> into one flv file, the flv sequence end is be used,
> then the whole flv have many flv sequence end TAG.
> this flags can give user an option to ignore write sequence end TAG
>
> Signed-off-by: Steven Liu
> ---
> libavformat/flvenc.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- 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] ffplay: convert ffplay to use SDL2
On Wed, Sep 14, 2016, at 10:12 AM, Michael Niedermayer wrote: > On Tue, Sep 13, 2016 at 01:45:12PM -0300, James Almer wrote: > > > > Tested on Windows (compiled with mingw-w64) and works fine. > > patchwork uses "^Tested-by:" to detect patches having been tested > should the regexp be changed/extended ? I think it may be useful to extend it to define OSes and environments as well. Maybe something like: Tested-by: James Almer (Windows, mingw-w64) Obviously this would require people to use this format but I don't see how else you'd do it. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for fixing of nvenc.c compilation using msvc tools
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.30501 for x64 Copyright (C) Microsoft Corporation. All rights reserved. is what is reported when I run cl in my mingW environment. and the shell is launched from the VS2013 x64 Native Tools Command Prompt On Wed, Sep 14, 2016 at 4:15 PM, Matt Oliver wrote: > On 14 September 2016 at 20:22, Yogender Kumar Gupta < > yogender.gu...@gmail.com> wrote: > > > Currently libavcodec.c/nvenc.c is not compilable using MSVC tools. I am > > attaching a patch that fixes this issue. > > > > Thanks, > > Yogender > > > > What version of msvc are you using? 2015 and 2013 all work fine currently > so I assume this is with an older version. Since nvenc is currently enabled > by default then this should have been picked up by FATE (which currently > has not had this issue) and older versions of msvc rely on the c99 > converter which i would have thought should have properly handled that kind > of code. > ___ > 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 for fixing of nvenc.c compilation using msvc tools
On 14 September 2016 at 20:22, Yogender Kumar Gupta < yogender.gu...@gmail.com> wrote: > Currently libavcodec.c/nvenc.c is not compilable using MSVC tools. I am > attaching a patch that fixes this issue. > > Thanks, > Yogender > What version of msvc are you using? 2015 and 2013 all work fine currently so I assume this is with an older version. Since nvenc is currently enabled by default then this should have been picked up by FATE (which currently has not had this issue) and older versions of msvc rely on the c99 converter which i would have thought should have properly handled that kind of code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Patch for fixing of nvenc.c compilation using msvc tools
Currently libavcodec.c/nvenc.c is not compilable using MSVC tools. I am attaching a patch that fixes this issue. Thanks, Yogender msvc_compile_fix.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/drawutils: allow drawing opaque text on transparent background
Signed-off-by: Paul B Mahol
---
libavfilter/drawutils.c | 7 ---
libavfilter/drawutils.h | 8 +++-
libavfilter/vf_drawtext.c | 2 +-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index f6760be..f19fc5d 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -211,10 +211,11 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat
format, unsigned flags)
draw->desc = desc;
draw->format= format;
draw->nb_planes = nb_planes;
+draw->flags = flags;
memcpy(draw->pixelstep, pixelstep, sizeof(draw->pixelstep));
draw->hsub[1] = draw->hsub[2] = draw->hsub_max = desc->log2_chroma_w;
draw->vsub[1] = draw->vsub[2] = draw->vsub_max = desc->log2_chroma_h;
-for (i = 0; i < (desc->nb_components - !!(desc->flags &
AV_PIX_FMT_FLAG_ALPHA)); i++)
+for (i = 0; i < (desc->nb_components - !!(desc->flags &
AV_PIX_FMT_FLAG_ALPHA && !(flags & FF_DRAW_PROCESS_ALPHA))); i++)
draw->comp_mask[desc->comp[i].plane] |=
1 << desc->comp[i].offset;
return 0;
@@ -452,7 +453,7 @@ void ff_blend_rectangle(FFDrawContext *draw, FFDrawColor
*color,
/* 0x101 * alpha is in the [ 2 ; 0x1001] range */
alpha = 0x101 * color->rgba[3] + 0x2;
}
-nb_planes = draw->nb_planes - !!(draw->desc->flags &
AV_PIX_FMT_FLAG_ALPHA);
+nb_planes = draw->nb_planes - !!(draw->desc->flags & AV_PIX_FMT_FLAG_ALPHA
&& !(draw->flags & FF_DRAW_PROCESS_ALPHA));
nb_planes += !nb_planes;
for (plane = 0; plane < nb_planes; plane++) {
nb_comp = draw->pixelstep[plane];
@@ -630,7 +631,7 @@ void ff_blend_mask(FFDrawContext *draw, FFDrawColor *color,
} else {
alpha = (0x101 * color->rgba[3] + 0x2) >> 8;
}
-nb_planes = draw->nb_planes - !!(draw->desc->flags &
AV_PIX_FMT_FLAG_ALPHA);
+nb_planes = draw->nb_planes - !!(draw->desc->flags & AV_PIX_FMT_FLAG_ALPHA
&& !(draw->flags & FF_DRAW_PROCESS_ALPHA));
nb_planes += !nb_planes;
for (plane = 0; plane < nb_planes; plane++) {
nb_comp = draw->pixelstep[plane];
diff --git a/libavfilter/drawutils.h b/libavfilter/drawutils.h
index 1fb3e4f..cf53635 100644
--- a/libavfilter/drawutils.h
+++ b/libavfilter/drawutils.h
@@ -55,6 +55,7 @@ typedef struct FFDrawContext {
uint8_t vsub[MAX_PLANES]; /*< vertical subsampling */
uint8_t hsub_max;
uint8_t vsub_max;
+unsigned flags;
} FFDrawContext;
typedef struct FFDrawColor {
@@ -67,11 +68,16 @@ typedef struct FFDrawColor {
} FFDrawColor;
/**
+ * Process alpha pixel component.
+ */
+#define FF_DRAW_PROCESS_ALPHA 1
+
+/**
* Init a draw context.
*
* Only a limited number of pixel formats are supported, if format is not
* supported the function will return an error.
- * No flags currently defined.
+ * flags is combination of FF_DRAW_* flags.
* @return 0 for success, < 0 for error
*/
int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat format, unsigned
flags);
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 214aef0..65d3baa 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -730,7 +730,7 @@ static int config_input(AVFilterLink *inlink)
DrawTextContext *s = ctx->priv;
int ret;
-ff_draw_init(&s->dc, inlink->format, 0);
+ff_draw_init(&s->dc, inlink->format, FF_DRAW_PROCESS_ALPHA);
ff_draw_color(&s->dc, &s->fontcolor, s->fontcolor.rgba);
ff_draw_color(&s->dc, &s->shadowcolor, s->shadowcolor.rgba);
ff_draw_color(&s->dc, &s->bordercolor, s->bordercolor.rgba);
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: convert ffplay to use SDL2
On Tue, Sep 13, 2016 at 01:45:12PM -0300, James Almer wrote: > On 9/12/2016 3:58 PM, Josh de Kock wrote: > > From: Marton Balint > > > > Depends on the other SDL patches. > > > > Signed-off-by: Josh de Kock > > --- > > configure | 6 +- > > ffplay.c | 594 > > ++ > > 2 files changed, 249 insertions(+), 351 deletions(-) > > Tested on Windows (compiled with mingw-w64) and works fine. patchwork uses "^Tested-by:" to detect patches having been tested should the regexp be changed/extended ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/utils: fix timebase error in avformat_seek_file()
When there is only one stream and stream_index has not specified, The ts has been transferd by the timebase of stream0 without modifying the stream_index In this condation it cause seek failure. --- libavformat/utils.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/utils.c b/libavformat/utils.c index daf2d5b..6aedb5d 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -2412,6 +2412,7 @@ int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, max_ts = av_rescale_rnd(max_ts, time_base.den, time_base.num * (int64_t)AV_TIME_BASE, AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX); +stream_index = 0; } ret = s->iformat->read_seek2(s, stream_index, min_ts, -- 2.6.4 (Apple Git-63) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/utils: simplify matching MOV-like formats
On Tue, Sep 13, 2016 at 01:06:17PM +0200, Michael Niedermayer wrote:
> On Tue, Sep 13, 2016 at 11:00:27AM +0200, Clément Bœsch wrote:
> > On Tue, Sep 13, 2016 at 10:51:25AM +0200, Clément Bœsch wrote:
> > > From: Clément Bœsch
> > >
> > > ---
> > > libavformat/utils.c | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > > index 92a29ae..acb781e 100644
> > > --- a/libavformat/utils.c
> > > +++ b/libavformat/utils.c
> > > @@ -5315,9 +5315,7 @@ int
> > > avformat_transfer_internal_stream_timing_info(const AVOutputFormat *ofmt,
> > > enc_ctx->ticks_per_frame = 2;
> > > }
> > > } else if (!(ofmt->flags & AVFMT_VARIABLE_FPS)
> > > - && strcmp(ofmt->name, "mov") && strcmp(ofmt->name, "mp4")
> > > && strcmp(ofmt->name, "3gp")
> > > - && strcmp(ofmt->name, "3g2") && strcmp(ofmt->name, "psp")
> > > && strcmp(ofmt->name, "ipod")
> > > - && strcmp(ofmt->name, "f4v")) {
> > > + && !av_match_name(ofmt->name,
> > > "mov,mp4,3g2,psp,ipod,f4v")) {
> >
> > forgot to add 3gp, which means the next commit is all about adding ismv
>
> LGTM without missing parts
>
done and pushed
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add avformat_transfer_internal_stream_timing_info() and use it in ffmpeg
On Tue, Sep 13, 2016 at 02:56:16PM -0300, James Almer wrote:
> On 9/13/2016 2:42 PM, Clément Bœsch wrote:
> > On Tue, Sep 13, 2016 at 02:36:46PM -0300, James Almer wrote:
> > [...]
> >>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> >>> index 74915a1..389d985 100644
> >>> --- a/libavformat/avformat.h
> >>> +++ b/libavformat/avformat.h
> >>> @@ -2894,6 +2894,27 @@ int av_apply_bitstream_filters(AVCodecContext
> >>> *codec, AVPacket *pkt,
> >>> AVBitStreamFilterContext *bsfc);
> >>> #endif
> >>>
> >>> +enum AVTimebaseCopyFrom {
> >>
> >> AVTimebaseSource? CopySource? CopyFrom sounds kinda weird.
> >>
> >
> > Sure, anything you prefer
> >
> >>> +AVFMT_TBCF_AUTO = -1,
> >>> +AVFMT_TBCF_DECODER,
> >>> +AVFMT_TBCF_DEMUXER,
> >>> +AVFMT_TBCF_R_FRAMERATE,
> >>
> >> What's the deal with r_frame_rate anyway? There's an FF_API define for it
> >> as
> >> if it were deprecated, yet the field is not tagged as such and said define
> >> is
> >> not wrapping all its uses.
> >>
> >
> > I have no idea. Should I drop it from the public enum and keep the ==2
> > hack in the function until we find a clean way?
>
> You could also wrap the enum inside a FF_API_R_FRAME_RATE check, i guess.
> But in any case i was just wondering why the field (or the functionality)
> is supposedly deprecated but not really. Your code is fine as is.
>
Applied with FF_API_R_FRAME_RATE check and AVTimebaseSource
Thanks,
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/utils: sync MOV-like formats with the muxers found in lavf/movenc
On Tue, Sep 13, 2016 at 06:43:17PM +0200, Michael Niedermayer wrote:
> On Tue, Sep 13, 2016 at 10:51:26AM +0200, Clément Bœsch wrote:
> > From: Clément Bœsch
> >
> > ---
> > libavformat/utils.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index acb781e..35f13c1 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -5315,7 +5315,7 @@ int
> > avformat_transfer_internal_stream_timing_info(const AVOutputFormat *ofmt,
> > enc_ctx->ticks_per_frame = 2;
> > }
> > } else if (!(ofmt->flags & AVFMT_VARIABLE_FPS)
> > - && !av_match_name(ofmt->name, "mov,mp4,3g2,psp,ipod,f4v")) {
> > + && !av_match_name(ofmt->name,
> > "mov,3gp,mp4,psp,3g2,ipod,ismv,f4v")) {
> > if (copy_tb == AVFMT_TBCF_AUTO && dec_ctx->time_base.den
> > && av_q2d(dec_ctx->time_base)*dec_ctx->ticks_per_frame >
> > av_q2d(ist->time_base)
> > && av_q2d(ist->time_base) < 1.0/500
>
> LGTM
>
> thx
>
applied
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.
On Tue, Sep 13, 2016 at 4:39 PM, Sasi Inguva wrote: > Sorry for the very late reply. I was busy with other things. > > On Sat, Sep 3, 2016 at 4:48 PM, Michael Niedermayer < > mich...@niedermayer.cc> wrote: > >> On Sat, Sep 03, 2016 at 12:06:39PM -0700, Sasi Inguva wrote: >> > Hi Michael, >> > >> > In fact from audacity I see that out-ingu.wav out-mp3.wav are almost >> > equivalent, >> >> They do not match. (and that is alot more vissible if you scale the >> time axis up a bit) >> >> You also dont use the existing API for handling initial padding/skip >> And you didnt reply to this concern >> its probably not that hard to fix that ... >> instead of droping just at packet granularity you would set the stuff >> for droping at sample granularity (too) >> > > Yes. Looking at it more closely now, they don't matrch exactly and this is > because as you said, number of samples to drop is not exactly multiple of > number of packets. In that case we need to partially discard some samples > of a packet. This can be done by using AV_PKT_SIDE_DATA_SKIP_SAMPLES. I > can change the code to use this packet side data instead of discard packet > flag, if it is ok. > > >> >> also maybe you missed my question about your oppinion on the correct >> timestamp output: >> "My first question is, entirely independant of the implementation from >> the patches. What is the correct output ? (my primary focus is on >> the timestamps)" >> >> Iam curious because to me the timestamps of the dropped packets look >> wrong and id like to know your oppinion about this. Is this a >> implementation issue (if so please explain) or is there some reason >> independant of the implementation (if so please explain too) >> > > The correct output according to me should be - we should show exactly the > same presentation timestmap indicated by the MOV stts, ctts atoms, for the > samples that fall inside the edits. As long as the PTS is according to what > the edit and stts,ctts atoms say. I don't really have to worry about what > the decoding timestamp for those packets should be (DTS might as well be > AV_NOPTS_VALUE for all packets) . > > In the current implementation, we directly assign the timestamp in the > AVIndex to pkt->dts . http://git.videolan.org/?p=ffmpeg.git;a=blob;f= > libavformat/mov.c;h=6e80b93271a4f998af6ba1af795d7d7c5d67f5a1;hb=HEAD#l5332 > . The implementation of the edit list code is such that, it needs to be > filled with "linear monotonically increasing timestamps for the > non-discarded packets " to have the samples denoted by the editlists to > have linear monotonically increasing timestamps, in essence, to avoid a big > gap between the presentation of the end of first edit list and the start of > next edit list because of the discarded packets. > Hence while parsing a new edit list we bump down the index entry timestamp > to (frame_duration + last non-discarded packet from previous edit list ) . > And that's why we get non-monotonic timestamps as a whole in the > AVIndexEntry . > > I think my wording is confusing here. Just clarifying . For one editlist/ within one editlist, the AVIndexEntry samples pertaining to that edit, need to be filled with "monotonic timestamps which increase in steps of their corresponding 'stts' atom entries ", to achieve the correct presentation timestamp for those samples. When we start parsing the next edit list entry, and start adding index entries to AVIndexEntry we need to avoid a big gap between the presentation of the end of first edit and the start of next edit, that might happen because of the DISCARD packets added to the AVIndexEntry while parsing the first edit. Hence we start adding index entries from a bumped down value corresponding to (frame_duration + last non-discarded packet from previous edit ) . And that's why we get non-monotonic timestamps as a whole in the AVIndexEntry . > Let us take an example of a file with two edit lists. First edit list > ending on a B frame. This is what ffprobe -show_packet -pf compact looks > like . Where 'D' stands for discarded frame. ( I've attached a 6th patch to > ffprobe to achieve this formatting ). > ./ffprobe -show_packets -print_format compact mov-2elist-bpyramid-1elist- > ends-on-bref.mov > . > packet|codec_type=video|stream_index=0|pts=10752|pts_ > time=0.875000|dts=8192|dts_time=0.67|duration=512| > duration_time=0.041667|convergence_duration=N/A| > convergence_duration_time=N/A|size=1281|pos=39546|flags=__ - Pframe > packet|codec_type=video|stream_index=0|pts=9728|pts_ > time=0.791667|dts=8704|dts_time=0.708333|duration=512| > duration_time=0.041667|convergence_duration=N/A| > convergence_duration_time=N/A|size=749|pos=40827|flags=__ - B pyramidal > ref > packet|codec_type=video|stream_index=0|pts=9216|pts_ > time=0.75|dts=9216|dts_time=0.75|duration=512| > duration_time=0.041667|convergence_duration=N/A| > convergence_duration_time=N/A|size=487|pos=41576|flags=__ - B > packet|codec_type=video|stream_index=0|pts=10
