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

Satendra spsatendra
Tue Mar 23 13:34:01 CET 2010


Hi,

I was searching information regarding PicAFF/interlace features and stumbled
on this post.


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
> ...
>

Is this supported by spec??

Best Regards
Satendra


On Sun, Jul 27, 2008 at 7:59 AM, Michael Niedermayer <michaelni at gmx.at>wrote:

> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFIi913YR7HhwQLD6sRApl4AJ9kiEA6kFKoYPlXXJLNsCbuxyoiFQCfYxKX
> BPO9BXolH90XL/I2Hyq1+9M=
> =8pFY
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>



-- 

-----------------------------------------------------------------------------------------------------------------------------------

"We all agree on the necessity of compromise. We just can't agree on when
it's necessary to compromise."  ------Larry Wall
-----------------------------------------------------------------------------------------------------------------------------------



More information about the ffmpeg-devel mailing list