[FFmpeg-devel] [PATCH] Implement PAFF in H.264

Michael Niedermayer michaelni
Sun Jul 27 04:29:12 CEST 2008


On Sat, Jul 26, 2008 at 03:58:34PM -0400, Jeff Downs wrote:
> On Fri, 25 Jul 2008, Michael Niedermayer wrote:
> 
> > On Thu, Sep 20, 2007 at 03:04:50PM -0400, Jeff Downs wrote:
> > > On Wed, 19 Sep 2007, Michael Niedermayer wrote:
> > [...]
> > >          case MMCO_LONG:
> > > -            pic= remove_long(h, mmco[i].long_arg);
> > > -            if(pic) unreference_pic(h, pic);
> > > +            j = 1;
> > > +            if (FIELD_PICTURE && !s->first_field) {
> > > +                if (h->long_ref[mmco[i].long_arg] == s->current_picture_ptr) {
> > > +                    /* Just mark second field as referenced */
> > > +                    j = 0;
> > > +                } else if (s->current_picture_ptr->valid_structure) {
> > > +                    /* First field in pair in short term list.
> > > +                     * This is not allowed; see 7.4.3, notes 2 and 3.
> > > +                     */
> > > +                    av_log(h->s.avctx, AV_LOG_ERROR,
> > > +                        "illegal long term reference assignment for second "
> > > +                        "field in complementary field pair (first field is "
> > > +                        "short term)\n");
> > > +                    j = 0;
> > [...]
> > > -    if(!current_is_long){
> > > -        pic= remove_short(h, s->current_picture_ptr->frame_num);
> > > +    if (!current_ref_assigned && FIELD_PICTURE &&
> > > +            !s->first_field && s->current_picture_ptr->valid_structure) {
> > > +
> > > +        /* Second field of complementary field pair; the first field of
> > > +         * which is already referenced. If short referenced, it
> > > +         * should be first entry in short_ref. If not, it must exist
> > > +         * in long_ref; trying to put it on the short list here is an
> > > +         * error in the encoded bit stream (ref: 7.4.3, NOTE 2 and 3).
> > > +         * If on neither list, we have a logic problem elsewhere
> > > +         */
> > 
> > the notes 2 & 3 in 7.4.3 do not say anything that would support that view.
> 
> Yes. Apologies - the citation as you noticed should be 7.4.3.3.
> I've changed this.
> 
> > the notes 2 & 3 in 7.4.3.3 could be bent toward this given the assumtation
> > that the stream does not contain non paired reference fields.
> > What made you think such fields do not occur? No i dont have a stream that
> > i know contains such things.
> > iam just curious if theres something in the spec that supports this
> > view.
> 
> The first hunk quoted up there is wrong.  I misread spec to be that 
> you cannot have second field in a complementary pair be marked long unless 
> the first had already been marked long.  That doesn't hold here.  The only 
> restriction is that if the first was made long, then the second must be 
> too.

hmmmmmm
are you sure?
I mean, what is the first field then? Its not a long ref because that would
force the 2nd to be too, but if it is a short ref, I think IIRC the 2nd must
be a short ref as well. Whats left is a non reference field, but i think
non reference and reference may not be mixed in 1 pair again IIRC.
The spec is very obfuscated and information is spread out nastily so i may
be totally wrong, iam just writing this from memory without cross checking ...


> It looks like that comment is the only thing surviving there, and can 
> probably be removed if you agree.
> 
> Second hunk...  Both ways to assign long term to a field (IDR long term 
> ref flag, MMCO current is long, and MMCO short to long) specify that if 
> applied to the first, you have to apply the same to the second field in a 
> pair.
> 

> Unpaired fields aren't considered by that comment/code (first_field == 1 
> for unpaired fields); the restriction doesn't apply.

My problem with unpaired fields is we dont support them at all ...
Think of Top Top Top Bottom Bottom Bottom and these get reordered before
output ...
What iam really curious about is, if the spec allows something like that ...


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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/20080727/2fa44bd2/attachment.pgp>



More information about the ffmpeg-devel mailing list