[Ffmpeg-devel] UNSUBSCRIBE PLEASE

Ian J Snead ian
Wed Feb 28 09:53:55 CET 2007



-----Original Message-----
From: ffmpeg-devel-bounces at mplayerhq.hu
[mailto:ffmpeg-devel-bounces at mplayerhq.hu] On Behalf Of
ffmpeg-devel-request at mplayerhq.hu
Sent: 27 February 2007 22:33
To: ffmpeg-devel at mplayerhq.hu
Subject: ffmpeg-devel Digest, Vol 23, Issue 269

Send ffmpeg-devel mailing list submissions to
	ffmpeg-devel at mplayerhq.hu

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
or, via email, send a message with subject or body 'help' to
	ffmpeg-devel-request at mplayerhq.hu

You can reach the person managing the list at
	ffmpeg-devel-owner at mplayerhq.hu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ffmpeg-devel digest..."


Today's Topics:

   1. Re: HTTP/1.1 Breaks ffserver/ffmpeg combo (Ryan Martell)
   2. Re: HTTP probing issue... [PATCH] (Ronald S. Bultje)
   3. Re: [RFC][PATCH]Doxygenize libavutil/fifo.h (Michael Niedermayer)
   4. Re: [RFC][PATCH]Doxygenize libavutil/fifo.h (Michael Niedermayer)
   5. Re: -quiet flag patch (Michael Niedermayer)
   6. Re: Stream file handle hijacking by another thread (Stas Oskin)
   7. swscale and palette ... what am I missing? (Karl H. Beckers)


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

Message: 1
Date: Tue, 27 Feb 2007 14:36:55 -0600
From: Ryan Martell <rdm4 at martellventures.com>
Subject: Re: [Ffmpeg-devel] HTTP/1.1 Breaks ffserver/ffmpeg combo
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <68192A32-47C8-4732-9998-FB12262DF816 at martellventures.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Jan 15, 2007, at 3:27 AM, Michael Niedermayer wrote:

> Hi
>
> On Mon, Jan 15, 2007 at 10:19:12AM +0100, Guillaume POIRIER wrote:
>> Hi,
>>
>> On 1/15/07, C.Ren Boca <crboca32 at yahoo.com> wrote:
>>> I think the problem is in libavformat/http.c
>>>
>>> I diffed the files between the two svn revisions that I have,    
>>> 7486, and
>>> 7529, and there are major differences. ffserver and ffmpeg show  
>>> no diff.
>>>
>>> I really like the ffmpeg/ffserver combo. At one point I had it  
>>> working
>>> pretty damn good.
>>
>> Please use binary search to find the exact revision that broke it.  
>> You
>
> my guess would be that it was the http seeking patch which broke  
> it ...
> if so maybe ronald has a clue why?
>
> [...]

Not sure if this is relevant, but this may be the reason that my  
parsing wasn't working either.  http.c sends 1.1 headers now, whereas  
before it was 1.0.  In my case, that meant that the server was  
closing the connection after sending an entire .asx (playlist) file.   
In the new version, it wasn't closing the connection, so I was  
hanging waiting to read data from the connection in the format probe...

My patch to http.c that would respect the Content-Length: header and  
generate an eof was rejected.

The only other thing that might be able to fix this (if this is  
indeed the same issue) is adding "Connection: Close" to the get  
request, although that might screw up the http_seeking stuff.   
Changing the version back to 1.0 would make the seeking stuff be in  
non-conformance.

For more on this, see  [Ffmpeg-devel] HTTP probing issue... [PATCH].

Just my 2 cents.

-Ryan


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

Message: 2
Date: Tue, 27 Feb 2007 15:48:23 -0500
From: "Ronald S. Bultje" <rbultje at ronald.bitfreak.net>
Subject: Re: [Ffmpeg-devel] HTTP probing issue... [PATCH]
To: ffmpeg-devel at mplayerhq.hu
Message-ID: <816C73BB-CB81-49EA-98CE-69FC59CA965B at ronald.bitfreak.net>
Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed

On Feb 27, 2007, Baptiste Coudurier wrote:
> Ok, I dig svn and found out something. See patch attached.
> Basically http_seek returns -1 (like file_seek), and then url_fseek  
> will
> return -1 instead of EPIPE, and that will make probing fail:

Didn't I submit a patch for that ages ago [1]?

Ronald

[1] http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-December/ 
050325.html



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

Message: 3
Date: Tue, 27 Feb 2007 22:07:21 +0100
From: Michael Niedermayer <michaelni at gmx.at>
Subject: Re: [Ffmpeg-devel] [RFC][PATCH]Doxygenize libavutil/fifo.h
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <20070227210721.GQ25795 at MichaelsNB>
Content-Type: text/plain; charset="iso-8859-1"

Hi

On Tue, Feb 27, 2007 at 06:47:06PM +0100, Diego Biurrun wrote:
> On Tue, Feb 27, 2007 at 05:33:53PM +0100, Dujardin Bernard wrote:
> > Dujardin Bernard a icrit :
> > >
> > >I submit ;-)   attached patch which take account of your remarks.
> > >
> > I send this to take account the recent revision 8149.
> 
> Thanks, applied with some further fixes.

revert it! ive not approved the patch, you are not maintainer of fifo.h

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070227/f1f1e6
0c/attachment-0001.pgp

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

Message: 4
Date: Tue, 27 Feb 2007 22:27:35 +0100
From: Michael Niedermayer <michaelni at gmx.at>
Subject: Re: [Ffmpeg-devel] [RFC][PATCH]Doxygenize libavutil/fifo.h
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <20070227212735.GR25795 at MichaelsNB>
Content-Type: text/plain; charset="iso-8859-1"

Hi

On Tue, Feb 27, 2007 at 05:33:53PM +0100, Dujardin Bernard wrote:
> Dujardin Bernard a icrit :
> >Hi,
> >
> >I submit ;-)   attached patch which take account of your remarks.
> >
> I send this to take account the recent revision 8149.
> 
> Regards
> Bernard

> Index: fifo.h
> ===================================================================
> --- fifo.h	(revision 8149)
> +++ fifo.h	(working copy)
> @@ -16,6 +16,11 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
>   */
>  
> +/**
> + * @file fifo.h
> + * A very simple circular buffer FIFO implementation.
> + */

as already said remove the word "implementation" it is not appropriate
for the header


> + 
>  #ifndef FIFO_H
>  #define FIFO_H
>  
> @@ -24,15 +29,74 @@
>      uint8_t *rptr, *wptr, *end;
>  } AVFifoBuffer;
>  
> +/**
> + * Initializes a FIFO *.

initalizes an AVFifoBuffer
also the function does not initalize a pointer to a fifo but the fifo struct
itself so the * is not appropriate


> + * @param *f fifo buffer

@param f the AVFifoBuffer to initalize


> + * @param size of fifo
> + * @return <0 for failure >=0 otherwise
> + */
>  int av_fifo_init(AVFifoBuffer *f, int size);
> +
> +/**
> + * Frees a FIFO *.

frees an AVFifoBuffer


> + * @param *f fifo buffer

@param f the AVFifoBuffer to free


> + */
>  void av_fifo_free(AVFifoBuffer *f);
> +
> +/**
> + * Gets the size of a FIFO *.

what is the size of a fifo? this is unlear, if you dont know what a function
does then dont add a comment to it but leave it to someone else to do who
does
goal is not to have as many comments as possible but to provide helpfull
information to the reader

correct here is
gets the amount of data in bytes in the fifo, that is the amount
you could read from it


> + * @param *f fifo buffer
> + * @return size
> + */
>  int av_fifo_size(AVFifoBuffer *f);
> +
> +/**
> + * Reads the data from the FIFO *.
> + * @param *f fifo buffer
> + * @param *buf data destination
> + * @param buf_size of data

@param buf_size number of bytes to read


> + * @return -1 if not enough data

ive already said that implementation details like -1 return are unaccptable
<0 is error >= 0 is no error
the doxygen comments in the header are a API specification they must be
written carefully, errors are totally unacceptable its much better if
something is undocumented


> + */
>  int av_fifo_read(AVFifoBuffer *f, uint8_t *buf, int buf_size);
> +
> +/**
> + * Reads the data from the FIFO *.

again dont write half correct comments, the comment is the same as for
the last but the function does not do the same

it rather feeds data from the fifo to a user supplied callback while
the previous reads data into a buffer


> + * @param *f fifo buffer
> + * @param buf_size data size
> + * @param *func generic read function
> + * @param *dest data destination

> + * @return -1 if not enough data

implementation detail


> + */
>  int av_fifo_generic_read(AVFifoBuffer *f, int buf_size, void
(*func)(void*, void*, int), void* dest);
> +
> +/**
> + * Writes the data in the FIFO *.

"in" is wrong use "into"


> + * @param *f fifo buffer
> + * @param *buf data source
> + * @param size of data
> + */
>  void av_fifo_write(AVFifoBuffer *f, const uint8_t *buf, int size);
> +
> +/**
> + * Resizes the FIFO *.
> + * @param *f fifo buffer
> + * @param size
> + */
>  void av_fifo_realloc(AVFifoBuffer *f, unsigned int size);
> +
> +/**
> + * Discards the data from the FIFO *.

reads and descards the specified amount of data from the AVFifoBuffer


> + * @param *f fifo buffer
> + * @param size of data
> + */
>  void av_fifo_drain(AVFifoBuffer *f, int size);
>  
> +/**
> + * Returns a pointer with circular offset from FIFO's read pointer.
> + * @param *f fifo buffer
> + * @param offs offset
> + * @return ptr=rptr+offs if rptr+offs<end else rptr+offs -(end-begin)
> + */
>  static inline uint8_t av_fifo_peek(AVFifoBuffer *f, int offs)

this function should be removed as it exposes implemenbtation details
and should thus not be documented


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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070227/f90d91
2c/attachment-0001.pgp

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

Message: 5
Date: Tue, 27 Feb 2007 22:53:26 +0100
From: Michael Niedermayer <michaelni at gmx.at>
Subject: Re: [Ffmpeg-devel] -quiet flag patch
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <20070227215325.GS25795 at MichaelsNB>
Content-Type: text/plain; charset="us-ascii"

Hi

On Thu, Feb 22, 2007 at 07:59:12PM -0800, Dan Brumleve wrote:
> Attached is a -quiet flag patch for ffmpeg.  It closes stderr, sets
verbose
> to -1, and bypasses the undesirable termios.  I was forced to move
> show_banner to after parse_options in order to suppress the banner.

may i ask what this patch is good for?

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070227/47ec79
0a/attachment-0001.pgp

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

Message: 6
Date: Wed, 28 Feb 2007 00:10:14 +0200
From: "Stas Oskin" <stas.oskin at gmail.com>
Subject: Re: [Ffmpeg-devel] Stream file handle hijacking by another
	thread
To: "FFmpeg development discussions and patches"
	<ffmpeg-devel at mplayerhq.hu>
Message-ID:
	<77938bc20702271410x554a50b2q61681eda6ab44945 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi.

> It sounds like you've got your threads mixed up, and one of them is
> closing a file descriptor belonging to another.

Well, after I checked it some more, you were right. I indeed had some
rogue closing of file descriptor in an unrelated thread.

Thanks!
Stas.


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

Message: 7
Date: Tue, 27 Feb 2007 23:33:02 +0100
From: "Karl H. Beckers" <karl.h.beckers at gmx.net>
Subject: [Ffmpeg-devel] swscale and palette ... what am I missing?
To: ffmpeg-devel at mplayerhq.hu
Message-ID: <1172615582.5805.12.camel at ubuntu.example.com>
Content-Type: text/plain

Hi all,

I'm trying to convert a pal8 frame to yuv420p using libswscale rather
than converting it to rbg myself. From what I'm reading in the archives
I kinda think this should be possible, but I'm not getting past a
segfault in swScale_MMX with input_pixfmt = PIX_FMT_PAL8 where RGBx work
nicely.

I'm setting up my frame like the following, contiguous char data in
data[0], linesize in bytes in linesize[0] and pointer to palette as arbg
(with alpha always 0) in data[1]:
            avpicture_fill ((AVPicture *) p_inpic, scratchbuf8bit,
                            input_pixfmt, image->width, image->height);
            p_inpic->data[0] = scratchbuf8bit;
            p_inpic->linesize[0] = image->width;
            p_inpic->data[1] = job->color_table;

then I construct my SwsContext:
            img_resample_ctx = sws_getContext (image->width,
                                               image->height,
                                               input_pixfmt,
                                               out_st->codec->width,
                                               out_st->codec->height,
                                               out_st->codec->pix_fmt,1,
                                               NULL, NULL, NULL);

and later call the sws_scale function:
    if (sws_scale (img_resample_ctx, p_inpic->data, p_inpic->linesize,
                   0, image->height, p_outpic->data, p_outpic->linesize)
 		< 0) {
        fprintf (stderr, .......


this always yields a segfault immediately:

Program terminated with signal 11, Segmentation fault.
#0  0x0836dd0f in swScale_MMX (c=0x87f2ca0, src=0x87c5490,
srcStride=0xb639228c, srcSliceY=0, srcSliceH=144, dst=0x87c5570,
dstStride=0xb6392298)
    at swscale_template.c:2288
2288                    int b= pal[d]     &0xFF;


Trying to debug this:

Starting program: /home/kb87850/xvidcap/bin/xvidcap 
[Thread debugging using libthread_db enabled]
[New Thread -1221232448 (LWP 7570)]
[New Thread -1238369376 (LWP 7571)]
[mpeg4 @ 0x8444f60]removing common factors from framerate
[New Thread -1248855136 (LWP 7572)]
[Switching to Thread -1238369376 (LWP 7571)]

Breakpoint 1, swScale_MMX (c=0xb5950fc0, src=0xb5935910,
srcStride=0xb62ff28c, srcSliceY=0, srcSliceH=144, dst=0xb593c9e0,
dstStride=0xb62ff298)
    at swscale_template.c:2285
2285            for(i=0; i<width; i++)
(gdb) print i
$7 = <value optimized out>
(gdb) print width
No symbol "width" in current context.
(gdb) step
2288                    int b= pal[d]     &0xFF;
(gdb) print d
No symbol "d" in current context.
(gdb) print src[0]
$8 = (uint8_t *) 0xb59359d8 ""
(gdb) print /d src[0]
$9 = 3046332888
(gdb) print pal
$10 = (uint8_t *) 0x0
(gdb) print *pal
Cannot access memory at address 0x0
(gdb) print pal[3046332888]
$11 = 0 '\0'


comparing with the relevant code in swscale_template.c:

static inline void RENAME(palToY)(uint8_t *dst, uint8_t *src, int width,
uint32_t *pal)
{
        int i;
        for(i=0; i<width; i++) 
        {    
                int d= src[i];
                int b= pal[d]     &0xFF;
                int g=(pal[d]>>8 )&0xFF;
                int r= pal[d]>>16;
av_log(NULL, AV_LOG_DEBUG, "i: %i\n", i);

                dst[i]= ((RY*r + GY*g + BY*b)>>RGB2YUV_SHIFT) + 16;
        }    
}

in gdb I see neither width nor stepping through the program see the line
"int d= src[i];" at all. pal seems to be a NULL pointer, but I don't
know why ... the palette needs to go in AVFrame.data[1] after all,
doesn't it?

Am I missing anything obvious?

TIA,

Karl.






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

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

End of ffmpeg-devel Digest, Vol 23, Issue 269
*********************************************





More information about the ffmpeg-devel mailing list