[FFmpeg-devel] [PATCH] lavc/h264_slice: use sps directly when checking for invalid 8x8 inference
---
libavcodec/h264_slice.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index ca492ba..22916f1 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1466,7 +1466,7 @@ static int h264_slice_header_parse(H264Context *h,
H264SliceContext *sl)
if (sps->frame_mbs_only_flag) {
picture_structure = PICT_FRAME;
} else {
-if (!h->ps.sps->direct_8x8_inference_flag && slice_type ==
AV_PICTURE_TYPE_B) {
+if (!sps->direct_8x8_inference_flag && slice_type ==
AV_PICTURE_TYPE_B) {
av_log(h->avctx, AV_LOG_ERROR, "This stream was generated by a
broken encoder, invalid 8x8 inference\n");
return -1;
}
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: mark stream as const pointer in av_stream_get_side_data()
On Mon, Jun 27, 2016 at 12:10:53PM +0200, Clément Bœsch wrote: > From: Clément Bœsch > > TODO: bump lavf minor > XXX: should i add a FF_API_NOCONST_GET_SIDE_DATA? > --- > libavformat/avformat.h | 2 +- > libavformat/utils.c| 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > ping -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avformat: Adding accessors for externally used AVStream fields which are after the public field list
On Wed, Jun 29, 2016 at 09:36:39PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/avformat.h |4
> libavformat/utils.c| 21 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 876f1e3..89f014b 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1224,6 +1224,10 @@ void av_stream_set_r_frame_rate(AVStream *s,
> AVRational r);
> struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
> char* av_stream_get_recommended_encoder_configuration(const AVStream *s);
> void av_stream_set_recommended_encoder_configuration(AVStream *s, char
> *configuration);
> +int64_t av_stream_get_cur_dts(AVStream *s);
> +int64_t av_stream_get_first_dts(AVStream *s);
> +int av_stream_get_pts_wrap_bits(AVStream *s);
> +int64_t av_stream_get_codec_info_nb_frames(AVStream *s);
>
> /**
> * Returns the pts of the last muxed packet + its duration
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 6f343f2..5168816 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -132,6 +132,27 @@ struct AVCodecParserContext *av_stream_get_parser(const
> AVStream *st)
> return st->parser;
> }
>
> +int64_t av_stream_get_cur_dts(AVStream *s)
> +{
> +return s->cur_dts;
> +}
> +
> +int64_t av_stream_get_first_dts(AVStream *s)
> +{
> +return s->first_dts;
> +}
> +
> +int av_stream_get_pts_wrap_bits(AVStream *s)
> +{
> +return s->pts_wrap_bits;
> +}
> +
> +int64_t av_stream_get_codec_info_nb_frames(AVStream *s)
> +{
> +return s->codec_info_nb_frames;
> +}
> +
> +
erm. how about we move them in the public fields instead?
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] git: ignore test binaries
On Wed, Jun 29, 2016 at 05:54:37PM +0200, Benoit Fouet wrote: > > From e514644033781cb431641ae088482f5a8aa2de42 Mon Sep 17 00:00:00 2001 > From: Benoit Fouet > Date: Wed, 29 Jun 2016 17:53:50 +0200 > Subject: [PATCH] git: ignore test binaries > > --- > .gitignore | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.gitignore b/.gitignore > index 524fb73..670d1d2 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -19,6 +19,7 @@ > *.swp > *.ver > *_g > +*-test > \#* > .\#* > /.config You shouldn't have any, they moved somewhere else without the -test suffix (with the exception of fate api tests which have the proper entry in their own .gitignore) Maybe previously built programs? -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264_slice: move au_pps_id and current_sps_id assignment earlier
On Wed, Jun 29, 2016 at 01:56:25PM +0200, Michael Niedermayer wrote: > On Wed, Jun 29, 2016 at 12:52:18PM +0200, Clément Bœsch wrote: > > From: Clément Bœsch > > > > This will simplify the next merge commit from Libav. > > --- > > libavcodec/h264_slice.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > all files i tried still work with this patch > they also all work if i remove both fields entirely > as in: > So the security relevant samples do not cause harm anymore? If so then please apply these patches (with the removal of the field in the context) -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/h264_slice: move au_pps_id and current_sps_id assignment earlier
From: Clément Bœsch
This will simplify the next merge commit from Libav.
---
libavcodec/h264_slice.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 474400b..0b5079c 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1202,6 +1202,9 @@ int ff_h264_decode_slice_header(H264Context *h,
H264SliceContext *sl)
pps = h->ps.pps;
sps = h->ps.sps;
+h->au_pps_id = pps_id;
+h->current_sps_id = h->ps.pps->sps_id;
+
must_reinit = (h->context_initialized &&
( 16*sps->mb_width != h->avctx->coded_width
|| 16*sps->mb_height * (2 - sps->frame_mbs_only_flag) !=
h->avctx->coded_height
@@ -1782,9 +1785,6 @@ int ff_h264_decode_slice_header(H264Context *h,
H264SliceContext *sl)
(sl->ref_list[j][i].reference & 3);
}
-h->au_pps_id = pps_id;
-h->current_sps_id = h->ps.pps->sps_id;
-
if (h->avctx->debug & FF_DEBUG_PICT_INFO) {
av_log(h->avctx, AV_LOG_DEBUG,
"slice:%d %s mb:%d %c%s%s pps:%u frame:%d poc:%d/%d ref:%d/%d
qp:%d loop:%d:%d:%d weight:%d%s %s\n",
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavf: mark stream as const pointer in av_stream_get_side_data()
From: Clément Bœsch
TODO: bump lavf minor
XXX: should i add a FF_API_NOCONST_GET_SIDE_DATA?
---
libavformat/avformat.h | 2 +-
libavformat/utils.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 876f1e3..43b4a02 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2051,7 +2051,7 @@ uint8_t *av_stream_new_side_data(AVStream *stream,
* @param size pointer for side information size to store (optional)
* @return pointer to data if present or NULL otherwise
*/
-uint8_t *av_stream_get_side_data(AVStream *stream,
+uint8_t *av_stream_get_side_data(const AVStream *stream,
enum AVPacketSideDataType type, int *size);
AVProgram *av_new_program(AVFormatContext *s, int id);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 4d53f8f..093fcf9 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4936,7 +4936,7 @@ int ff_generate_avci_extradata(AVStream *st)
return 0;
}
-uint8_t *av_stream_get_side_data(AVStream *st, enum AVPacketSideDataType type,
+uint8_t *av_stream_get_side_data(const AVStream *st, enum AVPacketSideDataType
type,
int *size)
{
int i;
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavf/utils: add some const to pointers parameters in a few functions
From: Clément Bœsch
---
libavformat/internal.h | 2 +-
libavformat/utils.c| 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 647ad65..f66acae 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -552,7 +552,7 @@ enum AVWriteUncodedFrameFlags {
/**
* Copies the whilelists from one context to the other
*/
-int ff_copy_whiteblacklists(AVFormatContext *dst, AVFormatContext *src);
+int ff_copy_whiteblacklists(AVFormatContext *dst, const AVFormatContext *src);
int ffio_open2_wrapper(struct AVFormatContext *s, AVIOContext **pb, const char
*url, int flags,
const AVIOInterruptCB *int_cb, AVDictionary **options);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 6f343f2..4d53f8f 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -90,7 +90,7 @@ static int is_relative(int64_t ts) {
* @param timestamp the time stamp to wrap
* @return resulting time stamp
*/
-static int64_t wrap_timestamp(AVStream *st, int64_t timestamp)
+static int64_t wrap_timestamp(const AVStream *st, int64_t timestamp)
{
if (st->pts_wrap_behavior != AV_PTS_WRAP_IGNORE &&
st->pts_wrap_reference != AV_NOPTS_VALUE && timestamp !=
AV_NOPTS_VALUE) {
@@ -142,7 +142,7 @@ void av_format_inject_global_side_data(AVFormatContext *s)
}
}
-int ff_copy_whiteblacklists(AVFormatContext *dst, AVFormatContext *src)
+int ff_copy_whiteblacklists(AVFormatContext *dst, const AVFormatContext *src)
{
av_assert0(!dst->codec_whitelist &&
!dst->format_whitelist &&
@@ -162,7 +162,7 @@ int ff_copy_whiteblacklists(AVFormatContext *dst,
AVFormatContext *src)
return 0;
}
-static const AVCodec *find_decoder(AVFormatContext *s, AVStream *st, enum
AVCodecID codec_id)
+static const AVCodec *find_decoder(AVFormatContext *s, const AVStream *st,
enum AVCodecID codec_id)
{
#if FF_API_LAVF_AVCTX
FF_DISABLE_DEPRECATION_WARNINGS
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const
On Fri, Jun 24, 2016 at 09:20:35AM +0200, Benoit Fouet wrote: [...] > >>Any objection to this patch now? > >iam ok with the patch, maybe give others a bit of time to reply > >before applying though > > Yeah, I'm in no hurry, I just saw this FIXME in the context of one of > Mateo's patches. > I was more waiting for some feedback from Hendrik or Clément, anyway, as > they were the ones raising the points. Should be fine if indeed the following computation: int width = 16 * sps->mb_width; int height = 16 * sps->mb_height * (2 - sps->frame_mbs_only_flag); ...is always correct. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: parse rtmd track timecode
On Sat, Jun 25, 2016 at 11:36:05AM +0200, Paul B Mahol wrote:
> Hi,
>
> patch attached.
> From fbf2d600e048a417183ab32fdb2e7e2bcf238071 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Sat, 25 Jun 2016 11:33:46 +0200
> Subject: [PATCH] avformat/mov: parse rtmd track timecode
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/mov.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index d75605d..34ce246 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4674,6 +4674,31 @@ static int
> parse_timecode_in_framenum_format(AVFormatContext *s, AVStream *st,
> return 0;
> }
>
> +static int mov_read_rtmd_track(AVFormatContext *s, AVStream *st)
> +{
> +MOVStreamContext *sc = st->priv_data;
> +char buf[AV_TIMECODE_STR_SIZE];
> +int64_t cur_pos = avio_tell(sc->pb);
> +int dd, hh, mm, ss;
> +
> +if (!st->nb_index_entries)
> +return -1;
> +
> +avio_seek(sc->pb, st->index_entries->pos, SEEK_SET);
> +avio_skip(s->pb, 13);
> +dd = avio_r8(s->pb);
> +hh = avio_r8(s->pb);
> +mm = avio_r8(s->pb);
> +avio_skip(s->pb, 1);
isn't this the drop flag? if so you should probably honor it as as ';' in
the timecode string
> +ss = avio_r8(s->pb);
> +snprintf(buf, AV_TIMECODE_STR_SIZE, "%02d:%02d:%02d:%02d",
> + dd, hh, mm, ss);
> +av_dict_set(&st->metadata, "timecode", buf, 0);
> +
> +avio_seek(sc->pb, cur_pos, SEEK_SET);
> +return 0;
> +}
> +
> static int mov_read_timecode_track(AVFormatContext *s, AVStream *st)
> {
> MOVStreamContext *sc = st->priv_data;
> @@ -4952,8 +4977,11 @@ static int mov_read_header(AVFormatContext *s)
> if (mov->chapter_track > 0 && !mov->ignore_chapters)
> mov_read_chapters(s);
> for (i = 0; i < s->nb_streams; i++)
> -if (s->streams[i]->codecpar->codec_tag == AV_RL32("tmcd"))
> +if (s->streams[i]->codecpar->codec_tag == AV_RL32("tmcd")) {
> mov_read_timecode_track(s, s->streams[i]);
> +} else if (s->streams[i]->codecpar->codec_tag ==
> AV_RL32("rtmd")) {
> +mov_read_rtmd_track(s, s->streams[i]);
> +}
> }
>
> /* copy timecode metadata from tmcd tracks to the related video streams
> */
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: drop people who do not appear in git history > 2013
On Fri, Jun 24, 2016 at 01:30:42PM +0200, Michael Niedermayer wrote: > On Fri, Jun 24, 2016 at 12:31:46PM +0200, Clément Bœsch wrote: > > From: Clément Bœsch > [...] > > @@ -500,16 +416,10 @@ Resamplers: > > Operating systems / CPU architectures > > = > > > > -Alpha Falk Hueffner > > MIPSNedeljko Babic > > > -Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier > > i dont know if Guillaume still maintains this but he was active past > 2013: > Date: Sun, 24 Aug 2014 21:52:17 +0200 > From: Guillaume POIRIER > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH/RFC] avutil/pixelutils: port ppc/altivec > sad functions > I don't see anything in the history; % git log -i --author=poirier -1 commit 337e3fd990aab76bfcdceb84cd3f62f3e31fa22f Author: Guillaume Poirier Date: Thu Dec 25 18:27:49 2008 + -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] MAINTAINERS: drop people who do not appear in git history > 2013
From: Clément Bœsch --- MAINTAINERS | 113 +--- 1 file changed, 8 insertions(+), 105 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fd87db5..e908def 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -35,17 +35,12 @@ ffserver: Commandline utility code: cmdutils.c, cmdutils.hMichael Niedermayer -QuickTime faststart: - tools/qt-faststart.c Baptiste Coudurier - Miscellaneous Areas === -documentation Stefano Sabatini, Mike Melanson, Timothy Gu, Lou Logan +documentation Stefano Sabatini, Timothy Gu, Lou Logan project server Árpád Gereöffy, Michael Niedermayer, Reimar Doeffinger, Alexander Strasser -presets Robert Swain -metadata subsystem Aurelien Jacobs release management Michael Niedermayer @@ -55,7 +50,7 @@ Communication website Deby Barbara Lepage fate.ffmpeg.org Timothy Gu Trac bug trackerAlexander Strasser, Michael Niedermayer, Carl Eugen Hoyos, Lou Logan -mailing lists Baptiste Coudurier, Lou Logan +mailing lists Lou Logan Google+ Paul B Mahol, Michael Niedermayer, Alexander Strasser Twitter Lou Logan, Reynaldo H. Verdejo Pinochet Launchpad Timothy Gu @@ -133,29 +128,22 @@ Generic Parts: Codecs: 4xm.c Michael Niedermayer 8bps.cRoberto Togni - 8svx.cJaikrishnan Menon aacenc*, aaccoder.c Rostislav Pehlivanov - alacenc.c Jaikrishnan Menon alsdec.c Thilo Borgmann - ass* Aurelien Jacobs asv* Michael Niedermayer atrac3plus* Maxim Poliakovski bgmc.c, bgmc.hThilo Borgmann binkaudio.c Peter Ross - cavs* Stefan Gehrer cdxl.cPaul B Mahol celp_filters.*Vitor Sessak cinepak.c Roberto Togni cinepakenc.c Rl / Aetey G.T. AB ccaption_dec.cAnshul Maheshwari - cljr Alex Beregszaszi cpia.cStephan Hilb crystalhd.c Philip Langdale cscd.cReimar Doeffinger cuvid.c Timo Rothenpieler dirac*Rostislav Pehlivanov - dnxhd*Baptiste Coudurier - dpcm.cMike Melanson dss_sp.c Oleksij Rempel dv.c Roman Shaposhnik dvbsubdec.c Anshul Maheshwari @@ -164,32 +152,21 @@ Codecs: exif.c, exif.hThilo Borgmann ffv1* Michael Niedermayer ffwavesynth.c Nicolas George - flicvideo.c Mike Melanson g722.cMartin Storsjo g726.cRoman Shaposhnik - gifdec.c Baptiste Coudurier h261* Michael Niedermayer h263* Michael Niedermayer h264* Loren Merritt, Michael Niedermayer hap* Tom Butterworth huffyuv* Michael Niedermayer, Christophe Gisquet - idcinvideo.c Mike Melanson - interplayvideo.c Mike Melanson jni*, ffjni* Matthieu Bouron jpeg2000* Nicolas Bertrand jvdec.c Peter Ross lcl*.cRoberto Togni, Reimar Doeffinger libcelt_dec.c Nicolas George - libdirac* David Conrad - libgsm.c Michel Bardiaux libkvazaar.c Arttu Ylä-Outinen - libopenjpeg.c Jaikrishnan Menon libopenjpegenc.c Michael Bradshaw - libschroedinger* David Conrad - libtheoraenc.cDavid Conrad - libvorbis.c David Conrad libvpx* James Zern - libxavs.c Stefan Gehrer libzvbi
[FFmpeg-devel] [PATCH] doc: add Libav merge document
From: Clément Bœsch --- Very incomplete, maybe splittable (split out the 3 first sections somewhere as an announce on the website) Comments from other people who have done merges in the past very welcome, notably on the last 2 sections. --- doc/libav-merge.txt | 109 1 file changed, 109 insertions(+) create mode 100644 doc/libav-merge.txt diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt new file mode 100644 index 000..2ae22b1 --- /dev/null +++ b/doc/libav-merge.txt @@ -0,0 +1,109 @@ +CONTEXT +=== + +The FFmpeg project merges all the changes from the Libav project +(https://libav.org) since the origin of the fork (around 2011). + +With the exceptions of some commits due to technical/political disagreements or +issues, the changes are merged on a more or less regular schedule (daily for +years thanks to Michael, but more sparse nowadays). + +WHY +=== + +The majority of the active developers believe the project needs to keep this +policy for various reasons. + +The most important one is that we don't want our users to have to choose +between two distributors of libraries of the exact same name in order to have a +different set of features and bugfixes. By taking the responsibility of +unifying the two codebases, we allow users to benefit from the changes from the +two teams. + +Today, FFmpeg has a much larger user database (we are distributed by every +major distribution), so we consider this mission a priority. + +A different approach to the merge could have been to pick the changes we are +interested in and drop most of the cosmetics and other less important changes. +Unfortunately, this makes the following picks much harder, especially since the +Libav project is involved in various deep API changes. As a result, we decide +to virtually take everything done there. + +Any Libav developer is of course welcome anytime to contribute directly to the +FFmpeg tree. Of course, we fully understand and are forced to accept that very +few Libav developers are interested in doing so, but we still want to recognize +their work. This leads us to create merge commits for every single one from +Libav. The original commit appears totally unchanged with full authorship in +our history (and the conflict are solved in the merge one). That way, not a +single thing from Libav will be lost in the future in case some reunification +happens, or that project disappears one way or another. + +DOWNSIDES += + +Of course, there are many downsides to this approach. + +- It causes a non negligible merge commits pollution. We make sure there are + not several level of merges entangled (we do a 1:1 merge/commit), but it's + still a non-linear history. + +- Many duplicated work. For instance, we added libavresample in our tree to + keep compatibility with Libav when our libswresample was already covering the + exact same purpose. The same thing happened for various elements such as the + ProRes support (but differences in features, bugs, licenses, ...). There are + many work to do to unify them, and any help is very much welcome. + +- So much manpower from both FFmpeg and Libav is lost because of this mess. We + know it, and we don't know how to fix it. It takes incredible time to do + these merges, so we have even less time to work on things we personally care + about. The bad vibes also do not help with keeping our developers motivated. + +- There is a growing technical risk factor with the merges due to the codebase + differing more and more. + +MERGE GUIDELINES + + +The following gives developer guidelines on how to proceed when merging Libav commits. + +Before starting, you can reduce the risk of errors on merge conflicts by using +a different merge conflict style: + +$ git config --global merge.conflictstyle diff3 + +Here is a script to help merging the next commit in the queue: + +#!/bin/sh + +if [ "$1" != "merge" -a "$1" != "noop" ]; then + printf "Usage: $0 \n" + exit 0 +fi + +[ "$1" = "noop" ] && merge_opts="-s ours" + +nextrev=$(git rev-list libav/master --not master --no-merges | tail -n1) +if [ -z "$nextrev" ]; then +printf "Nothing to merge..\n" +exit 0 +fi +printf "Merging $(git log -n 1 --oneline $nextrev)\n" +git merge --no-commit $merge_opts --no-ff --log $nextrev + +if [ "$1" = "noop" -a -n "$2" ]; then + printf "\nThis commit is a noop, see $2\n" >> .git/MERGE_MSG +fi + +printf "\nMerged-by: $(git config --get user.name) <$(git config --get user.email)>\n" >> .git/MERGE_MSG + + +The script assumes a remote named libav. + +It has two modes: merge, and noop. The noop mode creates a merge with no change +to the HEAD. You can pass a h
Re: [FFmpeg-devel] [FFmpeg-cvslog] MAINTAINERS: Remove Linux / PowerPC maintainer
On Thu, Jun 23, 2016 at 01:44:42AM +0200, Michael Niedermayer wrote: > On Thu, Jun 23, 2016 at 01:01:41AM +0200, Clément Bœsch wrote: > > On Thu, Jun 23, 2016 at 12:57:44AM +0200, Michael Niedermayer wrote: > > > ffmpeg | branch: master | Michael Niedermayer | > > > Thu Jun 23 00:49:29 2016 +0200| > > > [18f687f73709a3ad5bb6b6fbbdbbce6dc8a91036] | committer: Michael > > > Niedermayer > > > > > > MAINTAINERS: Remove Linux / PowerPC maintainer > > > > > > See: [FFmpeg-devel] PPC64: PowerPC Maintainer information is incorrect > > > > > > Signed-off-by: Michael Niedermayer > > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=18f687f73709a3ad5bb6b6fbbdbbce6dc8a91036 > > > --- > > > > > > MAINTAINERS |1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 24145da..b9fa0c5 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -552,7 +552,6 @@ AVR32 Mans Rullgard > > > MIPSMans Rullgard, Nedeljko Babic > > > Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier > > > Amiga / PowerPC Colin Ward > > > -Linux / PowerPC Luca Barbato > > > Windows MinGW Alex Beregszaszi, Ramiro Polla > > > Windows Cygwin Victor Paesa > > > Windows MSVCMatthew Oliver, Hendrik Leppkes > > > > Don't you think you should remove Diego, Måns, Kostya, ... as well? > > They didnt ask me to remove them, they didnt remove themselfs even > though they could, they didnt post a patch to remove themselfs. > No contributor said that he contacted them and they no longer maintain > the code they are listed for. (or i missed that) Well… I think it's common knowledge that they left the FFmpeg Project, and with the exception of Diego, they also left the Libav project (public declaration can be found). -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] MAINTAINERS: Remove Linux / PowerPC maintainer
On Thu, Jun 23, 2016 at 12:57:44AM +0200, Michael Niedermayer wrote: > ffmpeg | branch: master | Michael Niedermayer | Thu > Jun 23 00:49:29 2016 +0200| [18f687f73709a3ad5bb6b6fbbdbbce6dc8a91036] | > committer: Michael Niedermayer > > MAINTAINERS: Remove Linux / PowerPC maintainer > > See: [FFmpeg-devel] PPC64: PowerPC Maintainer information is incorrect > > Signed-off-by: Michael Niedermayer > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=18f687f73709a3ad5bb6b6fbbdbbce6dc8a91036 > --- > > MAINTAINERS |1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 24145da..b9fa0c5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -552,7 +552,6 @@ AVR32 Mans Rullgard > MIPSMans Rullgard, Nedeljko Babic > Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier > Amiga / PowerPC Colin Ward > -Linux / PowerPC Luca Barbato > Windows MinGW Alex Beregszaszi, Ramiro Polla > Windows Cygwin Victor Paesa > Windows MSVCMatthew Oliver, Hendrik Leppkes Don't you think you should remove Diego, Måns, Kostya, ... as well? -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add pnm pipe demuxers
On Wed, Jun 22, 2016 at 11:56:43AM +0200, Michael Niedermayer wrote:
> On Wed, Jun 22, 2016 at 10:28:14AM +0200, Clément Bœsch wrote:
> > On Mon, Jun 20, 2016 at 04:39:47PM +0200, Michael Niedermayer wrote:
> > [...]
> > > > +static inline int pnm_probe(const AVProbeData *p)
> > > > +{
> > > > +const uint8_t *b = p->buf;
> > > > +
> > > > +while (b[2] == '\r')
> > > > +b++;
> > >
> > > shouldnt this check buf_size ?
> > >
> >
> > Inside AVProbeData struct declaration:
> > unsigned char *buf; /**< Buffer must have AVPROBE_PADDING_SIZE of extra
> > allocated bytes filled with zero. */
> >
> > So in the worst case it will reach a zero, and then bail out because it's
> > not a '\n'
>
> patch ok
>
applied, thanks
> maybe the zeroness of the padding should be checked somewhere
>
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add pnm pipe demuxers
On Mon, Jun 20, 2016 at 04:39:47PM +0200, Michael Niedermayer wrote:
[...]
> > +static inline int pnm_probe(const AVProbeData *p)
> > +{
> > +const uint8_t *b = p->buf;
> > +
> > +while (b[2] == '\r')
> > +b++;
>
> shouldnt this check buf_size ?
>
Inside AVProbeData struct declaration:
unsigned char *buf; /**< Buffer must have AVPROBE_PADDING_SIZE of extra
allocated bytes filled with zero. */
So in the worst case it will reach a zero, and then bail out because it's
not a '\n'
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add pnm pipe demuxers
On Mon, Jun 20, 2016 at 01:07:09PM +, Carl Eugen Hoyos wrote:
> Clément Bœsch pkh.me> writes:
>
> > +static int pgmyuv_probe(AVProbeData *p)
> > +{
> > +int ret = pgmx_probe(p);
> > +return ret && av_match_ext(p->filename, "pgmyuv") ? ret : 0;
>
> You could add a comment that this format was invented within
> FFmpeg, I hadn't realized this.
I'm not sure the probe code is really the best place to do that but added
locally anyway
> And you could check for positive resolutions if you want to
> improve probing.
Yeah, probing could be improved, but it requires some line skipping logic
(empty lines, comments, etc) I wasn't that motivated to write (probably
due to a traumatic history with text subtitles).
> Did you run the probe test for the new functions?
Should I pass special parameters?
testing size=1
testing size=2
testing size=4
testing size=8
Failure of vqf probing code with score=50 type=3 p=C2A size=8
Failure of mov,mp4,m4a,3gp,3g2,mj2 probing code with score=50 type=3 p=FD1
size=8
Failure of 3dostr probing code with score=66 type=3 p=E2 size=8
Failure of mov,mp4,m4a,3gp,3g2,mj2 probing code with score=100 type=3 p=75
size=8
testing size=16
Failure of musx probing code with score=40 type=3 p=A6A size=16
Failure of alias_pix probing code with score=51 type=0 p=CBA size=16
testing size=32
testing size=64
Failure of mpc8 probing code with score=49 type=3 p=85A size=64
testing size=128
testing size=256
testing size=512
testing size=1024
testing size=2048
testing size=4096
testing size=8192
testing size=16384
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const
On Tue, Jun 21, 2016 at 02:34:33PM +0200, Benoit Fouet wrote:
> Hi,
>
> Unless I totally missed something, the FIXME in H264ParamSets structure
> should be fixed by attached patch.
>
> --
> Ben
>
> From 28ae10498f81070539bdb8f40236326743350101 Mon Sep 17 00:00:00 2001
> From: Benoit Fouet
> Date: Tue, 21 Jun 2016 14:17:13 +0200
> Subject: [PATCH] h264: make H264ParamSets sps const
>
> ---
> libavcodec/h264.h | 3 +--
> libavcodec/h264_slice.c | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/h264.h b/libavcodec/h264.h
> index c4d2921..b809ee5 100644
> --- a/libavcodec/h264.h
> +++ b/libavcodec/h264.h
> @@ -234,8 +234,7 @@ typedef struct H264ParamSets {
> AVBufferRef *sps_ref;
> /* currently active parameters sets */
> const PPS *pps;
> -// FIXME this should properly be const
> -SPS *sps;
> +const SPS *sps;
> } H264ParamSets;
>
> /**
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 6e7b940..da7f9dd 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -873,7 +873,7 @@ static enum AVPixelFormat get_pixel_format(H264Context
> *h, int force_callback)
> /* export coded and cropped frame dimensions to AVCodecContext */
> static int init_dimensions(H264Context *h)
> {
> -SPS *sps = h->ps.sps;
> +SPS *sps = (SPS*)h->ps.sps_ref->data;
> int width = h->width - (sps->crop_right + sps->crop_left);
> int height = h->height - (sps->crop_top + sps->crop_bottom);
> av_assert0(sps->crop_right + sps->crop_left < (unsigned)h->width);
So it's not actually const, right?
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add pnm pipe demuxers
On Thu, Jun 16, 2016 at 11:26:02AM +0200, Clément Bœsch wrote: > From: Clément Bœsch > > --- > Still unsure about the FATE changes. > Also couldn't test pgm vs pgmyuv due to a crash > --- > libavformat/Makefile| 5 + > libavformat/allformats.c| 5 + > libavformat/img2dec.c | 55 > + > tests/ref/seek/lavf-pbmpipe | 50 ++--- > tests/ref/seek/lavf-pgmpipe | 50 ++--- > tests/ref/seek/lavf-ppmpipe | 50 ++--- > 6 files changed, 146 insertions(+), 69 deletions(-) > ping -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] lavf: add libopenmpt demuxer
On Sun, Jun 19, 2016 at 12:49:56PM +0100, Josh de Kock wrote:
[...]
> +static int probe_openmpt(AVProbeData *p)
> +{
> +if(!p->filename)
> +return AVERROR(enoent);
> +
I'd say return 0 here instead
> +FILE *file = fopen(p->filename, "rb");
> +if (!file)
> +return AVERROR(errno);
> +
> +double ret =
> openmpt_could_open_propability(openmpt_stream_get_file_callbacks(), file,
> 1.0, openmpt_logfunc, NULL);
Please move the declaration of file and ret at the beginning of the scope
> +fclose(file);
> +return ret ? ret * AVPROBE_SCORE_MAX : 0;
So apparently this breaks FATE as it detects some random mp3 and others as
supported. You probably need to lower it down a lot, something like ret *
AVPROBE_SCORE_EXTENSION/2 or something.
[...]
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/magicyuv: fix undefined behaviour introduced in 8a135a55b
Order of evaluation of parameters in C is not defined.
---
libavcodec/magicyuv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/magicyuv.c b/libavcodec/magicyuv.c
index ce0ea9b..3bb4c5a 100644
--- a/libavcodec/magicyuv.c
+++ b/libavcodec/magicyuv.c
@@ -245,7 +245,7 @@ static int decode_frame(AVCodecContext *avctx,
AVFrame *p = data;
GetByteContext gb;
GetBitContext b;
-int i, j, k;
+int i, j, k, width, height;
bytestream2_init(&gb, avpkt->data, avpkt->size);
if (bytestream2_get_le32(&gb) != MKTAG('M','A','G','Y'))
@@ -309,7 +309,9 @@ static int decode_frame(AVCodecContext *avctx,
s->interlaced = !!(bytestream2_get_byte(&gb) & 2);
bytestream2_skip(&gb, 3);
-if ((ret = ff_set_dimensions(avctx, bytestream2_get_le32(&gb),
bytestream2_get_le32(&gb))) < 0)
+width = bytestream2_get_le32(&gb);
+height = bytestream2_get_le32(&gb);
+if ((ret = ff_set_dimensions(avctx, width, height)) < 0)
return ret;
slice_width = bytestream2_get_le32(&gb);
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add libopenmpt demuxer
On Sun, Jun 19, 2016 at 12:40:57AM +0100, Josh de Kock wrote:
[...]
> +#define OFFSET(x) offsetof(OpenMPTContext, x)
> +#define A AV_OPT_FLAG_AUDIO_PARAM
> +#define D AV_OPT_FLAG_DECODING_PARAM
> +static const AVOption options[] = {
> +{"sample_rate", "set sample rate",
> OFFSET(sample_rate), AV_OPT_TYPE_INT,{.i64 = 44100},
> 1000, INT_MAX, A|D},
> +{"layout", "set channel layout (default: stereo)", OFFSET(layout),
> AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64 = AV_CH_LAYOUT_STEREO}, 0,
> INT64_MAX, A|D},
You can drop "(default: stereo)". If it doesn't appear in "ffmpeg -h
demuxer=libopenmpt" then libavutil/opt.c needs some patching (to use
av_get_channel_layout_string()).
> +{NULL}
> +};
> +
> +static void openmpt_logfunc(const char *message, void *userdata)
> +{
> +int level = AV_LOG_INFO;
> +if (strstr(message, "ERROR") != NULL) {
> +level = AV_LOG_ERROR;
> +}
> +av_log(userdata, level, "%s\n", message);
> +}
> +
> +static int probe_openmpt(AVProbeData *p)
> +{
> +FILE *file = fopen(p->filename, "rb");
Someone needs to confirm, but I wonder if filename can't be NULL under
certain circomstances. Also, you need to check the return value of
fopen().
> +double ret =
> openmpt_could_open_propability(openmpt_stream_get_file_callbacks(), file,
> 1.0, openmpt_logfunc, NULL);
pro...pa?
not proba?
> +fclose(file);
> +return ret ? ret * AVPROBE_SCORE_MAX : 0;
> +}
[...]
> +st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +avpriv_set_pts_info(st, 64, 1, 1000);
> +if (st->duration > 0)
> +st->duration = (int64_t)(openmpt->duration*AV_TIME_BASE+0.5);
llrint()?
[...]
> +AVInputFormat ff_libopenmpt_demuxer = {
> +.name = "libopenmpt",
> +.long_name = NULL_IF_CONFIG_SMALL("Tracker formats (libopenmpt)"),
> +.priv_data_size = sizeof(OpenMPTContext),
> +.read_probe = probe_openmpt,
> +.read_header= read_header_openmpt,
> +.read_packet= read_packet_openmpt,
> +.read_close = read_close_openmpt,
> +.read_seek = read_seek_openmpt,
> +.priv_class = &class_openmpt,
> +.extensions = "mod",
Can you extend this list of extensions? libmodplug has the following
monster:
669,abc,amf,ams,dbm,dmf,dsm,far,it,mdl,med,mid,mod,mt2,mtm,okt,psm,ptm,s3m,stm,ult,umx,xm,itgz,itr,itz,mdgz,mdr,mdz,s3gz,s3r,s3z,xmgz,xmr,xmz
Does libopenmpt documentation (or source) provide such a list?
Anyway, aside from these things, next iteration should be good to go.
Thanks.
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: Add sm2v ref10 test
On Sat, Jun 18, 2016 at 07:06:08PM +0200, Michael Niedermayer wrote: > --- > tests/fate/h264.mak|3 ++ > tests/ref/fate/h264-sm2v-ref10 | 82 > > 2 files changed, 85 insertions(+) > create mode 100644 tests/ref/fate/h264-sm2v-ref10 > thanks, that will help with the next merge I couldn't find anything in git log referencing that particular sample. Do you know if it comes from a bug report? -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 12:58:59PM +0200, Paul B Mahol wrote: > On 6/18/16, Clement Boesch wrote: > > On Sat, Jun 18, 2016 at 12:34:10PM +0200, Paul B Mahol wrote: > >> On 6/18/16, Hendrik Leppkes wrote: > >> > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes > >> > wrote: > >> >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: > >> >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: > >> > >> 0001-avfilter-add-libebur128-port.patch > >> This first patch ports libebur128 to ffmpeg. I haven't re-indented > >> these yet, so please diff `ebur128.c' and `ebur128.h' with the > >> original libebur128 files[1][2] to see what has changed. Also > >> included > >> is `queue.h' which comes from BSD, which AFAIK should be > >> distributable > >> if we decide to go this route. All these files still need their > >> license header, as libebur128 is MIT licensed and needs its own > >> copyright message. One other thing to take a look at is the section > >> with the sse2 optimizations - does FFmpeg already have a macro we > >> could use for this? > >> > >> > >> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch > >> This patch removes the libebur128 dependency for the loudnorm and > >> uses > >> the new internal ebur128 API. > >> > >> >>> > >> >>> Hi, > >> >>> > >> >>> Two updated patches attached. This is the libebur128 port and the > >> >>> af_loudnorm update. Please review if you can, as I'd like to try push > >> >>> these before v3.1. Updates to af_astats and f_ebur128 to use this > >> >>> new > >> >>> API will be coming in the near future as well. > >> >>> > >> >> > >> >> The libebur128 port still contains global state (ie. static data > >> >> initialized at runtime), as commented on in the earlier reviews can > >> >> you get rid of those and move them into a library context (ie. not > >> >> static globals)? > >> >> We really don't like global state like this because of thread safety > >> >> issues. > >> >> > >> > > >> > Also, in general I must say I really don't like the idea or the > >> > precedence this sets of porting complex external libraries into the > >> > avfilter code. > >> > Whats wrong with simply linking the library when you want to use it? > >> > This is how it works for everything else, what makes this different to > >> > warrant such a step? > >> > >> Because f_ebur128 is GPL and unlikely to get relicensed. > > > > 11:50 <@ubitux> nowadays i care much less about f_ebur128 being gpl or not > > But you are blocking other ebur128 implementation to be used in f_ebur128.c Yes but not because of licence issues. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 12:34:10PM +0200, Paul B Mahol wrote: > On 6/18/16, Hendrik Leppkes wrote: > > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes > > wrote: > >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: > >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: > > 0001-avfilter-add-libebur128-port.patch > This first patch ports libebur128 to ffmpeg. I haven't re-indented > these yet, so please diff `ebur128.c' and `ebur128.h' with the > original libebur128 files[1][2] to see what has changed. Also included > is `queue.h' which comes from BSD, which AFAIK should be distributable > if we decide to go this route. All these files still need their > license header, as libebur128 is MIT licensed and needs its own > copyright message. One other thing to take a look at is the section > with the sse2 optimizations - does FFmpeg already have a macro we > could use for this? > > > 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch > This patch removes the libebur128 dependency for the loudnorm and uses > the new internal ebur128 API. > > >>> > >>> Hi, > >>> > >>> Two updated patches attached. This is the libebur128 port and the > >>> af_loudnorm update. Please review if you can, as I'd like to try push > >>> these before v3.1. Updates to af_astats and f_ebur128 to use this new > >>> API will be coming in the near future as well. > >>> > >> > >> The libebur128 port still contains global state (ie. static data > >> initialized at runtime), as commented on in the earlier reviews can > >> you get rid of those and move them into a library context (ie. not > >> static globals)? > >> We really don't like global state like this because of thread safety > >> issues. > >> > > > > Also, in general I must say I really don't like the idea or the > > precedence this sets of porting complex external libraries into the > > avfilter code. > > Whats wrong with simply linking the library when you want to use it? > > This is how it works for everything else, what makes this different to > > warrant such a step? > > Because f_ebur128 is GPL and unlikely to get relicensed. 11:50 <@ubitux> nowadays i care much less about f_ebur128 being gpl or not -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 01:43:26AM -0500, Kyle Swanson wrote: > On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: > > > > 0001-avfilter-add-libebur128-port.patch > > This first patch ports libebur128 to ffmpeg. I haven't re-indented > > these yet, so please diff `ebur128.c' and `ebur128.h' with the > > original libebur128 files[1][2] to see what has changed. Also included > > is `queue.h' which comes from BSD, which AFAIK should be distributable > > if we decide to go this route. All these files still need their > > license header, as libebur128 is MIT licensed and needs its own > > copyright message. One other thing to take a look at is the section > > with the sse2 optimizations - does FFmpeg already have a macro we > > could use for this? > > > > > > 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch > > This patch removes the libebur128 dependency for the loudnorm and uses > > the new internal ebur128 API. > > > > Hi, > Hi, > Two updated patches attached. This is the libebur128 port and the > af_loudnorm update. Please review if you can, as I'd like to try push > these before v3.1. Updates to af_astats and f_ebur128 to use this new > API will be coming in the near future as well. I'm against using libebur128 to replace our native code in f_ebur128 so you do not need to spend effort on that. Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] two small untested VT patches
On Fri, Jun 17, 2016 at 10:49:32AM -0400, Richard Kern wrote: > > > On Jun 17, 2016, at 10:10 AM, Clément Bœsch wrote: > > > > $subj > > > > (sorry no mac available right now) > > OS X works fine. I can test iOS later today if you like, but it’s small. LGTM. > Applied, thanks -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate/h264: add test for ticket #631
On Fri, Jun 17, 2016 at 02:38:14PM +0200, Clément Bœsch wrote: > From: Clément Bœsch > > --- > tests/fate/h264.mak| 2 ++ > tests/ref/fate/h264-attachment-631 | 20 > 2 files changed, 22 insertions(+) > create mode 100644 tests/ref/fate/h264-attachment-631 > 17:56 ubitux, about 631, i dont see a better solution, so its ok applied -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/videotoolbox: fix H.264 hwaccel init issue
On Fri, Jun 17, 2016 at 09:43:09AM -0400, Richard Kern wrote: > Since ca2f19b9cc (h264: switch to h2645_parse for NAL parsing) the hwaccel > wouldn’t init (when the first h.264 frame is decoded). It was the same on OS > X and iOS - creating the decoder would return a “decoder malfunction” error. > Apple’s suggested way to create the decoder config for h.264 decoders is > CMVideoFormatDescriptionCreateFromH264ParameterSets(), and switching to this > function solved the issue on OS X and iOS. A user on IRC confirmed it worked > for them too. > So avc_info constructed from extradata in decoder_config_create() wasn't enough? (Any idea why?) "the hwaccel wouldn't init", why? Is it because the SPS/PPS NALs were somehow split out of the packets since ca2f19b9cc and thus VT never got them, or I misunderstand? -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavc/videotoolbox: remove config_info maximum capacity
From: Clément Bœsch
In case of extradata, config_info will contain two entries instead of
one.
---
libavcodec/videotoolbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 7f72612..502b2e3 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -407,7 +407,7 @@ static CFDictionaryRef
videotoolbox_decoder_config_create(CMVideoCodecType codec
AVCodecContext
*avctx)
{
CFMutableDictionaryRef config_info =
CFDictionaryCreateMutable(kCFAllocatorDefault,
- 1,
+ 0,
&kCFTypeDictionaryKeyCallBacks,
&kCFTypeDictionaryValueCallBacks);
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] two small untested VT patches
$subj (sorry no mac available right now) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavc/videotoolbox: CFRelease() session
From: Clément Bœsch
"When you are done with a decompression session you created, call
VTDecompressionSessionInvalidate to tear it down and then CFRelease to
release your object reference."
---
libavcodec/videotoolbox.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 384bb8a..7f72612 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -628,8 +628,10 @@ static void videotoolbox_default_free(AVCodecContext
*avctx)
if (videotoolbox->cm_fmt_desc)
CFRelease(videotoolbox->cm_fmt_desc);
-if (videotoolbox->session)
+if (videotoolbox->session) {
VTDecompressionSessionInvalidate(videotoolbox->session);
+CFRelease(videotoolbox->session);
+}
}
}
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate/h264: add test for ticket #631
From: Clément Bœsch --- tests/fate/h264.mak| 2 ++ tests/ref/fate/h264-attachment-631 | 20 2 files changed, 22 insertions(+) create mode 100644 tests/ref/fate/h264-attachment-631 diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak index e12263c..4ae1305 100644 --- a/tests/fate/h264.mak +++ b/tests/fate/h264.mak @@ -208,6 +208,7 @@ FATE_H264-$(call ALLYES, MOV_DEMUXER H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4t FATE_H264-$(call DEMDEC, MATROSKA, H264) += fate-h264-direct-bff FATE_H264-$(call DEMDEC, FLV, H264) += fate-h264-brokensps-2580 FATE_H264-$(call DEMDEC, MXF, H264) += fate-h264-xavc-4389 +FATE_H264-$(call DEMDEC, MOV, H264) += fate-h264-attachment-631 FATE_H264_FFPROBE-$(call DEMDEC, MATROSKA, H264) += fate-h264-dts_5frames FATE_SAMPLES_AVCONV += $(FATE_H264-yes) @@ -410,6 +411,7 @@ fate-h264-lossless: CMD = framecrc -i $(TARGET_SAM fate-h264-direct-bff: CMD = framecrc -i $(TARGET_SAMPLES)/h264/direct-bff.mkv fate-h264-brokensps-2580: CMD = framecrc -i $(TARGET_SAMPLES)/h264/brokensps.flv -vf format=yuv420p,scale=w=192:h=144 -sws_flags bitexact+bilinear fate-h264-xavc-4389: CMD = framecrc -i $(TARGET_SAMPLES)/h264/SonyXAVC_LongGOP_green_pixelation_early_Frames.MXF -pix_fmt yuv422p10le +fate-h264-attachment-631: CMD = framecrc -i $(TARGET_SAMPLES)/h264/attachment631-small.mp4 -an -max_error_rate 0.95 fate-h264-invalid-ref-mod:CMD = framecrc -i $(TARGET_SAMPLES)/h264/h264refframeregression.mp4 -an -frames 10 -pix_fmt yuv420p10le fate-h264-unescaped-extradata:CMD = framecrc -i $(TARGET_SAMPLES)/h264/unescaped_extradata.mp4 -an -frames 10 diff --git a/tests/ref/fate/h264-attachment-631 b/tests/ref/fate/h264-attachment-631 new file mode 100644 index 000..ebb5eb4 --- /dev/null +++ b/tests/ref/fate/h264-attachment-631 @@ -0,0 +1,20 @@ +#tb 0: 1/60 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 720x480 +#sar 0: 8/9 +0,598,598,1, 518400, 0xc3c0f1cf +0,603,603,1, 518400, 0x21a5df80 +0,607,607,1, 518400, 0x5b8e115b +0,611,611,1, 518400, 0x7ce09331 +0,615,615,1, 518400, 0x30ff1f1f +0,619,619,1, 518400, 0x64f091ed +0,623,623,1, 518400, 0xb3c117a2 +0,627,627,1, 518400, 0x0fbe146d +0,631,631,1, 518400, 0x75209293 +0,635,635,1, 518400, 0xa3030208 +0,639,639,1, 518400, 0x8cea6941 +0,643,643,1, 518400, 0xf41d1dbd +0,647,647,1, 518400, 0xcc9fe95e +0,651,651,1, 518400, 0xa2a60dbc +0,655,655,1, 518400, 0x3f5eecdb -- 2.8.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/videotoolbox: fix H.264 hwaccel init issue
On Fri, Jun 17, 2016 at 03:24:10AM +0200, Rick Kern wrote: > ffmpeg | branch: master | Rick Kern | Wed Jun 1 21:40:22 > 2016 -0400| [8e47a99f576da10b2a36e33b6b9acbf1c2da7485] | committer: Rick Kern > > lavc/videotoolbox: fix H.264 hwaccel init issue > > Fixes VTDecompressionSessionCreate() error. > Please reference the closing Ticket next time, and mention that it's a regression. Also, can you elaborate on why this fix is required? What was wrong exactly previously, and why was it working? It feels like it's including more than a fix. (BTW, do you happen to be on IRC?) Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/img2dec: add pnm pipe demuxers
From: Clément Bœsch
---
Still unsure about the FATE changes.
Also couldn't test pgm vs pgmyuv due to a crash
---
libavformat/Makefile| 5 +
libavformat/allformats.c| 5 +
libavformat/img2dec.c | 55 +
tests/ref/seek/lavf-pbmpipe | 50 ++---
tests/ref/seek/lavf-pgmpipe | 50 ++---
tests/ref/seek/lavf-ppmpipe | 50 ++---
6 files changed, 146 insertions(+), 69 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 481f3b1..12d8f6b 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -226,9 +226,14 @@ OBJS-$(CONFIG_IMAGE_EXR_PIPE_DEMUXER) += img2dec.o
img2.o
OBJS-$(CONFIG_IMAGE_J2K_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_JPEG_PIPE_DEMUXER)+= img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_JPEGLS_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PAM_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PBM_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PCX_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PGMYUV_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PGM_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PICTOR_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PNG_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PPM_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_QDRAW_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ddf540c..d490cc4 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -356,9 +356,14 @@ void av_register_all(void)
REGISTER_DEMUXER (IMAGE_J2K_PIPE,image_j2k_pipe);
REGISTER_DEMUXER (IMAGE_JPEG_PIPE, image_jpeg_pipe);
REGISTER_DEMUXER (IMAGE_JPEGLS_PIPE, image_jpegls_pipe);
+REGISTER_DEMUXER (IMAGE_PAM_PIPE,image_pam_pipe);
+REGISTER_DEMUXER (IMAGE_PBM_PIPE,image_pbm_pipe);
REGISTER_DEMUXER (IMAGE_PCX_PIPE,image_pcx_pipe);
+REGISTER_DEMUXER (IMAGE_PGMYUV_PIPE, image_pgmyuv_pipe);
+REGISTER_DEMUXER (IMAGE_PGM_PIPE,image_pgm_pipe);
REGISTER_DEMUXER (IMAGE_PICTOR_PIPE, image_pictor_pipe);
REGISTER_DEMUXER (IMAGE_PNG_PIPE,image_png_pipe);
+REGISTER_DEMUXER (IMAGE_PPM_PIPE,image_ppm_pipe);
REGISTER_DEMUXER (IMAGE_QDRAW_PIPE, image_qdraw_pipe);
REGISTER_DEMUXER (IMAGE_SGI_PIPE,image_sgi_pipe);
REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 1b0e608..9cbc9dc 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -862,6 +862,56 @@ static int webp_probe(AVProbeData *p)
return 0;
}
+static int pnm_magic_check(const AVProbeData *p, int magic)
+{
+const uint8_t *b = p->buf;
+
+return b[0] == 'P' && b[1] == magic + '0';
+}
+
+static inline int pnm_probe(const AVProbeData *p)
+{
+const uint8_t *b = p->buf;
+
+while (b[2] == '\r')
+b++;
+if (b[2] == '\n' && (b[3] == '#' || (b[3] >= '0' && b[3] <= '9')))
+return AVPROBE_SCORE_EXTENSION + 2;
+return 0;
+}
+
+static int pbm_probe(AVProbeData *p)
+{
+return pnm_magic_check(p, 1) || pnm_magic_check(p, 4) ? pnm_probe(p) : 0;
+}
+
+static inline int pgmx_probe(AVProbeData *p)
+{
+return pnm_magic_check(p, 2) || pnm_magic_check(p, 5) ? pnm_probe(p) : 0;
+}
+
+static int pgm_probe(AVProbeData *p)
+{
+int ret = pgmx_probe(p);
+return ret && !av_match_ext(p->filename, "pgmyuv") ? ret : 0;
+}
+
+static int pgmyuv_probe(AVProbeData *p)
+{
+int ret = pgmx_probe(p);
+return ret && av_match_ext(p->filename, "pgmyuv") ? ret : 0;
+}
+
+static int ppm_probe(AVProbeData *p)
+{
+return pnm_magic_check(p, 3) || pnm_magic_check(p, 6) ? pnm_probe(p) : 0;
+}
+
+static int pam_probe(AVProbeData *p)
+{
+return pnm_magic_check(p, 7) ? pnm_probe(p) : 0;
+}
+
#define IMAGEAUTO_DEMUXER(imgname, codecid)\
static const AVClass imgname ## _class = {\
.class_name = AV_STRINGIFY(imgname) " demuxer",\
@@ -888,9 +938,14 @@ IMAGEAUTO_DEMUXER(exr, AV_CODEC_ID_EXR)
IMAGEAUTO_DEMUXER(j2k, AV_CODEC_ID_JPEG2000)
IMAGEAUTO_DEMUXER(jpeg,AV_CODEC_ID_MJPEG)
IMAGEAUTO_DEMUXER(jpegls, AV_CODEC_ID_JPEGLS)
+IMAGEAUTO_DEMUXER(pam, AV_CODEC_ID_PAM)
+IMAGEAUTO_DEMUXER(pbm, AV_CODEC_ID_PBM)
IMAGEAUTO_DEMUXER(pcx, AV_CODEC_ID_PCX)
+IMAGEAUTO_DEMUXER(pgm, AV_CODEC_ID_PGM)
+IMAGEAUTO_DEMUXER(pgmyuv, AV_CODEC_ID_PGMYUV)
IMAGEAUTO_DEMUXER(pictor, AV_CODEC_ID_PICTOR)
IMAGEAUTO_DEMUXE
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add ppm pipe demuxer
On Fri, Jun 10, 2016 at 04:28:55AM +0200, Michael Niedermayer wrote: > On Thu, Jun 09, 2016 at 04:35:02PM +0200, Clément Bœsch wrote: > > On Thu, Jun 09, 2016 at 03:59:30PM +0200, Clément Bœsch wrote: > > > On Thu, Jun 09, 2016 at 01:35:19PM +, Carl Eugen Hoyos wrote: > > > > Clément Bœsch pkh.me> writes: > > > > > > > > > +if (b[3] == '#') > > > > > +return AVPROBE_SCORE_EXTENSION + 1; > > > > > +if (b[3] >= '0' && b[3] <= '9') > > > > > +return AVPROBE_SCORE_MAX - 1; > > > > > > > > Imo, this should be: > > > > if (b[3] == '#' || (b[3] >= '0' && b[3] <= '9')) > > > > return AVPROBE_SCORE_EXTENSION + 2; > > > > or similar > > > > > > > > I count 37 and 34 bits which is only a little more than > > > > the usual 32 bit for EXTENSION + 1. > > > > > > > > > > Sure. Changed locally, will push soon, thanks. > > > > > > > For some reasons it makes seeking with pgm somehow working. The reference > > test doesn't look that great IIUC, but seeking in these file with ffplay > > is fine AFAICT. > > it seems it messes with pgmyuv detection (which i think was filename > extension based) > > example: > ./ffmpeg -i matrixbench_mpeg2.mpg -pix_fmt yuv420p16be -vframes 1 test.pgmyuv > ./ffplay-ref test.pgmyuv > Input #0, image2, from 'test.pgmyuv':B vq=0KB sq=0B f=0/0 > Duration: 00:00:00.04, start: 0.00, bitrate: 248835 kb/s > Stream #0:0: Video: pgmyuv, yuv420p16le, 720x576, 25 tbr, 25 tbn > This currently crashes for me with git/master: pnm_decode_frame (avctx=, data=0x7fffe8012f40, got_frame=0x7fffecbe89cc, avpkt=) at src/libavcodec/pnmdec.c:225 225 v = av_be2ne16(((uint16_t *)s->bytestream)[j]); (gdb) bt #0 pnm_decode_frame (avctx=, data=0x7fffe8012f40, got_frame=0x7fffecbe89cc, avpkt=) at src/libavcodec/pnmdec.c:225 #1 0x00cde5e8 in avcodec_decode_video2 (avctx=avctx@entry=0x7fffe8000e00, picture=0x7fffe8012f40, got_picture_ptr=got_picture_ptr@entry=0x7fffecbe89cc, avpkt=avpkt@entry=0x7fffecbe8ac0) at src/libavcodec/utils.c:2217 #2 0x00cdf1c0 in do_decode (avctx=avctx@entry=0x7fffe8000e00, pkt=0x7fffecbe8ac0) at src/libavcodec/utils.c:2727 #3 0x00ce014b in avcodec_send_packet (avctx=avctx@entry=0x7fffe8000e00, avpkt=, avpkt@entry=0x7fffecbe8ac0) at src/libavcodec/utils.c:2813 #4 0x00710cf5 in try_decode_frame (s=s@entry=0x7fffe8009240, st=st@entry=0x7fffe8007500, avpkt=avpkt@entry=0x7fffecbe8c40, options=) at src/libavformat/utils.c:2899 #5 0x007194d4 in avformat_find_stream_info (ic=0x7fffe8009240, options=0x7fffe8007880) at src/libavformat/utils.c:3595 #6 0x00487d08 in read_thread (arg=0x70ae9040) at src/ffplay.c:2880 #7 0x7647afe8 in ?? () from /usr/lib/libSDL-1.2.so.0 #8 0x764bc8a9 in ?? () from /usr/lib/libSDL-1.2.so.0 #9 0x76254484 in start_thread () from /usr/lib/libpthread.so.0 #10 0x756436dd in clone () from /usr/lib/libc.so.6 [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/srtdec: fix probing files with negative first timestamps
On Thu, Jun 09, 2016 at 11:01:54PM -0500, Rodger Combs wrote: > --- > libavformat/srtdec.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c > index 585aa6a..9ab7a4e 100644 > --- a/libavformat/srtdec.c > +++ b/libavformat/srtdec.c > @@ -52,7 +52,10 @@ static int srt_probe(AVProbeData *p) > /* Check if the next line matches a SRT timestamp */ > if (ff_subtitles_read_line(&tr, buf, sizeof(buf)) < 0) > return 0; > -if (buf[0] >= '0' && buf[0] <= '9' && strstr(buf, " --> ") > +pbuf = buf; > +if (buf[0] == '-') > + pbuf++; > +if (pbuf[0] >= '0' && pbuf[0] <= '9' && strstr(buf, " --> ") > && sscanf(buf, "%*d:%*d:%*d%*1[,.]%*d --> %*d:%*d:%*d%*1[,.]%d", &v) > == 1) > return AVPROBE_SCORE_MAX; Wrong indent but looks fine functionally. Thanks -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tools: update normalize script example to use loudnorm
On Wed, Jun 15, 2016 at 09:40:41AM -0500, Kyle Swanson wrote: > On Mon, Jun 13, 2016 at 3:23 AM, Clément Bœsch wrote: > > On Sun, Jun 12, 2016 at 10:44:15PM -0500, Kyle Swanson wrote: > >> Signed-off-by: Kyle Swanson > >> --- > >> tools/normalize.py | 33 -- > >> tools/normalize.rb | 60 > >> ++ > >> 2 files changed, 60 insertions(+), 33 deletions(-) > >> delete mode 100755 tools/normalize.py > >> create mode 100644 tools/normalize.rb > >> > > > > Please de not delete normalize.py > > We have a filter that does this now, if we're distributing a loudness > normalization script it should be using the loudnorm filter. > Add your script if you want, but keep the current one in place. You can also rename them normalize-ebur128 and normalize-lourdnorm. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] PATCH: dshow: don't add two instances of same device to graphs
On Wed, Jun 15, 2016 at 02:54:09AM -0600, Roger Pack wrote: > A handful of devices don't support this, and the rest work fine with it :) > > -roger- > From e724d7f169bcae3217455cd88f9c023d275d367a Mon Sep 17 00:00:00 2001 > From: rogerdpack > Date: Wed, 15 Jun 2016 02:17:11 -0600 > Subject: [PATCH] dshow: don't add two instances of same device to graphs > > Signed-off-by: rogerdpack > --- > libavdevice/dshow.c | 37 ++--- > libavdevice/dshow_capture.h | 2 ++ > 2 files changed, 32 insertions(+), 7 deletions(-) > > diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c > index 5f2cad7..e1ac855 100644 > --- a/libavdevice/dshow.c > +++ b/libavdevice/dshow.c > @@ -108,6 +108,10 @@ dshow_read_close(AVFormatContext *s) > av_freep(&ctx->device_name[0]); > if (ctx->device_name[1]) > av_freep(&ctx->device_name[1]); > +if (ctx->device_unique_name[0]) > +av_freep(&ctx->device_unique_name[0]); > +if (ctx->device_unique_name[1]) > +av_freep(&ctx->device_unique_name[1]); I can't comment the rest of the patch, but please remove the ifs. They are, and always were, totally useless. Just like those above. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] lavc/h264: move green meta logging out of the sei decoding
On Tue, Jun 14, 2016 at 12:01:25AM +0200, Hendrik Leppkes wrote: > On Mon, Jun 13, 2016 at 11:02 PM, Clément Bœsch wrote: > > This will simplify the next Libav merge where SEI decoding doesn't have > > access to the debug level anymore. > > This whole business looks rather fragile and wtf'ish, but its better > then before and should be fine. So the entire set LGTM. patchset applied, thanks -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/os_support.h: Fix for unicode filenames on windows.
On Tue, Jun 14, 2016 at 07:08:58AM +1000, Matt Oliver wrote:
> On 13 June 2016 at 18:29, Benoit Fouet wrote:
>
> > Hi,
> >
> >
> >
> > On 13/06/2016 10:21, Clément Bœsch wrote:
> >
> >> On Mon, Jun 13, 2016 at 05:50:18AM +0200, Matt Oliver wrote:
> >>
> >>> ffmpeg | branch: master | Matt Oliver | Mon Jun
> >>> 6 17:04:39 2016 +1000| [37787f261639c53998487400e874741c17e85fc6] |
> >>> committer: Matt Oliver
> >>>
> >>> lavf/os_support.h: Fix for unicode filenames on windows.
> >>>
> >>> Fixes #819 #5256 #5281
> >>>
> >>> Signed-off-by: Matt Oliver
> >>>
> >>>
> >>>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=37787f261639c53998487400e874741c17e85fc6
> >>>>
> >>> ---
> >>>
> >>> libavformat/file.c |4
> >>> libavformat/os_support.h | 24
> >>> 2 files changed, 28 insertions(+)
> >>>
> >>> diff --git a/libavformat/file.c b/libavformat/file.c
> >>> index 5765ce7..264542a 100644
> >>> --- a/libavformat/file.c
> >>> +++ b/libavformat/file.c
> >>> @@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
> >>> ret |= AVIO_FLAG_WRITE;
> >>> #else
> >>> struct stat st;
> >>> +# ifndef _WIN32
> >>> ret = stat(filename, &st);
> >>> +# else
> >>> +ret = win32_stat(filename, &st);
> >>> +# endif
> >>>
> >> why this chunk?
> >>
> >> if (ret < 0)
> >>> return AVERROR(errno);
> >>> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> >>> index a332911..9e312a5 100644
> >>> --- a/libavformat/os_support.h
> >>> +++ b/libavformat/os_support.h
> >>> @@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
> >>> DEF_FS_FUNCTION(mkdir, _wmkdir, _mkdir)
> >>> DEF_FS_FUNCTION(rmdir, _wrmdir , _rmdir)
> >>> +#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
> >>> +static inline int win32_##name(const char *filename_utf8, partype par) \
> >>> +{ \
> >>> +wchar_t *filename_w; \
> >>> +int ret; \
> >>> + \
> >>> +if (utf8towchar(filename_utf8, &filename_w)) \
> >>> +return -1;\
> >>> +if (!filename_w) \
> >>> +goto fallback;\
> >>> + \
> >>> +ret = wfunc(filename_w, par); \
> >>> +av_free(filename_w); \
> >>> +return ret; \
> >>> + \
> >>> +fallback: \
> >>> +/* filename may be be in CP_ACP */\
> >>> +return afunc(filename_utf8, par); \
> >>> +}
> >>> +
> >>> +DEF_FS_FUNCTION2(access, _waccess, _access, int)
> >>> +DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
> >>> +
> >>> static inline int win32_rename(const char *src_utf8, const char
> >>> *dest_utf8)
> >>> {
> >>> wchar_t *src_w, *dest_w;
> >>> @@ -231,6 +254,7 @@ fallback:
> >>> #define rename win32_rename
> >>> #define rmdir win32_rmdir
> >>> #define unlink win32_unlink
> >>> +#define access win32_access
> >>>
> >>>
> >> ...instead of #define stat win32_stat here?
> >>
> >
> > as already noted by someone else, this should be
> > #define stat(a, b) win32_stat((a), (b))
> > in order not to conflict with "struct stat" definition.
> >
>
> As stated in the original patch thread a define for the win32_stat function
> can not be used as there is already a define for the 'stat' struct.
> So using:
> #define stat(a, b) win32_stat((a), (b))
> clashes with the existing
> #define stat _stat64
>
> Since there is a stat function and a stat struct then a macro can only be
> used for one of them and there is already an object macro for the stat
> struct.
> If the suggested "#define stat(a, b) win32_stat((a), (b))" was added this
> overrides the struct macro causing the compiler not to use _stat64 and use
> a 32 variant instead which results in memory corruption.
Sorry, I wasn't following the thread, I just happened to read cvslog.
A comment in the source would probably be welcome though, no one is going
to be aware of these discussions in the future.
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] lavc/h264_sei: fix broken style around green metadata code
---
libavcodec/h264.h | 10 +-
libavcodec/h264_sei.c | 30 ++
2 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index 8c7a537..b156805 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -293,13 +293,13 @@ typedef struct FPA {
} FPA;
/**
- * Green MetaData Information Type
+ * Green MetaData Information Type
*/
typedef struct H264SEIGreenMetaData {
-uint8_t green_metadata_type;
-uint8_t period_type;
-uint16_t num_seconds;
-uint16_t num_pictures;
+uint8_t green_metadata_type;
+uint8_t period_type;
+uint16_t num_seconds;
+uint16_t num_pictures;
uint8_t percent_non_zero_macroblocks;
uint8_t percent_intra_coded_macroblocks;
uint8_t percent_six_tap_filtering;
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index ab98c27..8fcaa61 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -363,28 +363,26 @@ static int decode_display_orientation(H264Context *h)
return 0;
}
-static int decode_GreenMetadata(H264SEIGreenMetaData *h, GetBitContext *gb)
+static int decode_green_metadata(H264SEIGreenMetaData *h, GetBitContext *gb)
{
-h->green_metadata_type=get_bits(gb, 8);
+h->green_metadata_type = get_bits(gb, 8);
-if (h->green_metadata_type==0){
-h->period_type=get_bits(gb, 8);
+if (h->green_metadata_type == 0) {
+h->period_type = get_bits(gb, 8);
-if (h->period_type==2){
+if (h->period_type == 2)
h->num_seconds = get_bits(gb, 16);
-}
-else if (h->period_type==3){
+else if (h->period_type == 3)
h->num_pictures = get_bits(gb, 16);
-}
-h->percent_non_zero_macroblocks=get_bits(gb, 8);
-h->percent_intra_coded_macroblocks=get_bits(gb, 8);
-h->percent_six_tap_filtering=get_bits(gb, 8);
-h->percent_alpha_point_deblocking_instance=get_bits(gb, 8);
+h->percent_non_zero_macroblocks= get_bits(gb, 8);
+h->percent_intra_coded_macroblocks = get_bits(gb, 8);
+h->percent_six_tap_filtering = get_bits(gb, 8);
+h->percent_alpha_point_deblocking_instance = get_bits(gb, 8);
-}else if( h->green_metadata_type==1){
-h->xsd_metric_type=get_bits(gb, 8);
-h->xsd_metric_value=get_bits(gb, 16);
+} else if (h->green_metadata_type == 1) {
+h->xsd_metric_type = get_bits(gb, 8);
+h->xsd_metric_value = get_bits(gb, 16);
}
return 0;
@@ -443,7 +441,7 @@ int ff_h264_decode_sei(H264Context *h)
ret = decode_display_orientation(h);
break;
case SEI_TYPE_GREEN_METADATA:
-ret = decode_GreenMetadata(&h->sei_green_metadata, &h->gb);
+ret = decode_green_metadata(&h->sei_green_metadata, &h->gb);
break;
default:
av_log(h->avctx, AV_LOG_DEBUG, "unknown SEI type %d\n", type);
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] lavc/h264: move green meta logging out of the sei decoding
This will simplify the next Libav merge where SEI decoding doesn't have
access to the debug level anymore.
---
libavcodec/h264.c | 30 ++
libavcodec/h264_sei.c | 33 -
2 files changed, 30 insertions(+), 33 deletions(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 367f6bf..46eaec2 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -959,6 +959,34 @@ static int get_last_needed_nal(H264Context *h)
return nals_needed;
}
+static void debug_green_metadata(const GreenMetaData *gm, void *logctx)
+{
+av_log(logctx, AV_LOG_DEBUG, "Green Metadata Info SEI message\n");
+av_log(logctx, AV_LOG_DEBUG, " green_metadata_type: %d\n",
gm->green_metadata_type);
+
+if (gm->green_metadata_type == 0) {
+av_log(logctx, AV_LOG_DEBUG, " green_metadata_period_type: %d\n",
gm->period_type);
+
+if (gm->period_type == 2)
+av_log(logctx, AV_LOG_DEBUG, " green_metadata_num_seconds: %d\n",
gm->num_seconds);
+else if (gm->period_type == 3)
+av_log(logctx, AV_LOG_DEBUG, " green_metadata_num_pictures:
%d\n", gm->num_pictures);
+
+av_log(logctx, AV_LOG_DEBUG, " SEI GREEN Complexity Metrics: %f %f %f
%f\n",
+ (float)gm->percent_non_zero_macroblocks/255,
+ (float)gm->percent_intra_coded_macroblocks/255,
+ (float)gm->percent_six_tap_filtering/255,
+ (float)gm->percent_alpha_point_deblocking_instance/255);
+
+} else if (gm->green_metadata_type == 1) {
+av_log(logctx, AV_LOG_DEBUG, " xsd_metric_type: %d\n",
gm->xsd_metric_type);
+
+if (gm->xsd_metric_type == 0)
+av_log(logctx, AV_LOG_DEBUG, " xsd_metric_value: %f\n",
+ (float)gm->xsd_metric_value/100);
+}
+}
+
static int decode_nal_units(H264Context *h, const uint8_t *buf, int buf_size,
int parse_extradata)
{
@@ -1141,6 +1169,8 @@ again:
case NAL_SEI:
h->gb = nal->gb;
ret = ff_h264_decode_sei(h);
+if (avctx->debug & FF_DEBUG_GREEN_MD)
+debug_green_metadata(&h->sei_green_metadata, h->avctx);
if (ret < 0 && (h->avctx->err_recognition & AV_EF_EXPLODE))
goto end;
break;
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 3c6d988..b23878c 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -365,33 +365,16 @@ static int decode_display_orientation(H264Context *h)
static int decode_GreenMetadata(H264Context *h)
{
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "Green Metadata Info SEI
message\n");
-
h->sei_green_metadata.green_metadata_type=get_bits(&h->gb, 8);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_type
= %d\n",
- h->sei_green_metadata.green_metadata_type);
-
if (h->sei_green_metadata.green_metadata_type==0){
h->sei_green_metadata.period_type=get_bits(&h->gb, 8);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_period_type
= %d\n",
- h->sei_green_metadata.period_type);
-
if (h->sei_green_metadata.period_type==2){
h->sei_green_metadata.num_seconds = get_bits(&h->gb, 16);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_num_seconds
= %d\n",
- h->sei_green_metadata.num_seconds);
}
else if (h->sei_green_metadata.period_type==3){
h->sei_green_metadata.num_pictures = get_bits(&h->gb, 16);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_num_pictures
= %d\n",
- h->sei_green_metadata.num_pictures);
}
h->sei_green_metadata.percent_non_zero_macroblocks=get_bits(&h->gb, 8);
@@ -399,25 +382,9 @@ static int decode_GreenMetadata(H264Context *h)
h->sei_green_metadata.percent_six_tap_filtering=get_bits(&h->gb, 8);
h->sei_green_metadata.percent_alpha_point_deblocking_instance=get_bits(&h->gb,
8);
-if (h->avctx->debug & FF_DEBUG_GREEN_MD)
-av_log(h->avctx, AV_LOG_DEBUG, "SEI GREEN Complexity Metrics
= %f %f %f %f\n",
-
(float)h->sei_green_metadata.percent_non_zero_macroblocks/255,
-
(float)h->sei_green_metadata.percent_intra_coded_macroblocks/255,
-
(float)h->sei_green_metadata.percent_six_tap_filtering/255,
-
(float)h->sei_green_metadata.percent_alpha_point_deblocking_
[FFmpeg-devel] [PATCH 2/4] lavc/h264_sei: reduce scope of parameters for green meta decode
This is again will help the merge as ff_h264_decode_sei will not have
access to H264Context anymore.
---
libavcodec/h264_sei.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index b23878c..46d1814 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -363,28 +363,28 @@ static int decode_display_orientation(H264Context *h)
return 0;
}
-static int decode_GreenMetadata(H264Context *h)
+static int decode_GreenMetadata(GreenMetaData *h, GetBitContext *gb)
{
-h->sei_green_metadata.green_metadata_type=get_bits(&h->gb, 8);
+h->green_metadata_type=get_bits(gb, 8);
-if (h->sei_green_metadata.green_metadata_type==0){
-h->sei_green_metadata.period_type=get_bits(&h->gb, 8);
+if (h->green_metadata_type==0){
+h->period_type=get_bits(gb, 8);
-if (h->sei_green_metadata.period_type==2){
-h->sei_green_metadata.num_seconds = get_bits(&h->gb, 16);
+if (h->period_type==2){
+h->num_seconds = get_bits(gb, 16);
}
-else if (h->sei_green_metadata.period_type==3){
-h->sei_green_metadata.num_pictures = get_bits(&h->gb, 16);
+else if (h->period_type==3){
+h->num_pictures = get_bits(gb, 16);
}
-h->sei_green_metadata.percent_non_zero_macroblocks=get_bits(&h->gb, 8);
-h->sei_green_metadata.percent_intra_coded_macroblocks=get_bits(&h->gb,
8);
-h->sei_green_metadata.percent_six_tap_filtering=get_bits(&h->gb, 8);
-
h->sei_green_metadata.percent_alpha_point_deblocking_instance=get_bits(&h->gb,
8);
+h->percent_non_zero_macroblocks=get_bits(gb, 8);
+h->percent_intra_coded_macroblocks=get_bits(gb, 8);
+h->percent_six_tap_filtering=get_bits(gb, 8);
+h->percent_alpha_point_deblocking_instance=get_bits(gb, 8);
-}else if( h->sei_green_metadata.green_metadata_type==1){
-h->sei_green_metadata.xsd_metric_type=get_bits(&h->gb, 8);
-h->sei_green_metadata.xsd_metric_value=get_bits(&h->gb, 16);
+}else if( h->green_metadata_type==1){
+h->xsd_metric_type=get_bits(gb, 8);
+h->xsd_metric_value=get_bits(gb, 16);
}
return 0;
@@ -443,7 +443,7 @@ int ff_h264_decode_sei(H264Context *h)
ret = decode_display_orientation(h);
break;
case SEI_TYPE_GREEN_METADATA:
-ret = decode_GreenMetadata(h);
+ret = decode_GreenMetadata(&h->sei_green_metadata, &h->gb);
break;
default:
av_log(h->avctx, AV_LOG_DEBUG, "unknown SEI type %d\n", type);
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] lavc/h264: rename GreenMetaData to H264SEIGreenMetaData
Reduces diff for the next merge with Libav.
---
libavcodec/h264.c | 2 +-
libavcodec/h264.h | 6 +++---
libavcodec/h264_sei.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 46eaec2..795e599 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -959,7 +959,7 @@ static int get_last_needed_nal(H264Context *h)
return nals_needed;
}
-static void debug_green_metadata(const GreenMetaData *gm, void *logctx)
+static void debug_green_metadata(const H264SEIGreenMetaData *gm, void *logctx)
{
av_log(logctx, AV_LOG_DEBUG, "Green Metadata Info SEI message\n");
av_log(logctx, AV_LOG_DEBUG, " green_metadata_type: %d\n",
gm->green_metadata_type);
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index da8a92f..8c7a537 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -295,7 +295,7 @@ typedef struct FPA {
/**
* Green MetaData Information Type
*/
-typedef struct GreenMetaData {
+typedef struct H264SEIGreenMetaData {
uint8_t green_metadata_type;
uint8_t period_type;
uint16_t num_seconds;
@@ -306,7 +306,7 @@ typedef struct GreenMetaData {
uint8_t percent_alpha_point_deblocking_instance;
uint8_t xsd_metric_type;
uint16_t xsd_metric_value;
-} GreenMetaData;
+} H264SEIGreenMetaData;
/**
* Memory management control operation opcode.
@@ -831,7 +831,7 @@ typedef struct H264Context {
qpel_mc_func (*qpel_avg)[16];
/*Green Metadata */
-GreenMetaData sei_green_metadata;
+H264SEIGreenMetaData sei_green_metadata;
} H264Context;
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 46d1814..ab98c27 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -363,7 +363,7 @@ static int decode_display_orientation(H264Context *h)
return 0;
}
-static int decode_GreenMetadata(GreenMetaData *h, GetBitContext *gb)
+static int decode_GreenMetadata(H264SEIGreenMetaData *h, GetBitContext *gb)
{
h->green_metadata_type=get_bits(gb, 8);
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264_sei: fix green metadata typo
On Mon, Jun 13, 2016 at 07:51:39PM +0200, Michael Niedermayer wrote: > On Mon, Jun 13, 2016 at 05:42:00PM +0200, Clément Bœsch wrote: > > From: Clément Bœsch > > > > --- > > I'm guessing this is what was wanted. > > --- > > libavcodec/h264_sei.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > should be ok, i found a draft that matches this but not the > number of bits oddly > > either way patch should be better than before > thanks, applied -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/h264_sei: fix green metadata typo
From: Clément Bœsch
---
I'm guessing this is what was wanted.
---
libavcodec/h264_sei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index bdc5c9f..3c6d988 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -381,7 +381,7 @@ static int decode_GreenMetadata(H264Context *h)
av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_period_type
= %d\n",
h->sei_green_metadata.period_type);
-if (h->sei_green_metadata.green_metadata_type==2){
+if (h->sei_green_metadata.period_type==2){
h->sei_green_metadata.num_seconds = get_bits(&h->gb, 16);
if (h->avctx->debug & FF_DEBUG_GREEN_MD)
av_log(h->avctx, AV_LOG_DEBUG, "green_metadata_num_seconds
= %d\n",
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
On Sun, Jun 12, 2016 at 10:58:37PM +0200, Paul B Mahol wrote: > Hi, > > As requested in the IRC meeting I hereby request for the > voting committee to begin voting on whatever to ban Carl > Eugen Hoyos from mailing list, trac and IRC for 4 months, > starting after the voting has finished. > > Voting will last 7 days from now. > In order for the vote to pass, at least 50% of all votes > from committee need to agree to do so. > > All developers and users are welcome to write about their > experiences with Carl. I'm against for several reasons: - there is not a single reason provided in this mail (not saying there isn't any but it seems you're expecting people to provide them) - 4 months is extremely long, there is no proof Carl Eugen is a criminal - I don't think we should consider the CoC retroactive While I disagree with Carl Eugen on various aspects (mainly the toxic attitude towards certain other developers and at times users), this chastisement request sounds completely out of the reality, and illustrate very well the problem of overreacting in this community. Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tools: update normalize script example to use loudnorm
On Sun, Jun 12, 2016 at 10:44:15PM -0500, Kyle Swanson wrote: > Signed-off-by: Kyle Swanson > --- > tools/normalize.py | 33 -- > tools/normalize.rb | 60 > ++ > 2 files changed, 60 insertions(+), 33 deletions(-) > delete mode 100755 tools/normalize.py > create mode 100644 tools/normalize.rb > Please de not delete normalize.py Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/os_support.h: Fix for unicode filenames on windows.
On Mon, Jun 13, 2016 at 05:50:18AM +0200, Matt Oliver wrote:
> ffmpeg | branch: master | Matt Oliver | Mon Jun 6
> 17:04:39 2016 +1000| [37787f261639c53998487400e874741c17e85fc6] | committer:
> Matt Oliver
>
> lavf/os_support.h: Fix for unicode filenames on windows.
>
> Fixes #819 #5256 #5281
>
> Signed-off-by: Matt Oliver
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=37787f261639c53998487400e874741c17e85fc6
> ---
>
> libavformat/file.c |4
> libavformat/os_support.h | 24
> 2 files changed, 28 insertions(+)
>
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 5765ce7..264542a 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
> ret |= AVIO_FLAG_WRITE;
> #else
> struct stat st;
> +# ifndef _WIN32
> ret = stat(filename, &st);
> +# else
> +ret = win32_stat(filename, &st);
> +# endif
why this chunk?
> if (ret < 0)
> return AVERROR(errno);
>
> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> index a332911..9e312a5 100644
> --- a/libavformat/os_support.h
> +++ b/libavformat/os_support.h
> @@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
> DEF_FS_FUNCTION(mkdir, _wmkdir, _mkdir)
> DEF_FS_FUNCTION(rmdir, _wrmdir , _rmdir)
>
> +#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
> +static inline int win32_##name(const char *filename_utf8, partype par) \
> +{ \
> +wchar_t *filename_w; \
> +int ret; \
> + \
> +if (utf8towchar(filename_utf8, &filename_w)) \
> +return -1;\
> +if (!filename_w) \
> +goto fallback;\
> + \
> +ret = wfunc(filename_w, par); \
> +av_free(filename_w); \
> +return ret; \
> + \
> +fallback: \
> +/* filename may be be in CP_ACP */\
> +return afunc(filename_utf8, par); \
> +}
> +
> +DEF_FS_FUNCTION2(access, _waccess, _access, int)
> +DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
> +
> static inline int win32_rename(const char *src_utf8, const char *dest_utf8)
> {
> wchar_t *src_w, *dest_w;
> @@ -231,6 +254,7 @@ fallback:
> #define rename win32_rename
> #define rmdir win32_rmdir
> #define unlink win32_unlink
> +#define access win32_access
>
...instead of #define stat win32_stat here?
Regards,
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: add libopenmpt demuxer
On Sun, Jun 12, 2016 at 02:43:10AM +0100, Josh de Kock wrote:
> ---
> configure| 4 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/libopenmpt.c | 185
> +++
> 4 files changed, 191 insertions(+)
> create mode 100644 libavformat/libopenmpt.c
>
> diff --git a/configure b/configure
> index 7c463a5..a74aaab 100755
> --- a/configure
> +++ b/configure
> @@ -248,6 +248,7 @@ External library support:
>--enable-libopencv enable video filtering via libopencv [no]
>--enable-libopenh264 enable H.264 encoding via OpenH264 [no]
>--enable-libopenjpeg enable JPEG 2000 de/encoding via OpenJPEG [no]
> + --enable-libopenmpt enable decoding tracked mod files via libopenmpt
> [no]
libopenmpt is supposed to replace libmodplug support all kind of trackers,
not only MOD.
>--enable-libopus enable Opus de/encoding via libopus [no]
>--enable-libpulseenable Pulseaudio input via libpulse [no]
>--enable-librubberband enable rubberband needed for rubberband filter
> [no]
> @@ -1495,6 +1496,7 @@ EXTERNAL_LIBRARY_LIST="
> libopencv
> libopenh264
> libopenjpeg
> +libopenmpt
> libopus
> libpulse
> librtmp
> @@ -2741,6 +2743,7 @@ libopencore_amrwb_decoder_deps="libopencore_amrwb"
> libopenh264_encoder_deps="libopenh264"
> libopenjpeg_decoder_deps="libopenjpeg"
> libopenjpeg_encoder_deps="libopenjpeg"
> +libopenmpt_demuxer_deps="libopenmpt"
> libopus_decoder_deps="libopus"
> libopus_encoder_deps="libopus"
> libopus_encoder_select="audio_frame_queue"
> @@ -5633,6 +5636,7 @@ enabled libopenjpeg && { check_lib
> openjpeg-2.1/openjpeg.h opj_version -lo
> check_lib openjpeg-1.5/openjpeg.h opj_version
> -lopenjpeg -DOPJ_STATIC ||
> check_lib openjpeg.h opj_version -lopenjpeg
> -DOPJ_STATIC ||
> die "ERROR: libopenjpeg not found"; }
> +enabled libopenmpt&& require libopenmpt libopenmpt/libopenmpt.h
> openmpt_module_create -lopenmpt -lstdc++
openmpt is distributed with pkg-config so please use require_pkg_config.
And then you shouldn't need -lstdc++ if the .pc is properly done.
[...]
> +/**
> +* @file
> +* libopenmpt demuxer
> +*/
not really useful
> +
> +#include
> +#include "libavutil/avstring.h"
> +#include "libavutil/eval.h"
doesn't look necessary (maybe check the other includes)
> +#include "libavutil/opt.h"
> +#include "avformat.h"
> +#include "internal.h"
> +
> +typedef struct OpenMPTContext {
> +const AVClass *class;
> +openmpt_module *module;
> +
> +int channels;
> +double length;
better call this duration for consistency
> +/* options */
> +int sample_rate;
> +} OpenMPTContext;
> +
> +#define OFFSET(x) offsetof(OpenMPTContext, x)
> +#define A AV_OPT_FLAG_AUDIO_PARAM
> +#define D AV_OPT_FLAG_DECODING_PARAM
> +static const AVOption options[] = {
> +{"sample_rate", "set sample rate", OFFSET(sample_rate), AV_OPT_TYPE_INT,
> {.i64 = 44100}, 1000, 99, A|D},
INT_MAX instead of 99?
> +{NULL}
> +};
> +
> +static int probe_openmpt(AVProbeData *p)
> +{
> +if (p->buf_size < 1084)
> +return 0;
> +
> +if (p->buf[1080] == 'M' && p->buf[1081] == '.' &&
> +p->buf[1082] == 'K' && p->buf[1083] == '.')
> +return AVPROBE_SCORE_MAX;
> +
So this is going to probe only one kind of tracker? It would be nice to
detect all the tracker files the library supports. With modplug we rely on
extension (bad); does openmpt support something better (something better
than trying to decode, which will be slow and slow down every other
probing)?
> +return 0;
> +}
> +
> +static void openmpt_logfunc(const char *message, void *userdata)
> +{
> +av_log((AVFormatContext*)userdata, AV_LOG_INFO, "%s\n", message);
The cast is not necessary. No loglevel to differenciate error from
warnings from info? That's a shame.
> +}
> +
> +#define add_meta(s, name, value) \
> +if (value && value[0])\
> + av_dict_set(&s->metadata, name, value, 0); \
> +
nit: scope this in a do { ... } while (0) form
> +static int read_header_openmpt(AVFormatContext *s)
> +{
> +AVStream *st;
> +OpenMPTContext *openmpt = s->priv_data;
> +int64_t size = avio_size(s->pb);
> +char *buf = av_malloc(size);
> +
> +if (!buf)
> +return AVERROR(ENOMEM);
> +size = avio_read(s->pb, buf, size);
> +
> +if (!(openmpt->module = openmpt_module_create_from_memory(buf, size,
> openmpt_logfunc, s, NULL))) {
> +av_free(buf);
> +return AVERROR_INVALIDDATA;
> +}
> +av_free(buf);
openmpt->module = openmpt_module_create_from_memory(buf, size,
openmpt_logfunc, s, NULL);
av_freep(&buf);
if (!openmpt->module)
return AVERROR_EXTERNAL;
(or maybe AVERROR(ENOMEM)?)
> +openmpt->channels = o
Re: [FFmpeg-devel] [PATCH] lavc/vda_h264: fixes compilation after 1534ef87
On Sun, Jun 12, 2016 at 08:12:33PM +0200, Clément Bœsch wrote:
> ---
> untested
> ---
> libavcodec/vda_h264_dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
> index a092693..a196eb7 100644
> --- a/libavcodec/vda_h264_dec.c
> +++ b/libavcodec/vda_h264_dec.c
> @@ -226,7 +226,7 @@ static av_cold int vdadec_init(AVCodecContext *avctx)
> ctx->h264_initialized = 1;
>
> for (i = 0; i < MAX_SPS_COUNT; i++) {
> -SPS *sps = ctx->h264ctx.sps_buffers[i];
> +const SPS *sps = (const SPS*)ctx->h264ctx.ps.sps_list[i]->data;
> if (sps && (sps->bit_depth_luma != 8 ||
> sps->chroma_format_idc == 2 ||
> sps->chroma_format_idc == 3)) {
Tested by a user on IRC (maru @ #mpv-devel) and applied
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: fixes compilation after 1534ef87
On Sun, Jun 12, 2016 at 08:38:12PM +0200, Clément Bœsch wrote: > --- > untested > --- > libavcodec/videotoolbox.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c > index 4dc843d..4d86251 100644 > --- a/libavcodec/videotoolbox.c > +++ b/libavcodec/videotoolbox.c > @@ -102,11 +102,11 @@ CFDataRef > ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx) > memcpy(p + 9, h->ps.sps->data, h->ps.sps->data_size); > p += 9 + h->ps.sps->data_size; > AV_W8(p + 0, 1); /* number of pps */ > -AV_WB16(p + 1, h->pps.data_size + 1); > +AV_WB16(p + 1, h->ps.pps->data_size + 1); > AV_W8(p + 3, NAL_PPS | (3 << 5)); // NAL unit header > -memcpy(p + 4, h->pps.data, h->pps.data_size); > +memcpy(p + 4, h->ps.pps->data, h->ps.pps->data_size); > > -p += 4 + h->pps.data_size; > +p += 4 + h->ps.pps->data_size; > av_assert0(p - vt_extradata == vt_extradata_size); > > data = CFDataCreate(kCFAllocatorDefault, vt_extradata, > vt_extradata_size); Tested by a user on IRC (maru @ #mpv-devel) and applied with another runtime fix -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/videotoolbox: fixes compilation after 1534ef87
--- untested --- libavcodec/videotoolbox.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c index 4dc843d..4d86251 100644 --- a/libavcodec/videotoolbox.c +++ b/libavcodec/videotoolbox.c @@ -102,11 +102,11 @@ CFDataRef ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx) memcpy(p + 9, h->ps.sps->data, h->ps.sps->data_size); p += 9 + h->ps.sps->data_size; AV_W8(p + 0, 1); /* number of pps */ -AV_WB16(p + 1, h->pps.data_size + 1); +AV_WB16(p + 1, h->ps.pps->data_size + 1); AV_W8(p + 3, NAL_PPS | (3 << 5)); // NAL unit header -memcpy(p + 4, h->pps.data, h->pps.data_size); +memcpy(p + 4, h->ps.pps->data, h->ps.pps->data_size); -p += 4 + h->pps.data_size; +p += 4 + h->ps.pps->data_size; av_assert0(p - vt_extradata == vt_extradata_size); data = CFDataCreate(kCFAllocatorDefault, vt_extradata, vt_extradata_size); -- 2.8.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/vda_h264: fixes compilation after 1534ef87
---
untested
---
libavcodec/vda_h264_dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
index a092693..a196eb7 100644
--- a/libavcodec/vda_h264_dec.c
+++ b/libavcodec/vda_h264_dec.c
@@ -226,7 +226,7 @@ static av_cold int vdadec_init(AVCodecContext *avctx)
ctx->h264_initialized = 1;
for (i = 0; i < MAX_SPS_COUNT; i++) {
-SPS *sps = ctx->h264ctx.sps_buffers[i];
+const SPS *sps = (const SPS*)ctx->h264ctx.ps.sps_list[i]->data;
if (sps && (sps->bit_depth_luma != 8 ||
sps->chroma_format_idc == 2 ||
sps->chroma_format_idc == 3)) {
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] MAINTAINERS cleanup
On Sat, Jun 11, 2016 at 12:57:13PM +0200, Michael Niedermayer wrote: > Hi > > the MAINTAINERs file contains a bunch of inaccurate and outdated > entries. > > What should be done about this ? > should we remove everyone who was inactive in FFmpeg > (aka no commit/author since 2 years) as in git log --first-parent ... ? > should we mark everyone above as inactive instead like "(inactive)" > > shuuld someone send mails to everyone and ask if they stil maintain > the code they are listed for ? > I'd say at most 30% of the file is still accurate, which means 70% of the file could be dropped. And then we'll see that it's so small the file is mostly irrelevant. Now I'd rather have the file used as a "community profile" to look for qualified people in the various area of the project; or said differently, keep only applications, misc areas, communication, generic parts entries. I feel like this file had for mission to be used as an argument to make sure people are indeed responsible for their code (as in "hey you're the maintainer of X, please review my patch"). Does it work? Did it in the past? -- lément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Bugs and CC
On Fri, Jun 10, 2016 at 11:21:04PM +0200, Hendrik Leppkes wrote: > On Fri, Jun 10, 2016 at 10:36 AM, Michael Niedermayer > wrote: > > Hi all > > > > Should the author of a commit causing a regression be added to the CC > > of bugs if he has a trac account ? > > > > iam thinking yes because i quite often find out about regressions > > by running into them by chance on trac which is ofte long after > > the git hash that caused the regression was added to the ticket > > > > If its a patch written by me, I would be fine getting notifications if > it breaks something. Same here. But I think this rule should be restricted to people who are active. I don't think people who left the project for one reason or another would want to be nagged about such thing. [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add ppm pipe demuxer
On Fri, Jun 10, 2016 at 04:28:55AM +0200, Michael Niedermayer wrote:
> On Thu, Jun 09, 2016 at 04:35:02PM +0200, Clément Bœsch wrote:
> > On Thu, Jun 09, 2016 at 03:59:30PM +0200, Clément Bœsch wrote:
> > > On Thu, Jun 09, 2016 at 01:35:19PM +, Carl Eugen Hoyos wrote:
> > > > Clément Bœsch pkh.me> writes:
> > > >
> > > > > +if (b[3] == '#')
> > > > > +return AVPROBE_SCORE_EXTENSION + 1;
> > > > > +if (b[3] >= '0' && b[3] <= '9')
> > > > > +return AVPROBE_SCORE_MAX - 1;
> > > >
> > > > Imo, this should be:
> > > > if (b[3] == '#' || (b[3] >= '0' && b[3] <= '9'))
> > > > return AVPROBE_SCORE_EXTENSION + 2;
> > > > or similar
> > > >
> > > > I count 37 and 34 bits which is only a little more than
> > > > the usual 32 bit for EXTENSION + 1.
> > > >
> > >
> > > Sure. Changed locally, will push soon, thanks.
> > >
> >
> > For some reasons it makes seeking with pgm somehow working. The reference
> > test doesn't look that great IIUC, but seeking in these file with ffplay
> > is fine AFAICT.
>
> it seems it messes with pgmyuv detection (which i think was filename
> extension based)
>
> example:
> ./ffmpeg -i matrixbench_mpeg2.mpg -pix_fmt yuv420p16be -vframes 1 test.pgmyuv
> ./ffplay-ref test.pgmyuv
> Input #0, image2, from 'test.pgmyuv':B vq=0KB sq=0B f=0/0
> Duration: 00:00:00.04, start: 0.00, bitrate: 248835 kb/s
> Stream #0:0: Video: pgmyuv, yuv420p16le, 720x576, 25 tbr, 25 tbn
>
> ./ffplay test.pgmyuv
> Input #0, ppm_pipe, from 'test.pgmyuv':vq=0KB sq=0B f=0/0
> Duration: N/A, bitrate: N/A
> Stream #0:0: Video: ppm, gray16le, 720x864, 25 tbr, 25 tbn, 25 tbc
>
Yes, this is a good thing (same thing happens if you s/pgmyuv/png/).
I now realize I forgot to attach the diff, so new patch attached.
So the question is: are the FATE changes that affect the "pipe" tests OK?
Playback and seeking in tests/data/lavf/{pbmpipe.pbm,ppmpipe.ppm,
pgmpipe.pgm} now looks OK but the seek ref tests looks odd to me.
--
Clément B.
From b3380ad077e2da8bf50505b904f96d22b50b1564 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?=
Date: Wed, 8 Jun 2016 15:16:34 +0200
Subject: [PATCH] lavf/img2dec: add ppm pipe demuxer
---
libavformat/Makefile| 1 +
libavformat/allformats.c| 1 +
libavformat/img2dec.c | 14 +
libavformat/version.h | 4 ++--
tests/ref/seek/lavf-pbmpipe | 50 -
tests/ref/seek/lavf-pgmpipe | 50 -
tests/ref/seek/lavf-ppmpipe | 50 -
7 files changed, 99 insertions(+), 71 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6684ead..6f473b0 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -229,6 +229,7 @@ OBJS-$(CONFIG_IMAGE_JPEGLS_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PCX_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PICTOR_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PNG_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PPM_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_QDRAW_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ddf540c..0e3322f 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -359,6 +359,7 @@ void av_register_all(void)
REGISTER_DEMUXER (IMAGE_PCX_PIPE,image_pcx_pipe);
REGISTER_DEMUXER (IMAGE_PICTOR_PIPE, image_pictor_pipe);
REGISTER_DEMUXER (IMAGE_PNG_PIPE,image_png_pipe);
+REGISTER_DEMUXER (IMAGE_PPM_PIPE,image_ppm_pipe);
REGISTER_DEMUXER (IMAGE_QDRAW_PIPE, image_qdraw_pipe);
REGISTER_DEMUXER (IMAGE_SGI_PIPE,image_sgi_pipe);
REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 1b0e608..ea07633 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -862,6 +862,19 @@ static int webp_probe(AVProbeData *p)
return 0;
}
+static int ppm_probe(AVProbeData *p)
+{
+const uint8_t *b = p->buf;
+
+if (b[0] == 'P' && b[1] >= '0' && b[1] <= '7') {
+while (b[2] == '\r')
+b++;
+if (b[2] == '\n' && (b[3] == '#&#
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add ppm pipe demuxer
On Thu, Jun 09, 2016 at 03:59:30PM +0200, Clément Bœsch wrote: > On Thu, Jun 09, 2016 at 01:35:19PM +, Carl Eugen Hoyos wrote: > > Clément Bœsch pkh.me> writes: > > > > > +if (b[3] == '#') > > > +return AVPROBE_SCORE_EXTENSION + 1; > > > +if (b[3] >= '0' && b[3] <= '9') > > > +return AVPROBE_SCORE_MAX - 1; > > > > Imo, this should be: > > if (b[3] == '#' || (b[3] >= '0' && b[3] <= '9')) > > return AVPROBE_SCORE_EXTENSION + 2; > > or similar > > > > I count 37 and 34 bits which is only a little more than > > the usual 32 bit for EXTENSION + 1. > > > > Sure. Changed locally, will push soon, thanks. > For some reasons it makes seeking with pgm somehow working. The reference test doesn't look that great IIUC, but seeking in these file with ffplay is fine AFAICT. Is this change acceptable? -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add ppm pipe demuxer
On Thu, Jun 09, 2016 at 01:35:19PM +, Carl Eugen Hoyos wrote: > Clément Bœsch pkh.me> writes: > > > +if (b[3] == '#') > > +return AVPROBE_SCORE_EXTENSION + 1; > > +if (b[3] >= '0' && b[3] <= '9') > > +return AVPROBE_SCORE_MAX - 1; > > Imo, this should be: > if (b[3] == '#' || (b[3] >= '0' && b[3] <= '9')) > return AVPROBE_SCORE_EXTENSION + 2; > or similar > > I count 37 and 34 bits which is only a little more than > the usual 32 bit for EXTENSION + 1. > Sure. Changed locally, will push soon, thanks. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/img2dec: add ppm pipe demuxer
From: Clément Bœsch
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/img2dec.c| 18 ++
libavformat/version.h| 4 ++--
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6684ead..6f473b0 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -229,6 +229,7 @@ OBJS-$(CONFIG_IMAGE_JPEGLS_PIPE_DEMUXER) += img2dec.o
img2.o
OBJS-$(CONFIG_IMAGE_PCX_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PICTOR_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PNG_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_PPM_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_QDRAW_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0a38793..c3c906f 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -360,6 +360,7 @@ void av_register_all(void)
REGISTER_DEMUXER (IMAGE_PCX_PIPE,image_pcx_pipe);
REGISTER_DEMUXER (IMAGE_PICTOR_PIPE, image_pictor_pipe);
REGISTER_DEMUXER (IMAGE_PNG_PIPE,image_png_pipe);
+REGISTER_DEMUXER (IMAGE_PPM_PIPE,image_ppm_pipe);
REGISTER_DEMUXER (IMAGE_QDRAW_PIPE, image_qdraw_pipe);
REGISTER_DEMUXER (IMAGE_SGI_PIPE,image_sgi_pipe);
REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 8dfb813..668f31c 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -862,6 +862,23 @@ static int webp_probe(AVProbeData *p)
return 0;
}
+static int ppm_probe(AVProbeData *p)
+{
+const uint8_t *b = p->buf;
+
+if (b[0] == 'P' && b[1] >= '0' && b[1] <= '7') {
+while (b[2] == '\r')
+b++;
+if (b[2] == '\n') {
+if (b[3] == '#')
+return AVPROBE_SCORE_EXTENSION + 1;
+if (b[3] >= '0' && b[3] <= '9')
+return AVPROBE_SCORE_MAX - 1;
+}
+}
+return 0;
+}
+
#define IMAGEAUTO_DEMUXER(imgname, codecid)\
static const AVClass imgname ## _class = {\
.class_name = AV_STRINGIFY(imgname) " demuxer",\
@@ -891,6 +908,7 @@ IMAGEAUTO_DEMUXER(jpegls, AV_CODEC_ID_JPEGLS)
IMAGEAUTO_DEMUXER(pcx, AV_CODEC_ID_PCX)
IMAGEAUTO_DEMUXER(pictor, AV_CODEC_ID_PICTOR)
IMAGEAUTO_DEMUXER(png, AV_CODEC_ID_PNG)
+IMAGEAUTO_DEMUXER(ppm, AV_CODEC_ID_PPM)
IMAGEAUTO_DEMUXER(qdraw, AV_CODEC_ID_QDRAW)
IMAGEAUTO_DEMUXER(sgi, AV_CODEC_ID_SGI)
IMAGEAUTO_DEMUXER(sunrast, AV_CODEC_ID_SUNRAST)
diff --git a/libavformat/version.h b/libavformat/version.h
index acfa513..b856085 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,8 +32,8 @@
// When bumping major check Ticket5467 for regressing
// Also please add any ticket numbers that you belive might regress here
#define LIBAVFORMAT_VERSION_MAJOR 57
-#define LIBAVFORMAT_VERSION_MINOR 37
-#define LIBAVFORMAT_VERSION_MICRO 101
+#define LIBAVFORMAT_VERSION_MINOR 38
+#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/srtdec: fix probing files with negative first timestamps
On Mon, Jun 06, 2016 at 01:26:40PM -0500, Rodger Combs wrote: > --- > libavformat/srtdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c > index 585aa6a..06061a8 100644 > --- a/libavformat/srtdec.c > +++ b/libavformat/srtdec.c > @@ -52,7 +52,7 @@ static int srt_probe(AVProbeData *p) > /* Check if the next line matches a SRT timestamp */ > if (ff_subtitles_read_line(&tr, buf, sizeof(buf)) < 0) > return 0; > -if (buf[0] >= '0' && buf[0] <= '9' && strstr(buf, " --> ") > +if (((buf[0] >= '0' && buf[0] <= '9') || buf[0] == '-') && strstr(buf, " > --> ") It would be more correct to just skip the '-' if present and still do the [0-9] range check after that. So maybe if (buf[0] == '-') buf++ just before the unchanged if. Thanks > && sscanf(buf, "%*d:%*d:%*d%*1[,.]%*d --> %*d:%*d:%*d%*1[,.]%d", &v) > == 1) > return AVPROBE_SCORE_MAX; > -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
On Sun, May 29, 2016 at 01:32:54AM +0200, Michael Niedermayer wrote: [...] > Please state clearly if you agree to add AVClass&AVOption to > AVCodecParameters or if you disagree about adding it or if you dont > care either way I'm OK with adding an AVClass* on top of AVCodecParameters. Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On Wed, May 18, 2016 at 10:33:23PM +0200, Paul B Mahol wrote: > Hi, > > I want to propose to have an FFmpeg IRC meeting on > the Saturday of the next week, Saturday May 28, > UTC 17. > So I suppose this happens in about half an hour. Can you remind us the IRC channel? -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Add a G.729 muxer
On Wed, May 18, 2016 at 02:46:34PM +0100, Derek Buitenhuis wrote: > On 5/18/2016 2:32 PM, Carl Eugen Hoyos wrote: > > I should probably add that this is an interesting comment > > coming from somebody who breaks FFmpeg with nearly every > > commit and not only absolutely refuses to work on fixes but > > even blocks fixes if others want to help him. > > Frankly, this is nothing nothing but an ad hominem attack. > > I am tired of it. This happens constantly, and the community > is always silent[1], and far too accepting of such toxic behavior. > > It has given me far too much unneeded stress and sourness. The > complete inability of the community to address such behavior and > individuals is appalling. > > I've had enough. I've already distanced myself from the Libav > community recently for similar behavior, and I will be doing > so for the FFmpeg community as well now. > > Both are toxic communities. As of this email, I am unsubscribing > from both ffmpeg-devel and libav-devel. > > I hope both communities enjoy their little out of touch bubbles. > It seems I'm late to the party again... As some people like to remind me, I'm indeed guilty and staying silent when I should raise arms against the devil. But just like you, I assume many people here are also very tired of the fighting (be it "between" or "within" projects) and as a result don't feel like getting more involved in this. So, just like others in this thread, yes of course you have my support against sanctions wrt the non respect of the common technical workflow, and indeed more into to the other issue, the heated crap following. One thing I don't understand though, this kind of situation happens from time to time, and every single time there is like a hand of developers spouting hatred at a single or two individuals, and complaining along the lines "the project doesn't do shit about $issue", followed by a tendency to shift the blame onto the other people who might not give much of a thought about that particular issue, or simply don't necessarily want to be involved in. So instead of these explosive and abrasive behaviours (which I'm not even condemning), I'd suggest the people who are really unhappy about it to bring potential ways out of it. Why was it needed for Michael to step in with a code of conduct even though we know he is much more efficient at non political or writing stuff, and has/had a delicate position in the matter? Paul suggested an IRC meeting, which is probably a step in the good direction, but I think Kieran, wm4, or you Derek (maybe missing others), should have been the first to send a draft for a code of conduct + sanctions things, or whatever other plan you had in mind. You think someone else is going to take responsibility for this? Don't fool yourself, it's unlikely to happen. I understand the anger, I really do. But shouting about a 3rd fork, getting angry at Carl or leaving slamming the door does not look like it's going to help (this last sentence is not directly aimed at you, but more at the group looking for changes). It's sad to see all this anger energy not be transformed in something more constructive, and it will be another loss to see you leave. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On Wed, May 18, 2016 at 10:33:23PM +0200, Paul B Mahol wrote: > Hi, > > I want to propose to have an FFmpeg IRC meeting on > the Saturday of the next week, Saturday May 28, > UTC 17. > > Candidate topics of the day: > - Code of Conduct and policy around it > - technical development issues > - misc topics > Sure, fine with me. Might want to add infrastructure (the conclusion will likely be that we lack someone to handle it though) -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web: remove myself from consulting
On Thu, May 19, 2016 at 08:51:24AM +0200, Thilo Borgmann wrote: > Hi, > > Am 19.05.16 um 08:37 schrieb Clément Bœsch: > > I get too much mails, on a mailbox I forget to check, about issues I'm > > most of the time not willing to address. And I feel bad about not > > answering anymore lately. > > --- > > src/consulting | 39 --- > > 1 file changed, 12 insertions(+), 27 deletions(-) > > when I added myself someone edited my entry to start a new row... so maybe > this > patch also needs a reordering in terms of tabular appearance of the remaining > entries, too. > I dropped the last row and moved you at the end of the same row I was in order to keep the diff relatively small. Would you prefer a full shift of all the entries below? -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web: remove myself from consulting
I get too much mails, on a mailbox I forget to check, about issues I'm most of the time not willing to address. And I feel bad about not answering anymore lately. --- src/consulting | 39 --- 1 file changed, 12 insertions(+), 27 deletions(-) diff --git a/src/consulting b/src/consulting index 0b03806..dfa0576 100644 --- a/src/consulting +++ b/src/consulting @@ -85,19 +85,6 @@ E.g.: - Clément Bœsch - -Clément is located in France and is available for contracting work. -He has worked on FFmpeg since 2011 and has been a maintainer since 2011. -He has experience with subtitles, filters and all kinds of random -things across the codebase. -You can contact him by email at -mailto:ubitux%20at%20gmail%20dot%20com";>ubitux at gmail dot com. - - - - - Michael Niedermayer Michael is located in Vienna, Austria and is available for contracting work. @@ -118,6 +105,18 @@ E.g.: + + + Thilo Borgmann + +Thilo is located in Berlin, Germany and is available for contract work. +He has worked on FFmpeg since 2009 and has been a maintainer since 2010. +He has special expertise with decoders, metadata, input devices and +filters. You can contact him by email at +mailto:thilo.borgm...@mail.de";>thilo.borgm...@mail.de. + + + @@ -157,17 +156,3 @@ E.g.: - - - - Thilo Borgmann - -Thilo is located in Berlin, Germany and is available for contract work. -He has worked on FFmpeg since 2009 and has been a maintainer since 2010. -He has special expertise with decoders, metadata, input devices and -filters. You can contact him by email at -mailto:thilo.borgm...@mail.de";>thilo.borgm...@mail.de. - - - - -- 2.8.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH WIP 0/2] Update usage of SDL1 library to SDL2
On Tue, May 17, 2016 at 06:00:21PM +0100, Josh de Kock wrote: [...] > Should I be replacing sdl.c instead of creating sdl2.c? This comes > under a more semantic question: should it be called SDL2? I'd say replace sdl.c and use .name = "sdl,sdl2"? It would be a shame to keep the SDL1 dependency and configure garbage just because of a mostly unused libavdevice output. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Mon, May 09, 2016 at 02:40:09PM -0500, Kyle Swanson wrote: [...] > I thought about extracting the FFmpeg ebur128 functions so they could be > reused elsewhere in FFmpeg, but the R128 logic from the ebur128 filter > is quite tangled, tied to filter functions, internal states are spread > out between several structs, and is not easily extracted into a reusable > API. Or you could just either add options to the filter, or even declare another filter within the same file, using the same shared structure, like we do in many other filters. Note: please don't cc me, I'm on the ml -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9
On Sun, May 08, 2016 at 11:15:22PM -0300, James Almer wrote: [...] > >>> there where failures with some gcc versions recetly on fate that > >>> disappesred when the gcc version used on these clients changed. > >>> I dont know if anyone identified what was the cause of these issues > >> > >> Do you know what clients? You can look at the history to see what the > >> failed test > >> was and the compiler version used. > > > > i think they where some clients from ubitux IIRC > > Ubitux's clients haven't changed the gcc version for some months now. Afaik > the > current one is the same as it was before tree vectorization was enabled. > His clients also every now and then fail for some weird reason unrelated to > gcc or > even the latest ffmpeg snapshot. They seem to make changes to the source > files, > adding random characters that generate errors. See > > http://fate.ffmpeg.org/log.cgi?time=20160503100201&log=compile&slot=x86_64-archlinux-gcc-threads > http://fate.ffmpeg.org/log.cgi?time=20160424045346&log=compile&slot=x86_64-archlinux-gcc-threads Yeah, I got all kind of freaking random bitflip everywhere, like 2 or 3x a week (and that's only accounting the one i detected). I recently disabled a disk from the raid and it doesn't seem to happen anymore so I'm guessing it's a bug in the HD firmware or something. I'll try to swap the disk in use for the raid to see if the bit rot happens again starting next week or so. Anyway, sorry about that. And yeah, I haven't updated GCC for a while now, but will do when I figure out the bitrot shitstorm properly. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] Add input swap functionality to movie filter (src_movie.c)
On Wed, May 04, 2016 at 12:15:26AM +, Felt, Patrick wrote:
> Afternoon all,
> I apologize if this isn’t right way to submit a patch.
You're supposed to git commit and use git format-patch.
[...]
> +/* libavfilter documentation says that filter init will be called only once.
> ffmpeg calls the init twice to enable it to validate
> + * the complex filtering has the right input and output pads. this allows us
> to bypass the first call if we've specified a stream
> + * specifier string */
> +static int initRun=0;
> +static int uninitRun=0;
You're not allowed to do this, it belongs in the local context.
> +
> typedef struct MovieStream {
> AVStream *st;
> AVCodecContext *codec_ctx;
> int done;
> +int64_t lastPts;/* this is used exclusively by the reset code */
> +int64_t basePts;/* idem */
Here and many times below, keep the naming convention.
[...]
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mpl2dec: skip BOM
On Fri, Apr 15, 2016 at 02:58:00PM +0200, wm4 wrote:
> Stolen from microdvddec.c.
>
> Fixes ticket #5442.
> ---
> libavformat/mpl2dec.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/mpl2dec.c b/libavformat/mpl2dec.c
> index 59589d5..2a0cb28 100644
> --- a/libavformat/mpl2dec.c
> +++ b/libavformat/mpl2dec.c
> @@ -26,6 +26,7 @@
> #include "avformat.h"
> #include "internal.h"
> #include "subtitles.h"
> +#include "libavutil/intreadwrite.h"
>
> typedef struct {
> FFDemuxSubtitlesQueue q;
> @@ -39,6 +40,9 @@ static int mpl2_probe(AVProbeData *p)
> const unsigned char *ptr = p->buf;
> const unsigned char *ptr_end = ptr + p->buf_size;
>
> +if (AV_RB24(ptr) == 0xEFBBBF)
> +ptr += 3; /* skip UTF-8 BOM */
> +
> for (i = 0; i < 2; i++) {
> if (sscanf(ptr, "[%"SCNd64"][%"SCNd64"]%c", &start, &end, &c) != 3 &&
> sscanf(ptr, "[%"SCNd64"][]%c", &start, &c) != 2)
make sure you don't need it in the read_header() callback too.
BTW, as a side note, it will be appropriate to s/if/while/, I have a few
samples with more than one bom... IIRC only in ASS files but we probably
to have it uniformly across sub text decoder. It's fine to keep it
consistent with a single if for now.
thanks
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sws/aarch64: add ff_yuv2planeX_8_neon
On Fri, Apr 08, 2016 at 05:46:13PM +0200, Clément Bœsch wrote: > On Fri, Apr 08, 2016 at 05:35:20PM +0200, Clément Bœsch wrote: > > From: Clément Bœsch > > > > --- > > libswscale/aarch64/Makefile | 1 + > > libswscale/aarch64/output.S | 66 > > > > libswscale/aarch64/swscale.c | 7 + > > libswscale/utils.c | 3 +- > > 4 files changed, 76 insertions(+), 1 deletion(-) > > create mode 100644 libswscale/aarch64/output.S > > > > ./ffmpeg -nostats -f lavfi -i > testsrc2=uhd4320:d=1,format=yuv420p,bench=start,scale=1024x1024,bench=stop -f > null - > > before: [bench @ 0x37706390] t:0.395010 avg:0.395212 max:0.397024 min:0.394710 > after: [bench @ 0x22101390] t:0.262277 avg:0.262560 max:0.264740 min:0.260876 > Applied. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sws/aarch64/yuv2rgb: honor iOS calling convention
On Fri, Apr 08, 2016 at 10:25:13AM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, Apr 8, 2016 at 7:41 AM, Clément Bœsch wrote: > > > From: Clément Bœsch > > > > y_offset and y_coeff being successive 32-bit integers, they are packed > > into 8 bytes instead of 2x8 bytes. > > > lgtm. > applied, thanks -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sws/aarch64: add ff_yuv2planeX_8_neon
On Fri, Apr 08, 2016 at 05:35:20PM +0200, Clément Bœsch wrote: > From: Clément Bœsch > > --- > libswscale/aarch64/Makefile | 1 + > libswscale/aarch64/output.S | 66 > > libswscale/aarch64/swscale.c | 7 + > libswscale/utils.c | 3 +- > 4 files changed, 76 insertions(+), 1 deletion(-) > create mode 100644 libswscale/aarch64/output.S > ./ffmpeg -nostats -f lavfi -i testsrc2=uhd4320:d=1,format=yuv420p,bench=start,scale=1024x1024,bench=stop -f null - before: [bench @ 0x37706390] t:0.395010 avg:0.395212 max:0.397024 min:0.394710 after: [bench @ 0x22101390] t:0.262277 avg:0.262560 max:0.264740 min:0.260876 [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] sws/aarch64: add ff_yuv2planeX_8_neon
From: Clément Bœsch
---
libswscale/aarch64/Makefile | 1 +
libswscale/aarch64/output.S | 66
libswscale/aarch64/swscale.c | 7 +
libswscale/utils.c | 3 +-
4 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 libswscale/aarch64/output.S
diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
index 51bff08..64a3fe2 100644
--- a/libswscale/aarch64/Makefile
+++ b/libswscale/aarch64/Makefile
@@ -2,4 +2,5 @@ OBJS+= aarch64/swscale.o\
aarch64/swscale_unscaled.o \
NEON-OBJS += aarch64/hscale.o \
+ aarch64/output.o \
aarch64/yuv2rgb_neon.o \
diff --git a/libswscale/aarch64/output.S b/libswscale/aarch64/output.S
new file mode 100644
index 000..31809b4
--- /dev/null
+++ b/libswscale/aarch64/output.S
@@ -0,0 +1,66 @@
+/*
+ * Copyright (c) 2016 Clément Bœsch
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+
+function ff_yuv2planeX_8_neon, export=1
+ld1 {v0.8B}, [x5] // load 8x8-bit
dither
+cbz w6, 1f // check if
offseting present
+ext v0.8B, v0.8B, v0.8B, #3 // honor offseting
which can be 0 or 3 only
+1: uxtlv0.8H, v0.8B// extend dither
to 16-bit
+ushll v1.4S, v0.4H, #12 // extend dither
to 32-bit with left shift by 12 (part 1)
+ushll2 v2.4S, v0.8H, #12 // extend dither
to 32-bit with left shift by 12 (part 2)
+mov x7, #0 // i = 0
+2: mov v3.16B, v1.16B // initialize
accumulator part 1 with dithering value
+mov v4.16B, v2.16B // initialize
accumulator part 2 with dithering value
+mov w8, w1 // tmpfilterSize =
filterSize
+mov x9, x2 // srcp= src
+mov x10, x0 // filterp = filter
+3: ldp x11, x12, [x9], #16 // get 2 pointers:
src[j] and src[j+1]
+add x11, x11, x7, lsl #1// &src[j ][i]
+add x12, x12, x7, lsl #1// &src[j+1][i]
+ld1 {v5.8H}, [x11] // read 8x16-bit @
src[j ][i + {0..7}]: A,B,C,D,E,F,G,H
+ld1 {v6.8H}, [x12] // read 8x16-bit @
src[j+1][i + {0..7}]: I,J,K,L,M,N,O,P
+ldr w11, [x10], #4 // read 2x16-bit
coeffs (X, Y) at (filter[j], filter[j+1])
+zip1v16.8H, v5.8H, v6.8H// A,I,B,J,C,K,D,L
+zip2v17.8H, v5.8H, v6.8H// E,M,F,N,F,O,H,P
+dup v7.4S, w11 // X,Y,X,Y,X,Y,X,Y
+smull v18.4S, v16.4H, v7.4H // A.X I.Y B.X J.Y
+smull v20.4S, v17.4H, v7.4H // E.X M.Y F.X N.Y
+smull2 v19.4S, v16.8H, v7.8H // C.X K.Y D.X L.Y
+smull2 v21.4S, v17.8H, v7.8H // G.X O.Y H.X P.Y
+addpv16.4S, v18.4S, v19.4S // A.X+I.Y B.X+J.Y
C.X+K.Y D.X+L.Y
+addpv17.4S, v20.4S, v21.4S // E.X+M.Y F.X+N.Y
F.X+O.Y H.X+P.Y
+add v3.4S, v3.4S, v16.4S// update val
accumulator for part 1
+add v4.4S, v4.4S, v17.4S// update val
accumulator for part 2
+subsw8, w8, #2 // tmpfilterSize
-= 2
+b.gt3b // loop until
filterSize consumed
+sshrv3.4S, v3.4S, #19 // val>>19 (part 1)
+sshrv4.4S, v4.4S, #19 // val>>19 (part 2)
+sqxtun v3.4H, v3.4S
Re: [FFmpeg-devel] [PATCH 0/2] add readvitc filter
On Fri, Apr 08, 2016 at 10:50:23AM +0200, Tobias Rapp wrote: > The following patches add a filter that allows to scan video frames for VITC > lines, including FATE test. > > The sample file for the FATE test can be found at: > https://cerebrum.noa-archive.com/noacloud/public.php?service=files&t=88eeb716819bba39584be03c2d1f053b > (1.4MB) > and is assumed to be stored as $FATE_SAMPLES/filter/sample-vitc.avi > > MD5SUM:150ca9d1f6283f136ce14bd7a7cf025e > SHA256SUM: ec39eeda7587536a4c90ae14288e895defa8fc64c536eeca88b34899a963d42f > Hey that's pretty cool. I'll check that patch later. BTW, how about updating drawtext filter so it can pick the timecode information from metadata? We already have drawtext code handling timecode printing. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] sws/aarch64/yuv2rgb: honor iOS calling convention
From: Clément Bœsch
y_offset and y_coeff being successive 32-bit integers, they are packed
into 8 bytes instead of 2x8 bytes.
See
https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
> iOS diverges from Procedure Call Standard for the ARM 64-bit
> Architecture in several ways
[...]
> In the generic procedure call standard, all function arguments passed
> on the stack consume slots in multiples of 8 bytes. In iOS, this
> requirement is dropped, and values consume only the space required.
[...]
> Padding is still inserted on the stack to satisfy arguments’ alignment
> requirements.
---
libswscale/aarch64/yuv2rgb_neon.S | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/libswscale/aarch64/yuv2rgb_neon.S
b/libswscale/aarch64/yuv2rgb_neon.S
index 8cefe22..b7446aa 100644
--- a/libswscale/aarch64/yuv2rgb_neon.S
+++ b/libswscale/aarch64/yuv2rgb_neon.S
@@ -21,10 +21,18 @@
#include "libavutil/aarch64/asm.S"
+.macro load_yoff_ycoeff yoff ycoeff
+#if defined(__APPLE__)
+ldp w9, w10, [sp, #\yoff]
+#else
+ldr w9, [sp, #\yoff]
+ldr w10, [sp, #\ycoeff]
+#endif
+.endm
+
.macro load_args_nv12
ldr x8, [sp] //
table
-ldr w9, [sp, #8] //
y_offset
-ldr w10, [sp, #16] //
y_coeff
+load_yoff_ycoeff8, 16 //
y_offset, y_coeff
ld1 {v1.1D}, [x8]
dup v0.8H, w10
dup v3.8H, w9
@@ -42,8 +50,7 @@
ldr x13, [sp] // srcV
ldr w14, [sp, #8] //
linesizeV
ldr x8, [sp, #16] //
table
-ldr w9, [sp, #24] //
y_offset
-ldr w10, [sp, #32] //
y_coeff
+load_yoff_ycoeff24, 32 //
y_offset, y_coeff
ld1 {v1.1D}, [x8]
dup v0.8H, w10
dup v3.8H, w9
@@ -59,8 +66,7 @@
ldr x13, [sp] // srcV
ldr w14, [sp, #8] //
linesizeV
ldr x8, [sp, #16] //
table
-ldr w9, [sp, #24] //
y_offset
-ldr w10, [sp, #32] //
y_coeff
+load_yoff_ycoeff24, 32 //
y_offset, y_coeff
ld1 {v1.1D}, [x8]
dup v0.8H, w10
dup v3.8H, w9
--
2.8.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: new colorspace conversion filter.
On Wed, Apr 06, 2016 at 11:44:22AM -0400, Ronald S. Bultje wrote:
[...]
> > Note: a cleaner way to do this (IMO) is to do put the settings into the
> > template file, and do something like:
> >
> >#define TEMPLATE_444
> >#include "colorspacedsp_template.c"
> >#undef TEMPLATE_444
> >
> >#define TEMPLATE_422
> >#include "colorspacedsp_template.c"
> >#undef TEMPLATE_422
> >
> >#define TEMPLATE_420
> >#include "colorspacedsp_template.c"
> >#undef TEMPLATE_420
> >
> > it's simpler for the caller, and in the template you see the exact
> > settings in use for each "profile".
> >
> > See libswresample/rematrix{,_template}.c for a complete example.
> >
>
> Hm, I based this off of how lavc/bit_depth_template.c is typically used. I
> guess there's various way to do it. How much do you want me to change it?
>
The question is: if you ignore the changing effort and the consistency,
which version do you actually prefer? It's your filter so it's up to you.
I just believe this is much more readable that way, but it's an opinion :)
> [...]
> > > +typedef void (*yuv2rgb_fn)(int16_t *rgb[3], ptrdiff_t rgb_stride,
> > > + uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
> > > + int w, int h, const int16_t
> > yuv2rgb_coeffs[3][3][8],
> > > + const int16_t yuv_offset[8]);
> > > +typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
> > > + int16_t *rgb[3], ptrdiff_t rgb_stride,
> > > + int w, int h, const int16_t
> > rgb2yuv_coeffs[3][3][8],
> > > + const int16_t yuv_offset[8]);
> > > +typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t
> > yuv_out_stride[3],
> > > + uint8_t *yuv_in[3], ptrdiff_t
> > yuv_in_stride[3],
> > > + int w, int h, const int16_t
> > yuv2yuv_coeffs[3][3][8],
> > > + const int16_t yuv_offset[2][8]);
> >
> > I suppose you didn't make use of const for the input because of the
> > pain of the multiple dimensions?
> >
>
> Right.
>
> uint8_t * const in[N] doesn't do the trick?
> >
>
> Well, it's incomplete const, right? I want to indicate that both the plane
> pointers as well as the data in the plane pointers should be considered
> immutable for the dsp function, but as you pointed out, that's not easy
> with C multi-dimensional arrays... I can add half-baked const if you like...
>
It's fine, I just like to hint about the constness. Knowning that it's not
trashing or permuting the input is kinda helpful in these cases.
[...]
> > > +yuv0 += (yuv_stride[0] * (1 << SS_H)) / sizeof(pixel);
> > > +yuv1 += yuv_stride[1] / sizeof(pixel);
> > > +yuv2 += yuv_stride[2] / sizeof(pixel);
> > > +rgb0 += rgb_stride * (1 << SS_H);
> > > +rgb1 += rgb_stride * (1 << SS_H);
> > > +rgb2 += rgb_stride * (1 << SS_H);
> >
> > i know we will have some asm for this, but compiler will probably like to
> > have these increment variables in some const before the loop instead of
> > computing them every time.
> >
> > I don't think we will have ASM for all the architectures soon so having a
> > fast C is still relevant for such important code.
> >
>
> But this is used in various lavc templating schemes also, right? These all
> revert back to single instructions, since assembly operates on pointer
> values as bytes, not types, so int16_t *something; something += stride / 2;
> actually becomes "add something, stride" in assembly... Which part do you
> feel will be calculated at runtime inside the loop?
>
If they are able to do that then that's fine. They weren't so smart in the
past.
[...]
> I've uploaded a new version addressing these concerns, adding some
> refactoring and adding SIMD for x86 (SSE2, 64bit only) on github:
> https://github.com/rbultje/ffmpeg/commits/colorspace
> Would you like me to squash everything in a single big patch and re-send?
> Or something else?
I'd say 2 patches if possible; one for the filter, one adding the SIMD. If
too complex, just one is OK.
>
> Ronald
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Wed, Apr 06, 2016 at 05:16:31PM +0200, Tobias Rapp wrote: > On 06.04.2016 17:02, Clément Bœsch wrote: > >On Wed, Apr 06, 2016 at 09:52:51AM -0500, Kyle Swanson wrote: > >>On Wed, Apr 6, 2016 at 12:45 AM, Clément Bœsch wrote: > >>>Mmh. That's nice and all but... why not use/adjust the native ebur128 > >>>filter we have instead of relying on an external library? > >>> > >>>[...] > >>> > >>>-- > >>>Clément B. > >> > >>This could be an option for the future. We'll need to break all the > >>EBU R128 logic out into utility functions > > > >why? what do you need exactly from the filter? The meta are exported in > >each audio frame. > > > >>and update it to use the newest version BS.1770 so it can be used by > >>both filters. Using libebur128 is a > >>good option because it is widely used, actively developed, and updated > >>whenever the spec changes. > > > >except it's an external dependency and we have code builtin available, > >doing the same thing, and with no open issue (afaik). > > From the top of my head libebur128 additionally supports sample-rates != > 48kHz The standard is (was?) only defined for 48kHz, although the filters coefficients could be derivated for other frequencies. ff ebur128 could be adjusted for that. > and allows true-peak measurement (oversampling with the help of > libspeex-dsp). True peak is implemented in ebur128 (oversampling with the help of swresample). [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Wed, Apr 06, 2016 at 09:52:51AM -0500, Kyle Swanson wrote: > On Wed, Apr 6, 2016 at 12:45 AM, Clément Bœsch wrote: > > On Tue, Apr 05, 2016 at 07:01:14PM -0500, Kyle Swanson wrote: > >> Here's another audio filter. I hinted at this a few months ago, but I > >> found out that > >> finishing the last 5% took almost as long as the first 95%. This is an EBU > >> R128 > >> dynamic loudness normalization filter. This filter uses libebur128 > >> v1.1.0[1] and must be > >> configured with `--enable-libebur128'. Please also see the accompanying > >> blog post[2] > >> which has an algorithm description, as well as some usage instructions. > >> > >> [1] https://github.com/jiixyj/libebur128 > >> [2] http://k.ylo.ph/2016/04/04/loudnorm.html > >> > >> Thanks! > >> Kyle > >> > >> Signed-off-by: Kyle Swanson > >> --- > >> Changelog | 1 + > >> MAINTAINERS | 1 + > >> configure | 5 + > >> doc/filters.texi | 42 +++ > >> libavfilter/Makefile | 1 + > >> libavfilter/af_loudnorm.c | 905 > >> ++ > >> libavfilter/allfilters.c | 1 + > >> libavfilter/version.h | 4 +- > >> 8 files changed, 958 insertions(+), 2 deletions(-) > >> create mode 100644 libavfilter/af_loudnorm.c > >> > > > > Mmh. That's nice and all but... why not use/adjust the native ebur128 > > filter we have instead of relying on an external library? > > > > [...] > > > > -- > > Clément B. > > This could be an option for the future. We'll need to break all the > EBU R128 logic out into utility functions why? what do you need exactly from the filter? The meta are exported in each audio frame. > and update it to use the newest version BS.1770 so it can be used by > both filters. Using libebur128 is a > good option because it is widely used, actively developed, and updated > whenever the spec changes. except it's an external dependency and we have code builtin available, doing the same thing, and with no open issue (afaik). -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Tue, Apr 05, 2016 at 07:01:14PM -0500, Kyle Swanson wrote: > Here's another audio filter. I hinted at this a few months ago, but I found > out that > finishing the last 5% took almost as long as the first 95%. This is an EBU > R128 > dynamic loudness normalization filter. This filter uses libebur128 v1.1.0[1] > and must be > configured with `--enable-libebur128'. Please also see the accompanying blog > post[2] > which has an algorithm description, as well as some usage instructions. > > [1] https://github.com/jiixyj/libebur128 > [2] http://k.ylo.ph/2016/04/04/loudnorm.html > > Thanks! > Kyle > > Signed-off-by: Kyle Swanson > --- > Changelog | 1 + > MAINTAINERS | 1 + > configure | 5 + > doc/filters.texi | 42 +++ > libavfilter/Makefile | 1 + > libavfilter/af_loudnorm.c | 905 > ++ > libavfilter/allfilters.c | 1 + > libavfilter/version.h | 4 +- > 8 files changed, 958 insertions(+), 2 deletions(-) > create mode 100644 libavfilter/af_loudnorm.c > Mmh. That's nice and all but... why not use/adjust the native ebur128 filter we have instead of relying on an external library? [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: Test for Ticket4560
On Fri, Apr 01, 2016 at 01:02:56AM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > tests/fate/filter-video.mak |9 ++ > tests/ref/fate/filter-meta-4560-rotate0 | 259 > +++ > 2 files changed, 268 insertions(+) > create mode 100644 tests/ref/fate/filter-meta-4560-rotate0 > It looks like this test is failing for aarch64... [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: new colorspace conversion filter.
On Thu, Mar 31, 2016 at 08:29:37PM -0400, Ronald S. Bultje wrote:
> The intent here is similar to colormatrix, but it's LGPLv2.1-or-later
> (instead of GPLv2.0) and supports gamma/chromaticity correction.
> ---
> doc/filters.texi | 183 +++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/colorspacedsp.c | 130 +
> libavfilter/colorspacedsp.h | 51 ++
> libavfilter/colorspacedsp_template.c | 256 ++
> libavfilter/vf_colorspace.c | 909
> +++
note: don't forget Changelog and minor lavfi bump
note2: sorry in advance if my comments aren't very deeply related to the
algorithms themselves.
[...]
> +#include "colorspacedsp.h"
> +
> +#define SS_W 0
> +#define SS_H 0
> +
> +#define BIT_DEPTH 8
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 10
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 12
> +#include "colorspacedsp_template.c"
> +
> +#undef SS_W
> +#undef SS_H
> +
> +#define SS_W 1
> +#define SS_H 0
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 8
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 10
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 12
> +#include "colorspacedsp_template.c"
> +
> +#undef SS_W
> +#undef SS_H
> +
> +#define SS_W 1
> +#define SS_H 1
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 8
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 10
> +#include "colorspacedsp_template.c"
> +
> +#undef BIT_DEPTH
> +#define BIT_DEPTH 12
> +#include "colorspacedsp_template.c"
> +
Note: a cleaner way to do this (IMO) is to do put the settings into the
template file, and do something like:
#define TEMPLATE_444
#include "colorspacedsp_template.c"
#undef TEMPLATE_444
#define TEMPLATE_422
#include "colorspacedsp_template.c"
#undef TEMPLATE_422
#define TEMPLATE_420
#include "colorspacedsp_template.c"
#undef TEMPLATE_420
it's simpler for the caller, and in the template you see the exact
settings in use for each "profile".
See libswresample/rematrix{,_template}.c for a complete example.
[...]
> +typedef void (*yuv2rgb_fn)(int16_t *rgb[3], ptrdiff_t rgb_stride,
> + uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
> + int w, int h, const int16_t
> yuv2rgb_coeffs[3][3][8],
> + const int16_t yuv_offset[8]);
> +typedef void (*rgb2yuv_fn)(uint8_t *yuv[3], ptrdiff_t yuv_stride[3],
> + int16_t *rgb[3], ptrdiff_t rgb_stride,
> + int w, int h, const int16_t
> rgb2yuv_coeffs[3][3][8],
> + const int16_t yuv_offset[8]);
> +typedef void (*yuv2yuv_fn)(uint8_t *yuv_out[3], ptrdiff_t yuv_out_stride[3],
> + uint8_t *yuv_in[3], ptrdiff_t yuv_in_stride[3],
> + int w, int h, const int16_t
> yuv2yuv_coeffs[3][3][8],
> + const int16_t yuv_offset[2][8]);
I suppose you didn't make use of const for the input because of the
pain of the multiple dimensions?
uint8_t * const in[N] doesn't do the trick?
[...]
> +static void fn(yuv2rgb)(int16_t *rgb[3], ptrdiff_t rgb_stride,
> +uint8_t *_yuv[3], ptrdiff_t yuv_stride[3],
> +int w, int h, const int16_t yuv2rgb_coeffs[3][3][8],
> +const int16_t yuv_offset[8])
> +{
> +pixel **yuv = (pixel **) _yuv;
> +const pixel *yuv0 = yuv[0], *yuv1 = yuv[1], *yuv2 = yuv[2];
> +int16_t *rgb0 = rgb[0], *rgb1 = rgb[1], *rgb2 = rgb[2];
> +int y, x;
> +int cy = yuv2rgb_coeffs[0][0][0];
> +int crv = yuv2rgb_coeffs[0][2][0];
> +int cgu = yuv2rgb_coeffs[1][1][0];
> +int cgv = yuv2rgb_coeffs[1][2][0];
> +int cbu = yuv2rgb_coeffs[2][1][0];
> +int sh = BIT_DEPTH - 1;
> +int uv_offset = 128 << (BIT_DEPTH - 8);
nit: if these aren't going to change in this big function, you might want
to set them const. It could help the compilers, and particularly the last
two.
> +
> +av_assert2(yuv2rgb_coeffs[0][1][0] == 0);
> +av_assert2(yuv2rgb_coeffs[2][2][0] == 0);
> +av_assert2(yuv2rgb_coeffs[1][0][0] == cy && yuv2rgb_coeffs[2][0][0] ==
> cy);
> +
> +#if SS_W == 1
> +w = (w + 1) >> 1;
> +#if SS_H == 1
> +h = (h + 1) >> 1;
> +#endif
> +#endif
this should save some ifdefery, still be a noop when SS_X are 0, and
generate the same instruction (if i'm not mistaken) when not 0:
w = AV_CEIL_RSHIFT(w, SS_W);
h = AV_CEIL_RSHIFT(h, SS_H);
but maybe that's not what you want.
> +for (y = 0; y < h; y++) {
> +for (x = 0; x < w; x++) {
> +int y00 = yuv0[x << SS_W] - yuv_offset[0];
> +#if SS_W == 1
> +int y01 = yuv0[2 * x + 1] - yuv_offset[0];
> +#if SS_H == 1
> +
Re: [FFmpeg-devel] [PATCH] fate: Add test for Ticket 2397
On Sat, Apr 02, 2016 at 03:49:12AM +0200, Michael Niedermayer wrote: > If someone can create a smaller test file (its 2.5Mb) that still has the same > coverage that is welcome. > otherwise ill upload the sample attached to the ticket > > Signed-off-by: Michael Niedermayer > --- > tests/fate/filter-video.mak|4 + > tests/filtergraphs/overlay-2397|2 + > tests/ref/fate/filter-overlay-2397 | 848 > > 3 files changed, 854 insertions(+) > create mode 100644 tests/filtergraphs/overlay-2397 > create mode 100644 tests/ref/fate/filter-overlay-2397 > > diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak > index 7fb7677..5fd6ae0 100644 > --- a/tests/fate/filter-video.mak > +++ b/tests/fate/filter-video.mak > @@ -304,6 +304,10 @@ FATE_FILTER-$(call ALLYES, SMJPEG_DEMUXER MJPEG_DECODER > PERMS_FILTER HQDN3D_FILT > fate-filter-hqdn3d-sample: tests/data/filtergraphs/hqdn3d > fate-filter-hqdn3d-sample: CMD = framecrc -idct simple -i > $(TARGET_SAMPLES)/smjpeg/scenwin.mjpg -filter_complex_script > $(TARGET_PATH)/tests/data/filtergraphs/hqdn3d -an > > +FATE_FILTER-$(call ALLYES, MATROSKA_DEMUXER OVERLAY_FILTER H264_DECODER > DVDSUB_DECODER) += fate-filter-overlay-2397 > +fate-filter-overlay-2397: tests/data/filtergraphs/overlay-2397 > +fate-filter-overlay-2397: CMD = framecrc -flags bitexact -i > $(TARGET_SAMPLES)/filter/242_4.mkv -filter_complex_script > $(TARGET_PATH)/tests/data/filtergraphs/overlay-2397 -c:a copy > + is it relevant to include the audio? also i'd better mention "dvdsub" than the ticket id (commit message should still contain the reference to the ticket though). thanks -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec: rawenc: Use the AVCodecContext pix_fmt/width/height
On Mon, Apr 04, 2016 at 03:56:31PM +0200, Hugo Beauzée-Luyssen wrote:
> Instead of using the ones in the AVFrame which can be uninitialized
In what context?
> ---
> libavcodec/rawenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
> index d837056..27e4a29 100644
> --- a/libavcodec/rawenc.c
> +++ b/libavcodec/rawenc.c
> @@ -60,8 +60,8 @@ static int raw_encode(AVCodecContext *avctx, AVPacket *pkt,
> return ret;
> if ((ret = av_image_copy_to_buffer(pkt->data, pkt->size,
> (const uint8_t **)frame->data,
> frame->linesize,
> - frame->format,
> - frame->width, frame->height, 1)) < 0)
> + avctx->pix_fmt,
> + avctx->width, avctx->height, 1)) < 0)
> return ret;
>
> if(avctx->codec_tag == AV_RL32("yuv2") && ret > 0 &&
> --
> 2.8.0.rc3
>
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sws/aarch64: restore hscale for a limited subset of filter sizes
On Mon, Apr 04, 2016 at 10:35:16AM +0200, Clément Bœsch wrote: > From: Clément Bœsch > > --- > I need to add a &3 (mod4) version now... I don't know if it can be any > smaller. > --- > libswscale/aarch64/hscale.S | 2 +- > libswscale/aarch64/swscale.c | 5 +++-- > 2 files changed, 4 insertions(+), 3 deletions(-) > Please disregard this patch. [...] -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] sws/aarch64: restore hscale for a limited subset of filter sizes
From: Clément Bœsch
---
I need to add a &3 (mod4) version now... I don't know if it can be any smaller.
---
libswscale/aarch64/hscale.S | 2 +-
libswscale/aarch64/swscale.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libswscale/aarch64/hscale.S b/libswscale/aarch64/hscale.S
index c32394c..e6bd365 100644
--- a/libswscale/aarch64/hscale.S
+++ b/libswscale/aarch64/hscale.S
@@ -20,7 +20,7 @@
#include "libavutil/aarch64/asm.S"
-function ff_hscale_8_to_15_neon, export=1
+function ff_hscale_8_to_15_X8_neon, export=1
add x10, x4, w6, UXTW #1// filter2 = filter +
filterSize*2 (x2 because int16)
1: ldr w8, [x5], #4// filterPos[0]
ldr w9, [x5], #4// filterPos[1]
diff --git a/libswscale/aarch64/swscale.c b/libswscale/aarch64/swscale.c
index ebf76a5..f38effe 100644
--- a/libswscale/aarch64/swscale.c
+++ b/libswscale/aarch64/swscale.c
@@ -21,7 +21,7 @@
#include "libswscale/swscale_internal.h"
#include "libavutil/aarch64/cpu.h"
-void ff_hscale_8_to_15_neon(SwsContext *c, int16_t *dst, int dstW,
+void ff_hscale_8_to_15_X8_neon(SwsContext *c, int16_t *dst, int dstW,
const uint8_t *src, const int16_t *filter,
const int32_t *filterPos, int filterSize);
@@ -31,7 +31,8 @@ av_cold void ff_sws_init_swscale_aarch64(SwsContext *c)
if (have_neon(cpu_flags)) {
if (c->srcBpc == 8 && c->dstBpc <= 14) {
-//c->hyScale = c->hcScale = ff_hscale_8_to_15_neon;
+if (c->hLumFilterSize & 7) c->hyScale = ff_hscale_8_to_15_X8_neon;
+if (c->hChrFilterSize & 7) c->hcScale = ff_hscale_8_to_15_X8_neon;
}
}
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add coded_width/height to AVCodecParameters
On Sun, Apr 03, 2016 at 02:07:47PM +0200, Michael Niedermayer wrote:
> Without this or some other change moving data back and forth corrupts it
> as the cropped & possibly low res resolution modified w/h will be taken
> a the pre lowres resolution
> also without 2 sets theres no place to communicate the cropped dimensions
>
> can be reproduced with
> ./ffplay_g -vlowres 2 tickets/162/avid.avi
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avcodec.h |8 +++-
> libavcodec/utils.c |4
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index ec45add..19bc1a6 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3826,12 +3826,18 @@ typedef struct AVCodecParameters {
> int level;
>
> /**
> - * Video only. The dimensions of the video frame in pixels.
> + * Video only. The dimensions of the presented video frame in pixels.
> */
> int width;
> int height;
>
> /**
> + * Video only. The dimensions of the stored video frame in pixels.
> + */
> +int coded_width;
> +int coded_height;
> +
> +/**
> * Video only. The aspect ratio (width / height) which a single pixel
> * should have when displayed.
> *
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index a26a5ed..1fd7f29 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -3772,6 +3772,8 @@ int avcodec_parameters_from_context(AVCodecParameters
> *par,
> switch (par->codec_type) {
> case AVMEDIA_TYPE_VIDEO:
> par->format = codec->pix_fmt;
> +par->coded_width = codec->coded_width;
> +par->coded_height= codec->coded_height;
> par->width = codec->width;
> par->height = codec->height;
> par->field_order = codec->field_order;
> @@ -3827,6 +3829,8 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
> codec->pix_fmt= par->format;
> codec->width = par->width;
> codec->height = par->height;
> +codec->coded_width= par->coded_width;
> +codec->coded_height = par->coded_height;
> codec->field_order= par->field_order;
> codec->color_range= par->color_range;
> codec->color_primaries= par->color_primaries;
dv needed something like this too, but the code was pretty much hacky in
the first place and it was changed not to use them, which avoided such
commit. Where is this needed exactly?
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: remove usage of avctx->time_base
On Mon, Mar 28, 2016 at 06:09:03PM +0200, Clément Bœsch wrote: > On Mon, Mar 28, 2016 at 04:57:51PM +0200, Michael Niedermayer wrote: > > On Mon, Mar 28, 2016 at 02:10:51PM +0200, Clément Bœsch wrote: > > > lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q > > > before calling the decode callback. This prevents from rescaling again > > > into the decoder, and avoid the use of avctx->time_base which will > > > disappear in the incoming codecpar merge. > > > > > > This commit also replaces the use of "20 centisecond" (ass time base) > > > with "200 ms". > > > --- > > > libavcodec/ccaption_dec.c | 14 +++--- > > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > with > > ./ffmpeg -f lavfi -i "movie=Starship_Troopers.vob[out0+subcc]" -vn -map s > > out.srt > > > > this causes a moderate change in the timings > > is that intended ? > > > > Nope, that was a bug, thanks for noticing. It appears FATE isn't enough... > > New patch attached. > > [...] > > -- > Clément B. > From 1c79debbb09c0ed8f1d771cc4224248351f4cea2 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= > Date: Mon, 28 Mar 2016 14:10:08 +0200 > Subject: [PATCH 1/2] lavc/ccaption_dec: remove usage of avctx->time_base > > lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q > before calling the decode callback. This prevents from rescaling again > into the decoder, and avoid the use of avctx->time_base which will > disappear in the incoming codecpar merge. > > This commit also replaces the use of "20 centisecond" (ass time base) > with "200 ms". > --- > libavcodec/ccaption_dec.c | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > Applied. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/utils: use pkt_timebase for legacy subtitles timing code
On Mon, Mar 28, 2016 at 07:36:18PM +0200, Clément Bœsch wrote: [...] > From a885683c02fce7037e882e52216afa8a96aaf1e7 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= > Date: Mon, 28 Mar 2016 14:15:42 +0200 > Subject: [PATCH 2/2] lavc/utils: use pkt_timebase for legacy subtitles timing > code > > This is consistent with other AVSubtitle timing adjustments. > --- > libavcodec/utils.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > pushed -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: add bt2020 yuv2rgb coefficients.
On Thu, Mar 31, 2016 at 02:29:12PM -0400, Ronald S. Bultje wrote:
> Also fix the bt709 ones. They seem derived from incorrect values
> cr=0.2125 (should be cr=0.2126) and cb=0.0721 (should be cb=0.0722).
Can you split?
> ---
> libswscale/swscale.h | 1 +
> libswscale/yuv2rgb.c | 13 -
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/libswscale/swscale.h b/libswscale/swscale.h
> index da9dd2e..6b8b926 100644
> --- a/libswscale/swscale.h
> +++ b/libswscale/swscale.h
> @@ -91,6 +91,7 @@ const char *swscale_license(void);
> #define SWS_CS_SMPTE170M 5
> #define SWS_CS_SMPTE240M 7
> #define SWS_CS_DEFAULT5
> +#define SWS_CS_BT2020 9
>
probably requires micro or minor bump in version.h
> /**
> * Return a pointer to yuv<->rgb coefficients for the given colorspace
> diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
> index 62abb7d..1fe5abe 100644
> --- a/libswscale/yuv2rgb.c
> +++ b/libswscale/yuv2rgb.c
> @@ -46,20 +46,23 @@
> *
> * where Y = cr * R + cg * G + cb * B and cr + cg + cb = 1.
> */
> -const int32_t ff_yuv2rgb_coeffs[8][4] = {
> -{ 117504, 138453, 13954, 34903 }, /* no sequence_display_extension */
> -{ 117504, 138453, 13954, 34903 }, /* ITU-R Rec. 709 (1990) */
> +const int32_t ff_yuv2rgb_coeffs[11][4] = {
> +{ 117489, 138438, 13975, 34925 }, /* no sequence_display_extension */
> +{ 117489, 138438, 13975, 34925 }, /* ITU-R Rec. 709 (1990) */
no FATE change? oO
> { 104597, 132201, 25675, 53279 }, /* unspecified */
> { 104597, 132201, 25675, 53279 }, /* reserved */
> { 104448, 132798, 24759, 53109 }, /* FCC */
> { 104597, 132201, 25675, 53279 }, /* ITU-R Rec. 624-4 System B, G */
> { 104597, 132201, 25675, 53279 }, /* SMPTE 170M */
> -{ 117579, 136230, 16907, 35559 } /* SMPTE 240M (1987) */
> +{ 117579, 136230, 16907, 35559 }, /* SMPTE 240M (1987) */
> +{ 0 }, /* YCgCo */
why the empty entry?
> +{ 110013, 140363, 12277, 42626 }, /* Bt-2020-NCL */
> +{ 110013, 140363, 12277, 42626 }, /* Bt-2020-CL */
> };
>
> const int *sws_getCoefficients(int colorspace)
> {
> -if (colorspace > 7 || colorspace < 0)
> +if (colorspace > 10 || colorspace < 0 || colorspace == 8)
> colorspace = SWS_CS_DEFAULT;
> return ff_yuv2rgb_coeffs[colorspace];
> }
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 8/9] swscale/arm/yuv2rgb: save a few instructions by processing the luma line interleaved
On Thu, Mar 31, 2016 at 11:17:43AM +0200, Benoit Fouet wrote:
[...]
> What about adding a level of macro here? Something like:
> .macro process_1l_internal ofmt src_addr res
> compute_premult
> vld2.8{d14, d15}, [\src_addr]!
> compute\res, \ofmt
> .endm
>
> (again, the naming could be changed, according to your own taste :-) )
>
> This way, we would get:
> .macro process_1l ofmt
> process_1l_internal \ofmt, r4, r2
> .endm
>
> .macro process_2l ofmt
> process_1l_internal \ofmt, r4, r2
> process_1l_internal \ofmt, r12, r11
> .endm
>
You loose the possibility of doing pairing if you do that
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] sws/aarch64: add ff_hscale_8_to_15_neon
On Thu, Mar 24, 2016 at 01:28:37PM +0100, Clément Bœsch wrote: > From: Clément Bœsch > > ./ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf > bench=start,scale=1024x1024,bench=stop -f null - > > before: t:0.489726 avg:0.489883 max:0.491852 min:0.489482 > after: t:0.256515 avg:0.256458 max:0.256999 min:0.253755 > --- > Changes: > - FIX: not using the v8-v15 registers > - writing directly from the SIMD register (thx Martin) > - misc reordering > > I'm looking at the vscale part now. > --- > libswscale/aarch64/Makefile | 6 +++-- > libswscale/aarch64/hscale.S | 59 > +++ > libswscale/aarch64/swscale.c | 37 +++ > libswscale/swscale.c | 2 ++ > libswscale/swscale_internal.h | 1 + > libswscale/utils.c| 4 ++- > 6 files changed, 106 insertions(+), 3 deletions(-) > create mode 100644 libswscale/aarch64/hscale.S > create mode 100644 libswscale/aarch64/swscale.c > Applied. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/utils: use pkt_timebase for legacy subtitles timing code
On Mon, Mar 28, 2016 at 06:52:26PM +0200, wm4 wrote:
> On Mon, 28 Mar 2016 18:44:33 +0200
> Michael Niedermayer wrote:
>
> > On Mon, Mar 28, 2016 at 02:15:50PM +0200, Clément Bœsch wrote:
> > > This is consistent with other AVSubtitle timing adjustments.
> > > ---
> > > libavcodec/utils.c | 9 +++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > > index c625bbc..2c8fc9c 100644
> > > --- a/libavcodec/utils.c
> > > +++ b/libavcodec/utils.c
> > > @@ -2582,8 +2582,13 @@ int avcodec_decode_subtitle2(AVCodecContext
> > > *avctx, AVSubtitle *sub,
> > >
> > > #if FF_API_ASS_TIMING
> > > if (avctx->sub_text_format ==
> > > FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS
> > > -&& *got_sub_ptr && sub->num_rects)
> > > -ret = convert_sub_to_old_ass_form(sub, avpkt,
> > > avctx->time_base);
> > > +&& *got_sub_ptr && sub->num_rects) {
> > > +if (!avctx->pkt_timebase.num) {
> > > +av_log(avctx, AV_LOG_ERROR, "packet time base not
> > > set\n");
> > > +return AVERROR_BUG;
> > > +}
> > > +ret = convert_sub_to_old_ass_form(sub, avpkt,
> > > avctx->pkt_timebase);
> > > +}
> > > #endif
> >
> > this change does make sense
> >
> > do all apps that get into this code set avctx->pkt_timebase so that
> > this works though or is it otherwise guranteed to be set ?
> >
> > [...]
>
> No they don't. It's an API change.
New patch attached.
--
Clément B.
From a885683c02fce7037e882e52216afa8a96aaf1e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?=
Date: Mon, 28 Mar 2016 14:15:42 +0200
Subject: [PATCH 2/2] lavc/utils: use pkt_timebase for legacy subtitles timing
code
This is consistent with other AVSubtitle timing adjustments.
---
libavcodec/utils.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index c625bbc..793f589 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2582,8 +2582,11 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, AVSubtitle *sub,
#if FF_API_ASS_TIMING
if (avctx->sub_text_format == FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS
-&& *got_sub_ptr && sub->num_rects)
-ret = convert_sub_to_old_ass_form(sub, avpkt, avctx->time_base);
+&& *got_sub_ptr && sub->num_rects) {
+const AVRational tb = avctx->pkt_timebase.num ? avctx->pkt_timebase
+ : avctx->time_base;
+ret = convert_sub_to_old_ass_form(sub, avpkt, tb);
+}
#endif
if (sub->num_rects && !sub->end_display_time && avpkt->duration &&
--
2.7.4
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: remove usage of avctx->time_base
On Mon, Mar 28, 2016 at 04:57:51PM +0200, Michael Niedermayer wrote:
> On Mon, Mar 28, 2016 at 02:10:51PM +0200, Clément Bœsch wrote:
> > lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q
> > before calling the decode callback. This prevents from rescaling again
> > into the decoder, and avoid the use of avctx->time_base which will
> > disappear in the incoming codecpar merge.
> >
> > This commit also replaces the use of "20 centisecond" (ass time base)
> > with "200 ms".
> > ---
> > libavcodec/ccaption_dec.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
>
> with
> ./ffmpeg -f lavfi -i "movie=Starship_Troopers.vob[out0+subcc]" -vn -map s
> out.srt
>
> this causes a moderate change in the timings
> is that intended ?
>
Nope, that was a bug, thanks for noticing. It appears FATE isn't enough...
New patch attached.
[...]
--
Clément B.
From 1c79debbb09c0ed8f1d771cc4224248351f4cea2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?=
Date: Mon, 28 Mar 2016 14:10:08 +0200
Subject: [PATCH 1/2] lavc/ccaption_dec: remove usage of avctx->time_base
lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q
before calling the decode callback. This prevents from rescaling again
into the decoder, and avoid the use of avctx->time_base which will
disappear in the incoming codecpar merge.
This commit also replaces the use of "20 centisecond" (ass time base)
with "200 ms".
---
libavcodec/ccaption_dec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index d3f32dd..3b15149 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -30,7 +30,7 @@
#define UNSET_FLAG(var, val) ( (var) &= ~( 1 << (val)) )
#define CHECK_FLAG(var, val) ( (var) &( 1 << (val)) )
-static const AVRational ass_tb = {1, 100};
+static const AVRational ms_tb = {1, 1000};
/*
* TODO list
@@ -723,6 +723,7 @@ static int decode(AVCodecContext *avctx, void *data, int *got_sub, AVPacket *avp
{
CCaptionSubContext *ctx = avctx->priv_data;
AVSubtitle *sub = data;
+const int64_t start_time = sub->pts;
uint8_t *bptr = NULL;
int len = avpkt->size;
int ret = 0;
@@ -747,7 +748,7 @@ static int decode(AVCodecContext *avctx, void *data, int *got_sub, AVPacket *avp
if(cc_type == 1)
continue;
else
-process_cc608(ctx, avpkt->pts, *(bptr + i + 1) & 0x7f, *(bptr + i + 2) & 0x7f);
+process_cc608(ctx, start_time, *(bptr + i + 1) & 0x7f, *(bptr + i + 2) & 0x7f);
if (!ctx->buffer_changed)
continue;
@@ -759,21 +760,21 @@ static int decode(AVCodecContext *avctx, void *data, int *got_sub, AVPacket *avp
ret = ff_ass_add_rect(sub, ctx->buffer.str, ctx->readorder++, 0, NULL, NULL);
if (ret < 0)
return ret;
-sub->pts = av_rescale_q(ctx->start_time, avctx->time_base, AV_TIME_BASE_Q);
+sub->pts = ctx->start_time;
if (!ctx->real_time)
sub->end_display_time = av_rescale_q(ctx->end_time - ctx->start_time,
- avctx->time_base, av_make_q(1, 1000));
+ AV_TIME_BASE_Q, ms_tb);
else
sub->end_display_time = -1;
ctx->buffer_changed = 0;
-ctx->last_real_time = avpkt->pts;
+ctx->last_real_time = sub->pts;
ctx->screen_touched = 0;
}
}
if (ctx->real_time && ctx->screen_touched &&
-avpkt->pts > ctx->last_real_time + av_rescale_q(20, ass_tb, avctx->time_base)) {
-ctx->last_real_time = avpkt->pts;
+sub->pts > ctx->last_real_time + av_rescale_q(200, ms_tb, AV_TIME_BASE_Q)) {
+ctx->last_real_time = sub->pts;
ctx->screen_touched = 0;
capture_screen(ctx);
--
2.7.4
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/ccaption_dec: remove usage of avctx->time_base
lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q
before calling the decode callback. This prevents from rescaling again
into the decoder, and avoid the use of avctx->time_base which will
disappear in the incoming codecpar merge.
This commit also replaces the use of "20 centisecond" (ass time base)
with "200 ms".
---
libavcodec/ccaption_dec.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index d3f32dd..dfc17a1 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -30,7 +30,7 @@
#define UNSET_FLAG(var, val) ( (var) &= ~( 1 << (val)) )
#define CHECK_FLAG(var, val) ( (var) &( 1 << (val)) )
-static const AVRational ass_tb = {1, 100};
+static const AVRational ms_tb = {1, 1000};
/*
* TODO list
@@ -747,7 +747,7 @@ static int decode(AVCodecContext *avctx, void *data, int
*got_sub, AVPacket *avp
if(cc_type == 1)
continue;
else
-process_cc608(ctx, avpkt->pts, *(bptr + i + 1) & 0x7f, *(bptr + i
+ 2) & 0x7f);
+process_cc608(ctx, sub->pts, *(bptr + i + 1) & 0x7f, *(bptr + i +
2) & 0x7f);
if (!ctx->buffer_changed)
continue;
@@ -759,21 +759,21 @@ static int decode(AVCodecContext *avctx, void *data, int
*got_sub, AVPacket *avp
ret = ff_ass_add_rect(sub, ctx->buffer.str, ctx->readorder++, 0,
NULL, NULL);
if (ret < 0)
return ret;
-sub->pts = av_rescale_q(ctx->start_time, avctx->time_base,
AV_TIME_BASE_Q);
+sub->pts = ctx->start_time;
if (!ctx->real_time)
sub->end_display_time = av_rescale_q(ctx->end_time -
ctx->start_time,
- avctx->time_base,
av_make_q(1, 1000));
+ AV_TIME_BASE_Q, ms_tb);
else
sub->end_display_time = -1;
ctx->buffer_changed = 0;
-ctx->last_real_time = avpkt->pts;
+ctx->last_real_time = sub->pts;
ctx->screen_touched = 0;
}
}
if (ctx->real_time && ctx->screen_touched &&
-avpkt->pts > ctx->last_real_time + av_rescale_q(20, ass_tb,
avctx->time_base)) {
-ctx->last_real_time = avpkt->pts;
+sub->pts > ctx->last_real_time + av_rescale_q(200, ms_tb,
AV_TIME_BASE_Q)) {
+ctx->last_real_time = sub->pts;
ctx->screen_touched = 0;
capture_screen(ctx);
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/utils: use pkt_timebase for legacy subtitles timing code
This is consistent with other AVSubtitle timing adjustments.
---
libavcodec/utils.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index c625bbc..2c8fc9c 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2582,8 +2582,13 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
AVSubtitle *sub,
#if FF_API_ASS_TIMING
if (avctx->sub_text_format == FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS
-&& *got_sub_ptr && sub->num_rects)
-ret = convert_sub_to_old_ass_form(sub, avpkt,
avctx->time_base);
+&& *got_sub_ptr && sub->num_rects) {
+if (!avctx->pkt_timebase.num) {
+av_log(avctx, AV_LOG_ERROR, "packet time base not set\n");
+return AVERROR_BUG;
+}
+ret = convert_sub_to_old_ass_form(sub, avpkt,
avctx->pkt_timebase);
+}
#endif
if (sub->num_rects && !sub->end_display_time && avpkt->duration &&
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
