[FFmpeg-devel] [PATCH] avcodec/aac/aacdec: set profile after decoding an audio specific config
Fix the reported profile when probing an fMP4 initialization segment --- libavcodec/aac/aacdec.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libavcodec/aac/aacdec.c b/libavcodec/aac/aacdec.c index f6e79700d5..a779b47b39 100644 --- a/libavcodec/aac/aacdec.c +++ b/libavcodec/aac/aacdec.c @@ -1063,6 +1063,13 @@ static int decode_audio_specific_config_gb(AACDecContext *ac, return AVERROR(ENOSYS); } +if (m4ac->ps) +avctx->profile = AV_PROFILE_AAC_HE_V2; +else if (m4ac->ext_object_type != AOT_NULL) +avctx->profile = m4ac->ext_object_type - 1; +else +avctx->profile = m4ac->object_type - 1; + ff_dlog(avctx, "AOT %d chan config %d sampling index %d (%d) SBR %d PS %d\n", m4ac->object_type, m4ac->chan_config, m4ac->sampling_index, -- 2.45.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] ffmpeg: fix increment of sync_opts
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
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
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, &rps[list], poc, HEVC_FRAME_FLAG_SHORT_REF,
1);
+ret = add_candidate_ref(s, &rps[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, &rps[list], poc, HEVC_FRAME_FLAG_LONG_REF,
long_rps->poc_msb_present[i]);
+ret = add_candidate_ref(s, &rps[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
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
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, &rps[list], poc, HEVC_FRAME_FLAG_SHORT_REF,
1);
+maybe_missing = list != ST_CURR_BEF && list != ST_CURR_AFT;
+
+ret = add_candidate_ref(s, &rps[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, &rps[list], poc, HEVC_FRAME_FLAG_LONG_REF,
long_rps->poc_msb_present[i]);
+ret = add_candidate_ref(s, &rps[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
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
+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|sampl
[FFmpeg-devel] [PATCH v2 0/1] libavcodec/h264: always set video signal type fields
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
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
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
On 12/16/2017 04:19 PM, Wang Bin wrote: > 2017-12-16 15:33 GMT+08:00 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. >> > > 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
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] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On 10/16/2017 07:36 PM, wm4 wrote: > On Mon, 16 Oct 2017 19:28:27 +0800 > Xiaolei Yu wrote: > >> On 10/03/2017 09:15 PM, wm4 wrote: >>> From: Anton Khirnov >>> >>> Use the AVFrame.opaque_ref field. The original user's opaque_ref is >>> wrapped in the lavc struct and then unwrapped before the frame is >>> returned to the caller. >>> >>> This new struct will be useful in the following commits. >>> >> >> How about using AVFrame::buf[]? > > My local crash-fix hack for videotoolbox actually uses buf[] for this > purpose, but it won't work in general, because video data might need > it. Also that would have exactly the same problems as opaque_ref. > Actually, all approaches will have exactly the same problems as > opaque_ref, but michael doesn't get it. I think handling foreign memory with a cpu-centric api will always be kinda awkward. But using AVFrame::buf[] is more natural if we treat them as a family of cpu-unaddressable images. Also it would be great (in the future) to allow users to pass them around without a round trip to the main memory. > ___ > 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 2/7] decode: add a method for attaching lavc-internal data to frames
On 10/03/2017 09:15 PM, wm4 wrote: > From: Anton Khirnov > > Use the AVFrame.opaque_ref field. The original user's opaque_ref is > wrapped in the lavc struct and then unwrapped before the frame is > returned to the caller. > > This new struct will be useful in the following commits. > How about using AVFrame::buf[]? ___ 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
On 04/21/2017 10:15 PM, Hendrik Leppkes wrote: > On Fri, Apr 21, 2017 at 3:34 PM, Xiaolei Yu 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
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
--- 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
--- 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
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
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
On 02/17/2016 03:19 AM, Hendrik Leppkes wrote:
> On Tue, Feb 16, 2016 at 4:00 PM, Yu Xiaolei wrote:
>> On Tue, Feb 16, 2016 at 9:01 PM, Michael Niedermayer >> 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
[FFmpeg-devel] [PATCH] avutil: disable arch specific intmath routines if optimizations are disabled
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(+) diff --git a/configure b/configure index 2148f11..70e0161 100755 --- a/configure +++ b/configure @@ -1950,6 +1950,7 @@ HAVE_LIST=" $THREADS_LIST $TOOLCHAIN_FEATURES $TYPES_LIST +optimizations atomics_native dos_paths dxva2_lib diff --git a/libavutil/intmath.h b/libavutil/intmath.h index 9573109..d15f210 100644 --- a/libavutil/intmath.h +++ b/libavutil/intmath.h @@ -26,12 +26,14 @@ #include "config.h" #include "attributes.h" +#if HAVE_OPTIMIZATIONS #if ARCH_ARM # include "arm/intmath.h" #endif #if ARCH_X86 # include "x86/intmath.h" #endif +#endif #if HAVE_FAST_CLZ #if AV_GCC_VERSION_AT_LEAST(3,4) -- 2.7.0 ___ 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
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
