"Ronald S. Bultje" <[email protected]> writes: > Hi, > > On Thu, May 19, 2011 at 9:03 PM, Felipe Contreras > <[email protected]> wrote: >> 2011/5/20 Måns Rullgård <[email protected]>: >>> "Ronald S. Bultje" <[email protected]> writes: >>>> On Thu, May 19, 2011 at 5:39 PM, Felipe Contreras >>>> <[email protected]> wrote: >>>>> Signed-off-by: Felipe Contreras <[email protected]> >>>>> --- >>>>> libavcodec/h264.c | 3 +++ >>>>> 1 files changed, 3 insertions(+), 0 deletions(-) >>>>> >>>>> diff --git a/libavcodec/h264.c b/libavcodec/h264.c >>>>> index 6b262bc..2e04308 100644 >>>>> --- a/libavcodec/h264.c >>>>> +++ b/libavcodec/h264.c >>>>> @@ -1914,6 +1914,9 @@ static int decode_slice_header(H264Context *h, >>>>> H264Context *h0){ >>>>> s->avctx->sample_aspect_ratio= h->sps.sar; >>>>> av_assert0(s->avctx->sample_aspect_ratio.den); >>>>> >>>>> + h->s.avctx->coded_width = 16*s->mb_width; >>>>> + h->s.avctx->coded_height = 16*s->mb_height; >>>>> + >>>>> if(h->sps.video_signal_type_present_flag){ >>>>> s->avctx->color_range = h->sps.full_range ? AVCOL_RANGE_JPEG >>>>> : AVCOL_RANGE_MPEG; >>>>> if(h->sps.colour_description_present_flag){ >>>> >>>> Shouldn't avcodec_set_dimensions() set this? >>> >>> The line before the context of this diff looks like this: >>> >>> avcodec_set_dimensions(s->avctx, s->width, s->height); >>> >>> This sets coded_{width,height} to s->{width,height}. I don't know how >>> this relates to mb_width and mb_height. >> >> The code is above: >> >> s->width = 16*s->mb_width - 2*FFMIN(h->sps.crop_right, 7); >> if(h->sps.frame_mbs_only_flag) >> s->height= 16*s->mb_height - 2*FFMIN(h->sps.crop_bottom, 7); >> else >> s->height= 16*s->mb_height - 4*FFMIN(h->sps.crop_bottom, 7); >> >> So basically one is cropped, the other one isn't. > > Plus coded_* is full resolution whereas the other has lowres > applied... It seems silly to set coded_width/height and then to reset > it to something else, though... But I can live with it, can't quickly > think of something simpler... Anyone else have ideas?
Ditch lowres. I doubt it works anyway. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
