Re: [FFmpeg-devel] [PATCH v2 5/6] vaapi_encode: Add ROI support

2019-04-17 Thread Fu, Linjie
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, March 13, 2019 08:18
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 5/6] vaapi_encode: Add ROI support
> 
> ---
>  libavcodec/vaapi_encode.c   | 128
> 
>  libavcodec/vaapi_encode.h   |  11 +++
>  libavcodec/vaapi_encode_h264.c  |   2 +
>  libavcodec/vaapi_encode_h265.c  |   2 +
>  libavcodec/vaapi_encode_mpeg2.c |   2 +
>  libavcodec/vaapi_encode_vp8.c   |   2 +
>  libavcodec/vaapi_encode_vp9.c   |   2 +
>  7 files changed, 149 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 2dda451882..03a7f5ce3e 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -143,6 +143,7 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
>  int err, i;
>  char data[MAX_PARAM_BUFFER_SIZE];
>  size_t bit_len;
> +AVFrameSideData *sd;
> 
>  av_log(avctx, AV_LOG_DEBUG, "Issuing encode for
> pic %"PRId64"/%"PRId64" "
> "as type %s.\n", pic->display_order, pic->encode_order,
> @@ -412,6 +413,91 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
>  }
>  }
> 
> +sd = av_frame_get_side_data(pic->input_image,
> +AV_FRAME_DATA_REGIONS_OF_INTEREST);
> +
> +#if VA_CHECK_VERSION(1, 0, 0)
> +if (sd && ctx->roi_allowed) {
> +const AVRegionOfInterest *roi;
> +int nb_roi;
> +VAEncMiscParameterBuffer param_misc = {
> +.type = VAEncMiscParameterTypeROI,
> +};
> +VAEncMiscParameterBufferROI param_roi;
> +// VAAPI requires the second structure to immediately follow the
> +// first in the parameter buffer, but they have different natural
> +// alignment on 64-bit architectures (4 vs. 8, since the ROI
> +// structure contains a pointer).  This means we can't make a
> +// single working structure, nor can we make the buffer
> +// separately and map it because dereferencing the second pointer
> +// would be undefined.  Therefore, construct the two parts
> +// separately and combine them into a single character buffer
> +// before uploading.
> +char param_buffer[sizeof(param_misc) + sizeof(param_roi)];
> +int i, v;

How about using packed attribute to cope with this? Like:
struct {
VAEncMiscParameterBuffer misc;
VAEncMiscParameterBufferROI param_roi;
 } __attribute__((packed)) mfs_params;

This happens a lot during vaapi feature development, like 
MaxFrameSize:
struct {
VAEncMiscParameterBuffer misc;
VAEncMiscParameterBufferMultiPassFrameSize mfs;
} __attribute__((packed)) mfs_params;
Trellis: (currently waiting for bug fix in libva)
 https://patchwork.ffmpeg.org/patch/11733/

Thanks,
Linjie

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] add tests/ref/fate/hls-segment-size for the fate test

2019-04-17 Thread Steven Liu
Signed-off-by: Steven Liu 
---
 tests/ref/fate/hls-segment-size | 772 
 1 file changed, 772 insertions(+)
 create mode 100644 tests/ref/fate/hls-segment-size

diff --git a/tests/ref/fate/hls-segment-size b/tests/ref/fate/hls-segment-size
new file mode 100644
index 00..ee3c7b2c62
--- /dev/null
+++ b/tests/ref/fate/hls-segment-size
@@ -0,0 +1,772 @@
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 44100
+#channel_layout 0: 4
+#channel_layout_name 0: mono
+0,  0,  0, 1152, 2304, 0x907cb7fa
+0,   1152,   1152, 1152, 2304, 0xb8dc7525
+0,   2304,   2304, 1152, 2304, 0x3e7d6905
+0,   3456,   3456, 1152, 2304, 0xef47877b
+0,   4608,   4608, 1152, 2304, 0xfe916b7e
+0,   5760,   5760, 1152, 2304, 0xe3d08cde
+0,   6912,   6912, 1152, 2304, 0xff7f86cf
+0,   8064,   8064, 1152, 2304, 0x843e6f95
+0,   9216,   9216, 1152, 2304, 0x81577c26
+0,  10368,  10368, 1152, 2304, 0x04a085d5
+0,  11520,  11520, 1152, 2304, 0x1c5a76f5
+0,  12672,  12672, 1152, 2304, 0x4ee78623
+0,  13824,  13824, 1152, 2304, 0x8ec861dc
+0,  14976,  14976, 1152, 2304, 0x0ca179d8
+0,  16128,  16128, 1152, 2304, 0xc6da750f
+0,  17280,  17280, 1152, 2304, 0xf6bf79b5
+0,  18432,  18432, 1152, 2304, 0x97b88a43
+0,  19584,  19584, 1152, 2304, 0xf13c7b9c
+0,  20736,  20736, 1152, 2304, 0xdfba83af
+0,  21888,  21888, 1152, 2304, 0xc9467d4b
+0,  23040,  23040, 1152, 2304, 0xbbb58e2b
+0,  24192,  24192, 1152, 2304, 0x3a1078ea
+0,  25344,  25344, 1152, 2304, 0xe9587a5c
+0,  26496,  26496, 1152, 2304, 0xef5a8039
+0,  27648,  27648, 1152, 2304, 0x9d5f782f
+0,  28800,  28800, 1152, 2304, 0x1a548291
+0,  29952,  29952, 1152, 2304, 0x07517701
+0,  31104,  31104, 1152, 2304, 0x78127d6e
+0,  32256,  32256, 1152, 2304, 0x62e2788a
+0,  33408,  33408, 1152, 2304, 0x29397ad9
+0,  34560,  34560, 1152, 2304, 0x45da82d6
+0,  35712,  35712, 1152, 2304, 0x8ed66e51
+0,  36864,  36864, 1152, 2304, 0x660775cd
+0,  38016,  38016, 1152, 2304, 0x802c767a
+0,  39168,  39168, 1152, 2304, 0xcc055840
+0,  40320,  40320, 1152, 2304, 0x701b7eaf
+0,  41472,  41472, 1152, 2304, 0x8290749f
+0,  42624,  42624, 1152, 2304, 0x2c7b7d30
+0,  43776,  43776, 1152, 2304, 0xe4f17743
+0,  44928,  44928, 1152, 2304, 0x0e747d6e
+0,  46080,  46080, 1152, 2304, 0xbe7775a0
+0,  47232,  47232, 1152, 2304, 0xcf797673
+0,  48384,  48384, 1152, 2304, 0x29cb7800
+0,  49536,  49536, 1152, 2304, 0xfc947890
+0,  50688,  50688, 1152, 2304, 0x62757fc6
+0,  51840,  51840, 1152, 2304, 0x098876d0
+0,  52992,  52992, 1152, 2304, 0xa9567ee2
+0,  54144,  54144, 1152, 2304, 0xe3bb9173
+0,  55296,  55296, 1152, 2304, 0xcc2d6dee
+0,  56448,  56448, 1152, 2304, 0xe94591ab
+0,  57600,  57600, 1152, 2304, 0x5c7588de
+0,  58752,  58752, 1152, 2304, 0xfd83643c
+0,  59904,  59904, 1152, 2304, 0x528177f1
+0,  61056,  61056, 1152, 2304, 0x65d08474
+0,  62208,  62208, 1152, 2304, 0x738d765b
+0,  63360,  63360, 1152, 2304, 0xdd3d810e
+0,  64512,  64512, 1152, 2304, 0xef4f90d3
+0,  65664,  65664, 1152, 2304, 0x61e28d43
+0,  66816,  66816, 1152, 2304, 0x9a11796b
+0,  67968,  67968, 1152, 2304, 0x96c97dcd
+0,  69120,  69120, 1152, 2304, 0xa8fe8621
+0,  70272,  70272, 1152, 2304, 0x499b7d38
+0,  71424,  71424, 1152, 2304, 0xfcb078a9
+0,  72576,  72576, 1152, 2304, 0x40d78651
+0,  73728,  73728, 1152, 2304, 0xa4af7234
+0,  74880,  74880, 1152, 2304, 0x6831870a
+0,  76032,  76032, 1152, 2304, 0x030e7b9d
+0,  77184,  77184, 1152, 2304, 0x445a75b6
+0,  78336,  78336, 1152, 2304, 0x09857389
+0,  79488,  79488, 1152, 2304, 0x0d018866
+0,  80640,  80640, 1152, 2304, 0x2afe810a
+0,  81792,  81792, 1152, 2304, 0x0bcf7c43
+0,  82944,  82944, 1152, 2304, 0x13737c12
+0,  84096,  84096, 1152, 2304, 0x716c7bba
+0,  85248,  85248, 1152, 2304, 0xb801823b
+0,  86400,  86400, 1152,  

Re: [FFmpeg-devel] [FFmpeg-cvslog] tests/fate: add fate-hls-segment-size for hls_segment_size test

2019-04-17 Thread Steven Liu


> 在 2019年4月18日,09:35,Carl Eugen Hoyos  写道:
> 
> 2019-04-17 10:11 GMT+02:00, Steven Liu :
>> ffmpeg | branch: master | Steven Liu  | Sun Apr 14
>> 21:22:22 2019 +0800| [2a50f1d9e414bdf3d97c6aa649769d17793f2991] | committer:
>> Steven Liu
>> 
>> tests/fate: add fate-hls-segment-size for hls_segment_size test
> 
> I believe this commit broke fate.
> 
Ah, forget commit the tests/ref/fate/hls-segment-size
Can i append the file for commit?

> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Thanks
Steven





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] tests/fate: add fate-hls-segment-size for hls_segment_size test

2019-04-17 Thread James Almer
On 4/17/2019 10:35 PM, Carl Eugen Hoyos wrote:
> 2019-04-17 10:11 GMT+02:00, Steven Liu :
>> ffmpeg | branch: master | Steven Liu  | Sun Apr 14
>> 21:22:22 2019 +0800| [2a50f1d9e414bdf3d97c6aa649769d17793f2991] | committer:
>> Steven Liu
>>
>> tests/fate: add fate-hls-segment-size for hls_segment_size test
> 
> I believe this commit broke fate.
> 
> Carl Eugen

It's missing the ref file, which should be generated running the test
with GEN=1. But unless detailed information for each frame (size,
length, pts, etc) is needed, I think it'd be better if it instead uses
the md5() CMD function with the inline() CMP mode, like other tests in
this same file, instead of framecrc().
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH]tests: Add EXESUF to program calls

2019-04-17 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes fate on Windows subsystem for Linux here.

Please comment, Carl Eugen
From 5f7ffdc2968bdc6f37fdeb3870ccb8135e91048a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 18 Apr 2019 03:24:35 +0200
Subject: [PATCH] tests: Add EXESUF to program calls.

Fixes fate in Windows subsystem for Linux.
---
 tests/fate-run.sh   |   20 +--
 tests/fate/api.mak  |   16 -
 tests/fate/checkasm.mak |2 +-
 tests/fate/fft.mak  |8 ++---
 tests/fate/filter-audio.mak |2 +-
 tests/fate/hw.mak   |2 +-
 tests/fate/libavcodec.mak   |   40 +++---
 tests/fate/libavformat.mak  |   10 +++---
 tests/fate/libavutil.mak|   78 +--
 tests/fate/libswscale.mak   |2 +-
 10 files changed, 90 insertions(+), 90 deletions(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 696fc24..56c4efb 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -86,11 +86,11 @@ runecho(){
 }
 
 probefmt(){
-run ffprobe${PROGSUF} -show_entries format=format_name -print_format default=nw=1:nk=1 -v 0 "$@"
+run ffprobe${PROGSUF}${EXECSUF} -show_entries format=format_name -print_format default=nw=1:nk=1 -v 0 "$@"
 }
 
 probetags(){
-run ffprobe${PROGSUF} -show_entries format_tags -v 0 "$@"
+run ffprobe${PROGSUF}${EXECSUF} -show_entries format_tags -v 0 "$@"
 }
 
 runlocal(){
@@ -99,24 +99,24 @@ runlocal(){
 }
 
 probeframes(){
-run ffprobe${PROGSUF} -show_frames -v 0 "$@"
+run ffprobe${PROGSUF}${EXECSUF} -show_frames -v 0 "$@"
 }
 
 probechapters(){
-run ffprobe${PROGSUF} -show_chapters -v 0 "$@"
+run ffprobe${PROGSUF}${EXECSUF} -show_chapters -v 0 "$@"
 }
 
 probegaplessinfo(){
 filename="$1"
 shift
-run ffprobe${PROGSUF} -bitexact -select_streams a -show_entries format=start_time,duration:stream=index,start_pts,duration_ts -v 0 "$filename" "$@"
+run ffprobe${PROGSUF}${EXECSUF} -bitexact -select_streams a -show_entries format=start_time,duration:stream=index,start_pts,duration_ts -v 0 "$filename" "$@"
 pktfile1="${outdir}/${test}.pkts"
 framefile1="${outdir}/${test}.frames"
 cleanfiles="$cleanfiles $pktfile1 $framefile1"
-run ffprobe${PROGSUF} -bitexact -select_streams a -of compact -count_packets -show_entries packet=pts,dts,duration,flags:stream=nb_read_packets -v 0 "$filename" "$@" > "$pktfile1"
+run ffprobe${PROGSUF}${EXECSUF} -bitexact -select_streams a -of compact -count_packets -show_entries packet=pts,dts,duration,flags:stream=nb_read_packets -v 0 "$filename" "$@" > "$pktfile1"
 head -n 8 "$pktfile1"
 tail -n 9 "$pktfile1"
-run ffprobe${PROGSUF} -bitexact -select_streams a -of compact -count_frames -show_entries frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames -v 0 "$filename" "$@" > "$framefile1"
+run ffprobe${PROGSUF}${EXECSUF} -bitexact -select_streams a -of compact -count_frames -show_entries frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames -v 0 "$filename" "$@" > "$framefile1"
 head -n 8 "$framefile1"
 tail -n 9 "$framefile1"
 }
@@ -386,7 +386,7 @@ pixfmts(){
 prefilter_chain=$2
 nframes=${3:-1}
 
-showfiltfmts="$target_exec $target_path/libavfilter/tests/filtfmts"
+showfiltfmts="$target_exec $target_path/libavfilter/tests/filtfmts${EXECSUF}"
 scale_exclude_fmts=${outfile}_scale_exclude_fmts
 scale_in_fmts=${outfile}_scale_in_fmts
 scale_out_fmts=${outfile}_scale_out_fmts
@@ -471,10 +471,10 @@ concat(){
 awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
 
 if [ "$mode" = "md5" ]; then
-run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -v 0 -fflags keepside -safe 0 $extra_args $concatfile | tr -d '\r' > $packetfile
+run ffprobe${PROGSUF}${EXECSUF} -bitexact -show_streams -show_packets -v 0 -fflags keepside -safe 0 $extra_args $concatfile | tr -d '\r' > $packetfile
 do_md5sum $packetfile
 else
-run ffprobe${PROGSUF} -bitexact -show_streams -show_packets -v 0 -of compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
+run ffprobe${PROGSUF}${EXECSUF} -bitexact -show_streams -show_packets -v 0 -of compact=p=0:nk=1 -fflags keepside -safe 0 $extra_args $concatfile
 fi
 }
 
diff --git a/tests/fate/api.mak b/tests/fate/api.mak
index b716b3b..3e1cc99 100644
--- a/tests/fate/api.mak
+++ b/tests/fate/api.mak
@@ -1,37 +1,37 @@
 FATE_API_LIBAVCODEC-$(call ENCDEC, FLAC, FLAC) += fate-api-flac
 fate-api-flac: $(APITESTSDIR)/api-flac-test$(EXESUF)
-fate-api-flac: CMD = run $(APITESTSDIR)/api-flac-test
+fate-api-flac: CMD = run $(APITESTSDIR)/api-flac-test$(EXESUF)
 fate-api-flac: CMP = null
 
 FATE_API_SAMPLES_LIBAVFORMAT-$(call DEMDEC, FLV, FLV) += fate-api-band
 fate-api-band: $(APITESTSDIR)/api-band-test$(EXESUF)
-fate-api-band: CMD = run $(APITESTSDIR)/api-band-test $(TARGET_SAMPLES)/mpeg4/resize_down-u

Re: [FFmpeg-devel] [FFmpeg-cvslog] tests/fate: add fate-hls-segment-size for hls_segment_size test

2019-04-17 Thread Carl Eugen Hoyos
2019-04-17 10:11 GMT+02:00, Steven Liu :
> ffmpeg | branch: master | Steven Liu  | Sun Apr 14
> 21:22:22 2019 +0800| [2a50f1d9e414bdf3d97c6aa649769d17793f2991] | committer:
> Steven Liu
>
> tests/fate: add fate-hls-segment-size for hls_segment_size test

I believe this commit broke fate.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] lavf/img2enc: add support for option strftime_source

2019-04-17 Thread Carl Eugen Hoyos
2019-04-18 2:02 GMT+02:00, Jun Li :
> On Wed, Apr 17, 2019 at 3:11 PM Carl Eugen Hoyos  wrote:
>
>> 2019-04-15 8:43 GMT+02:00, Jun Li :
>> > Currently the strftime option generate timestamp based on generation
>> > time. The new option would calcualte timestamp from source's
>> > start_realtime and pkt->pts, try to generate a timestamp matches the
>> > source starting time.
>>
>> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> > index 8349840c96..16bb143ca6 100644
>> > --- a/libavformat/rtsp.c
>> > +++ b/libavformat/rtsp.c
>> > @@ -2253,6 +2253,7 @@ redo:
>> >  (uint64_t)
>> > rtpctx->st->time_base.num * 100,
>> >
>> > rtpctx->st->time_base.den);
>> >  }
>> > +av_dict_set_int(&s->metadata, "start_realtime",
>> > s->start_time_realtime, 0);
>>
>> Is this change related?

> Thanks Carl for review !

> Yes, it is related.

But the change should be separate unless something gets broken.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cbs_h2645: rename macros to read and write fields with custom range of values

2019-04-17 Thread James Almer
On 4/16/2019 11:56 PM, James Almer wrote:
> @@ -164,9 +164,9 @@ static int FUNC(profile_tier_level)(CodedBitstreamContext 
> *ctx, RWContext *rw,
>  
>  for (i = 0; i < max_num_sub_layers_minus1; i++) {
>  if (current->sub_layer_profile_present_flag[i]) {
> -us(2, sub_layer_profile_space[i], 0, 0, 1, i);
> +ucs(2, sub_layer_profile_space[i], 0, 0, 1, i);
>  flags(sub_layer_tier_flag[i],   1, i);
> -us(5, sub_layer_profile_idc[i], 0, 31,  1, i);
> +ucs(5, sub_layer_profile_idc[i], 0, 31,  1, i);
>  
>  for (j = 0; j < 32; j++)
>  flags(sub_layer_profile_compatibility_flag[i][j], 2, i, j);
> @@ -220,7 +220,7 @@ static int FUNC(profile_tier_level)(CodedBitstreamContext 
> *ctx, RWContext *rw,
>  #undef profile_compatible
>  }
>  if (current->sub_layer_level_present_flag[i])
> -us(8, sub_layer_level_idc[i], 0, 255, 1, i);
> +ucs(8, sub_layer_level_idc[i], 0, 255, 1, i);

The last two should have been changed to ubs() in the first patch instead.

Fixed locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] lavf/img2enc: add support for option strftime_source

2019-04-17 Thread Jun Li
On Wed, Apr 17, 2019 at 3:11 PM Carl Eugen Hoyos  wrote:

> 2019-04-15 8:43 GMT+02:00, Jun Li :
> > Currently the strftime option generate timestamp based on generation
> > time. The new option would calcualte timestamp from source's
> > start_realtime and pkt->pts, try to generate a timestamp matches the
> > source starting time.
>
> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> > index 8349840c96..16bb143ca6 100644
> > --- a/libavformat/rtsp.c
> > +++ b/libavformat/rtsp.c
> > @@ -2253,6 +2253,7 @@ redo:
> >  (uint64_t)
> > rtpctx->st->time_base.num * 100,
> >
> > rtpctx->st->time_base.den);
> >  }
> > +av_dict_set_int(&s->metadata, "start_realtime",
> > s->start_time_realtime, 0);
>
> Is this change related?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Thanks Carl for review !
Yes, it is related. The value is passed into metadata so that image2enc to
get it during muxing.
The change on image2enc relies on metadata "start_realtime" and
"creation_time".

Best Regards,
Jun
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: add frame threads

2019-04-17 Thread Michael Niedermayer
On Thu, Apr 18, 2019 at 01:19:58AM +0200, Michael Niedermayer wrote:
> On Wed, Apr 17, 2019 at 06:16:39PM +0200, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavcodec/dvdec.c | 19 ++-
> >  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> Is this intended to be 100% same output ?
> 
> I have a few cases that produce differences. Dont have a good testcase though
> ./ffmpeg -i ~/tickets/1589/A1590.dv avi-b.avi
> produces different output.
> oddly -f framecrc produces the same output
> not sure this is a problem or not the input file may have issues

heres another testcase:
./ffmpeg -i ~/tickets/2390/dv_cut.dv aviavi2.avi

-rw-r- 1 michael michael 112414 Apr 18 01:18 aviavi2.avi
-rw-r- 1 michael michael 112446 Apr 18 01:18 aviavi.avi
--- strings12019-04-18 01:19:42.472574387 +0200
+++ strings22019-04-18 01:19:37.764574245 +0200
@@ -1,4 +1,4 @@
-RIFF6
+RIFF
 AVI LIST
 hdrlavih8
 LIST
@@ -8,7 +8,7 @@
 FMP4
 JUNK
 00dc
-vprpd
+vprpD
 LIST
 strlstrh8
 auds


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: add frame threads

2019-04-17 Thread Michael Niedermayer
On Wed, Apr 17, 2019 at 06:16:39PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/dvdec.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)

Is this intended to be 100% same output ?

I have a few cases that produce differences. Dont have a good testcase though
./ffmpeg -i ~/tickets/1589/A1590.dv avi-b.avi
produces different output.
oddly -f framecrc produces the same output
not sure this is a problem or not the input file may have issues

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH]lavf/vc1dec: Reduce probe score for streams with invalid frames

2019-04-17 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes ticket #7853.

Please comment, Carl Eugen
From 55851640fa9e4d23c6c32bf33a46927815544040 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 18 Apr 2019 00:50:48 +0200
Subject: [PATCH] lavf/vc1dec: Reduce probe score for streams with invalid
 frames.

Fixes ticket 7853.
---
 libavformat/vc1dec.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavformat/vc1dec.c b/libavformat/vc1dec.c
index f4101ae..5da5eb6 100644
--- a/libavformat/vc1dec.c
+++ b/libavformat/vc1dec.c
@@ -26,7 +26,7 @@
 
 static int vc1_probe(const AVProbeData *p)
 {
-int seq = 0, entry = 0, frame = 0, i;
+int seq = 0, entry = 0, invalid = 0, frame = 0, i;
 
 for (i = 0; i < p->buf_size + 5; i++) {
 uint32_t code = AV_RB32(p->buf + i);
@@ -39,16 +39,19 @@ static int vc1_probe(const AVProbeData *p)
 profile = (p->buf[i] & 0xc0) >> 6;
 if (profile != PROFILE_ADVANCED) {
 seq = 0;
+invalid++;
 continue;
 }
 level = (p->buf[i] & 0x38) >> 3;
 if (level >= 5) {
 seq = 0;
+invalid++;
 continue;
 }
 chromaformat = (p->buf[i] & 0x6) >> 1;
 if (chromaformat != 1) {
 seq = 0;
+invalid++;
 continue;
 }
 seq++;
@@ -56,8 +59,10 @@ static int vc1_probe(const AVProbeData *p)
 break;
 }
 case VC1_CODE_ENTRYPOINT:
-if (!seq)
+if (!seq) {
+invalid++;
 continue;
+}
 entry++;
 i += 2;
 break;
@@ -71,7 +76,7 @@ static int vc1_probe(const AVProbeData *p)
 }
 }
 
-if (frame > 1)
+if (frame > 1 && frame >> 1 > invalid)
 return AVPROBE_SCORE_EXTENSION / 2 + 1;
 if (frame == 1)
 return AVPROBE_SCORE_EXTENSION / 4;
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat: fix inputs initialization in mpegts muxer with filters

2019-04-17 Thread Carl Eugen Hoyos
2019-04-17 22:28 GMT+02:00, Andreas Håkon via ffmpeg-devel
:
> This patch solves the initialization of the inputs when using filters (a
> graph filter) with the mpegts muxer.
>
> This bug seems to be generated by a simple forgetting to copy. The same code
> is repeated two times, but only in one case the variable “inputs_done” is
> initialized. Compare the two blocks:
> - Correct:
> https://github.com/FFmpeg/FFmpeg/blob/a0559fcd81f42f446c93357a943699f9d44eeb79/fftools/ffmpeg.c#L4627
> - Incorrect:
> https://github.com/FFmpeg/FFmpeg/blob/a0559fcd81f42f446c93357a943699f9d44eeb79/fftools/ffmpeg.c#L4616
>
> In addition, the patch includes a more detailed version of two LOG lines.

Please split the patch.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] lavf/img2enc: add support for option strftime_source

2019-04-17 Thread Carl Eugen Hoyos
2019-04-15 8:43 GMT+02:00, Jun Li :
> Currently the strftime option generate timestamp based on generation
> time. The new option would calcualte timestamp from source's
> start_realtime and pkt->pts, try to generate a timestamp matches the
> source starting time.

> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 8349840c96..16bb143ca6 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -2253,6 +2253,7 @@ redo:
>  (uint64_t)
> rtpctx->st->time_base.num * 100,
>
> rtpctx->st->time_base.den);
>  }
> +av_dict_set_int(&s->metadata, "start_realtime",
> s->start_time_realtime, 0);

Is this change related?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] lavf/img2enc: add support for option strftime_source

2019-04-17 Thread Jun Li
On Sun, Apr 14, 2019 at 11:43 PM Jun Li  wrote:

> Currently the strftime option generate timestamp based on generation
> time. The new option would calcualte timestamp from source's
> start_realtime and pkt->pts, try to generate a timestamp matches the
> source starting time.
> ---
>  doc/muxers.texi   |  4 
>  libavformat/img2enc.c | 39 +++
>  libavformat/rtsp.c|  1 +
>  3 files changed, 44 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 83ae017d6c..58d2d0ee7c 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1190,6 +1190,10 @@ If set to 1, the filename will always be
> interpreted as just a
>  filename, not a pattern, and the corresponding file will be continuously
>  overwritten with new images. Default value is 0.
>
> +@item strftime_source
> +If set to 1, expand the filename with date and time information from
> source.
> +Useful when input is live stream like rtsp.
> +
>  @item strftime
>  If set to 1, expand the filename with date and time information from
>  @code{strftime()}. Default value is 0.
> diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
> index bec4bf81dd..8ba95ee3d5 100644
> --- a/libavformat/img2enc.c
> +++ b/libavformat/img2enc.c
> @@ -45,6 +45,7 @@ typedef struct VideoMuxData {
>  int frame_pts;
>  const char *muxer;
>  int use_rename;
> +int strftime_source;
>  } VideoMuxData;
>
>  static int write_header(AVFormatContext *s)
> @@ -96,6 +97,7 @@ static int write_packet(AVFormatContext *s, AVPacket
> *pkt)
>  struct tm *tm, tmpbuf;
>  time(&now0);
>  tm = localtime_r(&now0, &tmpbuf);
> +
>  if (!strftime(filename, sizeof(filename), img->path, tm)) {
>  av_log(s, AV_LOG_ERROR, "Could not get frame filename
> with strftime\n");
>  return AVERROR(EINVAL);
> @@ -105,6 +107,42 @@ static int write_packet(AVFormatContext *s, AVPacket
> *pkt)
>  av_log(s, AV_LOG_ERROR, "Cannot write filename by pts of
> the frames.");
>  return AVERROR(EINVAL);
>  }
> +} else if (img->strftime_source) {
> +int64_t start_realtime = s->start_time_realtime;
> +time_t sec = 0;
> +struct tm *tm;
> +
> +if (start_realtime == AV_NOPTS_VALUE) {
> +// The value is not passed from input context to output,
> try to find in metadata.
> +AVDictionaryEntry *entry = av_dict_get(s->metadata,
> "start_realtime", NULL, 0);
> +if (entry) {
> +av_log(s, AV_LOG_INFO, "Get start time from metadata
> start_realtime: %s\n", entry->value);
> +start_realtime = strtoll(entry->value, NULL, 0);
> +} else {
> +if (ff_parse_creation_time_metadata(s,
> &start_realtime, 0) != 0)
> +av_log(s, AV_LOG_INFO, "Use creation_time as
> start_timestamp.\n");
> +}
> +
> +if (start_realtime == 0 || start_realtime ==
> AV_NOPTS_VALUE) {
> +av_log(s, AV_LOG_WARNING, "Could not get
> start_realtime from source, set value to now.\n");
> +time(&sec);
> +s->start_time_realtime = sec * AV_TIME_BASE;
> +} else {
> +s->start_time_realtime = start_realtime;
> +}
> +}
> +
> +if (!sec) {
> +int64_t offset = av_rescale_q(pkt->pts,
> s->streams[0]->time_base, AV_TIME_BASE_Q);
> +int64_t timestamp = start_realtime + offset;
> +sec = timestamp / AV_TIME_BASE;
> +}
> +
> +tm = gmtime(&sec);
> +if (!strftime(filename, sizeof(filename), img->path, tm)) {
> +av_log(s, AV_LOG_ERROR, "Could not get frame filename
> with strftime\n");
> +return AVERROR(EINVAL);
> +}
>  } else if (av_get_frame_filename2(filename, sizeof(filename),
> img->path,
>img->img_number,
>
>  AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0 &&
> @@ -215,6 +253,7 @@ static const AVOption muxoptions[] = {
>  { "strftime", "use strftime for filename", OFFSET(use_strftime),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
>  { "frame_pts","use current frame pts for filename",
> OFFSET(frame_pts),  AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, ENC },
>  { "atomic_writing", "write files atomically (using temporary files
> and renames)", OFFSET(use_rename), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1,
> ENC },
> +{ "strftime_source", "use strftime for filename and timestamp(UTC)
> from source if exists", OFFSET(strftime_source), AV_OPT_TYPE_BOOL, { .i64 =
> 0 }, 0, 1, ENC },
>  { NULL },
>  };
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 8349840c96..16bb143ca6 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.

[FFmpeg-devel] [PATCH 2/2] web/security: add some missing CVEs

2019-04-17 Thread Michael Niedermayer
---
 src/security | 49 +
 1 file changed, 49 insertions(+)

diff --git a/src/security b/src/security
index b6239bf..9175aba 100644
--- a/src/security
+++ b/src/security
@@ -12,6 +12,14 @@ CVE-2019-9718, cc5361ed18ab0f69cfbead7afc88fb81ed4b36ae / 
1f00c97bc3475c477f3c46
 CVE-2019-9721, f7f3937494f6734d27fc3d0081c9c7a9a19614a8 / 
894995c41e0795c7a44f81adc4838dedc3932e65
 
 
+4.1.1
+
+Fixes following vulnerabilities:
+
+
+CVE-2019-116, b420f23566825192c3fc1f46fce24d19ffc1d72e / 
b97a4b658814b2de8b9f2a3bce491c002d34de31
+
+
 4.1
 
 Fixes following vulnerabilities:
@@ -29,6 +37,12 @@ CVE-2018-13305, d08d4a8c7387e758d439b0592782e4cfa2b4d6a4
 CVE-2018-14394, 3a2d21bc5f97aa0161db3ae731fc2732be6108b8
 CVE-2018-14395, fa19fbcf712a6a6cc5a5cfdc3254a97b9bce6582
 CVE-2018-15822, 6b67d7f05918f7a1ee8fc6ff21355d7e8736aa10
+CVE-2018-1999010, cced03dd667a5df6df8fd40d8de0bff477ee02e8
+CVE-2018-1999011, 2b46ebdbff1d8dec7a3d8ea280a612b91a582869
+CVE-2018-1999012, 9807d3976be0e92e4ece3b4b1701be894cd7c2e1
+CVE-2018-1999013, a7e032a277452366771951e29fd0bf2bd5c029f0
+CVE-2018-1999014, bab0716c7f4793ec42e05a5aa7e80d82a0dd4e75
+CVE-2018-1999015, 5aba5b89d0b1d73164d3b81764828bb8b20ff32a
 
 
 FFmpeg 4.0
@@ -62,6 +76,12 @@ CVE-2018-13303, 0003ace83b18f68c981c8ad401bee75315edf9f5 / 
00e8181bd97c834fe6075
 CVE-2018-13304, 5fd1dce39a70340b9fd508154e48985902602e25 / 
bd27a9364ca274ca97f1df6d984e88a0700fb235
 CVE-2018-14394, 0981dfee7d413ec6f30f00ddb109e3959c05bebd / 
3a2d21bc5f97aa0161db3ae731fc2732be6108b8
 CVE-2018-14395, fd53179f4a71e0acd807bdfff112a55e204fa4ba / 
fa19fbcf712a6a6cc5a5cfdc3254a97b9bce6582
+CVE-2018-1999010, 6d992a51c75aafba6e21bff95cddae9d717bc7e3 / 
cced03dd667a5df6df8fd40d8de0bff477ee02e8
+CVE-2018-1999011, a21703ca5d42e91b3a218e755020e90ef3af2eae / 
2b46ebdbff1d8dec7a3d8ea280a612b91a582869
+CVE-2018-1999012, 6f4b82cc3a879f5d3f9a4738bfd7d93757221958 / 
9807d3976be0e92e4ece3b4b1701be894cd7c2e1
+CVE-2018-1999013, 37f505cc853f592d93b6285c8a91eece2e5b8b07 / 
a7e032a277452366771951e29fd0bf2bd5c029f0
+CVE-2018-1999014, a28ab09e2a2ac3fcc61e77ff5d702d9157eb37bc / 
bab0716c7f4793ec42e05a5aa7e80d82a0dd4e75
+CVE-2018-1999015, 4439d6aa6956453f6f5479020ee71baebbec4287 / 
5aba5b89d0b1d73164d3b81764828bb8b20ff32a
 
 
 4.0.1
@@ -82,6 +102,7 @@ Fixes following vulnerabilities:
 CVE-2018-6912, 76cc0f0f673353cd4746cd3b83838ae335e5d9ed
 CVE-2018-7751, a6cba062051f345e8ebfdff34aba071ed73d923f
 CVE-2018-7557, 7414d0bda7763f9bd69c26c068e482ab297c1c96
+CVE-2018-9841, 35eeff30caf34df835206f1c12bcf4b7c2bd6758
 CVE-2018-10001, 47b7c68ae54560e2308bdb6be4fb076c73b93081
 
 
@@ -119,11 +140,16 @@ Fixes following vulnerabilities:
 
 CVE-2018-7557,  ae49cc73f265a155e5c4b1715570aab3d9741b4d / 
7414d0bda7763f9bd69c26c068e482ab297c1c96
 CVE-2018-7751,  3fa6e594a0f2575ddb6b2183961fde42ab5ab37b / 
a6cba062051f345e8ebfdff34aba071ed73d923f
+CVE-2018-9841,  43916494f8cac6ed294309e70de346e309d51058 / 
35eeff30caf34df835206f1c12bcf4b7c2bd6758
 CVE-2018-10001, 51035698bde9c13da7eedc1f6eb47d190bbc949d / 
47b7c68ae54560e2308bdb6be4fb076c73b93081
 CVE-2018-12458, bd1fd3ff4b0437153a6c4717f59ce31a7bba8ca0 / 
e1182fac1afba92a4975917823a5f644bee7e6e8
 CVE-2018-13300, 3a04f518ac283194bb13d8aff7d9fa963d551547 / 
95556e27e2c1d56d9e18f5db34d6f756f3011148
 CVE-2018-13302, 36c779bffe2ceef48a0fa4d7a6691c6895faf9e2 / 
ed22dc22216f74c75ee7901f82649e1ff725ba50
 CVE-2018-14394, 20ad61ffb7b0fc72d17b5c21035eb85a698ac64b / 
3a2d21bc5f97aa0161db3ae731fc2732be6108b8
+CVE-2018-1999010, 5da77e7e9e91a1f2a6b80f64f4202c0a4534e307 / 
cced03dd667a5df6df8fd40d8de0bff477ee02e8
+CVE-2018-1999011, 9dea41eac7229688e566a4a3e3f8251acf7ab97c / 
2b46ebdbff1d8dec7a3d8ea280a612b91a582869
+CVE-2018-1999012, 717ece29fd497500ef0315d1841fa7bd0640f53c / 
9807d3976be0e92e4ece3b4b1701be894cd7c2e1
+CVE-2018-1999013, 09401d0a0abec4d1db395af3ddb2c610c5b51153 / 
a7e032a277452366771951e29fd0bf2bd5c029f0
 
 
 3.4.2
@@ -174,6 +200,9 @@ CVE-2018-13300, 672ada0f179b3ef45e52987d8c96716d23aa0722 / 
95556e27e2c1d56d9e18f
 CVE-2018-13302, 78b1fbca3404459dcf8a1c34b5c7f9a5825ad61f / 
ed22dc22216f74c75ee7901f82649e1ff725ba50
 CVE-2018-14394, 6a0a16e563f07722acd4b666b2c501e186e9fa4b / 
3a2d21bc5f97aa0161db3ae731fc2732be6108b8
 CVE-2018-14395, 87ddf73e52b412ee015108ec2f1aaac7a05c947f / 
fa19fbcf712a6a6cc5a5cfdc3254a97b9bce6582
+CVE-2018-1999012, 9bb3047060c33e93ace258634aa89ee1705ec0c3 / 
9807d3976be0e92e4ece3b4b1701be894cd7c2e1
+CVE-2018-1999013, 34654d41d4bd9abb3b848477a6dd0a7d33816d4e / 
a7e032a277452366771951e29fd0bf2bd5c029f0
+CVE-2018-1999010, 4d77a4a54d2f5c34a9cc7d3b3424d16e24515a0f / 
cced03dd667a5df6df8fd40d8de0bff477ee02e8
 
 
 3.3.7
@@ -184,6 +213,7 @@ Fixes following vulnerabilities:
 CVE-2018-6621, 0322f781777d4413bd57815ee9b5a7d6a0cfe716 / 
118e1b0b3370dd1c0da442901b486689efd1654b
 CVE-2018-6392, d74839d793ebf8c6c7c4a2a8a22ae2bd695d2c41 / 
3f621455d62e46745453568d915badd5b1e5bcd5
 CVE-2018-7557, bafb13dc0fd60f49f613bf4c52ce88b91176755c / 
7414d0bda7763f9bd69c26c0

[FFmpeg-devel] [PATCH 1/2] web/security: fix typos

2019-04-17 Thread Michael Niedermayer
Signed-off-by: Michael Niedermayer 
---
 src/security | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/security b/src/security
index 8615685..b6239bf 100644
--- a/src/security
+++ b/src/security
@@ -33,7 +33,7 @@ CVE-2018-15822, 6b67d7f05918f7a1ee8fc6ff21355d7e8736aa10
 
 FFmpeg 4.0
 
-4.0.3
+4.0.4
 
 Fixes following vulnerabilities:
 
@@ -171,7 +171,7 @@ Fixes following vulnerabilities:
 
 CVE-2018-12458, d1bac7f2a68e164385d7018f2c2562e0d219 / 
e1182fac1afba92a4975917823a5f644bee7e6e8
 CVE-2018-13300, 672ada0f179b3ef45e52987d8c96716d23aa0722 / 
95556e27e2c1d56d9e18f5db34d6f756f3011148
-CVE-2018-13302, 78b1fbca3404459dcf8a1c34b5c7f9a5825ad61f / 
ed22dc22216f74c75ee7901f82649e1ff725ba5
+CVE-2018-13302, 78b1fbca3404459dcf8a1c34b5c7f9a5825ad61f / 
ed22dc22216f74c75ee7901f82649e1ff725ba50
 CVE-2018-14394, 6a0a16e563f07722acd4b666b2c501e186e9fa4b / 
3a2d21bc5f97aa0161db3ae731fc2732be6108b8
 CVE-2018-14395, 87ddf73e52b412ee015108ec2f1aaac7a05c947f / 
fa19fbcf712a6a6cc5a5cfdc3254a97b9bce6582
 
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libavformat: fix inputs initialization in mpegts muxer with filters

2019-04-17 Thread Andreas Håkon via ffmpeg-devel
This patch solves the initialization of the inputs when using filters (a graph 
filter) with the mpegts muxer.

This bug seems to be generated by a simple forgetting to copy. The same code is 
repeated two times, but only in one case the variable “inputs_done” is 
initialized. Compare the two blocks:
- Correct: 
https://github.com/FFmpeg/FFmpeg/blob/a0559fcd81f42f446c93357a943699f9d44eeb79/fftools/ffmpeg.c#L4627
- Incorrect: 
https://github.com/FFmpeg/FFmpeg/blob/a0559fcd81f42f446c93357a943699f9d44eeb79/fftools/ffmpeg.c#L4616

In addition, the patch includes a more detailed version of two LOG lines. These 
lines include useful information to detect this error. And they can help to 
discover other related errors (specifically related to the “cur_dts is invalid” 
bug that often appears in some user logs).

Regards.
A.H.From af81338c21c67c0ef2c30ab2009c7094b32327f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20H=C3=A5kon?= 
Date: Wed, 17 Apr 2019 21:22:43 +0100
Subject: [PATCH] libavformat: input init fix mpegts filters

---
 fftools/ffmpeg.c|8 ++--
 libavformat/utils.c |4 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0f157d6..b74a209 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3875,7 +3875,9 @@ static OutputStream *choose_output(void)
av_rescale_q(ost->st->cur_dts, ost->st->time_base,
 AV_TIME_BASE_Q);
 if (ost->st->cur_dts == AV_NOPTS_VALUE)
-av_log(NULL, AV_LOG_DEBUG, "cur_dts is invalid (this is harmless 
if it occurs once at the start per stream)\n");
+av_log(NULL, AV_LOG_DEBUG,
+"cur_dts is invalid st:%d (%d) [init:%d i_done:%d finish:%d] 
(this is harmless if it occurs once at the start per stream)\n",
+ost->st->index, ost->st->id, ost->initialized, 
ost->inputs_done, ost->finished);
 
 if (!ost->initialized && !ost->inputs_done)
 return ost;
@@ -4613,8 +4615,10 @@ static int transcode_step(void)
 }
 if ((ret = transcode_from_filter(ost->filter->graph, &ist)) < 0)
 return ret;
-if (!ist)
+if (!ist) {
+ost->inputs_done = 1;
 return 0;
+}
 } else if (ost->filter) {
 int i;
 for (i = 0; i < ost->filter->graph->nb_inputs; i++) {
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 9b3f0d2..6ef9423 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1402,8 +1402,8 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 st->cur_dts = pkt->dts;
 
 if (s->debug & FF_FDEBUG_TS)
-av_log(s, AV_LOG_DEBUG, "OUTdelayed:%d/%d pts:%s, dts:%s cur_dts:%s\n",
-presentation_delayed, delay, av_ts2str(pkt->pts), 
av_ts2str(pkt->dts), av_ts2str(st->cur_dts));
+av_log(s, AV_LOG_DEBUG, "OUTdelayed:%d/%d pts:%s, dts:%s cur_dts:%s 
st:%d (%d)\n",
+presentation_delayed, delay, av_ts2str(pkt->pts), 
av_ts2str(pkt->dts), av_ts2str(st->cur_dts), st->index, st->id);
 
 /* update flags */
 if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA || 
is_intra_only(st->codecpar->codec_id))
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Updated the documentation for libaom encoder options.

2019-04-17 Thread Gyan



On 18-04-2019 12:33 AM, Sam John via ffmpeg-devel wrote:

Hi,

Is there anything to be done for this patch ?


Just a tiny bit of formatting, which I'll do and push.

Thanks,
Gyan



On Tue, Apr 9, 2019 at 5:55 PM Sam John  wrote:


---
  doc/encoders.texi | 47 +++
  1 file changed, 47 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 94337d009c..15b9199549 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1434,6 +1434,16 @@ value is 1, which will be slow and high quality.
  Enable use of alternate reference frames.  Defaults to the internal
  default of the library.

+@item arnr-max-frames
+Set altref noise reduction max frame count.
+
+@item arnr-strength
+Set altref noise reduction filter strength.
+
+@item aq-mode
+Set adaptive quantization mode (0: off (default), 1: variance 2:
complexity, 3:
+cyclic refresh).
+
  @item lag-in-frames
  Set the maximum number of frames which the encoder may keep in flight
  at any one time for lookahead purposes.  Defaults to the internal
@@ -1466,6 +1476,31 @@ buffer falls below this percentage, frames will be
dropped until it
  has refilled above the threshold.  Defaults to zero (no frames are
  dropped).

+@item denoise-noise-level
+Amount of noise to be removed for grain synthesis. Grain synthesis is
disabled if
+this option is not set or set to 0.
+
+@item denoise-block-size
+Block size used for denoising for grain synthesis. If not set, AV1 codec
+uses the default value of 32.
+
+@item undershoot-pct
+Set datarate undershoot (min) percentage of the target bitrate.
+
+@item overshoot-pct
+Set datarate overshoot (max) percentage of the target bitrate.
+
+@item maxsection-pct
+Maximum percentage variation of the GOP bitrate from the target bitrate.
If maxsection-pct
+is not set, the libaomenc wrapper computes it as follows: @code{(maxrate
* 100 / bitrate)}.
+
+@item minrate
+Minimum percentage variation of the GOP bitrate from the target bitrate.
If minsection-pct
+is not set, the libaomenc wrapper computes it as follows: @code{(minrate
* 100 / bitrate)}.
+
+@item frame-parallel @var{boolean}
+Enable frame parallel decodability features. The default value is true.
+
  @item tiles
  Set the number of tiles to encode the input video with, as columns x
  rows.  Larger numbers allow greater parallelism in both encoding and
@@ -1480,6 +1515,18 @@ Provided for compatibility with libvpx/VP9.
  @item row-mt (Requires libaom >= 1.0.0-759-g90a15f4f2)
  Enable row based multi-threading. Disabled by default.

+@item enable-cdef @var{boolean}
+Flag to enable or disable Constrained Directional Enhancement Filter. The
libaom-av1
+encoder enables CDEF by default.
+
+@item enable-global-motion @var{boolean}
+Flag to enable or disable the use of global motion for block prediction.
+The default value is true.
+
+@item enable-intrabc @var{boolean}
+Flag to enable or disable block copy mode for intra block prediction.
This mode is
+useful for screen content. The default value is true.
+
  @end table

  @section libkvazaar
--
2.21.0.392.gf8f6787159e-goog



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Updated the documentation for libaom encoder options.

2019-04-17 Thread Sam John via ffmpeg-devel
Hi,

Is there anything to be done for this patch ?

Thanks
Sam John

On Tue, Apr 9, 2019 at 5:55 PM Sam John  wrote:

> ---
>  doc/encoders.texi | 47 +++
>  1 file changed, 47 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 94337d009c..15b9199549 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1434,6 +1434,16 @@ value is 1, which will be slow and high quality.
>  Enable use of alternate reference frames.  Defaults to the internal
>  default of the library.
>
> +@item arnr-max-frames
> +Set altref noise reduction max frame count.
> +
> +@item arnr-strength
> +Set altref noise reduction filter strength.
> +
> +@item aq-mode
> +Set adaptive quantization mode (0: off (default), 1: variance 2:
> complexity, 3:
> +cyclic refresh).
> +
>  @item lag-in-frames
>  Set the maximum number of frames which the encoder may keep in flight
>  at any one time for lookahead purposes.  Defaults to the internal
> @@ -1466,6 +1476,31 @@ buffer falls below this percentage, frames will be
> dropped until it
>  has refilled above the threshold.  Defaults to zero (no frames are
>  dropped).
>
> +@item denoise-noise-level
> +Amount of noise to be removed for grain synthesis. Grain synthesis is
> disabled if
> +this option is not set or set to 0.
> +
> +@item denoise-block-size
> +Block size used for denoising for grain synthesis. If not set, AV1 codec
> +uses the default value of 32.
> +
> +@item undershoot-pct
> +Set datarate undershoot (min) percentage of the target bitrate.
> +
> +@item overshoot-pct
> +Set datarate overshoot (max) percentage of the target bitrate.
> +
> +@item maxsection-pct
> +Maximum percentage variation of the GOP bitrate from the target bitrate.
> If maxsection-pct
> +is not set, the libaomenc wrapper computes it as follows: @code{(maxrate
> * 100 / bitrate)}.
> +
> +@item minrate
> +Minimum percentage variation of the GOP bitrate from the target bitrate.
> If minsection-pct
> +is not set, the libaomenc wrapper computes it as follows: @code{(minrate
> * 100 / bitrate)}.
> +
> +@item frame-parallel @var{boolean}
> +Enable frame parallel decodability features. The default value is true.
> +
>  @item tiles
>  Set the number of tiles to encode the input video with, as columns x
>  rows.  Larger numbers allow greater parallelism in both encoding and
> @@ -1480,6 +1515,18 @@ Provided for compatibility with libvpx/VP9.
>  @item row-mt (Requires libaom >= 1.0.0-759-g90a15f4f2)
>  Enable row based multi-threading. Disabled by default.
>
> +@item enable-cdef @var{boolean}
> +Flag to enable or disable Constrained Directional Enhancement Filter. The
> libaom-av1
> +encoder enables CDEF by default.
> +
> +@item enable-global-motion @var{boolean}
> +Flag to enable or disable the use of global motion for block prediction.
> +The default value is true.
> +
> +@item enable-intrabc @var{boolean}
> +Flag to enable or disable block copy mode for intra block prediction.
> This mode is
> +useful for screen content. The default value is true.
> +
>  @end table
>
>  @section libkvazaar
> --
> 2.21.0.392.gf8f6787159e-goog
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] avcodec: add AV_CODEC_FLAG_DROPCHANGED to flags

2019-04-17 Thread Gyan



On 17-04-2019 11:14 PM, Vittorio Giovara wrote:

On Tue, Apr 16, 2019 at 3:42 AM Gyan  wrote:


Patch revised as per
http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242591.html

Gyan


sorry if i'm late to the party but why are these new fields in
avcodeccontext?
they seem to be perfect candidates for side data, or am i missing something?
The latest patch only adds a constant to avctx. New fields are in 
AVCodecInternal.


The purpose is to allow the user to discard decoded output which 
deviates from initial stream parameters - mainly useful when receiving 
an input over an unreliable transport. The demuxer doesn't always catch 
all corrupted payload, and neither does the decoder (e.g. a mpeg audio 
header with some bits flipped), so some frames with different parameters 
can get through. This causes the filtergraph to be configured, 
destroying its context. Timestamps can go haywire which is not 
acceptable in an ongoing streaming scenario.


Originally I submitted this as a ffmpeg.c patch, but Michael suggested 
that avcodec users may find it useful.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avutil/colorspace: add macros for RGB->YUV BT.709

2019-04-17 Thread Gyan



On 17-04-2019 11:11 PM, Vittorio Giovara wrote:

On Wed, Apr 17, 2019 at 12:26 AM Gyan  wrote:



On 13-04-2019 05:23 PM, Gyan wrote:

Will be helpful for correct result in filters that paint like
fillborders/drawbox or those using drawutils.

Ping.


these seem to only work for 8 bit content, is that their only intended
usecase?
if so, could there be at least a comment mentioning that please?
Yes, the existing macros use Rec.601 co-efficients, but most data is 709 
now.

Will add a note.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] avcodec: add AV_CODEC_FLAG_DROPCHANGED to flags

2019-04-17 Thread Vittorio Giovara
On Tue, Apr 16, 2019 at 3:42 AM Gyan  wrote:

> Patch revised as per
> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242591.html
>
> Gyan
>

sorry if i'm late to the party but why are these new fields in
avcodeccontext?
they seem to be perfect candidates for side data, or am i missing something?
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avutil/colorspace: add macros for RGB->YUV BT.709

2019-04-17 Thread Vittorio Giovara
On Wed, Apr 17, 2019 at 12:26 AM Gyan  wrote:

>
>
> On 13-04-2019 05:23 PM, Gyan wrote:
> > Will be helpful for correct result in filters that paint like
> > fillborders/drawbox or those using drawutils.
>
> Ping.
>

these seem to only work for 8 bit content, is that their only intended
usecase?
if so, could there be at least a comment mentioning that please?
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/dvdec: add frame threads

2019-04-17 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/dvdec.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
index 7b16787e27..89864f2edc 100644
--- a/libavcodec/dvdec.c
+++ b/libavcodec/dvdec.c
@@ -49,6 +49,7 @@
 #include "internal.h"
 #include "put_bits.h"
 #include "simple_idct.h"
+#include "thread.h"
 
 typedef struct BlockInfo {
 const uint32_t *factor_table;
@@ -499,7 +500,7 @@ static int dvvideo_decode_frame(AVCodecContext *avctx, void 
*data,
 uint8_t *buf = avpkt->data;
 int buf_size = avpkt->size;
 DVVideoContext *s = avctx->priv_data;
-AVFrame *frame = data;
+ThreadFrame frame = { .f = data };
 const uint8_t *vsc_pack;
 int apt, is16_9, ret;
 const AVDVProfile *sys;
@@ -520,9 +521,9 @@ static int dvvideo_decode_frame(AVCodecContext *avctx, void 
*data,
 s->sys = sys;
 }
 
-s->frame= frame;
-frame->key_frame= 1;
-frame->pict_type= AV_PICTURE_TYPE_I;
+s->frame= frame.f;
+frame.f->key_frame  = 1;
+frame.f->pict_type  = AV_PICTURE_TYPE_I;
 avctx->pix_fmt  = s->sys->pix_fmt;
 avctx->framerate= av_inv_q(s->sys->time_base);
 
@@ -539,14 +540,14 @@ static int dvvideo_decode_frame(AVCodecContext *avctx, 
void *data,
 ff_set_sar(avctx, s->sys->sar[is16_9]);
 }
 
-if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
+if ((ret = ff_thread_get_buffer(avctx, &frame, 0)) < 0)
 return ret;
-frame->interlaced_frame = 1;
-frame->top_field_first  = 0;
+frame.f->interlaced_frame = 1;
+frame.f->top_field_first  = 0;
 
 /* Determine the codec's field order from the packet */
 if ( *vsc_pack == dv_video_control ) {
-frame->top_field_first = !(vsc_pack[3] & 0x40);
+frame.f->top_field_first = !(vsc_pack[3] & 0x40);
 }
 
 s->buf = buf;
@@ -569,6 +570,6 @@ AVCodec ff_dvvideo_decoder = {
 .priv_data_size = sizeof(DVVideoContext),
 .init   = dvvideo_decode_init,
 .decode = dvvideo_decode_frame,
-.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SLICE_THREADS,
+.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS | 
AV_CODEC_CAP_SLICE_THREADS,
 .max_lowres = 3,
 };
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/cbs_av1: add missing value range constrains to timecode Metadata OBU

2019-04-17 Thread James Almer
Also infer the value time_offset_length as 0 when it's not present.

Signed-off-by: James Almer 
---
Fun thing, this metadata OBU is clearly based on the H264/5 timecode SEI, yet
time_offset_length is unsigned here :p

 libavcodec/cbs_av1_syntax_template.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/libavcodec/cbs_av1_syntax_template.c 
b/libavcodec/cbs_av1_syntax_template.c
index 59a98b18c9..b04cd51d55 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1753,19 +1753,19 @@ static int 
FUNC(metadata_timecode)(CodedBitstreamContext *ctx, RWContext *rw,
 fb(9, n_frames);
 
 if (current->full_timestamp_flag) {
-fb(6, seconds_value);
-fb(6, minutes_value);
-fb(5, hours_value);
+fc(6, seconds_value, 0, 59);
+fc(6, minutes_value, 0, 59);
+fc(5, hours_value,   0, 23);
 } else {
 flag(seconds_flag);
 if (current->seconds_flag) {
-fb(6, seconds_value);
+fc(6, seconds_value, 0, 59);
 flag(minutes_flag);
 if (current->minutes_flag) {
-fb(6, minutes_value);
+fc(6, minutes_value, 0, 59);
 flag(hours_flag);
 if (current->hours_flag)
-fb(5, hours_value);
+fc(5, hours_value, 0, 23);
 }
 }
 }
@@ -1773,6 +1773,8 @@ static int FUNC(metadata_timecode)(CodedBitstreamContext 
*ctx, RWContext *rw,
 fb(5, time_offset_length);
 if (current->time_offset_length > 0)
 fb(current->time_offset_length, time_offset_value);
+else
+infer(time_offset_length, 0);
 
 return 0;
 }
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] Fix sdp size check on fmtp integer parameters

2019-04-17 Thread Olivier MAIGNIAL
Hello all
Just a reminder for this patch

On Mon, Apr 1, 2019 at 4:45 PM Olivier Maignial 
wrote:

> RFC-4566 do not give any limit of size on interger parameters given in
> fmtp line.
> By reading some more RFCs it is possible to find examples where some
> integers parameters are greater than 32 (see RFC-6416, 7.4)
>
> Instead I propose to check just check the eventual integer overflow.
> Using INT_MIN and INT_MAX ensure that it will work whatever the size of
> int given by compiler
>
> Signed-off-by: Olivier Maignial 
> ---
>
> Changes v1 -> v2:
> - Removed line break at end of 'if' line before brace
> - Added Signed-Off-By line
>
>  libavformat/rtpdec_mpeg4.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
> index 994ab49..14caa0a 100644
> --- a/libavformat/rtpdec_mpeg4.c
> +++ b/libavformat/rtpdec_mpeg4.c
> @@ -289,15 +289,23 @@ static int parse_fmtp(AVFormatContext *s,
>  for (i = 0; attr_names[i].str; ++i) {
>  if (!av_strcasecmp(attr, attr_names[i].str)) {
>  if (attr_names[i].type == ATTR_NAME_TYPE_INT) {
> -int val = atoi(value);
> -if (val > 32) {
> +char *end_ptr = NULL;
> +long int val = strtol(value, &end_ptr, 10);
> +if (value[0] == '\n' || end_ptr[0] != '\0') {
>  av_log(s, AV_LOG_ERROR,
> -   "The %s field size is invalid (%d)\n",
> +   "The %s field value is not a number
> (%s)\n",
> +   attr, value);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (val > INT_MAX || val < INT_MIN) {
> +av_log(s, AV_LOG_ERROR,
> +   "The %s field size is invalid (%ld)\n",
> attr, val);
>  return AVERROR_INVALIDDATA;
>  }
>  *(int *)((char *)data+
> -attr_names[i].offset) = val;
> +attr_names[i].offset) = (int) val;
>  } else if (attr_names[i].type == ATTR_NAME_TYPE_STR) {
>  char *val = av_strdup(value);
>  if (!val)
> --
> 2.7.4
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavfilter/f_select: response file support

2019-04-17 Thread Jonathan Gilbert
I've changed the allocation functions and attached the output of `git
format-patch` to this e-mail.

Thanks,

Jonathan Gilbert

On Tue, Apr 16, 2019 at 5:50 PM Carl Eugen Hoyos  wrote:

> 2019-04-16 19:14 GMT+02:00, Jonathan Gilbert :
> > Hello :-)
> >
> > I had a project recently where I wanted to externally specify a list
> > of specific frame numbers to drop. I understand this can be done with
> > select expressions like "not(eq(n,45)+eq(n,47)+eq(n,75))", but in my
> > case I wanted to drop nearly 16,000 frames, which would have required
> > a command-line over 250 KB in size. I chose a different approach: I
> > have added functionality to f_select.c so that you can specify the
> > list of frames you want to include/exclude in an external response
> > file. I have successfully used this code for my project, and thought I
> > might submit it up to for consideration. :-)
> >
> > I've never submitted a patch in this format before, I hope I'm doing
> > this correctly.
>
> This is definitely not the only issue:
> Instead of using malloc() and friends, please see libavutil/mem.h
> for the appropriate functions.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


0001-Added-options-file-filemode-filetype-and-warnunused-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".