Josh Varner | 1 May 01:20 2005
Picon

[PATCH] Changing FF_COMMON_FRAME to an include file

I've noticed that the documentation for AVFrame does not get processed
by doxygen correctly, since it's defined as a #define which are not
macro expanded by doxygen with the current Doxyfile included with
ffmpeg. The current documentation at
http://www.mplayerhq.hu/~michael/ffmpeg-doxy/structAVFrame.html gives
you the impression that it is an empty data structure, and even if you
know that FF_COMMON_FRAME contains most of the data the doxygen
documentation for FF_COMMON_FRAME shows nothing as well
http://www.mplayerhq.hu/~michael/ffmpeg-doxy/avcodec_8h.html#a78.

By changing this define into an include file the documentation will be
generated correctly by doxygen. I've tested this on my machine,
unfortunatly I don't have someplace to post the results, but I got the
expected results as doxygen does all of the including during its
processing, and the new include file does not have the backslashes at
the end of every line to throw off doxygen's processing. I think this
will greatly improve the readability of the documentation without any
functional changes.

Josh

P.S I ran the tests and got a failure at this point, but since it
passed several pages of tests I doubt this had anything do to with my
changes:
ffmpeg version 0.4.9-pre1, build 4753, Copyright (c) 2000-2004 Fabrice Bellard
  configuration:  
  built on Apr 30 2005 16:41:13, gcc: 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
../ffmpeg_g -y -bitexact -dct_algo 1 -idct_algo 2 -i
./data/b-libav.nut -f crc ./data/ffmpeg.crc
/home/josh/projects/ffmpeg/doc/tests/regression.sh: line 125: 21138
(Continue reading)

Michael Niedermayer | 1 May 13:28 2005
Picon
Picon

Re: [PATCH] Changing FF_COMMON_FRAME to an include file

Hi

On Sunday 01 May 2005 01:20, Josh Varner wrote:
> I've noticed that the documentation for AVFrame does not get processed
> by doxygen correctly, since it's defined as a #define which are not
> macro expanded by doxygen with the current Doxyfile included with
> ffmpeg. The current documentation at
> http://www.mplayerhq.hu/~michael/ffmpeg-doxy/structAVFrame.html gives
> you the impression that it is an empty data structure, and even if you
> know that FF_COMMON_FRAME contains most of the data the doxygen
> documentation for FF_COMMON_FRAME shows nothing as well
> http://www.mplayerhq.hu/~michael/ffmpeg-doxy/avcodec_8h.html#a78.
>
> By changing this define into an include file the documentation will be
> generated correctly by doxygen. I've tested this on my machine,
> unfortunatly I don't have someplace to post the results, but I got the
> expected results as doxygen does all of the including during its
> processing, and the new include file does not have the backslashes at
> the end of every line to throw off doxygen's processing. I think this
> will greatly improve the readability of the documentation without any
> functional changes.

rejected, this is a workaround either of our stupidity to configure doxygen 
correctly or a bug in doxygen

[...]
>   built on Apr 30 2005 16:41:13, gcc: 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
> ../ffmpeg_g -y -bitexact -dct_algo 1 -idct_algo 2 -i
> ./data/b-libav.nut -f crc ./data/ffmpeg.crc
> /home/josh/projects/ffmpeg/doc/tests/regression.sh: line 125: 21138
(Continue reading)

Fred Rothganger | 1 May 16:47 2005
Picon

Re: Revised os2.diff

Michael Niedermayer wrote:

>IIRC there must be no spaces before #
>so
>+    #ifdef CONFIG_OS2
>will cause problems
>

    I use spaces before the # regularly with impunity.  Compiles ok 
under bothe gcc and msvc.  However, if you want spaces, I think the 
style of putting them after the # is nicer.

-- Fred
Matti Hamalainen | 1 May 17:26 2005
Picon

Re: Revised os2.diff

On Sun, 1 May 2005, Fred Rothganger wrote:

> Michael Niedermayer wrote:
> 
> > IIRC there must be no spaces before #
> > so
> > +    #ifdef CONFIG_OS2
> > will cause problems
> > 
> 
>    I use spaces before the # regularly with impunity.  Compiles ok under bothe
> gcc and msvc.  However, if you want spaces, I think the style of putting them
> after the # is nicer.

Some preprocessors (GNU cpp too, in traditional mode) actually _require_ 
that the preprocessor directive  starts from the first column of line 
(whitespaces are allowed after '#' though). I don't know if this has any 
relevance to FFMPEG project, but I  think it's a widely used practice to 
do the right way(tm).

Some references:
http://tigcc.ticalc.org/doc/cpp.html
http://aragorn.uio.no/nanvaent/manpages/concepts/preprocessor.html

I couldn't find any references to C standards though, so this may just be 
a implementation related quirk that has been "circumvented" by following 
path of least resistance.

--

-- 
] ccr/TNSP^DKD^pWp :: ccr(at)tnsp(dot)org :: http://ccr.tnsp.org/
(Continue reading)

Balatoni Denes | 1 May 18:11 2005
Picon

Re: reading chunks of bits in reversed order (LSB first)

Hi!

Answers below.

2005. április 30. 20.31-kor Balatoni Denes ezeket a bolcs gondolatokat 
fogalmazta meg:
> Hi!
>
> I have a (perhaps stupid) question concerning the subject. In a vorbis
> stream if there is the byte 0xB8 (1011 1000) and I read 4 bits then 4 bits
> again I will get 1011 and than 1000. However I would like to get these
> numbers in reverse order i.e. first 1000 and then 1011.
> Is there perhaps a trivial way to fix this ?
Unfortunately not.

> Or should I try to make the bitreader count the bits from the least
> significant bit of what is yet to be read?
Yes that's the right way. Or rather, add new functions that read from the 
stream in little endian order, because all other codecs read the bitstreams 
in big endian order (MSB first).

> thanks, bye
> Denes

bye
Denes

--

-- 
- Use the Source Luke ! -
(Continue reading)

Aigars Krastins | 2 May 07:32 2005

FFServer Errors

Hello!

  I'm trying to use ffmpeg/ffserver for streaming from 
V4L device,but no luck. I get the latest source from 
CVS and compilled on Fedora Core 3. 
As result, player keeps buffering and

1) when ffpmeg starts sreaming or player connects  to ffserver 
prints bunch of "error, non monotone timestamps" messages.

2) ffmpeg often prints "buffer underflow" messages.  

Any ideas ?

Regars,
Aigars Krastins.
Bo Xie | 2 May 08:12 2005
Picon

Re: Bug Report: .AVI->.3GP transcoding with(-ss -t) is av desyn

Does any one care about this bug report?

Best Regards,
Xie Bo

On 4/21/05, Bo Xie <xiebopublic <at> gmail.com> wrote:
> Hi,
> 
>   I follow the
> guide(http://ffmpeg.sourceforge.net/ffmpeg-bugreport.html) to report
> this bug. I want to use ffmpeg to transcode a .avi (from 00:10:00 to
> 00:15:00) to .3gp file.
>   1.I am using the latest CVS
> version(http://www1.mplayerhq.hu/MPlayer/cvs/FFMpeg-20050421.tar.bz2)
> of FFMPEG.
>   2.I configure it by "./configure --enable-mp3lame --enable-faac
> --enable-faad --enable-amr_nb --enable-memalign-hack --enable-gpl
> --enable-xvid --enable-dts --enable-a52 --enable-vhook"
>   3.I run it by "ffmpeg.exe -ss 00:10:00 -t 00:05:00 -y -i E:\a.avi
> -bitexact -vcodec xvid -s 320x240 -r 15 -b 190 -acodec amr_nb -ac 1
> -ar 8000 -ab 12 -f 3gp c:\byffmpeg.3gp", and the following is log:
> -------
> ffmpeg version 0.4.9-pre1, build 4752, Copyright (c) 2000-2004 Fabrice Bellard
>  configuration:  --enable-mp3lame --enable-faac --enable-faad
> --enable-amr_nb --enable-memalign-hack --enable-gpl --enable-xvid
> --enable-dts --enable-a52 --enable-vhook
>  built on Apr 21 2005 13:42:25, gcc: 3.2.3 (mingw special 20030504-1)
> Input #0, avi, from 'E:a.avi':
>  Duration: 01:15:02.0, start: 0.000000, bitrate: 1312 kb/s
>  Stream #0.0: Video: mpeg4, 560x352, 25.00 fps
(Continue reading)

Torben Knerr | 2 May 12:29 2005
Picon
Picon

RTSP/RTP streaming with ffmpeg

hi,

i have some RTSP/RTP streaming related questions.
i found nothing in the documentation about streaming,
but google says that ffmpeg supports it :)

1) can ffmpeg act as an RTSP server and send encoded streams over RTP?

2) if not, is it possible to send the encoded stream over RTP to a 
Streaming server (e.g. Darwin),
which in turn does the RTSP Session setup etc.?

3) if yes, can ffmpeg also handle 3gp and mp4 (i know it supports it for 
file output) streams for sending over RTP?

Your help would be appreciated.

Best regards,
Torben
Luca Barbato | 2 May 12:57 2005
Picon

Re: RTSP/RTP streaming with ffmpeg

Torben Knerr wrote:
> hi,
> 
> i have some RTSP/RTP streaming related questions.
> i found nothing in the documentation about streaming,
> but google says that ffmpeg supports it :)
> 
> 1) can ffmpeg act as an RTSP server and send encoded streams over RTP?
ffserver should support it, if you want to help developing ffserver you
are welcome =)
> 
> 2) if not, is it possible to send the encoded stream over RTP to a
> Streaming server (e.g. Darwin),
> which in turn does the RTSP Session setup etc.?
fenice is commonly used with ffmpeg as live feeder ( see
http://streaming.polito.it/node/38 ), there is a set of experimental
tools in the svn to have some more control (FeLiCe and mclient).
> 
> 3) if yes, can ffmpeg also handle 3gp and mp4 (i know it supports it for
> file output) streams for sending over RTP?
ffserver _should_ support more or less everything ffmpeg can do, keep in
mind that I say should since ffserver probably requires some improvements.

lu

--

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Manager
(Continue reading)

Torben Knerr | 2 May 15:04 2005
Picon
Picon

Re: RTSP/RTP streaming with ffmpeg

thx for your reply!

i configured like this:

./configure --enable-memalign-hack --enable-mingw32 --enable-mp3lame 
--enable
-amr_nb --enable-amr_wb --enable-faac --enable-ffserver --enable-gpl 
--extra-cf
lags=-I/local/include --extra-ldflags=-L/local/lib

but no ffserver.exe was generated... have i missed something?

regards,
torben

Luca Barbato wrote:

>Torben Knerr wrote:
>  
>
>>hi,
>>
>>i have some RTSP/RTP streaming related questions.
>>i found nothing in the documentation about streaming,
>>but google says that ffmpeg supports it :)
>>
>>1) can ffmpeg act as an RTSP server and send encoded streams over RTP?
>>    
>>
>ffserver should support it, if you want to help developing ffserver you
(Continue reading)


Gmane