Re: [FFmpeg-devel] [PATCH 1/2] avutil/log: added av_log_format_line2 which returns buffer length

[Michael Niedermayer]

On Mon, Apr 25, 2016 at 08:32:23AM +0200, der_ghul...@ghulbus-inc.de wrote:
> From: Andreas Weis 
> 
> The new function behaves the same as av_log_format_line, but also forwards
> the return value from the underlying snprintf call. This will allow
> callers to accurately determine the size requirements for the line buffer.
> 
> Signed-off-by: Andreas Weis 
> ---
>  libavutil/log.c | 11 ++-
>  libavutil/log.h | 17 +
>  2 files changed, 27 insertions(+), 1 deletion(-)

the addition of a public function need a minor version bump and
APIChanges entry

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

[Matt Oliver]

On 26 April 2016 at 01:49, Carl Eugen Hoyos  wrote:

> Matt Oliver  gmail.com> writes:
>
> > Even so icl does also suffer from issues when using lto
> > with optimised builds aswell so its not just limited to
> > debug builds.
>
> Can you confirm that this is Windows-only, ie that lto
> works fine on Linux with the Intel compiler?
> (It did work fine when I last tested.)
>

I dont have icc in front of me at the moment but last time i checked it was
fine as its meant to interop with gcc so it often functions similarly. On
the other hand icl is designed to interop with msvc so as a result can
suffer from similar issues.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] qsvenc_hevc: Fix usage of ff_hevc_extract_rbsp

[Michael Niedermayer]

On Tue, Apr 26, 2016 at 12:00:16AM +0100, Derek Buitenhuis wrote:
> On 4/25/2016 11:37 PM, Michael Niedermayer wrote:
> > i cant easily test this but does this need a
> > av_freep of skipped_bytes_pos somewhere ?
> > 
> > otherwise it should be ok
> 
> I cannot easily test it either, unfortunately.
> 
> I'm not sure why it would, though (without having looked very hard).

ive missed that the av_reallocp_array is under a skipped_bytes_pos!=NULL
check

so it should be ok

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] qsvenc_hevc: Fix usage of ff_hevc_extract_rbsp

[Derek Buitenhuis]

On 4/25/2016 11:37 PM, Michael Niedermayer wrote:
> i cant easily test this but does this need a
> av_freep of skipped_bytes_pos somewhere ?
> 
> otherwise it should be ok

I cannot easily test it either, unfortunately.

I'm not sure why it would, though (without having looked very hard).

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

Re: [FFmpeg-devel] [PATCH] qsvenc_hevc: Fix usage of ff_hevc_extract_rbsp

[Michael Niedermayer]

On Mon, Apr 25, 2016 at 08:04:44PM +0100, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis 
> ---
> grep reveals no other usages.
> ---
>  libavcodec/qsvenc_hevc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> index 30fde72..e0bead9 100644
> --- a/libavcodec/qsvenc_hevc.c
> +++ b/libavcodec/qsvenc_hevc.c
> @@ -68,7 +68,7 @@ static int generate_fake_vps(QSVEncContext *q, 
> AVCodecContext *avctx)
>  }
>  
>  /* parse the SPS */
> -ret = ff_hevc_extract_rbsp(NULL, avctx->extradata + 4, 
> avctx->extradata_size - 4, _nal);
> +ret = ff_hevc_extract_rbsp(avctx->extradata + 4, avctx->extradata_size - 
> 4, _nal);
>  if (ret < 0) {
>  av_log(avctx, AV_LOG_ERROR, "Error unescaping the SPS buffer\n");
>  return ret;

i cant easily test this but does this need a
av_freep of skipped_bytes_pos somewhere ?

otherwise it should be ok

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH] configure: Don't require nonfree for nvenc

[Timo Rothenpieler]

ping

I'd really like some feedback on this.



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

Re: [FFmpeg-devel] [PATCH] lavc/hevc_parse: Don't take a HEVCContext

[Derek Buitenhuis]

On 4/25/2016 7:50 PM, John Warburton wrote:
> Is it possible that this patch, particularly to libavcodec/hevc.h, is
> causing my compilation error today, cross-compiling using mingw-w64
> and gcc-5.3.0 from GNU/Linux to Windows 64-bit?

Yes it looks as if qsv also called that, and I missed it.

I have sent a patch to fix it.

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

Re: [FFmpeg-devel] [PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"

[Andrey Utkin]

On Mon, Apr 25, 2016 at 04:35:03PM +0200, Nicolas George wrote:
> Thanks for sending it again. I find my version is simpler, and it is
> probably closer to what it will look like when migrating to the new API. If
> that is fine with you, I would like to push it.

Your patch breaks a particular usecase, however my patch handles it well.

$FFMPEG -f lavfi -i testsrc -t 1 -x264opts stitchable=1 -c:v libx264 -y 
/tmp/testsrc.mp4
echo -e "ffconcat version 1.0
file /tmp/testsrc.mp4
" > /tmp/test.mp4.concat

$FFMPEG -safe 0 -i /tmp/test.mp4.concat -c copy -y /tmp/concat.ts

# Adding BSF explicitly doesn't affect the result
# $FFMPEG -safe 0 -i /tmp/test.mp4.concat -bsf h264_mp4toannexb -c copy -y 
/tmp/concat.ts



ffmpeg version N-79633-g4c0d0ff Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5)
  configuration: --disable-everything 
--prefix=/home/j/work/employers/pitneybowes/interval_transcoder/build 
--extra-libs='/home/j/work/employers/pitneybowes/interval_transcoder/build/lib/libx264.a
 /home/j/work/employers/pitneybowes/interval_transcoder/build/lib/libfreetype.a 
/home/j/work/employers/pitneybowes/interval_transcoder/build/lib/libfribidi.a' 
--extra-ldflags=-L/home/j/work/employers/pitneybowes/interval_transcoder/build 
--extra-cflags='-I/home/j/work/employers/pitneybowes/interval_transcoder/build/include
 -O3' --disable-debug --enable-static --enable-libfribidi --enable-libfreetype 
--enable-libx264 --enable-gpl --disable-doc --disable-libxcb --disable-xlib 
--disable-sdl --disable-lzma --disable-bzlib --enable-protocol=file 
--enable-protocol=pipe --enable-indev=lavfi --enable-muxer=mp4 
--enable-muxer=hls --enable-muxer=segment --enable-muxer=mpegts 
--enable-muxer=mjpeg --enable-muxer=image2 --enable-muxer=matroska 
--enable-muxer=rawvideo --enable-demuxer=mov --enable-demuxer=hls 
--enable-demuxer=mpegts --enable-demuxer=mjpeg --enable-demuxer=mp3 
--enable-demuxer=concat --enable-demuxer=image2 --enable-demuxer=matroska 
--enable-demuxer=rawvideo --enable-decoder=h264 --enable-decoder=mpeg4 
--enable-decoder=mpeg2video --enable-decoder=aac --enable-decoder=mp2 
--enable-decoder=mp3 --enable-decoder=mjpeg --enable-decoder=rawvideo 
--enable-decoder=pcm_f32le --enable-decoder=pcm_f64le 
--enable-decoder=pcm_s16le --enable-parser=h264 --enable-parser=mpeg4video 
--enable-parser=mjpeg --enable-parser=aac --enable-encoder=libx264 
--enable-encoder=aac --enable-encoder=mjpeg --enable-encoder=mpeg4 
--enable-encoder=rawvideo --enable-filter=scale --enable-filter=fps 
--enable-filter=drawtext --enable-filter=overlay --enable-filter=copy 
--enable-filter=crop --enable-filter=fade --enable-filter=testsrc 
--enable-filter=movie --enable-filter=amovie --enable-filter=setpts 
--enable-filter=asetpts --enable-filter=settb --enable-filter=asettb 
--enable-filter=concat --enable-filter=format --enable-filter=aformat 
--enable-filter=amix --enable-filter=aresample --enable-filter=null 
--enable-filter=nullsrc --enable-filter=nullsink --enable-filter=anull 
--enable-filter=anullsrc --enable-filter=anullsink --enable-filter=aevalsrc 
--enable-filter=loop --enable-filter=aloop --enable-filter=sendcmd 
--enable-filter=asendcmd --enable-filter=showinfo --enable-filter=volume 
--enable-filter=volumedetect --enable-filter=dynaudnorm --enable-filter=vflip 
--enable-filter=hflip --enable-filter=blend --enable-filter=pad 
--enable-filter=geq --enable-bsf=h264_mp4toannexb --enable-bsf=aac_adtstoasc 
--enable-bsf=dump_extradata --enable-bsf=remove_extradata
  libavutil  55. 22.101 / 55. 22.101
  libavcodec 57. 38.100 / 57. 38.100
  libavformat57. 34.103 / 57. 34.103
  libavdevice57.  0.101 / 57.  0.101
  libavfilter 6. 44.100 /  6. 44.100
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc54.  0.100 / 54.  0.100
Input #0, lavfi, from 'testsrc':
  Duration: N/A, start: 0.00, bitrate: N/A
Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 
1:1 DAR 4:3], 25 fps, 25 tbr, 25 tbn
No pixel format specified, yuv444p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0x2efa080] using SAR=1/1
[libx264 @ 0x2efa080] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 0x2efa080] profile High 4:4:4 Predictive, level 1.3, 4:4:4 8-bit
[libx264 @ 0x2efa080] 264 - core 148 r2692 64f4e24 - H.264/MPEG-4 AVC codec - 
Copyleft 2003-2016 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 
deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 
mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 
fast_pskip=1 chroma_qp_offset=4 threads=6 lookahead_threads=1 sliced_threads=0 
nr=0 decimate=1 interlaced=0 bluray_compat=0 stitchable=1 constrained_intra=0 
bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 
weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 

Re: [FFmpeg-devel] [PATCH] lavc/hevc_parse: Don't take a HEVCContext

[John Warburton]

Is it possible that this patch, particularly to libavcodec/hevc.h, is
causing my compilation error today, cross-compiling using mingw-w64
and gcc-5.3.0 from GNU/Linux to Windows 64-bit?

libavcodec/qsvenc_hevc.c: In function 'generate_fake_vps':
libavcodec/qsvenc_hevc.c:71:38: warning: passing argument 2 of
'ff_hevc_extract_rbsp' makes integer from pointer without a cast
[-Wint-conversion]
 ret = ff_hevc_extract_rbsp(NULL, avctx->extradata + 4,
avctx->extradata_size - 4, _nal);
  ^
In file included from libavcodec/qsvenc_hevc.c:33:0:
libavcodec/hevc.h:1083:5: note: expected 'int' but argument is of type
'uint8_t * {aka unsigned char *}'
 int ff_hevc_extract_rbsp(const uint8_t *src, int length,
 ^
libavcodec/qsvenc_hevc.c:71:60: warning: passing argument 3 of
'ff_hevc_extract_rbsp' makes pointer from integer without a cast
[-Wint-conversion]
 ret = ff_hevc_extract_rbsp(NULL, avctx->extradata + 4,
avctx->extradata_size - 4, _nal);
^
In file included from libavcodec/qsvenc_hevc.c:33:0:
libavcodec/hevc.h:1083:5: note: expected 'HEVCNAL * {aka struct
HEVCNAL *}' but argument is of type 'int'
 int ff_hevc_extract_rbsp(const uint8_t *src, int length,
 ^
libavcodec/qsvenc_hevc.c:71:11: error: too many arguments to function
'ff_hevc_extract_rbsp'
 ret = ff_hevc_extract_rbsp(NULL, avctx->extradata + 4,
avctx->extradata_size - 4, _nal);
   ^
In file included from libavcodec/qsvenc_hevc.c:33:0:
libavcodec/hevc.h:1083:5: note: declared here
 int ff_hevc_extract_rbsp(const uint8_t *src, int length,
 ^
common.mak:60: recipe for target 'libavcodec/qsvenc_hevc.o' failed
make: *** [libavcodec/qsvenc_hevc.o] Error 1
Build failure. Please see error messages above.

On Mon, Apr 25, 2016 at 5:27 PM, Michael Niedermayer
 wrote:
> On Mon, Apr 25, 2016 at 02:41:33PM +0100, Derek Buitenhuis wrote:
>>
>>  libavcodec/hevc.c|  2 +-
>>  libavcodec/hevc.h|  4 ++--
>>  libavcodec/hevc_parse.c  | 11 +--
>>  libavcodec/hevc_parser.c |  2 +-
>>  4 files changed, 9 insertions(+), 10 deletions(-)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Backporting commits from head 1) commit hash 15ef98afd10b3696d29fb6d19606ba03a9dd47ad (configure: build fix for P5600 with mips code restructuring) 2) commit hash ad16eff64b

[Michael Niedermayer]

On Mon, Apr 25, 2016 at 03:40:28PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil 
> 
> Signed-off-by: Shivraj Patil 
> ---
>  configure | 252 
> ++
>  libavcodec/mips/aaccoder_mips.c   |   4 +
>  libavcodec/mips/aacdec_mips.h |   2 +
>  libavcodec/mips/aacpsdsp_mips.c   |   4 +
>  libavcodec/mips/aacpsy_mips.h |   2 +
>  libavcodec/mips/aacsbr_mips.c |   4 +
>  libavcodec/mips/aacsbr_mips.h |   2 +
>  libavcodec/mips/ac3dsp_mips.c |   6 +-
>  libavcodec/mips/acelp_filters_mips.c  |   4 +
>  libavcodec/mips/acelp_vectors_mips.c  |   4 +
>  libavcodec/mips/amrwbdec_mips.c   |   2 +
>  libavcodec/mips/amrwbdec_mips.h   |   2 +
>  libavcodec/mips/celp_filters_mips.c   |   4 +
>  libavcodec/mips/celp_math_mips.c  |   4 +
>  libavcodec/mips/compute_antialias_float.h |   2 +
>  libavcodec/mips/fft_mips.c|   4 +
>  libavcodec/mips/iirfilter_mips.c  |   4 +
>  libavcodec/mips/lsp_mips.h|   2 +
>  libavcodec/mips/mpegaudiodsp_mips_fixed.c |  10 ++
>  libavcodec/mips/mpegaudiodsp_mips_float.c |  10 ++
>  libavcodec/mips/sbrdsp_mips.c |   4 +
>  libavutil/mips/float_dsp_mips.c   |   4 +
>  22 files changed, 203 insertions(+), 133 deletions(-)

why are the 2 commits combined ?

normally backporting 2 commits should result in 2 commits

[...]

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH v3 1/2] lavc/ccaption_dec: do not ignore repeated character commands

[Thierry Foucu]

On Tue, Apr 19, 2016 at 10:04 AM, Aman Gupta  wrote:

> This is a tricky one.. I tried your sample in VLC, and it has the same
> issue as the latest version of ffmpeg.
>
> The previous behavior of ffmpeg can be restored with the following patch:
>
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index 3b15149..9eff843 100644
> --- a/libavcodec/ccaption_dec.c
> +++ b/libavcodec/ccaption_dec.c
> @@ -712,7 +712,6 @@ static void process_cc608(CCaptionSubContext *ctx,
> int64_t pts, uint8_t hi, uint
>  } else if (hi >= 0x20) {
>  /* Standard characters (always in pairs) */
>  handle_char(ctx, hi, lo, pts);
> -ctx->prev_cmd[0] = ctx->prev_cmd[1] = 0;
>  } else {
>  /* Ignoring all other non data code */
>  ff_dlog(ctx, "Unknown command 0x%hhx 0x%hhx\n", hi, lo);
>

Thanks for looking into it.

Do you think it will make sense to have a flag to turn on/off such feature?
If so, i'm wiling to do the patch.


>
> However, I've encountered a number of samples where the same character is
> legitimately repeated and is not supposed to be skipped.
>
> For instance, the samples on
> http://hackipedia.org/ATSC/EIA-608%20samples/EIA-608%20character%20set%20test/
> (https://www.youtube.com/watch?v=8TZLxPdC3hk) repeat the character "."
> multiple times to show correct spacing.
>
> Similarly, there are an endless number of words in the english language
> with repeated characters, such as "ss" in endless and "rr" in correct.
>
> It is unclear to me how the decoder is supposed to distinguish between
> characters that are meant to be displayed twice, vs streams that repeat
> every ascii character unconditionally.
>
> Further, in your sample it appears that every command is repeated not
> twice (as is common in many streams for special character sets and other
> command, see
> http://hackipedia.org/ATSC/EIA-608%20samples/EIA-608%20character%20set%20test/README.TXT),
> but three times.
>
> Aman
>
> On Mon, Apr 18, 2016 at 1:01 PM, Aman Gupta  wrote:
>
>> Please send me the sample and I will try to fix the issue.
>>
>> Aman
>>
>> On Mon, Apr 18, 2016 at 1:22 PM Thierry Foucu  wrote:
>>
>>> Hi all
>>>
>>> On Sun, Feb 14, 2016 at 6:11 PM, Aman Gupta  wrote:
>>>
 From: Aman Gupta 

 control codes in a cc stream can be repeated, and must be ignored.
 however, repeated characters must not be ignored. the code attempted to
 wipe prev_cmd in handle_char to allow repeated characters to be
 processed, but prev_cmd would previously get reset _after_ handle_char()

 i also moved the prev_cmd reset out from handle_char() so it can be
 re-used for special character sets, which _must_ be ignored when
 repeated.
 ---
  libavcodec/ccaption_dec.c | 19 ++-
  1 file changed, 10 insertions(+), 9 deletions(-)

 diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
 index 790f071..5fb2ec6 100644
 --- a/libavcodec/ccaption_dec.c
 +++ b/libavcodec/ccaption_dec.c
 @@ -484,9 +484,6 @@ static void handle_char(CCaptionSubContext *ctx,
 char hi, char lo, int64_t pts)
  if (ctx->mode != CCMODE_POPON)
  ctx->screen_touched = 1;

 -/* reset prev command since character can repeat */
 -ctx->prev_cmd[0] = 0;
 -ctx->prev_cmd[1] = 0;
  if (lo)
 ff_dlog(ctx, "(%c,%c)\n", hi, lo);
  else
 @@ -497,8 +494,15 @@ static void process_cc608(CCaptionSubContext *ctx,
 int64_t pts, uint8_t hi, uint
  {
  if (hi == ctx->prev_cmd[0] && lo == ctx->prev_cmd[1]) {
  /* ignore redundant command */
 -} else if ( (hi == 0x10 && (lo >= 0x40 && lo <= 0x5f)) ||
 -  ( (hi >= 0x11 && hi <= 0x17) && (lo >= 0x40 && lo <=
 0x7f) ) ) {
 +return;
 +}
 +
 +/* set prev command */
 +ctx->prev_cmd[0] = hi;
 +ctx->prev_cmd[1] = lo;
 +
 +if ( (hi == 0x10 && (lo >= 0x40 && lo <= 0x5f)) ||
 +   ( (hi >= 0x11 && hi <= 0x17) && (lo >= 0x40 && lo <= 0x7f) ) ) {
  handle_pac(ctx, hi, lo);
  } else if ( ( hi == 0x11 && lo >= 0x20 && lo <= 0x2f ) ||
  ( hi == 0x17 && lo >= 0x2e && lo <= 0x2f) ) {
 @@ -559,14 +563,11 @@ static void process_cc608(CCaptionSubContext
 *ctx, int64_t pts, uint8_t hi, uint
  } else if (hi >= 0x20) {
  /* Standard characters (always in pairs) */
  handle_char(ctx, hi, lo, pts);
 +ctx->prev_cmd[0] = ctx->prev_cmd[1] = 0;
  } else {
  /* Ignoring all other non data code */
  ff_dlog(ctx, "Unknown command 0x%hhx 0x%hhx\n", hi, lo);
  }
 -
 -/* set prev command */
 -ctx->prev_cmd[0] = hi;
 -ctx->prev_cmd[1] = lo;
  }

  static int decode(AVCodecContext *avctx, void 

Re: [FFmpeg-devel] libavcodec/exr : Fix slice threading

[James Almer]

On 4/23/2016 8:46 AM, Martin Vignali wrote:
> Hello,
> 
> Patch in attach, fix slice threading (reported by James Almer in
> "Libavcodec/exr : add support for tile" discussion)
> the xsize and ysize are now in the thread data instead of exr context.
> 
> Theses variables are used to store the real dimensions of a block (tile or
> scanline)
> specially in edge blocks.
> 
> For example can be tested with :
> ./ffmpeg -threads 2 -thread_type slice -i
> ./fate-suite/exr/rgba_multiscanline_half_b44.exr
> rgba_multiscanline_half_b44.png
> 
> or with
> 
> make fate-exr SAMPLES=fate-suite/ THREADS=2 THREAD_TYPE=slice
> 
> 
> Comments welcome
> 
> Martin
> Jokyo Images

Tested and applied, thanks.

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

Re: [FFmpeg-devel] [PATCH v2 01/12] lavc/videotoolboxenc: Use shared pixel buffer pool

[Richard Kern]

> On Apr 23, 2016, at 12:23 PM, Carl Eugen Hoyos  wrote:
> 
> Rick Kern  gmail.com> writes:
> 
>> +if(!*refPtr) return;
> 
> Is this needed (I don't know)?
> If yes, please make it two lines.
> 
>> +CFRelease(*refPtr);
>> +*refPtr = NULL;
>> +switch (fmt) {
>> +case AV_PIX_FMT_NV12:
>> +switch (range) {
>> +case AVCOL_RANGE_MPEG:
>> +*av_pixel_format = 
>> kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
>> +break;
>> +
>> +case AVCOL_RANGE_JPEG:
>> +*av_pixel_format = 
>> kCVPixelFormatType_420YpCbCr8BiPlanarFullRange;
>> +break;
>> +
>> +default:
>> +if (range_guessed) *range_guessed = 1;
>> +*av_pixel_format = 
>> kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
> 
> You can rearrange this to make the patch smaller (and 
> the default case easier to read).
> Same below.
> 
>> static const enum AVPixelFormat pix_fmts[] = {
>> AV_PIX_FMT_NV12,
>> -#if !TARGET_OS_IPHONE
>> AV_PIX_FMT_YUV420P,
>> -#endif
>> AV_PIX_FMT_NONE
> 
> Sorry: How is this related?
Using a shared pixel buffer pool also sets up an internal color converter when 
needed.

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

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

Re: [FFmpeg-devel] [PATCH v2 03/12] lavc/videotoolboxenc: Require hardware encoding

[Richard Kern]

> On Apr 23, 2016, at 12:25 PM, Carl Eugen Hoyos  wrote:
> 
> Rick Kern  gmail.com> writes:
> 
>> +#if !TARGET_OS_IPHONE
>> +{ "allow_sw", "Allow software encoding", OFFSET(allow_sw), 
> 
> I have no strong opinion, but shouldn't the option 
> always exist (but only work in some cases)?
iOS doesn’t support software encoding, and the dictionary keys to allow it 
aren’t part of the headers.

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

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

Re: [FFmpeg-devel] [PATCH] lavc/hevc_parse: Don't take a HEVCContext

[Michael Niedermayer]

On Mon, Apr 25, 2016 at 02:41:33PM +0100, Derek Buitenhuis wrote:
> It's not even used anymore, and the checks are no longer
> functionally important.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/hevc.c|  2 +-
>  libavcodec/hevc.h|  4 ++--
>  libavcodec/hevc_parse.c  | 11 +--
>  libavcodec/hevc_parser.c |  2 +-
>  4 files changed, 9 insertions(+), 10 deletions(-)

should be ok

thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

[Derek Buitenhuis]

On 4/25/2016 4:49 PM, Carl Eugen Hoyos wrote:
> Can you confirm that this is Windows-only, ie that lto 
> works fine on Linux with the Intel compiler?
> (It did work fine when I last tested.)

FWIW, I've had issues with LTO on Linux, with clang and gold, due to (lack of) 
DCE.

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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

[Hendrik Leppkes]

On Mon, Apr 25, 2016 at 5:44 PM, Ivan Uskov  wrote:
> Hello Derek,
>
> Monday, April 25, 2016, 4:50:28 PM, you wrote:
>
> DB> On 4/25/2016 2:14 PM, Ivan Uskov wrote:
>>> The   attached  patch  does  fixes  the  issue  of  frames  duplication when
>>> elementary h.264 stream decodes by qsvdec.
>
> DB> Could you perhaps elaborate in the commit message, and a code comment, on
> DB> why it must be 2? Where does that value come from, etc.
> I do not see a necessity for additional comments because
> AVCodecContext::ticks_per_frame is public API and already enough documented:
> https://ffmpeg.org/doxygen/2.8/structAVCodecContext.html#a5c62b9c1528a272923ea2a4b86dea31a
>

Its not about what the field does, but why this is needed here. So
please explain why its set here, and only for this case.

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

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

[Carl Eugen Hoyos]

Matt Oliver  gmail.com> writes:

> Even so icl does also suffer from issues when using lto 
> with optimised builds aswell so its not just limited to 
> debug builds.

Can you confirm that this is Windows-only, ie that lto 
works fine on Linux with the Intel compiler?
(It did work fine when I last tested.)

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

[Ivan Uskov]

Hello Derek,

Monday, April 25, 2016, 4:50:28 PM, you wrote:

DB> On 4/25/2016 2:14 PM, Ivan Uskov wrote:
>> The   attached  patch  does  fixes  the  issue  of  frames  duplication when
>> elementary h.264 stream decodes by qsvdec.

DB> Could you perhaps elaborate in the commit message, and a code comment, on
DB> why it must be 2? Where does that value come from, etc.
I do not see a necessity for additional comments because
AVCodecContext::ticks_per_frame is public API and already enough documented:
https://ffmpeg.org/doxygen/2.8/structAVCodecContext.html#a5c62b9c1528a272923ea2a4b86dea31a



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

[Matt Oliver]

On 25 April 2016 at 20:42, Michael Niedermayer 
wrote:

> On Mon, Apr 25, 2016 at 06:17:22PM +1000, Matt Oliver wrote:
> > On 23 April 2016 at 23:46, wm4  wrote:
> >
> > > On Sat, 23 Apr 2016 14:52:12 +0200
> > > Reimar Döffinger  wrote:
> > >
> > > > On 23.04.2016, at 13:21, wm4  wrote:
> > > >
> > > > > On Sat, 23 Apr 2016 01:16:31 +0200
> > > > > Hendrik Leppkes  wrote:
> > > > >
> > > > >> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
> > > > >>  wrote:
> > > > >>> I've noticed that when CONFIG_W64_DEMUXER is defined to zero that
> > > ffmpeg
> > > > >>> compiles in a reference to ff_w64_guid_data but doesn't not link
> > > w64.o
> > > > >>> (which defines that symbol).
> > > > >>>
> > > > >>> This normally works because most optimizers discard the reference
> > > > >>> to ff_w64_guid_data early enough to not cause a linker failure.
> > > However
> > > > >>> this assumption means that /Od (debug, unoptimized) and /GL (Link
> > > Time Code
> > > > >>> Generation - super optimized) builds with VC++ don't work.
> > > > >>>
> > > > >>
> > > > >> We require dead code elimination to be available in all build
> modes,
> > > > >> therefor such build settings that do not have it are not
> supported.
> > > > >> This is not the only place that uses this, and its a design
> decision
> > > > >> to rely on it, therefor we won't be accepting patches to change
> that
> > > > >> at this time, sorry.
> > > > >
> > > > > Why not? Someone just volunteered to cleanup this non-sense, so
> why not
> > > > > let them?
> > > >
> > > > Because it ends up with a horrible ifdef mess and also means that
> > > disabled parts will not even be checked for syntax.
> > > > I.e. the reasons why we did it this way.
> > >
> > > Pretty weak considering there are 3961 #ifs in the code (this excludes
> > > header file inclusion guards). This is because we readily allow
> > > disabling _any_ component because someone might not need it. We also
> > > have a big ifdef mess to switch between enabling and disabling
> > > deprecated APIs and their implementation or use within ffmpeg.
> > >
> > > There's even --enable-random, which is supposed to help with finding
> > > some of the configurations which don't even compile, out of
> > > the practically infinite number possible configurations.
> > >
> > > On the other hand, mere compilation failures on other architectures
> > > (which this idiom is supposed to catch) are easily detected by the
> > > numerous fate instances we run.
> > >
> > > In conclusion, this change would be pretty harmless compared to the
> > > ifdef mess we have for _way_ less legitimate use-cases.
> > >
> > > The add to this, we don't even need to use #ifdefs. Some sort of
> > > selection macro could achieve the same thing:
> > >
> > > #define CONCAT(a, b) a ## b
> > >
> > > #define VALUE0(a, b) a
> > > #define VALUE1(a, b) b
> > > #define TOK(v) CONCAT(VALUE, v)
> > >
> > > #define SELECT(v, a, b) TOK(v)(a, b)
> > >
> > > #define HAVE_SOMETHING 1
> > >
> > > SELECT(HAVE_SOMETHING, yes, no)
> > >
> > > So syntactically we could get something relatively elegant.
> > >
> > > I also want to remind that the reliance on DCE makes it a nightmare
> > > trying to compile an actually debugable ffmpeg binary.
> > >
> > > Though I agree with nev's comment that we should make a conscious
> > > decision to change this, rather than accepting random patches which
> > > just make things inconsistent.
> > >
> > > > > We may have been arguing that every compiler supports this level of
> > > > > DCE, but experience has been clearly showing that this is not
> always
> > > the
> > > > > case due to various reasons.
> > > >
> > > > I don't that was quite the argument. It is more a question if the
> rare
> > > cases are really worth the cost, especially when also the compilers
> could
> > > be changed to support this method of code configuration.
> > >
> > > The compilers have no reason to change here, as ffmpeg essentially
> > > violates the C standard with this idiom.
> > >
> >
> > Fixing one case isnt really an option as there are many DCE cases
> > throughout ffmpeg that all have the same issues (as previously stated).
> > Currently it is not possible to build ffmpeg with msvc using a debug or
> lto
> > build as it will just result in dozens if not hundreds of linker errors
> > (depending on the compiler version and options used). And the
> configuration
> > options here dont really matter as there are fundamentally missing
> > functions (h264_vaapi etc.) that are not available on windows and so
> > generate link errors no matter what you do.
> >
> > Obviously changing things would require a consensus from all the devs.
> > Personally I would like to see the DCE stuff removed as currently as
> stated
> > debug or lto builds will fail with msvc and these are both options that
> are
> > support 

Re: [FFmpeg-devel] [PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"

[Nicolas George]

Le septidi 7 floréal, an CCXXIV, Andrey Utkin a écrit :
> This is my patch which has stuck waiting for premoderation.
> 
> - Forwarded message from Andrey Utkin  -
> 
> From: Andrey Utkin 
> To: ffmpeg-devel@ffmpeg.org
> CC: andrey_ut...@fastmail.com, Carl Eugen Hoyos , Andrey 
> Utkin 
> Date: Sun, 24 Apr 2016 16:28:38 +0300
> Subject: [PATCH] concatdec: Fix handling of H.264 in MP4 in case of 
> "-auto_convert 0"
> 
> Bug ticket: http://trac.ffmpeg.org/ticket/5461
> This fix enables back the ability to concat appropriately encoded
> (with "-x264opts stitchable=1") MP4 files in less time, without conversion to
> mpegts and back.
> ---8<---
> Fixes regression bug #5461.
> ---
>  libavformat/concatdec.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)

Thanks for sending it again. I find my version is simpler, and it is
probably closer to what it will look like when migrating to the new API. If
that is fine with you, I would like to push it.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] lavc/hevc_parse: Don't take a HEVCContext

[Derek Buitenhuis]

It's not even used anymore, and the checks are no longer
functionally important.

Signed-off-by: Derek Buitenhuis 
---
 libavcodec/hevc.c|  2 +-
 libavcodec/hevc.h|  4 ++--
 libavcodec/hevc_parse.c  | 11 +--
 libavcodec/hevc_parser.c |  2 +-
 4 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 0d53a33..785aa7e 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2866,7 +2866,7 @@ static int decode_nal_units(HEVCContext *s, const uint8_t 
*buf, int length)
 
 /* split the input packet into NAL units, so we know the upper bound on the
  * number of slices in the frame */
-ret = ff_hevc_split_packet(s, >pkt, buf, length, s->avctx, s->is_nalff,
+ret = ff_hevc_split_packet(>pkt, buf, length, s->avctx, s->is_nalff,
s->nal_length_size);
 if (ret < 0) {
 av_log(s->avctx, AV_LOG_ERROR,
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index c91f815..5865f65 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -1080,13 +1080,13 @@ void ff_hevc_hls_mvd_coding(HEVCContext *s, int x0, int 
y0, int log2_cb_size);
 /**
  * Extract the raw (unescaped) HEVC bitstream.
  */
-int ff_hevc_extract_rbsp(HEVCContext *s, const uint8_t *src, int length,
+int ff_hevc_extract_rbsp(const uint8_t *src, int length,
  HEVCNAL *nal);
 
 /**
  * Split an input packet into NAL units.
  */
-int ff_hevc_split_packet(HEVCContext *s, HEVCPacket *pkt, const uint8_t *buf, 
int length,
+int ff_hevc_split_packet(HEVCPacket *pkt, const uint8_t *buf, int length,
  AVCodecContext *avctx, int is_nalff, int 
nal_length_size);
 
 int ff_hevc_encode_nal_vps(HEVCVPS *vps, unsigned int id,
diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
index d557cc7..6ee8496 100644
--- a/libavcodec/hevc_parse.c
+++ b/libavcodec/hevc_parse.c
@@ -29,14 +29,13 @@
 
 /* FIXME: This is adapted from ff_h264_decode_nal, avoiding duplication
  * between these functions would be nice. */
-int ff_hevc_extract_rbsp(HEVCContext *s, const uint8_t *src, int length,
+int ff_hevc_extract_rbsp(const uint8_t *src, int length,
  HEVCNAL *nal)
 {
 int i, si, di;
 uint8_t *dst;
 
-if (s)
-nal->skipped_bytes = 0;
+nal->skipped_bytes = 0;
 #define STARTCODE_TEST  \
 if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) { \
 if (src[i + 2] != 3) {  \
@@ -110,7 +109,7 @@ int ff_hevc_extract_rbsp(HEVCContext *s, const uint8_t 
*src, int length,
 dst[di++] = 0;
 si   += 3;
 
-if (s && nal->skipped_bytes_pos) {
+if (nal->skipped_bytes_pos) {
 nal->skipped_bytes++;
 if (nal->skipped_bytes_pos_size < nal->skipped_bytes) {
 nal->skipped_bytes_pos_size *= 2;
@@ -205,7 +204,7 @@ static int hls_nal_unit(HEVCNAL *nal, AVCodecContext *avctx)
 }
 
 
-int ff_hevc_split_packet(HEVCContext *s, HEVCPacket *pkt, const uint8_t *buf, 
int length,
+int ff_hevc_split_packet(HEVCPacket *pkt, const uint8_t *buf, int length,
  AVCodecContext *avctx, int is_nalff, int 
nal_length_size)
 {
 int consumed, ret = 0;
@@ -269,7 +268,7 @@ int ff_hevc_split_packet(HEVCContext *s, HEVCPacket *pkt, 
const uint8_t *buf, in
 }
 nal = >nals[pkt->nb_nals];
 
-consumed = ff_hevc_extract_rbsp(s, buf, extract_length, nal);
+consumed = ff_hevc_extract_rbsp(buf, extract_length, nal);
 if (consumed < 0)
 return consumed;
 
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 4625e61..59893bb 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -239,7 +239,7 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 src_length = 20;
 }
 
-consumed = ff_hevc_extract_rbsp(NULL, buf, src_length, nal);
+consumed = ff_hevc_extract_rbsp(buf, src_length, nal);
 if (consumed < 0)
 return consumed;
 
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

[Derek Buitenhuis]

On 4/25/2016 2:14 PM, Ivan Uskov wrote:
> The   attached  patch  does  fixes  the  issue  of  frames  duplication when
> elementary h.264 stream decodes by qsvdec.

Could you perhaps elaborate in the commit message, and a code comment, on
why it must be 2? Where does that value come from, etc.

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

[FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: Restoring decoding functionality after unsuccessful merge from libav.

[Ivan Uskov]

Hello All,

After   commit  d30cf57a7b2097b565db02ecfffbdc9c16423d0e  qsv-based  decoding
aborts  with  crash,  there  are many incorrect places appeared. The attached
patch fixes the issues but keeps new method of the 'sync' variable allocation
introduced in commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e.

Please review.


  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec.c-Restoring-decoding-functionality.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"

[Andrey Utkin]

This is my patch which has stuck waiting for premoderation.

- Forwarded message from Andrey Utkin  -

From: Andrey Utkin 
To: ffmpeg-devel@ffmpeg.org
CC: andrey_ut...@fastmail.com, Carl Eugen Hoyos , Andrey 
Utkin 
Date: Sun, 24 Apr 2016 16:28:38 +0300
Subject: [PATCH] concatdec: Fix handling of H.264 in MP4 in case of 
"-auto_convert 0"

Bug ticket: http://trac.ffmpeg.org/ticket/5461
This fix enables back the ability to concat appropriately encoded
(with "-x264opts stitchable=1") MP4 files in less time, without conversion to
mpegts and back.
---8<---
Fixes regression bug #5461.
---
 libavformat/concatdec.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index e3418e1..7ae4030 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -161,7 +161,8 @@ fail:
 return ret;
 }

-static int copy_stream_props(AVStream *st, AVStream *source_st)
+static int copy_stream_props(ConcatContext *cat, AVStream *st,
+ AVStream *source_st)
 {
 int ret;

@@ -182,8 +183,8 @@ static int copy_stream_props(AVStream *st, AVStream 
*source_st)
 }
 if ((ret = avcodec_parameters_copy(st->codecpar, source_st->codecpar)) < 0)
 return ret;
-/* We don't want to carry around MP4-style extradata, since we are usoign 
a bsf anyway. */
-if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
+if (cat->auto_convert && st->codecpar->codec_id == AV_CODEC_ID_H264) {
+/* We don't want to carry around MP4-style extradata, since we are 
using a bsf anyway. */
 av_freep(>codecpar->extradata);
 st->codecpar->extradata_size = 0;
 }
@@ -242,7 +243,7 @@ static int match_streams_one_to_one(AVFormatContext *avf)
 if (!(st = avformat_new_stream(avf, NULL)))
 return AVERROR(ENOMEM);
 }
-if ((ret = copy_stream_props(st, cat->avf->streams[i])) < 0)
+if ((ret = copy_stream_props(cat, st, cat->avf->streams[i])) < 0)
 return ret;
 cat->cur_file->streams[i].out_stream_index = i;
 }
@@ -262,7 +263,7 @@ static int match_streams_exact_id(AVFormatContext *avf)
 av_log(avf, AV_LOG_VERBOSE,
"Match slave stream #%d with stream #%d id 0x%x\n",
i, j, st->id);
-if ((ret = copy_stream_props(avf->streams[j], st)) < 0)
+if ((ret = copy_stream_props(cat, avf->streams[j], st)) < 0)
 return ret;
 cat->cur_file->streams[i].out_stream_index = j;
 }
--
2.8.1





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

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

[Derek Buitenhuis]

On 4/25/2016 1:09 PM, Nicolas George wrote:
> Indeed, I had made a note to look into it, if only to silence the warnings,
> and it seems the new API does the right thing. That will take a little time,
> though, it would probably be better to have the fix immediately.

I'm not opposed to it, as long as the API conversion is done in a reasonable
amount of time.

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

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

[Nicolas George]

Le septidi 7 floréal, an CCXXIV, Hendrik Leppkes a écrit :
> concatdec should be converted to the new BSF API, which should clear
> and/or replace the extradata itself then IIRC.

Indeed, I had made a note to look into it, if only to silence the warnings,
and it seems the new API does the right thing. That will take a little time,
though, it would probably be better to have the fix immediately.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

[Hendrik Leppkes]

On Mon, Apr 25, 2016 at 1:59 PM, Nicolas George  wrote:
> Le sextidi 6 floréal, an CCXXIV, Derek Buitenhuis a écrit :
>> Removing this causes failures when concatdec is used to concat two H.264
>> streams from an MP4 source, when remuxed, IIRC.
>>
>> Example: https://trac.ffmpeg.org/raw-attachment/ticket/3108/examplefiles.zip
>>
>> ./ffmpeg -f concat -i tickets/3108/concatfile.txt -codec copy out.mp4
>
> This one seems to work, but remuxing to Matroska shows problem, even with
> H.264 encoded from testsrc.
>
> I fixed it by clearing the extradata at the place where the bistream filter
> is inserted, since the bsf API does not do it. See the attached patch, to be
> applied on top of the small revert.
>

concatdec should be converted to the new BSF API, which should clear
and/or replace the extradata itself then IIRC.

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

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

[Nicolas George]

Le sextidi 6 floréal, an CCXXIV, Derek Buitenhuis a écrit :
> Removing this causes failures when concatdec is used to concat two H.264
> streams from an MP4 source, when remuxed, IIRC.
> 
> Example: https://trac.ffmpeg.org/raw-attachment/ticket/3108/examplefiles.zip
> 
> ./ffmpeg -f concat -i tickets/3108/concatfile.txt -codec copy out.mp4

This one seems to work, but remuxing to Matroska shows problem, even with
H.264 encoded from testsrc.

I fixed it by clearing the extradata at the place where the bistream filter
is inserted, since the bsf API does not do it. See the attached patch, to be
applied on top of the small revert.

Andrey, is it similar to what you proposed?

Note to self or others: TODO: add FATE tests, including the stitchable case.

Regards,

-- 
  Nicolas George
From fbccc4c2a1fa4830d0b8846404baaeadf6a2da98 Mon Sep 17 00:00:00 2001
From: Nicolas George 
Date: Mon, 25 Apr 2016 13:46:10 +0200
Subject: [PATCH] lavf/concatdec: clear extradata when inserting
 h264_mp4toannexb bsf.

Fix remuxing H.264-in-MP4 to Matroska, possibly others.

Signed-off-by: Nicolas George 
---
 libavformat/concatdec.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index b2bab55..b3a430e 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -214,6 +214,12 @@ static int detect_stream_specific(AVFormatContext *avf, int idx)
 if (!cs->avctx)
 return AVERROR(ENOMEM);
 
+/* This really should be part of the bsf work.
+   Note: input bitstream filtering will not work with bsf that
+   create extradata from the first packet. */
+av_freep(>codecpar->extradata);
+st->codecpar->extradata_size = 0;
+
 ret = avcodec_parameters_to_context(cs->avctx, st->codecpar);
 if (ret < 0) {
 avcodec_free_context(>avctx);
-- 
2.8.0.rc3



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

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

[Hendrik Leppkes]

On Mon, Apr 25, 2016 at 1:09 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Mon, Apr 25, 2016 at 1:17 AM, Matt Oliver  wrote:
>
>> Obviously changing things would require a consensus from all the devs.
>> Personally I would like to see the DCE stuff removed as currently as stated
>> debug or lto builds will fail with msvc and these are both options that are
>> support by the configure script yet wont actually build without errors
>> until DCE is removed. Ive also seen similar issues when using icl as well
>> so although some may state there advantages to DCE it is fundamentally
>> breaking things on certain platforms so it should be decided what is more
>> important.
>
>
> The discussion has so far always centered around the fact that DCE is
> available on all platforms we support. The same reason was given to use C99
> as a baseline.
>
> When it turned out that Microsoft had incompetent leaders in their compiler
> team, we wrote the converter for them, and the humiliation worked, MSVC
> supports C99 now.
>
> I'm estimating that writing a DCE converter would take as little as a tenth
> of the time it took us to wrote the C99 converter. Public embarrassment
> works really well in some situations, and Microsoft is in clear need of it.
>

Honestly I don't think these situations are comparable. There is no C
specification that mandates DCE to be executed in a debug build.
Relying on it happens to work on some compilers, but fails on others.
I wouldn't claim those where it fails in debug are necessarily
"broken".

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

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

[Ronald S. Bultje]

Hi,

On Mon, Apr 25, 2016 at 1:17 AM, Matt Oliver  wrote:

> Obviously changing things would require a consensus from all the devs.
> Personally I would like to see the DCE stuff removed as currently as stated
> debug or lto builds will fail with msvc and these are both options that are
> support by the configure script yet wont actually build without errors
> until DCE is removed. Ive also seen similar issues when using icl as well
> so although some may state there advantages to DCE it is fundamentally
> breaking things on certain platforms so it should be decided what is more
> important.


The discussion has so far always centered around the fact that DCE is
available on all platforms we support. The same reason was given to use C99
as a baseline.

When it turned out that Microsoft had incompetent leaders in their compiler
team, we wrote the converter for them, and the humiliation worked, MSVC
supports C99 now.

I'm estimating that writing a DCE converter would take as little as a tenth
of the time it took us to wrote the C99 converter. Public embarrassment
works really well in some situations, and Microsoft is in clear need of it.

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

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

[Michael Niedermayer]

On Mon, Apr 25, 2016 at 06:17:22PM +1000, Matt Oliver wrote:
> On 23 April 2016 at 23:46, wm4  wrote:
> 
> > On Sat, 23 Apr 2016 14:52:12 +0200
> > Reimar Döffinger  wrote:
> >
> > > On 23.04.2016, at 13:21, wm4  wrote:
> > >
> > > > On Sat, 23 Apr 2016 01:16:31 +0200
> > > > Hendrik Leppkes  wrote:
> > > >
> > > >> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
> > > >>  wrote:
> > > >>> I've noticed that when CONFIG_W64_DEMUXER is defined to zero that
> > ffmpeg
> > > >>> compiles in a reference to ff_w64_guid_data but doesn't not link
> > w64.o
> > > >>> (which defines that symbol).
> > > >>>
> > > >>> This normally works because most optimizers discard the reference
> > > >>> to ff_w64_guid_data early enough to not cause a linker failure.
> > However
> > > >>> this assumption means that /Od (debug, unoptimized) and /GL (Link
> > Time Code
> > > >>> Generation - super optimized) builds with VC++ don't work.
> > > >>>
> > > >>
> > > >> We require dead code elimination to be available in all build modes,
> > > >> therefor such build settings that do not have it are not supported.
> > > >> This is not the only place that uses this, and its a design decision
> > > >> to rely on it, therefor we won't be accepting patches to change that
> > > >> at this time, sorry.
> > > >
> > > > Why not? Someone just volunteered to cleanup this non-sense, so why not
> > > > let them?
> > >
> > > Because it ends up with a horrible ifdef mess and also means that
> > disabled parts will not even be checked for syntax.
> > > I.e. the reasons why we did it this way.
> >
> > Pretty weak considering there are 3961 #ifs in the code (this excludes
> > header file inclusion guards). This is because we readily allow
> > disabling _any_ component because someone might not need it. We also
> > have a big ifdef mess to switch between enabling and disabling
> > deprecated APIs and their implementation or use within ffmpeg.
> >
> > There's even --enable-random, which is supposed to help with finding
> > some of the configurations which don't even compile, out of
> > the practically infinite number possible configurations.
> >
> > On the other hand, mere compilation failures on other architectures
> > (which this idiom is supposed to catch) are easily detected by the
> > numerous fate instances we run.
> >
> > In conclusion, this change would be pretty harmless compared to the
> > ifdef mess we have for _way_ less legitimate use-cases.
> >
> > The add to this, we don't even need to use #ifdefs. Some sort of
> > selection macro could achieve the same thing:
> >
> > #define CONCAT(a, b) a ## b
> >
> > #define VALUE0(a, b) a
> > #define VALUE1(a, b) b
> > #define TOK(v) CONCAT(VALUE, v)
> >
> > #define SELECT(v, a, b) TOK(v)(a, b)
> >
> > #define HAVE_SOMETHING 1
> >
> > SELECT(HAVE_SOMETHING, yes, no)
> >
> > So syntactically we could get something relatively elegant.
> >
> > I also want to remind that the reliance on DCE makes it a nightmare
> > trying to compile an actually debugable ffmpeg binary.
> >
> > Though I agree with nev's comment that we should make a conscious
> > decision to change this, rather than accepting random patches which
> > just make things inconsistent.
> >
> > > > We may have been arguing that every compiler supports this level of
> > > > DCE, but experience has been clearly showing that this is not always
> > the
> > > > case due to various reasons.
> > >
> > > I don't that was quite the argument. It is more a question if the rare
> > cases are really worth the cost, especially when also the compilers could
> > be changed to support this method of code configuration.
> >
> > The compilers have no reason to change here, as ffmpeg essentially
> > violates the C standard with this idiom.
> >
> 
> Fixing one case isnt really an option as there are many DCE cases
> throughout ffmpeg that all have the same issues (as previously stated).
> Currently it is not possible to build ffmpeg with msvc using a debug or lto
> build as it will just result in dozens if not hundreds of linker errors
> (depending on the compiler version and options used). And the configuration
> options here dont really matter as there are fundamentally missing
> functions (h264_vaapi etc.) that are not available on windows and so
> generate link errors no matter what you do.
> 
> Obviously changing things would require a consensus from all the devs.
> Personally I would like to see the DCE stuff removed as currently as stated
> debug or lto builds will fail with msvc and these are both options that are
> support by the configure script yet wont actually build without errors
> until DCE is removed. Ive also seen similar issues when using icl as well
> so although some may state there advantages to DCE it is fundamentally
> breaking things on certain platforms so it should be decided what is more
> important.

does icl have 

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

[Andrey Utkin]

On Mon, Apr 25, 2016 at 08:58:40AM +0200, Nicolas George wrote:
> Le sextidi 6 floréal, an CCXXIV, Andrey Utkin a écrit :
> > Please look at my email in ffmpeg-devel
> > '[PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 
> > 0"'
> > it adds a check which allows to correctly handle both cases.
> 
> I will be able to look at this patch when it arrives, not before.

Sorry, it still awaits moderator approval (sent from non-subscribed
address) since yesterday.
I think I shouldn't resubmit but instead wait for original letter to
show up.

> > The chunk which Nicolas proposes to drop makes good work for default
> > (auto_convert=1) case and I wouldn't say that it shouldn't be there,
> > that code just doesn't consider auto_convert=0 case.
> 
> I am not entirely convinced this is quite everything.

Ok, anyway your patch fixes my usecase, too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Backporting commits from head 1) commit hash 15ef98afd10b3696d29fb6d19606ba03a9dd47ad (configure: build fix for P5600 with mips code restructuring) 2) commit hash ad16eff64ba78d

[shivraj.patil]

From: Shivraj Patil 

Signed-off-by: Shivraj Patil 
---
 configure | 252 ++
 libavcodec/mips/aaccoder_mips.c   |   4 +
 libavcodec/mips/aacdec_mips.h |   2 +
 libavcodec/mips/aacpsdsp_mips.c   |   4 +
 libavcodec/mips/aacpsy_mips.h |   2 +
 libavcodec/mips/aacsbr_mips.c |   4 +
 libavcodec/mips/aacsbr_mips.h |   2 +
 libavcodec/mips/ac3dsp_mips.c |   6 +-
 libavcodec/mips/acelp_filters_mips.c  |   4 +
 libavcodec/mips/acelp_vectors_mips.c  |   4 +
 libavcodec/mips/amrwbdec_mips.c   |   2 +
 libavcodec/mips/amrwbdec_mips.h   |   2 +
 libavcodec/mips/celp_filters_mips.c   |   4 +
 libavcodec/mips/celp_math_mips.c  |   4 +
 libavcodec/mips/compute_antialias_float.h |   2 +
 libavcodec/mips/fft_mips.c|   4 +
 libavcodec/mips/iirfilter_mips.c  |   4 +
 libavcodec/mips/lsp_mips.h|   2 +
 libavcodec/mips/mpegaudiodsp_mips_fixed.c |  10 ++
 libavcodec/mips/mpegaudiodsp_mips_float.c |  10 ++
 libavcodec/mips/sbrdsp_mips.c |   4 +
 libavutil/mips/float_dsp_mips.c   |   4 +
 22 files changed, 203 insertions(+), 133 deletions(-)

diff --git a/configure b/configure
index 475c087..9103e85 100755
--- a/configure
+++ b/configure
@@ -913,6 +913,25 @@ void foo(void){ __asm__ volatile($code); }
 EOF
 }
 
+check_inline_asm_flags(){
+log check_inline_asm_flags "$@"
+name="$1"
+code="$2"
+flags=''
+shift 2
+while [ "$1" != "" ]; do
+  append flags $1
+  shift
+done;
+disable $name
+cat > $TMPC options.coder;
 
@@ -2494,5 +2497,6 @@ void ff_aac_coder_init_mips(AACEncContext *c) {
 #if HAVE_MIPSFPU
 e->search_for_ms= search_for_ms_mips;
 #endif /* HAVE_MIPSFPU */
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_INLINE_ASM */
 }
diff --git a/libavcodec/mips/aacdec_mips.h b/libavcodec/mips/aacdec_mips.h
index c4f6438..758266f 100644
--- a/libavcodec/mips/aacdec_mips.h
+++ b/libavcodec/mips/aacdec_mips.h
@@ -61,6 +61,7 @@
 #include "libavutil/mips/asmdefs.h"
 
 #if HAVE_INLINE_ASM && HAVE_MIPSFPU
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 static inline float *VMUL2_mips(float *dst, const float *v, unsigned idx,
const float *scale)
 {
@@ -246,6 +247,7 @@ static inline float *VMUL4S_mips(float *dst, const float 
*v, unsigned idx,
 #define VMUL4 VMUL4_mips
 #define VMUL2S VMUL2S_mips
 #define VMUL4S VMUL4S_mips
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_INLINE_ASM && HAVE_MIPSFPU */
 
 #endif /* AVCODEC_MIPS_AACDEC_MIPS_H */
diff --git a/libavcodec/mips/aacpsdsp_mips.c b/libavcodec/mips/aacpsdsp_mips.c
index 695f9ef..83fdc2f 100644
--- a/libavcodec/mips/aacpsdsp_mips.c
+++ b/libavcodec/mips/aacpsdsp_mips.c
@@ -188,6 +188,7 @@ static void ps_hybrid_synthesis_deint_mips(float 
out[2][38][64],
 }
 
 #if HAVE_MIPSFPU
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 static void ps_add_squares_mips(float *dst, const float (*src)[2], int n)
 {
 int i;
@@ -442,6 +443,7 @@ static void ps_stereo_interpolate_mips(float (*l)[2], float 
(*r)[2],
 : "memory"
 );
 }
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_MIPSFPU */
 #endif /* HAVE_INLINE_ASM */
 
@@ -451,10 +453,12 @@ void ff_psdsp_init_mips(PSDSPContext *s)
 s->hybrid_analysis_ileave = ps_hybrid_analysis_ileave_mips;
 s->hybrid_synthesis_deint = ps_hybrid_synthesis_deint_mips;
 #if HAVE_MIPSFPU
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 s->add_squares= ps_add_squares_mips;
 s->mul_pair_single= ps_mul_pair_single_mips;
 s->decorrelate= ps_decorrelate_mips;
 s->stereo_interpolate[0]  = ps_stereo_interpolate_mips;
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_MIPSFPU */
 #endif /* HAVE_INLINE_ASM */
 }
diff --git a/libavcodec/mips/aacpsy_mips.h b/libavcodec/mips/aacpsy_mips.h
index 42ff442..a1fe5cc 100644
--- a/libavcodec/mips/aacpsy_mips.h
+++ b/libavcodec/mips/aacpsy_mips.h
@@ -59,6 +59,7 @@
 #include "libavutil/mips/asmdefs.h"
 
 #if HAVE_INLINE_ASM && HAVE_MIPSFPU && ( PSY_LAME_FIR_LEN == 21 )
+#if !HAVE_MIPS32R6 && !HAVE_MIPS64R6
 static void calc_thr_3gpp_mips(const FFPsyWindowInfo *wi, const int num_bands,
AacPsyChannel *pch, const uint8_t *band_sizes,
const float *coefs, const int cutoff)
@@ -232,5 +233,6 @@ static void psy_hp_filter_mips(const float *firbuf, float 
*hpfsmpl, const float
 #define calc_thr_3gpp calc_thr_3gpp_mips
 #define psy_hp_filter psy_hp_filter_mips
 
+#endif /* !HAVE_MIPS32R6 && !HAVE_MIPS64R6 */
 #endif /* HAVE_INLINE_ASM && HAVE_MIPSFPU */
 #endif /* AVCODEC_MIPS_AACPSY_MIPS_H */
diff --git a/libavcodec/mips/aacsbr_mips.c b/libavcodec/mips/aacsbr_mips.c
index e478290..56aa4e8 100644
--- 

Re: [FFmpeg-devel] CONFIG_W64_DEMUXER and dead-code elimination

[Matt Oliver]

On 23 April 2016 at 23:46, wm4  wrote:

> On Sat, 23 Apr 2016 14:52:12 +0200
> Reimar Döffinger  wrote:
>
> > On 23.04.2016, at 13:21, wm4  wrote:
> >
> > > On Sat, 23 Apr 2016 01:16:31 +0200
> > > Hendrik Leppkes  wrote:
> > >
> > >> On Sat, Apr 23, 2016 at 1:02 AM, Bruce Dawson
> > >>  wrote:
> > >>> I've noticed that when CONFIG_W64_DEMUXER is defined to zero that
> ffmpeg
> > >>> compiles in a reference to ff_w64_guid_data but doesn't not link
> w64.o
> > >>> (which defines that symbol).
> > >>>
> > >>> This normally works because most optimizers discard the reference
> > >>> to ff_w64_guid_data early enough to not cause a linker failure.
> However
> > >>> this assumption means that /Od (debug, unoptimized) and /GL (Link
> Time Code
> > >>> Generation - super optimized) builds with VC++ don't work.
> > >>>
> > >>
> > >> We require dead code elimination to be available in all build modes,
> > >> therefor such build settings that do not have it are not supported.
> > >> This is not the only place that uses this, and its a design decision
> > >> to rely on it, therefor we won't be accepting patches to change that
> > >> at this time, sorry.
> > >
> > > Why not? Someone just volunteered to cleanup this non-sense, so why not
> > > let them?
> >
> > Because it ends up with a horrible ifdef mess and also means that
> disabled parts will not even be checked for syntax.
> > I.e. the reasons why we did it this way.
>
> Pretty weak considering there are 3961 #ifs in the code (this excludes
> header file inclusion guards). This is because we readily allow
> disabling _any_ component because someone might not need it. We also
> have a big ifdef mess to switch between enabling and disabling
> deprecated APIs and their implementation or use within ffmpeg.
>
> There's even --enable-random, which is supposed to help with finding
> some of the configurations which don't even compile, out of
> the practically infinite number possible configurations.
>
> On the other hand, mere compilation failures on other architectures
> (which this idiom is supposed to catch) are easily detected by the
> numerous fate instances we run.
>
> In conclusion, this change would be pretty harmless compared to the
> ifdef mess we have for _way_ less legitimate use-cases.
>
> The add to this, we don't even need to use #ifdefs. Some sort of
> selection macro could achieve the same thing:
>
> #define CONCAT(a, b) a ## b
>
> #define VALUE0(a, b) a
> #define VALUE1(a, b) b
> #define TOK(v) CONCAT(VALUE, v)
>
> #define SELECT(v, a, b) TOK(v)(a, b)
>
> #define HAVE_SOMETHING 1
>
> SELECT(HAVE_SOMETHING, yes, no)
>
> So syntactically we could get something relatively elegant.
>
> I also want to remind that the reliance on DCE makes it a nightmare
> trying to compile an actually debugable ffmpeg binary.
>
> Though I agree with nev's comment that we should make a conscious
> decision to change this, rather than accepting random patches which
> just make things inconsistent.
>
> > > We may have been arguing that every compiler supports this level of
> > > DCE, but experience has been clearly showing that this is not always
> the
> > > case due to various reasons.
> >
> > I don't that was quite the argument. It is more a question if the rare
> cases are really worth the cost, especially when also the compilers could
> be changed to support this method of code configuration.
>
> The compilers have no reason to change here, as ffmpeg essentially
> violates the C standard with this idiom.
>

Fixing one case isnt really an option as there are many DCE cases
throughout ffmpeg that all have the same issues (as previously stated).
Currently it is not possible to build ffmpeg with msvc using a debug or lto
build as it will just result in dozens if not hundreds of linker errors
(depending on the compiler version and options used). And the configuration
options here dont really matter as there are fundamentally missing
functions (h264_vaapi etc.) that are not available on windows and so
generate link errors no matter what you do.

Obviously changing things would require a consensus from all the devs.
Personally I would like to see the DCE stuff removed as currently as stated
debug or lto builds will fail with msvc and these are both options that are
support by the configure script yet wont actually build without errors
until DCE is removed. Ive also seen similar issues when using icl as well
so although some may state there advantages to DCE it is fundamentally
breaking things on certain platforms so it should be decided what is more
important.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/concatdec: remove unrelated change during codecpar merge.

[Nicolas George]

Le sextidi 6 floréal, an CCXXIV, Andrey Utkin a écrit :
> Please look at my email in ffmpeg-devel
> '[PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"'
> it adds a check which allows to correctly handle both cases.

I will be able to look at this patch when it arrives, not before.

> The chunk which Nicolas proposes to drop makes good work for default
> (auto_convert=1) case and I wouldn't say that it shouldn't be there,
> that code just doesn't consider auto_convert=0 case.

I am not entirely convinced this is quite everything.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH 2/2] avutil/log: added test case for av_log_format_line2

[der_ghulbus]

From: Andreas Weis 

Signed-off-by: Andreas Weis 
---
 libavutil/log.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/libavutil/log.c b/libavutil/log.c
index 0efba7a..6d192b6 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -444,6 +444,17 @@ void avpriv_report_missing_feature(void *avc, const char 
*msg, ...)
 // LCOV_EXCL_START
 #include 
 
+int call_log_format_line2(const char *fmt, char *buffer, int buffer_size, ...)
+{
+va_list args;
+int ret;
+int print_prefix=1;
+va_start(args, buffer_size);
+ret = av_log_format_line2(NULL, AV_LOG_INFO, fmt, args, buffer, 
buffer_size, _prefix);
+va_end(args);
+return ret;
+}
+
 int main(int argc, char **argv)
 {
 int i;
@@ -458,6 +469,25 @@ int main(int argc, char **argv)
 }
 av_log(NULL, AV_LOG_PANIC, "\n");
 }
+{
+int result;
+char buffer[4];
+result = call_log_format_line2("foo", NULL, 0);
+if(result != 3) {
+printf("Test NULL buffer failed.\n");
+return 1;
+}
+result = call_log_format_line2("foo", buffer, 2);
+if(result != 3 || strncmp(buffer, "f", 2)) {
+printf("Test buffer too small failed.\n");
+return 1;
+}
+result = call_log_format_line2("foo", buffer, 4);
+if(result != 3 || strncmp(buffer, "foo", 4)) {
+printf("Test buffer sufficiently big failed.\n");
+return 1;
+}
+}
 return 0;
 }
 // LCOV_EXCL_STOP
-- 
2.5.0.windows.1

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

[FFmpeg-devel] [PATCH 1/2] avutil/log: added av_log_format_line2 which returns buffer length

[der_ghulbus]

From: Andreas Weis 

The new function behaves the same as av_log_format_line, but also forwards
the return value from the underlying snprintf call. This will allow
callers to accurately determine the size requirements for the line buffer.

Signed-off-by: Andreas Weis 
---
 libavutil/log.c | 11 ++-
 libavutil/log.h | 17 +
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/libavutil/log.c b/libavutil/log.c
index 4583519..0efba7a 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -284,10 +284,19 @@ static void format_line(void *avcl, int level, const char 
*fmt, va_list vl,
 void av_log_format_line(void *ptr, int level, const char *fmt, va_list vl,
 char *line, int line_size, int *print_prefix)
 {
+av_log_format_line2(ptr, level, fmt, vl, line, line_size, print_prefix);
+}
+
+int av_log_format_line2(void *ptr, int level, const char *fmt, va_list vl,
+char *line, int line_size, int *print_prefix)
+{
 AVBPrint part[4];
+int ret;
+
 format_line(ptr, level, fmt, vl, part, print_prefix, NULL);
-snprintf(line, line_size, "%s%s%s%s", part[0].str, part[1].str, 
part[2].str, part[3].str);
+ret = snprintf(line, line_size, "%s%s%s%s", part[0].str, part[1].str, 
part[2].str, part[3].str);
 av_bprint_finalize(part+3, NULL);
+return ret;
 }
 
 void av_log_default_callback(void* ptr, int level, const char* fmt, va_list vl)
diff --git a/libavutil/log.h b/libavutil/log.h
index 321748c..9b1d66f 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -317,6 +317,23 @@ AVClassCategory av_default_get_category(void *ptr);
 void av_log_format_line(void *ptr, int level, const char *fmt, va_list vl,
 char *line, int line_size, int *print_prefix);
 
+/**
+ * Format a line of log the same way as the default callback.
+ * @param line  buffer to receive the formatted line;
+ *  may be NULL if line_size is 0
+ * @param line_size size of the buffer; at most line_size-1 characters will
+ *  be written to the buffer, plus one null terminator
+ * @param print_prefix  used to store whether the prefix must be printed;
+ *  must point to a persistent integer initially set to 1
+ * @return Returns a negative value if an error occured, otherwise returns
+ * the number of characters that would have been written for a
+ * sufficiently large buffer, not including the terminating null
+ * character. If the return value is not less than line_size, it means
+ * that the log message was truncated to fit the buffer.
+ */
+int av_log_format_line2(void *ptr, int level, const char *fmt, va_list vl,
+char *line, int line_size, int *print_prefix);
+
 #if FF_API_DLOG
 /**
  * av_dlog macros
-- 
2.5.0.windows.1

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