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 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
+ */ + 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
On Sat, Jul 26, 2008 at 03:58:34PM -0400, Jeff Downs wrote: 3. 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 -----------------------------------------------------------------------------------------------------------------------------------