[FFmpeg-devel] [PATCH] Implement pixdesc.h:write_line()

Michael Niedermayer michaelni
Thu Apr 2 23:03:04 CEST 2009


On Thu, Apr 02, 2009 at 10:53:25PM +0200, Stefano Sabatini wrote:
> On date Thursday 2009-04-02 22:40:50 +0200, Michael Niedermayer encoded:
> > On Thu, Apr 02, 2009 at 09:15:41PM +0200, Stefano Sabatini wrote:
> > > On date Thursday 2009-04-02 01:27:18 +0200, Michael Niedermayer encoded:
> > > > On Thu, Apr 02, 2009 at 12:02:34AM +0200, Stefano Sabatini wrote:
> > > > > Hi all.
> > > > > 
> > > > > Formats when possible have been tested with the vf_pixdesc_test
> > > > > filter, included the monowhite and monoblack formats, with something
> > > > > like:
> > > > > 
> > > > > ffplay in.avi -vfilters "format=gray,pixdesc_test"
> > > > > 
> > > > > Some formats cannot be tested this way, for example all the formats
> > > > > not supported as output by sws, anyway I think that it's quite safe to
> > > > > apply it anyway.
> > > > > 
> > > > > Many interesting problems remains opened, for example:
> > > > > 
> > > > > * How are we supposed to deal with HW accelerated pixel formats?  Are
> > > > >   we supposed to add an entry in the pixdescs arrays for each of them?
> > > > > 
> > > > 
> > > > > * It's not clear which should be the interaction between lsws and
> > > > >   the pixdescs.
> > > > > 
> > > > >   Currently lsws doesn't depend on lavc, since the pixfmt descriptors
> > > > >   may and should be used in libsws to avoid code duplication
> > > > >   (e.g. sws_format_name()), we may either add lavc to the lsws
> > > > >   dependancies *or* move all the pixdesc stuff to lavu.
> > > > 
> > > > why would lavc need the pixdescs ? if it doesnt they could be moved to sws
> > > 
> > > To retain in lavc all the functionality currently implemented in
> > > imgconvert, which currently uses pixfmtinfo which we're trying to
> > > dump and substitute with pixdescs.
> > > 
> > > Alternatively we could make lavc depend on lsws, but somehow doesn't
> > > sound like a great idea...
> > >  
> > > > also let me repeat, 1 patch per mail please!
> > > > if we ever implement the suggested patch tracker all mails with multiple
> > > > patches will "disapear".
> > > > its easy to search subjs for [PATCH], easy to search for looks ok and
> > > > applied but this breaks down if there are multiple patches per mail
> > > > besides its alot harder for me to keep track and i suspect also for
> > > > others independant of any fancy tools
> > > > also its hard to reply to a subset of patches in this mess mails.
> > > 
> > > OK sorry, the patches attached were meant to help to actually test the
> > > write_line() patch. I'll repost them to separate threads.
> > > 
> > > Patch updated with the suggestions by Ben.
> > [...]
> > > +        while (w--) {
> > > +            int val = *src++;
> > > +            put_bits(&pb, depth, val);
> > > +            if (step - depth)
> > 
> > > +                skip_put_bits(&pb, step - depth);
> > 
> > i suspect this will randomize the bits
> 
> That's why I added the if (step - depth) check (yes without that it
> was broken).
> Am I missing something?
/**
 * Skips the given number of bits.
 * Must only be used if the actual values in the bitstream do not matter.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 */

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20090402/c79456f9/attachment.pgp>



More information about the ffmpeg-devel mailing list