[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