On Mon, Nov 4, 2013 at 2:27 PM, Vittorio Giovara
<vittorio.giov...@gmail.com> wrote:
> On Mon, Nov 4, 2013 at 1:28 PM, Yusuke Nakamura
> <muken.the.vfrman...@gmail.com> wrote:
>> ---
>> libavcodec/h264_ps.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
>> index 54b735d..422f522 100644
>> --- a/libavcodec/h264_ps.c
>> +++ b/libavcodec/h264_ps.c
>> @@ -178,7 +178,10 @@ static inline int decode_vui_parameters(H264Context *h,
>> SPS *sps)
>> /* chroma_sample_location_type_top_field */
>> h->avctx->chroma_sample_location = get_ue_golomb(&h->gb) + 1;
>> get_ue_golomb(&h->gb); /* chroma_sample_location_type_bottom_field
>> */
>> - }
>> + } else if (sps->chroma_format_idc == 1)
>> + h->avctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
>> + else
>> + h->avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
>>
>> sps->timing_info_present_flag = get_bits1(&h->gb);
>> if (sps->timing_info_present_flag) {
>
> I'm not sure about this, the only case in which it's considered an
> error to rely on chroma_sample_loc information is when
> chroma_fromat_idc is 0, the other values (2 for 422 and 3 for 444)
> mention the fact that chroma is colocated with luma, so maybe
> _LOC_CENTER should be more correct?
AVCHROMA_LOC_TOPLEFT*
>
> Vittorio
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
