[FFmpeg-devel] [PATCH] h264 parallelized

[Michael Niedermayer]

Hi

On Mon, Sep 03, 2007 at 10:32:43AM +0200, Andreas ?man wrote:
> Hello,
> 
> Michael Niedermayer wrote:
> > Hi
> > 
> 
> >> +    if(h->deblocking_filter == 1 && h0->max_contexts > 1) {
> >> +        h0->max_contexts = 1;
> >> +        if(h != h0)
> >> +            execute_decode_slices(h, 0); // deblocking switched inside frame, process pending slices
> >> +
> >> +        if(!h0->single_decode_warning) {
> >> +            av_log(s->avctx, AV_LOG_INFO, "Cannot parallelize deblocking type 1, decoding such frames in sequential order\n");
> >> +            h0->single_decode_warning = 1;
> >> +        }
> >> +    }
> > 
> > have you tested the code above?
> 
> The code that forces sequential decoding:
> Yes, md5 matches with unmodified svn.
> 
> The case where deblocking switches inside of a frame:
> No, i don't have such content available.
> 
> Do you think there is a bug lurking here?

no, i was just asking ...


> 
> > [...]
> >> +    if(h->current_context == 1) {
> >> +        decode_slice(avctx, h);
> >> +    } else {
> >> +        for(i = 1; i < h->current_context; i++) {
> >> +            hx = h->thread_context[i];
> > 
> >> +            hx->s.error_resilience = 1;
> > 
> > why?
> 
> Otherwise ff_er_add_slice() wont decrease error_count in the
> slave contexts.
> 
> But, i guess it should replaced with
> 
> hx->s.error_resilience = avctx->error_resilience;
> 
> instead, right?

yes


[...]
> > 
> > 
> > [...]
> >>          case NAL_IDR_SLICE:
> >> +            if(h != hx && (h->long_ref_count || h->short_ref_count))
> >> +                execute_decode_slices(h, 0); // idr() below will reap frames, execute all we've done so far
> >>              idr(h); //FIXME ensure we don't loose some frames if there is reordering
> > 
> > why is this needed?
> 
> The initial thought behind it was:
> 
> * idr() destroys pictures in h->long_ref and h->short_ref.
> * These may already have been copied with clone_slice()
> 
> However, that would only be the case if a picture contains
> mixed idr and non-idr slices. And that is not valid, right?

ive just checked:
"
When the value of nal_unit_type is equal to 5 for a NAL unit containing a slice of a coded picture, the value of
nal_unit_type shall be 5 in all other VCL NAL units of the same coded picture. Such a picture is referred to as an IDR
picture.
    NOTE 4  Slice data partitioning cannot be used for IDR pictures.
"


> 
> Perhaps it's better to add a check for this, and bail out?

yes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070903/7d4faff0/attachment.pgp>