[FFmpeg-devel] [PATCH] ffmpeg: fix increment of sync_opts

2022-09-08 Thread Xiaolei Yu 
The encoder time base could been overridden by the command line argument
and may not always be 1/ost->frame_rate.
---
 fftools/ffmpeg.c |  2 +-
 tests/fate/ffmpeg.mak|  5 +
 tests/ref/fate/enc_time_base-vfr | 25 +
 3 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/enc_time_base-vfr

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0e1477299d..8bc48125c8 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1344,7 +1344,7 @@ static void do_video_out(OutputFile *of,
 if (ret < 0 && ret != AVERROR_EOF)
 exit_program(1);
 
-ost->sync_opts++;
+ost->sync_opts += av_rescale_q(1, av_inv_q(ost->frame_rate), 
ost->enc_ctx->time_base);
 ost->vsync_frame_number++;
 }
 
diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 38a1ae7ed5..a3be79d65e 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -209,3 +209,8 @@ FATE_TIME_BASE-$(call PARSERDEMDEC, MPEGVIDEO, MPEGPS, 
MPEG2VIDEO, MPEGVIDEO_DEM
 fate-time_base: CMD = md5 -i $(TARGET_SAMPLES)/mpeg2/dvd_single_frame.vob -an 
-sn -c:v copy -r 25 -time_base 1001:3 -fflags +bitexact -f mxf
 
 FATE_SAMPLES_FFMPEG-yes += $(FATE_TIME_BASE-yes)
+
+FATE_ENC_TIME_BASE-$(call ALLYES, LAVFI_INDEV COLOR_FILTER FRAMEMD5_MUXER) += 
fate-enc_time_base-vfr
+fate-enc_time_base-vfr: CMD = framemd5 -auto_conversion_filters -fflags 
+bitexact -flags +bitexact -f lavfi -i "color=r=30:d=1" -enc_time_base 1/600 
-fps_mode vfr -r 15
+
+FATE_SAMPLES_FFMPEG-yes += $(FATE_ENC_TIME_BASE-yes)
diff --git a/tests/ref/fate/enc_time_base-vfr b/tests/ref/fate/enc_time_base-vfr
new file mode 100644
index 00..cb38177d8e
--- /dev/null
+++ b/tests/ref/fate/enc_time_base-vfr
@@ -0,0 +1,25 @@
+#format: frame checksums
+#version: 2
+#hash: MD5
+#tb 0: 1/600
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 320x240
+#sar 0: 1/1
+#stream#, dts,pts, duration, size, hash
+0,  0,  0,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0, 40, 40,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0, 80, 80,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,120,120,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,160,160,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,200,200,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,240,240,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,280,280,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,320,320,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,360,360,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,400,400,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,440,440,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,480,480,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,520,520,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,560,560,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
+0,600,600,   40,   115200, 8e4dd5c5c31a54672e30503f6ee13321
-- 
2.37.2
___
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 v2 2/2] avcodec/hevcdec: detect non-conformant missing refs

2022-04-16 Thread Xiaolei Yu 
For cases which prefer rejecting broken bitstreams.
---
 libavcodec/hevc_refs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 84a21991c7..9f8b6022c4 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -439,6 +439,8 @@ static int add_candidate_ref(HEVCContext *s, RefPicList 
*list,
 return 0;
 
 av_log(s->avctx, AV_LOG_ERROR, "Could not find ref with POC %d\n", 
poc);
+if (s->avctx->err_recognition & AV_EF_COMPLIANT)
+return AVERROR_INVALIDDATA;
 
 ref = generate_missing_ref(s, poc);
 if (!ref)
-- 
2.35.1



OpenPGP_0x22AEF7EFBDCEFF03.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital 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 v2 1/2] avcodec/hevcdec: skip generating missing refs in foll lists

2022-04-16 Thread Xiaolei Yu 
Missing refs shall be generated only when they are actually used.

Without this change a sequence of a BLA picture and an associated RASL picture
would still be decoded without complaints if the RASL picture is mislabeled
as RADL.
---
 libavcodec/hevc_refs.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index fe18ca2b1d..84a21991c7 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -378,9 +378,6 @@ static HEVCFrame *find_ref_idx(HEVCContext *s, int poc, 
uint8_t use_msb)
 }
 }
 
-if (s->nal_unit_type != HEVC_NAL_CRA_NUT && !IS_BLA(s))
-av_log(s->avctx, AV_LOG_ERROR,
-   "Could not find ref with POC %d\n", poc);
 return NULL;
 }
 
@@ -426,7 +423,7 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s, int 
poc)
 
 /* add a reference with the given poc to the list and mark it as used in DPB */
 static int add_candidate_ref(HEVCContext *s, RefPicList *list,
- int poc, int ref_flag, uint8_t use_msb)
+ int poc, int ref_flag, uint8_t use_msb, enum 
RPSType rps_type)
 {
 HEVCFrame *ref = find_ref_idx(s, poc, use_msb);
 
@@ -434,6 +431,15 @@ static int add_candidate_ref(HEVCContext *s, RefPicList 
*list,
 return AVERROR_INVALIDDATA;
 
 if (!ref) {
+int allow_missing = !(rps_type == ST_CURR_BEF || rps_type == 
ST_CURR_AFT ||
+  rps_type == LT_CURR);
+
+/* skip generating missing refs in foll lists as they are not used by 
current frame */
+if (allow_missing)
+return 0;
+
+av_log(s->avctx, AV_LOG_ERROR, "Could not find ref with POC %d\n", 
poc);
+
 ref = generate_missing_ref(s, poc);
 if (!ref)
 return AVERROR(ENOMEM);
@@ -484,7 +490,7 @@ int ff_hevc_frame_rps(HEVCContext *s)
 else
 list = ST_CURR_AFT;
 
-ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_SHORT_REF, 
1);
+ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_SHORT_REF, 
1, list);
 if (ret < 0)
 goto fail;
 }
@@ -494,7 +500,8 @@ int ff_hevc_frame_rps(HEVCContext *s)
 int poc  = long_rps->poc[i];
 int list = long_rps->used[i] ? LT_CURR : LT_FOLL;
 
-ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_LONG_REF, 
long_rps->poc_msb_present[i]);
+ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_LONG_REF, 
long_rps->poc_msb_present[i],
+list);
 if (ret < 0)
 goto fail;
 }
-- 
2.35.1


OpenPGP_0x22AEF7EFBDCEFF03.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital 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] libavcodec/hevcdec: detect non-conformant missing refs

2022-04-16 Thread Xiaolei Yu 
On 4/5/22 17:10, Anton Khirnov wrote:
> Quoting Xiaolei Yu (2022-04-05 08:49:24)
>>
>> For cases which prefer rejecting broken bitstreams.
>> ---
>>  libavcodec/hevc_refs.c | 15 ---
>>  1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
>> index fe18ca2b1d..7ea70e301b 100644
>> --- a/libavcodec/hevc_refs.c
>> +++ b/libavcodec/hevc_refs.cfind_ref_idx(
>> @@ -426,7 +426,7 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s, 
>> int poc)
>>
>>  /* add a reference with the given poc to the list and mark it as used in 
>> DPB */
>>  static int add_candidate_ref(HEVCContext *s, RefPicList *list,
>> - int poc, int ref_flag, uint8_t use_msb)
>> + int poc, int ref_flag, uint8_t use_msb, int 
>> maybe_missing)
>
> allow_missing would be clearer IMO
>

done

>>  {
>>  HEVCFrame *ref = find_ref_idx(s, poc, use_msb);
>>
>> @@ -434,6 +434,9 @@ static int add_candidate_ref(HEVCContext *s, RefPicList 
>> *list,
>>  return AVERROR_INVALIDDATA;
>>
>>  if (!ref) {
>> +if ((s->avctx->err_recognition & AV_EF_COMPLIANT) && !maybe_missing)
>
> a log message would be nice, so one can easily tell where exactly the
> error comes from
>

Moved the log message from find_ref_idx to where the missing refs are to be 
generated.

OpenPGP_0x22AEF7EFBDCEFF03.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital 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] libavcodec/hevcdec: detect non-conformant missing refs

2022-04-05 Thread Xiaolei Yu 


For cases which prefer rejecting broken bitstreams.
---
 libavcodec/hevc_refs.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index fe18ca2b1d..7ea70e301b 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -426,7 +426,7 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s, int 
poc)
 
 /* add a reference with the given poc to the list and mark it as used in DPB */
 static int add_candidate_ref(HEVCContext *s, RefPicList *list,
- int poc, int ref_flag, uint8_t use_msb)
+ int poc, int ref_flag, uint8_t use_msb, int 
maybe_missing)
 {
 HEVCFrame *ref = find_ref_idx(s, poc, use_msb);
 
@@ -434,6 +434,9 @@ static int add_candidate_ref(HEVCContext *s, RefPicList 
*list,
 return AVERROR_INVALIDDATA;
 
 if (!ref) {
+if ((s->avctx->err_recognition & AV_EF_COMPLIANT) && !maybe_missing)
+return AVERROR_INVALIDDATA;
+
 ref = generate_missing_ref(s, poc);
 if (!ref)
 return AVERROR(ENOMEM);
@@ -476,6 +479,7 @@ int ff_hevc_frame_rps(HEVCContext *s)
 for (i = 0; i < short_rps->num_delta_pocs; i++) {
 int poc = s->poc + short_rps->delta_poc[i];
 int list;
+int maybe_missing;
 
 if (!short_rps->used[i])
 list = ST_FOLL;
@@ -484,7 +488,10 @@ int ff_hevc_frame_rps(HEVCContext *s)
 else
 list = ST_CURR_AFT;
 
-ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_SHORT_REF, 
1);
+maybe_missing = list != ST_CURR_BEF && list != ST_CURR_AFT;
+
+ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_SHORT_REF, 
1,
+maybe_missing);
 if (ret < 0)
 goto fail;
 }
@@ -493,8 +500,10 @@ int ff_hevc_frame_rps(HEVCContext *s)
 for (i = 0; i < long_rps->nb_refs; i++) {
 int poc  = long_rps->poc[i];
 int list = long_rps->used[i] ? LT_CURR : LT_FOLL;
+int maybe_missing = list != LT_CURR;
 
-ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_LONG_REF, 
long_rps->poc_msb_present[i]);
+ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_LONG_REF, 
long_rps->poc_msb_present[i],
+maybe_missing);
 if (ret < 0)
 goto fail;
 }
-- 
2.35.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 v2 1/1] libavcodec/h264: always set video signal type fields

2021-11-24 Thread Xiaolei Yu 
The color range and color description fields when not present
shall be inferred to be LIMITED and UNSPECIFIED respectively.

Relevant info from containers will always be overriden.
This is consistent with the behavior of the hevc decoder.
---
 libavcodec/h264_ps.c |  4 +++-
 libavcodec/h264_slice.c  | 18 +++---
 tests/ref/fate/flv-demux |  2 +-
 tests/ref/fate/h264-dts_5frames  | 10 +-
 tests/ref/fate/matroska-spherical-mono-remux | 14 +++---
 tests/ref/fate/ts-small-demux|  2 +-
 6 files changed, 24 insertions(+), 26 deletions(-)

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index e21c2b56ac..164e6ea0cc 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -378,7 +378,9 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
AVCodecContext *avctx,
 memset(sps->scaling_matrix4, 16, sizeof(sps->scaling_matrix4));
 memset(sps->scaling_matrix8, 16, sizeof(sps->scaling_matrix8));
 sps->scaling_matrix_present = 0;
-sps->colorspace = 2; //AVCOL_SPC_UNSPECIFIED
+sps->colorspace = AVCOL_SPC_UNSPECIFIED;
+sps->color_trc = AVCOL_TRC_UNSPECIFIED;
+sps->color_primaries = AVCOL_PRI_UNSPECIFIED;
 
 if (sps->profile_idc == 100 ||  // High profile
 sps->profile_idc == 110 ||  // High10 profile
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 89ea16a57f..b7f1dfc9ef 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1103,17 +1103,13 @@ static int h264_init_ps(H264Context *h, const 
H264SliceContext *sl, int first_sl
 
 init_dimensions(h);
 
-if (sps->video_signal_type_present_flag) {
-h->avctx->color_range = sps->full_range > 0 ? AVCOL_RANGE_JPEG
-: AVCOL_RANGE_MPEG;
-if (sps->colour_description_present_flag) {
-if (h->avctx->colorspace != sps->colorspace)
-needs_reinit = 1;
-h->avctx->color_primaries = sps->color_primaries;
-h->avctx->color_trc   = sps->color_trc;
-h->avctx->colorspace  = sps->colorspace;
-}
-}
+h->avctx->color_range = sps->full_range > 0 ? AVCOL_RANGE_JPEG
+: AVCOL_RANGE_MPEG;
+if (h->avctx->colorspace != sps->colorspace)
+needs_reinit = 1;
+h->avctx->color_primaries = sps->color_primaries;
+h->avctx->color_trc   = sps->color_trc;
+h->avctx->colorspace  = sps->colorspace;
 
 if (h->sei.alternative_transfer.present &&
 
av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
 &&
diff --git a/tests/ref/fate/flv-demux b/tests/ref/fate/flv-demux
index 9daee0594e..f95eaba4cc 100644
--- a/tests/ref/fate/flv-demux
+++ b/tests/ref/fate/flv-demux
@@ -603,6 +603,6 @@ 
packet|codec_type=video|stream_index=0|pts=11612|pts_time=11.612000|dts=11612|dt
 
packet|codec_type=video|stream_index=0|pts=11645|pts_time=11.645000|dts=11645|dts_time=11.645000|duration=33|duration_time=0.033000|size=2600|pos=507811|flags=__|data_hash=CRC32:d35f9e6f
 
packet|codec_type=audio|stream_index=1|pts=11656|pts_time=11.656000|dts=11656|dts_time=11.656000|duration=46|duration_time=0.046000|size=346|pos=510431|flags=K_|data_hash=CRC32:4e6b44cb
 
packet|codec_type=video|stream_index=0|pts=11678|pts_time=11.678000|dts=11678|dts_time=11.678000|duration=33|duration_time=0.033000|size=1190|pos=510794|flags=__|data_hash=CRC32:a0206c90
-stream|index=0|codec_name=h264|profile=77|codec_type=video|codec_tag_string=[0][0][0][0]|codec_tag=0x|width=426|height=240|coded_width=426|coded_height=240|closed_captions=0|film_grain=0|has_b_frames=1|sample_aspect_ratio=1:1|display_aspect_ratio=71:40|pix_fmt=yuv420p|level=21|color_range=unknown|color_space=unknown|color_transfer=unknown|color_primaries=unknown|chroma_location=left|field_order=progressive|refs=1|is_avc=true|nal_length_size=4|id=N/A|r_frame_rate=3/1001|avg_frame_rate=30/1|time_base=1/1000|start_pts=0|start_time=0.00|duration_ts=N/A|duration=N/A|bit_rate=393929|max_bit_rate=N/A|bits_per_raw_sample=8|nb_frames=N/A|nb_read_frames=N/A|nb_read_packets=351|extradata_hash=CRC32:07b85ca9|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:ti
 
med_thumbnails=0|disposition:captions=0|disposition:descriptions=0|disposition:metadata=0|disposition:dependent=0|disposition:still_image=0

[FFmpeg-devel] [PATCH v2 0/1] libavcodec/h264: always set video signal type fields

2021-11-24 Thread Xiaolei Yu 
Fixed fate tests

Xiaolei Yu (1):
  libavcodec/h264: always set video signal type fields

 libavcodec/h264_ps.c |  4 +++-
 libavcodec/h264_slice.c  | 18 +++---
 tests/ref/fate/flv-demux |  2 +-
 tests/ref/fate/h264-dts_5frames  | 10 +-
 tests/ref/fate/matroska-spherical-mono-remux | 14 +++---
 tests/ref/fate/ts-small-demux|  2 +-
 6 files changed, 24 insertions(+), 26 deletions(-)
___
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] libavcodec/h264: always set color description fields

2021-11-23 Thread Xiaolei Yu 
Color description fields shall be inferred to be UNSPECIFIED if not present.
---
 libavcodec/h264_ps.c|  4 +++-
 libavcodec/h264_slice.c | 18 +++---
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index e21c2b56ac..164e6ea0cc 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -378,7 +378,9 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
AVCodecContext *avctx,
 memset(sps->scaling_matrix4, 16, sizeof(sps->scaling_matrix4));
 memset(sps->scaling_matrix8, 16, sizeof(sps->scaling_matrix8));
 sps->scaling_matrix_present = 0;
-sps->colorspace = 2; //AVCOL_SPC_UNSPECIFIED
+sps->colorspace = AVCOL_SPC_UNSPECIFIED;
+sps->color_trc = AVCOL_TRC_UNSPECIFIED;
+sps->color_primaries = AVCOL_PRI_UNSPECIFIED;
 
 if (sps->profile_idc == 100 ||  // High profile
 sps->profile_idc == 110 ||  // High10 profile
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 89ea16a57f..b7f1dfc9ef 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1103,17 +1103,13 @@ static int h264_init_ps(H264Context *h, const 
H264SliceContext *sl, int first_sl
 
 init_dimensions(h);
 
-if (sps->video_signal_type_present_flag) {
-h->avctx->color_range = sps->full_range > 0 ? AVCOL_RANGE_JPEG
-: AVCOL_RANGE_MPEG;
-if (sps->colour_description_present_flag) {
-if (h->avctx->colorspace != sps->colorspace)
-needs_reinit = 1;
-h->avctx->color_primaries = sps->color_primaries;
-h->avctx->color_trc   = sps->color_trc;
-h->avctx->colorspace  = sps->colorspace;
-}
-}
+h->avctx->color_range = sps->full_range > 0 ? AVCOL_RANGE_JPEG
+: AVCOL_RANGE_MPEG;
+if (h->avctx->colorspace != sps->colorspace)
+needs_reinit = 1;
+h->avctx->color_primaries = sps->color_primaries;
+h->avctx->color_trc   = sps->color_trc;
+h->avctx->colorspace  = sps->colorspace;
 
 if (h->sei.alternative_transfer.present &&
 
av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
 &&
-- 
2.33.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] libavformat/flvdec: add HEVC demuxing support

2021-07-25 Thread Xiaolei Yu 
Explicitly supply an HEVC codec id to enable this feature.
---
 libavformat/flv.h|  1 +
 libavformat/flvdec.c | 21 ++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/libavformat/flv.h b/libavformat/flv.h
index 3571b90279..7cb1b72b4c 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@ -42,6 +42,7 @@
 #define FLV_AUDIO_CODECID_MASK0xf0
 
 #define FLV_VIDEO_CODECID_MASK0x0f
+#define FLV_VIDEO_CODECID_MAX 0x0f
 #define FLV_VIDEO_FRAMETYPE_MASK  0xf0
 
 #define AMF_END_OF_OBJECT 0x09
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index b4a419177a..e44aa693b7 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -74,6 +74,7 @@ typedef struct FLVContext {
 int64_t *keyframe_times;
 int64_t *keyframe_filepositions;
 int missing_streams;
+int hevc_codec_id;
 AVRational framerate;
 int64_t last_ts;
 int64_t time_offset;
@@ -301,7 +302,7 @@ static void flv_set_audio_codec(AVFormatContext *s, 
AVStream *astream,
 }
 }
 
-static int flv_same_video_codec(AVCodecParameters *vpar, int flags)
+static int flv_same_video_codec(FLVContext *flv, AVCodecParameters *vpar, int 
flags)
 {
 int flv_codecid = flags & FLV_VIDEO_CODECID_MASK;
 
@@ -322,6 +323,8 @@ static int flv_same_video_codec(AVCodecParameters *vpar, 
int flags)
 case FLV_CODECID_H264:
 return vpar->codec_id == AV_CODEC_ID_H264;
 default:
+if (flv->hevc_codec_id && flv_codecid == flv->hevc_codec_id)
+return vpar->codec_id == AV_CODEC_ID_HEVC;
 return vpar->codec_tag == flv_codecid;
 }
 }
@@ -329,6 +332,7 @@ static int flv_same_video_codec(AVCodecParameters *vpar, 
int flags)
 static int flv_set_video_codec(AVFormatContext *s, AVStream *vstream,
int flv_codecid, int read)
 {
+FLVContext *flv = s->priv_data;
 int ret = 0;
 AVCodecParameters *par = vstream->codecpar;
 enum AVCodecID old_codec_id = vstream->codecpar->codec_id;
@@ -371,6 +375,12 @@ static int flv_set_video_codec(AVFormatContext *s, 
AVStream *vstream,
 ret = 3;
 break;
 default:
+if (flv->hevc_codec_id && flv_codecid == flv->hevc_codec_id) {
+par->codec_id = AV_CODEC_ID_HEVC;
+vstream->internal->need_parsing = AVSTREAM_PARSE_HEADERS;
+ret = 3; // not 4, reading packet type will consume one byte
+break;
+}
 avpriv_request_sample(s, "Video codec (%x)", flv_codecid);
 par->codec_tag = flv_codecid;
 }
@@ -1126,7 +1136,7 @@ skip:
 break;
 } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
 if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
-(s->video_codec_id || flv_same_video_codec(st->codecpar, 
flags)))
+(s->video_codec_id || flv_same_video_codec(flv, st->codecpar, 
flags)))
 break;
 } else if (stream_type == FLV_STREAM_TYPE_SUBTITLE) {
 if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
@@ -1241,6 +1251,7 @@ retry_duration:
 
 if (st->codecpar->codec_id == AV_CODEC_ID_AAC ||
 st->codecpar->codec_id == AV_CODEC_ID_H264 ||
+st->codecpar->codec_id == AV_CODEC_ID_HEVC ||
 st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
 int type = avio_r8(s->pb);
 size--;
@@ -1250,7 +1261,9 @@ retry_duration:
 goto leave;
 }
 
-if (st->codecpar->codec_id == AV_CODEC_ID_H264 || 
st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
+if (st->codecpar->codec_id == AV_CODEC_ID_H264 ||
+st->codecpar->codec_id == AV_CODEC_ID_HEVC ||
+st->codecpar->codec_id == AV_CODEC_ID_MPEG4) {
 // sign extension
 int32_t cts = (avio_rb24(s->pb) + 0xff80) ^ 0xff80;
 pts = av_sat_add64(dts, cts);
@@ -1266,6 +1279,7 @@ retry_duration:
 }
 }
 if (type == 0 && (!st->codecpar->extradata || st->codecpar->codec_id 
== AV_CODEC_ID_AAC ||
+st->codecpar->codec_id == AV_CODEC_ID_HEVC ||
 st->codecpar->codec_id == AV_CODEC_ID_H264)) {
 AVDictionaryEntry *t;
 
@@ -1361,6 +1375,7 @@ static const AVOption options[] = {
 { "flv_metadata", "Allocate streams according to the onMetaData array", 
OFFSET(trust_metadata), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
 { "flv_full_metadata", "Dump full metadata of the onMetadata", 
OFFSET(dump_full_metadata), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
 { "flv_ignore_prevtag", "Ignore the Size of previous tag", 
OFFSET(trust_datasize), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
+{ "flv_hevc_codec_id", "Assign HEVC stream codec ID", 
OFFSET(hevc_codec_id), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, FLV_VIDEO_CODECID_MAX, 
VD },
 { "missing_streams", "", OFFSET(missing_streams), AV_OPT_TYPE_INT, { .i64 
= 0 }, 0, 0xFF, VD | AV_OPT_FLAG_EXPORT | AV_OPT_FLAG_READONLY },
 { NULL

Re: [FFmpeg-devel] [PATCH 14/14] videotoolbox: remove opengl compatibility attribute

2017-12-16 Thread Xiaolei Yu 
On 12/16/2017 04:19 PM, Wang Bin wrote:
> 2017-12-16 15:33 GMT+08:00 Xiaolei Yu <dreifachst...@gmail.com>:
>> On 12/16/2017 02:07 PM, Wang Bin wrote:
>>> 2017-12-16 2:52 GMT+08:00 wm4 <nfx...@googlemail.com>:
>>>> On Fri, 15 Dec 2017 15:02:44 +0800
>>>> wbse...@gmail.com wrote:
>>>>
>>>>> From: wang-bin <wbse...@gmail.com>
>>>>>
>>>>> 1. a cvpixelbuffer backed by iosurface can always be converted to an 
>>>>> opengl texture, using CGLTexImageIOSurface2D for macOS, and undocumented 
>>>>> api texImageIOSurface(which is internally used by public api 
>>>>> CVOpenGLESTextureCacheCreateTextureFromImage) for iOS4.0+.
>>>>> 2. enabling the attribute can slow down decoding speed a lot. I tested 
>>>>> many video clips on my macbook air. for example: ffmpeg -ss 00:00:00 -t 
>>>>> 00:03:00 -hwaccel videotoolbox -an -i big_buck_bunny_1080p_h264.mov -f 
>>>>> null ->/dev/null, result with the attribute
>>>>> enabled: frame= 2082 fps= 85 q=-0.0 Lsize=N/A time=00:03:00.00 
>>>>> bitrate=N/A speed=7.34x
>>>>> disabled: frame= 2031 fps=104 q=-0.0 Lsize=N/A time=00:03:00.00 
>>>>> bitrate=N/A speed=9.22x
>>>>> ---
>>>>>  libavcodec/videotoolbox.c | 5 -
>>>>>  1 file changed, 5 deletions(-)
>>>>>
>>>>> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
>>>>> index 9d2f0afa20..24631684d7 100644
>>>>> --- a/libavcodec/videotoolbox.c
>>>>> +++ b/libavcodec/videotoolbox.c
>>>>> @@ -664,11 +664,6 @@ static CFDictionaryRef 
>>>>> videotoolbox_buffer_attributes_create(int width,
>>>>>  CFDictionarySetValue(buffer_attributes, 
>>>>> kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
>>>>>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
>>>>>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);
>>>>> -#if TARGET_OS_IPHONE
>>>>> -CFDictionarySetValue(buffer_attributes, 
>>>>> kCVPixelBufferOpenGLESCompatibilityKey, kCFBooleanTrue);
>>>>> -#else
>>>>> -CFDictionarySetValue(buffer_attributes, 
>>>>> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue);
>>>>> -#endif
>>>>>
>>>>>  CFRelease(io_surface_properties);
>>>>>  CFRelease(cv_pix_fmt);
>>>>
>>>> Does this have a negative effect on compatibility or performance? (In
>>>> both cases I'm asking about the case when actually using GL rendering.)
>>>
>>> Disabling the attribute improves performance in my tests. I can not
>>> find any document about these keys. What i know is the decoded
>>> cvpixelbuffer is backed by iosurface, and the api to create texture
>>> from iosurface is available since macOS10.6
>>
>> Maybe you can add a flag to make them optional?
>> They are documented at:
>> https://developer.apple.com/documentation/corevideo/kcvpixelbufferopenglescompatibilitykey
>> https://developer.apple.com/documentation/corevideo/kcvpixelbufferiosurfaceopengltexturecompatibilitykey
>>
>> Things may still work without them but I would like to follow the 
>> documentation whenever possible. And I think iOS DOES require the flag for 
>> those buffers to be consumed through GLES.
>>
> 
> Your links explain nothing. iOS does not need it as mentioned in the
> patch. I tested on iphone4s+iOS9 and some new devices.

Will find time to test this week.
VTDecompressionOutputCallback actually returns a CVImageBuffer and blindly 
casting it to a CVPixelBuffer is dangerous. I will test if the type ids of the 
output are affected with different key combinations.

> 
>> Pure speculation here. GPU texture units usually require special memory 
>> layouts that may be suboptimal for the decoder. When these constraints are 
>> not met either the driver has to perform the conversion or you pay the 
>> penalty at access time.
> 
> Not sure about memory layout. The fact is on mac the performance is
> much better without it. No difference on ios.
> ___
> 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 14/14] videotoolbox: remove opengl compatibility attribute

2017-12-15 Thread Xiaolei Yu 
On 12/16/2017 02:07 PM, Wang Bin wrote:
> 2017-12-16 2:52 GMT+08:00 wm4 :
>> On Fri, 15 Dec 2017 15:02:44 +0800
>> wbse...@gmail.com wrote:
>>
>>> From: wang-bin 
>>>
>>> 1. a cvpixelbuffer backed by iosurface can always be converted to an opengl 
>>> texture, using CGLTexImageIOSurface2D for macOS, and undocumented api 
>>> texImageIOSurface(which is internally used by public api 
>>> CVOpenGLESTextureCacheCreateTextureFromImage) for iOS4.0+.
>>> 2. enabling the attribute can slow down decoding speed a lot. I tested many 
>>> video clips on my macbook air. for example: ffmpeg -ss 00:00:00 -t 00:03:00 
>>> -hwaccel videotoolbox -an -i big_buck_bunny_1080p_h264.mov -f null 
>>> ->/dev/null, result with the attribute
>>> enabled: frame= 2082 fps= 85 q=-0.0 Lsize=N/A time=00:03:00.00 bitrate=N/A 
>>> speed=7.34x
>>> disabled: frame= 2031 fps=104 q=-0.0 Lsize=N/A time=00:03:00.00 bitrate=N/A 
>>> speed=9.22x
>>> ---
>>>  libavcodec/videotoolbox.c | 5 -
>>>  1 file changed, 5 deletions(-)
>>>
>>> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
>>> index 9d2f0afa20..24631684d7 100644
>>> --- a/libavcodec/videotoolbox.c
>>> +++ b/libavcodec/videotoolbox.c
>>> @@ -664,11 +664,6 @@ static CFDictionaryRef 
>>> videotoolbox_buffer_attributes_create(int width,
>>>  CFDictionarySetValue(buffer_attributes, 
>>> kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
>>>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
>>>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);
>>> -#if TARGET_OS_IPHONE
>>> -CFDictionarySetValue(buffer_attributes, 
>>> kCVPixelBufferOpenGLESCompatibilityKey, kCFBooleanTrue);
>>> -#else
>>> -CFDictionarySetValue(buffer_attributes, 
>>> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue);
>>> -#endif
>>>
>>>  CFRelease(io_surface_properties);
>>>  CFRelease(cv_pix_fmt);
>>
>> Does this have a negative effect on compatibility or performance? (In
>> both cases I'm asking about the case when actually using GL rendering.)
> 
> Disabling the attribute improves performance in my tests. I can not
> find any document about these keys. What i know is the decoded
> cvpixelbuffer is backed by iosurface, and the api to create texture
> from iosurface is available since macOS10.6

Maybe you can add a flag to make them optional?
They are documented at:
https://developer.apple.com/documentation/corevideo/kcvpixelbufferopenglescompatibilitykey
https://developer.apple.com/documentation/corevideo/kcvpixelbufferiosurfaceopengltexturecompatibilitykey

Things may still work without them but I would like to follow the documentation 
whenever possible. And I think iOS DOES require the flag for those buffers to 
be consumed through GLES.

Pure speculation here. GPU texture units usually require special memory layouts 
that may be suboptimal for the decoder. When these constraints are not met 
either the driver has to perform the conversion or you pay the penalty at 
access time.


> ___
> 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] Is it legal to modify h264 sps for cropping

2017-04-21 Thread Xiaolei Yu 
On 04/21/2017 10:15 PM, Hendrik Leppkes wrote:
> On Fri, Apr 21, 2017 at 3:34 PM, Xiaolei Yu <dreifachst...@gmail.com> wrote:
>> Some android devices do not properly align the input surface of MediaCodec 
>> (Nexus 4, Galxy Note 2) and
>> we are forced to specify a multiple of 16 as the video width. A possible 
>> workaround is to insert the desired crop
>> into the output sps, but I am not sure if it is legal.
> 
> H.264 always has a coded dimension which is a multiple of 16, and any
> smaller granularity on actual dimensions is achieved with cropping
> parameters.

I understand coding internally handles only 16x16 blocks. But I am not sure
whether a decoder is required to decode full blocks first before applying the
cropping. What happens if prediction requires data out side of the cropping 
area?

Say I have a 1088x1920 h264 file and crop it to (0,0 - 1080,1920) by editing 
the sps,
can I expect the new file is still conformant and the decoded images match 
those of
the original file in the cropped area?


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

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

[FFmpeg-devel] Is it legal to modify h264 sps for cropping

2017-04-21 Thread Xiaolei Yu 
Some android devices do not properly align the input surface of MediaCodec 
(Nexus 4, Galxy Note 2) and 
we are forced to specify a multiple of 16 as the video width. A possible 
workaround is to insert the desired crop
into the output sps, but I am not sure if it is legal.

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

[FFmpeg-devel] [PATCH v2] avcodec: fix vc1dsp dependencies

2016-09-25 Thread Xiaolei Yu 

---
 libavcodec/aarch64/Makefile   | 2 +-
 libavcodec/aarch64/h264cmc_neon.S | 2 +-
 libavcodec/arm/h264cmc_neon.S | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 36d9d34..c3df887 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -14,7 +14,7 @@ OBJS-$(CONFIG_VIDEODSP) += 
aarch64/videodsp_init.o
 # decoders/encoders
 OBJS-$(CONFIG_DCA_DECODER)  += aarch64/synth_filter_init.o
 OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o
-OBJS-$(CONFIG_VC1_DECODER)  += aarch64/vc1dsp_init_aarch64.o
+OBJS-$(CONFIG_VC1DSP)   += aarch64/vc1dsp_init_aarch64.o
 OBJS-$(CONFIG_VORBIS_DECODER)   += aarch64/vorbisdsp_init.o
 
 # ARMv8 optimizations
diff --git a/libavcodec/aarch64/h264cmc_neon.S 
b/libavcodec/aarch64/h264cmc_neon.S
index 486079f..ff97a29 100644
--- a/libavcodec/aarch64/h264cmc_neon.S
+++ b/libavcodec/aarch64/h264cmc_neon.S
@@ -445,7 +445,7 @@ endconst
 h264_chroma_mc4 avg, rv40
 #endif
 
-#if CONFIG_VC1_DECODER
+#if CONFIG_VC1DSP
 h264_chroma_mc8 put, vc1
 h264_chroma_mc8 avg, vc1
 h264_chroma_mc4 put, vc1
diff --git a/libavcodec/arm/h264cmc_neon.S b/libavcodec/arm/h264cmc_neon.S
index 77ed3c0..fc48a6f 100644
--- a/libavcodec/arm/h264cmc_neon.S
+++ b/libavcodec/arm/h264cmc_neon.S
@@ -455,7 +455,7 @@ endconst
 h264_chroma_mc4 avg, rv40
 #endif
 
-#if CONFIG_VC1_DECODER
+#if CONFIG_VC1DSP
 h264_chroma_mc8 put, vc1
 h264_chroma_mc8 avg, vc1
 h264_chroma_mc4 put, vc1
-- 
2.9.3

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

[FFmpeg-devel] avcodec: fix vc1dsp dependencies

2016-09-25 Thread Xiaolei Yu 
---
 libavcodec/aarch64/Makefile   | 2 +-
 libavcodec/aarch64/h264cmc_neon.S | 2 +-
 libavcodec/arm/h264cmc_neon.S | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 36d9d34..c3df887 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -14,7 +14,7 @@ OBJS-$(CONFIG_VIDEODSP) +=
aarch64/videodsp_init.o
 # decoders/encoders
 OBJS-$(CONFIG_DCA_DECODER)  += aarch64/synth_filter_init.o
 OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o
-OBJS-$(CONFIG_VC1_DECODER)  += aarch64/vc1dsp_init_aarch64.o
+OBJS-$(CONFIG_VC1DSP)   += aarch64/vc1dsp_init_aarch64.o
 OBJS-$(CONFIG_VORBIS_DECODER)   += aarch64/vorbisdsp_init.o

 # ARMv8 optimizations
diff --git a/libavcodec/aarch64/h264cmc_neon.S
b/libavcodec/aarch64/h264cmc_neon.S
index 486079f..ff97a29 100644
--- a/libavcodec/aarch64/h264cmc_neon.S
+++ b/libavcodec/aarch64/h264cmc_neon.S
@@ -445,7 +445,7 @@ endconst
 h264_chroma_mc4 avg, rv40
 #endif

-#if CONFIG_VC1_DECODER
+#if CONFIG_VC1DSP
 h264_chroma_mc8 put, vc1
 h264_chroma_mc8 avg, vc1
 h264_chroma_mc4 put, vc1
diff --git a/libavcodec/arm/h264cmc_neon.S b/libavcodec/arm/h264cmc_neon.S
index 77ed3c0..fc48a6f 100644
--- a/libavcodec/arm/h264cmc_neon.S
+++ b/libavcodec/arm/h264cmc_neon.S
@@ -455,7 +455,7 @@ endconst
 h264_chroma_mc4 avg, rv40
 #endif

-#if CONFIG_VC1_DECODER
+#if CONFIG_VC1DSP
 h264_chroma_mc8 put, vc1
 h264_chroma_mc8 avg, vc1
 h264_chroma_mc4 put, vc1
-- 
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [RFC] configure: test inter-procedural constant propagation for armv6 inline asm

2016-02-22 Thread Xiaolei Yu 
There are two routines in avutil/arm/intmath that fail to compile without IPCP.
This patch tries to detect if such optimizations are present.
I am unable to find a way to test it without using inline asm, so the check flag
is bound to each arch extension.

I also want optflags checks to be performed earlier but am unsure about the 
side-effect.
This patch just performs ipcp checks after optflags ones.

---
 configure | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/configure b/configure
index a78e228..3b35551 100755
--- a/configure
+++ b/configure
@@ -916,9 +916,25 @@ EOF
 check_insn(){
 log check_insn "$@"
 check_inline_asm ${1}_inline "\"$2\""
+enabled ${1}_inline && enable ${1}_ipcp
 echo "$2" | check_as && enable ${1}_external || disable ${1}_external
 }
 
+check_inline_asm_ipcp(){
+log check_inline_asm_ipcp "$@"
+name="${1}_ipcp"
+code="$2"
+param_decl="$3"
+param_val="$4"
+shift 4
+disable ${name}
+check_cc "$@" $optflags << EOF && enable $name
+static
+void foo($param_decl){ __asm__ volatile($code); }
+void bar() { foo($param_val); }
+EOF
+}
+
 check_yasm(){
 log check_yasm "$@"
 echo "$1" > $TMPS
@@ -1937,6 +1953,7 @@ HAVE_LIST="
 $ARCH_EXT_LIST
 $(add_suffix _external $ARCH_EXT_LIST)
 $(add_suffix _inline   $ARCH_EXT_LIST)
+$(add_suffix _ipcp $ARCH_EXT_LIST)
 $ARCH_FEATURES
 $ATOMICS_LIST
 $BUILTIN_LIST
@@ -2145,6 +2162,7 @@ vfpv3_deps="vfp"
 setend_deps="arm"
 
 map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
+map 'eval ${v}_ipcp_deps=${v}_inline'  $ARCH_EXT_LIST_ARM
 
 mipsfpu_deps="mips"
 mipsdsp_deps="mips"
@@ -5889,6 +5907,10 @@ check_optflags $optflags
 check_optflags -fno-math-errno
 check_optflags -fno-signed-zeros
 
+enabled armv6 && check_inline_asm_ipcp armv6 \
+'"ssat %0, %2, %1" : "=r"(x) : "r"(a), "i"(p)' 'int x, int a, int p' '1, 
1, 1' \
+$optflags
+
 enabled ftrapv && check_cflags -ftrapv
 
 check_cc -mno-red-zone

[FFmpeg-devel] [PATCH] swscale/arm: re-enable neon rgbx to nv12 routines

2016-02-22 Thread Xiaolei Yu 
Commit '842b8f4ba2e79b9c004a67f6fdb3d5c5d05805d3' fixed clang/iphone
build but failed on some versions of cygwin. It has now been verified
to work on both platforms.
---
 libswscale/arm/Makefile   | 4 ++--
 libswscale/arm/swscale_unscaled.c | 4 
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/libswscale/arm/Makefile b/libswscale/arm/Makefile
index 97b3561..9ccec3b 100644
--- a/libswscale/arm/Makefile
+++ b/libswscale/arm/Makefile
@@ -1,5 +1,5 @@
 OBJS+= arm/swscale_unscaled.o
 
-# NEON-OBJS   += arm/rgb2yuv_neon_32.o
-# NEON-OBJS   += arm/rgb2yuv_neon_16.o
+NEON-OBJS   += arm/rgb2yuv_neon_32.o
+NEON-OBJS   += arm/rgb2yuv_neon_16.o
 NEON-OBJS   += arm/yuv2rgb_neon.o
diff --git a/libswscale/arm/swscale_unscaled.c 
b/libswscale/arm/swscale_unscaled.c
index ac1e4a9..8aa933c 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -23,7 +23,6 @@
 #include "libswscale/swscale_internal.h"
 #include "libavutil/arm/cpu.h"
 
-#if 0
 extern void rgbx_to_nv12_neon_32(const uint8_t *src, uint8_t *y, uint8_t 
*chroma,
 int width, int height,
 int y_stride, int c_stride, int src_stride,
@@ -61,7 +60,6 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext *context, 
const uint8_t *src[
 
 return 0;
 }
-#endif
 
 #define YUV_TO_RGB_TABLE(precision)
 \
 c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),   
 \
@@ -167,14 +165,12 @@ DECLARE_FF_NVX_TO_ALL_RGBX_ALL_PRECISION_FUNCS(nv21)
 
 static void get_unscaled_swscale_neon(SwsContext *c) {
 int accurate_rnd = c->flags & SWS_ACCURATE_RND;
-#if 0
 if (c->srcFormat == AV_PIX_FMT_RGBA
 && c->dstFormat == AV_PIX_FMT_NV12
 && (c->srcW >= 16)) {
 c->swscale = accurate_rnd ? rgbx_to_nv12_neon_32_wrapper
 : rgbx_to_nv12_neon_16_wrapper;
 }
-#endif
 
 SET_FF_NVX_TO_ALL_RGBX_FUNC(nv12, NV12, accurate_rnd);
 SET_FF_NVX_TO_ALL_RGBX_FUNC(nv21, NV21, accurate_rnd);
-- 
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: disable arch specific intmath routines if optimizations are disabled

2016-02-17 Thread Xiaolei Yu 
On 02/17/2016 03:19 AM, Hendrik Leppkes wrote:
> On Tue, Feb 16, 2016 at 4:00 PM, Yu Xiaolei <dreifachst...@gmail.com> wrote:
>> On Tue, Feb 16, 2016 at 9:01 PM, Michael Niedermayer <mich...@niedermayer.cc
>>> wrote:
>>
>>> On Tue, Feb 16, 2016 at 02:40:10PM +0800, Xiaolei Yu wrote:
>>>> Current intmath routines for arm require inter-procedure constant
>>> propagation
>>>> and fail to compile when optimizations are disabled.
>>>> ---
>>>>  configure   | 1 +
>>>>  libavutil/intmath.h | 2 ++
>>>>  2 files changed, 3 insertions(+)
>>>
>>> on arm without opts and this patch i get
>>> src/libavcodec/arm/aac.h: In function ‘VMUL4S’:
>>> src/libavcodec/arm/aac.h:102:5: error: can't find a register in class
>>> ‘LO_REGS’ while reloading ‘asm’
>>> src/libavcodec/arm/aac.h:102:5: error: ‘asm’ operand has impossible
>>> constraints
>>> make: *** [libavcodec/aacdec.o] Error 1
>>>
>>>
>> This error seems unrelated to the patch, but I am not sure as I am only
>> building some selected codecs.
>> Can you build again without the patch?
>>
>> Without the patch I get:
>> In file included from src/libavutil/intmath.h:30:0,
>>  from src/libavutil/common.h:106,
>>  from src/libavutil/avutil.h:288,
>>  from src/libavutil/samplefmt.h:24,
>>  from src/libavcodec/avcodec.h:31,
>>  from src/libavcodec/internal.h:33,
>>  from src/libavcodec/h264_direct.c:28:
>> src/libavutil/arm/intmath.h: In function 'get_scale_factor':
>> src/libavutil/arm/intmath.h:69:5: warning: asm operand 2 probably doesn't
>> match constraints
>>  __asm__ ("ssat %0, %2, %1" : "=r"(x) : "r"(a), "i"(p+1));
>>  ^
>> src/libavutil/arm/intmath.h:69:5: error: impossible constraint in 'asm'
>>
>> on x86 build passes with and without the patch here
>>> with what compiler is this needed ?
>>>
>>>
>> Yes, x86 builds fine without this patch. But the underlying problem is not
>> arch specific and may be encountered in other inline asm. I think current
>> patch is more consistent if we consider these routines as manual
>> optimizations.
>>
> 
> --disable-optimization is just meant to disable compiler optimizations
> so that debugging is easier, its not meant to disable any kind of
> hand-written ASM, this may even be a target of the debugging in some
> cases.
> If one wanted to get rid of all ASM, there are other options for that.
> 

Point taken. I will post a new patch that only disables these two functions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] libavutil: Some VAAPI infrastructure

2016-01-18 Thread Xiaolei Yu 
On 01/18/2016 03:52 AM, Mark Thompson wrote:
> On 17/01/16 19:46, Mark Thompson wrote:
>> On 17/01/16 18:46, wm4 wrote:
>>>
>>> There are two issues:
>>> 1. global state in libav* which is not synchronized
>>> 2. thread-safety within
>>>
>>> 1. is is completely unacceptable, because it can trigger undefined
>>> behavior if there is more than 1 libav* user in the same process. I'm
>>> not really convinced that a "device string" is really reliably unique
>>> enough that it won't be a problem across library users. (For example,
>>> it's entirely possible enough to open 2 X11 Displays to the same X
>>> server using the same display name.)
>>
>> Ok, I'm happy with the first part of that (and that it is fixable by a
>> simple lock around the connection initialisation, assuming this code
>> stays in libavutil).
>>
>> Can you offer an example where the device strings actually create a
>> problem?
>>
>> Multiple users within the same process /must/ be given the same
>> connection if they ask for the same device, because we have no way to
>> distinguish different sets of instances which want to be able to work
>> together.  Equally, two connections to the same device under different
>> names are acceptably different, because they won't have come from the
>> same instance set.
> 
> Right, I see the problem.  The user will want to do something with the 
> surface they get back under the same X11 display handle.  We can't call 
> XOpenDisplay() in that case: the user has to be able to pass their own handle 
> in.  So we need some other way to register that connection.
> 
>>
>>> With 2. it's a bit more complicated. There should probably indeed be
>>> something like a big lock around all uses of the same VADisplay, as
>>> long as libva exhibits this problem.
>>
>> This is straightforward to do, if tedious.
>>
>> Can you explain the ABI and API constraints on changes to existing
>> structures?
>>
>> For the existing decoders (and their users) to work, it will require
>> either:
>> (a) a global list of connections somewhere to map VADisplay to lock
>> or
>> (b) an additional member in struct vaapi_context to point to the lock.
>>
>> If ABI and API compatibility is required for existing users then (b) is
>> out, and we have to have the global list (suitably locked).
>>
>> If we can break both then the right answer is probably to pass
>> hwaccel_context to encoders as well, and add a similar field to
>> AVFilterContext to use there too.
>>
>> If ABI compatibility is required but an API break is allowed then we
>> could do horrible things to hack (b) into working.  For example, replace
>> the VADisplay pointer in the first member of struct vaapi_context to
>> instead point at a new structure which contains some magic bytes at the
>> start.  If the magic bytes are where that pointer goes then we are using
>> the new API and can lock using that, and if they are not found then it
>> was a user-provided VADisplay and no locking is required.
>>
>> - Mark
>>
>>
>> PS:  I have no attachment to this piece of code (around connection
>> initialisation) at all; it was just required to make everything else
>> work.  If you want to suggest a better and completely different approach
>> then I am happy to throw it all away and start again.
>>

I think you can supply VADisplay to AVCodecContext through av_opt_ptr and
leave its initialization to user.

> 
> ___
> 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