[FFmpeg-devel] [PATCH]Fix for issue694. Dirac A/V sync loss
Anuradha Suraparaju
anuradha
Sat Nov 8 23:51:14 CET 2008
Hi,
On Fri, 2008-11-07 at 04:41 -0500, David Conrad wrote:
> On Nov 6, 2008, at 8:31 PM, Anuradha Suraparaju wrote:
>
> > Hi,
> >
> > On Thu, 2008-11-06 at 11:05 +0100, Diego Biurrun wrote:
> >> On Thu, Nov 06, 2008 at 01:49:55PM +1100, Anuradha Suraparaju wrote:
> >>>
> >>> On Sat, 2008-10-18 at 21:50 +0200, Diego Biurrun wrote:
> >>>> Hi Anuradha, I wanted to point out the following bug report we
> >>>> received
> >>>> to you:
> >>>>
> >>>> https://roundup.mplayerhq.hu/roundup/ffmpeg/issue694
> >>>>
> >>>> A/V sync is lost with Dirac. It's likely an issue in your code.
> >>>
> >>> I've attached a patch for the Dirac A/V sync loss. The patch
> >>> modifies 3
> >>> files.
> >> [...]
>
> > I've attached a modified patch to this email.
>
> > - if (buf_size>0)
> > + if (buf_size>0) {
> > /* set data to decode into buffer */
> > dirac_buffer (p_dirac_params->p_decoder, buf, buf+buf_size);
> > -
> > + if ((buf[4] &0x08) == 0x08 && (buf[4] & 0x03))
> > + avccontext->has_b_frames = 1;
> > + }
>
> From my understanding it's valid for a stream to have auxiliary or
> padding data between every picture; would has_b_frames be set in that
> case?
has_b_frames is only set when we encounter the first non-intra frame
with references. The patch I've submitted ensures that non-frame data
is always grouped with with frame data. So auxialiary and padding data
are grouped with frame data. This is important because we don't want to
associate a pts with non-frame data.
>
> > + pu->next_pu_offset = (start[5] << 24) +
> > + (start[6] << 16) +
> > + (start[7] << 8) +
> > + start[8];
>
> AV_RL32(start+5) is more readable imo.
Will use this in the next iteration on the patch.
Regards,
Anuradha
More information about the ffmpeg-devel
mailing list