[Ffmpeg-devel] RE: ffmpeg-devel Digest, Vol 21, Issue 153

Susan Montooth Susan.Montooth
Tue Dec 19 19:34:03 CET 2006



-----Original Message-----
From: "ffmpeg-devel-request at mplayerhq.hu" <ffmpeg-devel-request at mplayerhq.hu>
To: "ffmpeg-devel at mplayerhq.hu" <ffmpeg-devel at mplayerhq.hu>
Sent: 12/19/06 8:12 AM
Subject: ffmpeg-devel Digest, Vol 21, Issue 153

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. [PATCH] asf-enc brokes packets with padding (Nikolay Dobrev)
   2. Re: [PATCH] remove mingw32 ifdefs in file.c (Aurelien Jacobs)
   3. Re: moving non-SIMD parts of libswscale to LGPL (Luca Abeni)
   4. Re: Native H.264 encoder (Luca Abeni)
   5. alsa input / output (Luca Abeni)
   6. Re: alsa input / output (Stefan de Konink)
   7. Re: alsa input / output (Luca Abeni)
   8. Re: moving non-SIMD parts of libswscale to LGPL
      (Michael Niedermayer)
   9. Re: Help understanding AVParser (Michael Niedermayer)


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

Message: 1
Date: Tue, 19 Dec 2006 13:25:45 +0200
From: "Nikolay Dobrev" <dobrev666 at gmail.com>
Subject: [Ffmpeg-devel] [PATCH] asf-enc brokes packets with padding
To: ffmpeg-devel at mplayerhq.hu
Message-ID:
	<8627835b0612190325ud6055d2p9e8a42fa49a4ad7a at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hello,
Encoding of asf packets with padding is broken.
When asf->packet_size_left is not zero, one or two more bytes is added to
the parsing info and the asf->packet_size_left is not updated. Then the
packet_filled_size in function

static void flush_packet(AVFormatContext *s)

is wrong and the memset:

memset(asf->packet_buf + packet_filled_size, 0, asf->packet_size_left);

fills the end of the frame with zeroes. After that when the file is played
there is errors from the decoder of these frames.

I suggest the attached patch.

Nick.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asf-enc.patch
Type: application/octet-stream
Size: 1374 bytes
Desc: not available
Url : http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061219/51cb753f/asf-enc-0001.obj

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

Message: 2
Date: Tue, 19 Dec 2006 13:36:03 +0100
From: Aurelien Jacobs <aurel at gnuage.org>
Subject: Re: [Ffmpeg-devel] [PATCH] remove mingw32 ifdefs in file.c
To: ffmpeg-devel at mplayerhq.hu
Message-ID: <20061219133603.e5507d35.aurel at gnuage.org>
Content-Type: text/plain; charset=US-ASCII

On Tue, 19 Dec 2006 02:10:28 -0200 (BRDT)
ramiro at lisha.ufsc.br wrote:

> Hello,
> 
> This Windows support was added in revision 78. Probably still meant for
> MSVC++.
> 
> Regression tests pass. Except for ffserver tests, which shouldn't even be
> run, since ffserver wasn't built.
> 
> Is <sys/ioctl.h> really necessary? It compiled fine for me without
> including it on linux too.

I checked this whole file, and I can't see anything which require ioctl.h
so IMO, remove this include. (And AFAICT you could also remove the include
sys/time.h but that is a separate issue)

Aurel


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

Message: 3
Date: Tue, 19 Dec 2006 14:20:29 +0100
From: Luca Abeni <lucabe72 at email.it>
Subject: Re: [Ffmpeg-devel] moving non-SIMD parts of libswscale to
	LGPL
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <1166534429.997.13.camel at labeni.mm.mbigroup.it>
Content-Type: text/plain

On Fri, 2006-12-15 at 18:05 +0100, Michael Niedermayer wrote:
[...]
> > > doxygen ...
> > [...]
> > Ok; I hope I addressed all the issues. The new version of the is
> > attached; I post it again so that everyone can have a look, and someone
> 
> iam still ok with the patch (assuming it work / looks correct) ...
I tried some conversions (such as yuv420p <--> bgr24) with ffmpeg, and
they seemed to work ok, and I verified that swscale-example does not
crash.

Can I commit yuv2rgb_init.c (together with the patch I previously
posted), so that it can have more testing?
Some notes:
- this version of the patch should not change anything if CONFIG_GPL is
used (if it changes something, it's a bug). So, it should not break
mplayer. After it's committed, I propose to wait for a week or two, and
then change the code to always use yuv2rgb_init.c even if CONFIG_GPL is
used (to remove code / data duplication)
- the code still contains the first yuv ---> rgb tables I generated. I
plan to update them after the code is in the repository... Is this ok?


			Thanks,
				Luca
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !



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

Message: 4
Date: Tue, 19 Dec 2006 14:27:38 +0100
From: Luca Abeni <lucabe72 at email.it>
Subject: Re: [Ffmpeg-devel] Native H.264 encoder
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <1166534858.4471.1.camel at labeni.mm.mbigroup.it>
Content-Type: text/plain

Hi Michael,
On Mon, 2006-12-18 at 22:04 +0100, Michael Niedermayer wrote:
[...]
> btw 2 tips
> 1. submit small patches, a 40k motion estimation cleanup patch would be
>    a nightmare for me and whoever submits it ...
> 2. look at snow.c and try to reduce the number of lines of code which
> depend on MpegEncContext if it reaches 0 then motion estimation can be
> used without MpegEncContext ...
Thanks for the hint; I'm going to have a look at snow.c as soon as I
find some time.

			Thanks,
				Luca
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !



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

Message: 5
Date: Tue, 19 Dec 2006 16:22:47 +0100
From: Luca Abeni <lucabe72 at email.it>
Subject: [Ffmpeg-devel] alsa input / output
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <1166541767.4610.9.camel at labeni.mm.mbigroup.it>
Content-Type: text/plain

Hi all,

I wrote a small AVOutputFormat and AVInputFormat for supporting alsa
through alsalib. It is not perfect yet, and still has some bugs (A/V
synchronization might be incorrect because timestamps generation is very
naive, endianess is not correctly handled, only 16bit samples are
currently supported, etc...). But it is already usable (I tried to
capture an avi from video4linux2/alsa, and I had no xruns and audio and
video look in synch).

Is anyone interested in this alsa format? If yes, I can send it to the
list so that interested people can try it, and improve or fix it (in its
current form, I do not know if it can be submitted for inclusion...)

Also, just for the fun of it I am thinking about accessing alsa without
using alsalib (by directly accessing /dev/snd/*). Does anyone know where
can I find some documentation about the "raw" /dev/snd/* interface?


			Thanks,
				Luca
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !



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

Message: 6
Date: Tue, 19 Dec 2006 16:26:50 +0100 (CET)
From: Stefan de Konink <skinkie at xs4all.nl>
Subject: Re: [Ffmpeg-devel] alsa input / output
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <20061219162342.F70134-100000 at xs2.xs4all.nl>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 19 Dec 2006, Luca Abeni wrote:

> Also, just for the fun of it I am thinking about accessing alsa without
> using alsalib (by directly accessing /dev/snd/*). Does anyone know where
> can I find some documentation about the "raw" /dev/snd/* interface?

Would you really want to do this? Everytime the format changes you need to
update the code. Second to that... the 'remapping' of interfaces would
probably be broken I guess. Therefore the only thing that will work is the
naive interfaces to the hardware.

The idea of Alsa-suppert is very nice though :)


Yours Sincerely,

Stefan de Konink



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

Message: 7
Date: Tue, 19 Dec 2006 16:48:27 +0100
From: Luca Abeni <lucabe72 at email.it>
Subject: Re: [Ffmpeg-devel] alsa input / output
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <1166543307.4610.21.camel at labeni.mm.mbigroup.it>
Content-Type: text/plain

Hi Stefan,

On Tue, 2006-12-19 at 16:26 +0100, Stefan de Konink wrote:
> On Tue, 19 Dec 2006, Luca Abeni wrote:
> 
> > Also, just for the fun of it I am thinking about accessing alsa without
> > using alsalib (by directly accessing /dev/snd/*). Does anyone know where
> > can I find some documentation about the "raw" /dev/snd/* interface?
> 
> Would you really want to do this?
Well, it looked like something to try just for the fun of it :) (and to
understand how alsa work at a low level...)

More seriously, it happened to me to compile ffmpeg with alsa support on
a computer, to copy it on a different computer, and to be unable to run
ffmpeg on the second computer because libalsa was not installed there
(or a different version of alsalib was installed, I do not remember).
So, I wondered why a new dependency on alsalib was really needed, and I
had this funny idea of directly accessing the alsa drivers...

>  Everytime the format changes you need to update the code.
By "format" here you mean the kernel <---> userspace interface?
If yes, I do not think it can change during a stable kernel release
(Linus would never allow to break US in this way, I hope).
If such interface changed, a new version of alsalib would need to be
installed, creating a manteinance nightmare...


			Thanks,
				Luca
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !



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

Message: 8
Date: Tue, 19 Dec 2006 17:06:24 +0100
From: Michael Niedermayer <michaelni at gmx.at>
Subject: Re: [Ffmpeg-devel] moving non-SIMD parts of libswscale to
	LGPL
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <20061219160623.GB27723 at MichaelsNB>
Content-Type: text/plain; charset=us-ascii

Hi

On Tue, Dec 19, 2006 at 02:20:29PM +0100, Luca Abeni wrote:
> On Fri, 2006-12-15 at 18:05 +0100, Michael Niedermayer wrote:
> [...]
> > > > doxygen ...
> > > [...]
> > > Ok; I hope I addressed all the issues. The new version of the is
> > > attached; I post it again so that everyone can have a look, and someone
> > 
> > iam still ok with the patch (assuming it work / looks correct) ...
> I tried some conversions (such as yuv420p <--> bgr24) with ffmpeg, and
> they seemed to work ok, and I verified that swscale-example does not
> crash.
> 
> Can I commit yuv2rgb_init.c (together with the patch I previously
> posted), so that it can have more testing?

ok


> Some notes:
> - this version of the patch should not change anything if CONFIG_GPL is
> used (if it changes something, it's a bug). So, it should not break
> mplayer. After it's committed, I propose to wait for a week or two, and
> then change the code to always use yuv2rgb_init.c even if CONFIG_GPL is
> used (to remove code / data duplication)

ok


> - the code still contains the first yuv ---> rgb tables I generated. I
> plan to update them after the code is in the repository... Is this ok?

ok if regression tests pass

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

I count him braver who overcomes his desires than him who conquers his
enemies for the hardest victory is over self. -- Aristotle


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

Message: 9
Date: Tue, 19 Dec 2006 17:11:35 +0100
From: Michael Niedermayer <michaelni at gmx.at>
Subject: Re: [Ffmpeg-devel] Help understanding AVParser
To: FFmpeg development discussions and patches
	<ffmpeg-devel at mplayerhq.hu>
Message-ID: <20061219161134.GC27723 at MichaelsNB>
Content-Type: text/plain; charset=us-ascii

Hi

On Tue, Dec 19, 2006 at 09:59:00AM +0000, Cool_Zer0 wrote:
> Michael Niedermayer wrote:
> >Hi
> >
> >On Mon, Dec 18, 2006 at 06:37:22PM +0000, Cool_Zer0 wrote:
> >  
> >>On 12/18/06, Michael Niedermayer <michaelni at gmx.at> wrote:
> >>    
> >>>Hi
> >>>
> >>>On Mon, Dec 18, 2006 at 11:04:47AM +0000, Cool_Zer0 wrote:
> >>>      
> >>>>Hi there.
> >>>>
> >>>>I'm trying to use AVParser but I'm a bit lost and I can't find any
> >>>>documentation.
> >>>>
> >>>>So... Here's what I'm doing...
> >>>>
> >>>>
> >>>>I'm calling *av_parser_init(CODEC_ID_H263)* and then I think that I have
> >>>>        
> >>>to
> >>>      
> >>>>call *av_parser_parse()* for each H.263 packet that I receive.
> >>>>My main problem is understanding the parameters of the last function:
> >>>>
> >>>>AVCodecParserContext
> >>>>AVCodecContext
> >>>>poutbuf
> >>>>poutbuf_size
> >>>>buf
> >>>>buf_size
> >>>>pts
> >>>>dts
> >>>>
> >>>>The first ones I understand but the last 6 I can't understand what they
> >>>>are...
> >>>>Other question...  If buf_size takes the value 0 it means that I have a
> >>>>complete frame, right? So... Where is that frame and how can I put on a
> >>>>AVFrame/AVPicture in order to convert it to BGR24?
> >>>>
> >>>>If you don't want to answer my question at least give me some link to
> >>>>        
> >>>any
> >>>      
> >>>>documentation about AVParser.
> >>>>        
> >>>see av_read_frame_internal() in utils.c and the doxygen comment above
> >>>av_parser_parse in parser.c
> >>>      
> >>
> >>Hi.
> >>When I update my code the comment appear :)
> >>But I'm having the same problems that I had without the AVParser :(
> >>
> >>
> >>AVCodecParserContext *parser_context;
> >>uint8_t *poutbuf = new uint8_t[6000];
> >>int poutsize=0;
> >>
> >>{
> >>...
> >>parser_context = av_parser_init(CODEC_ID_H263);
> >>...
> >>}
> >>
> >>void video_decode(unsigned char* payload, int payloadsize)
> >>{
> >>   static int frame_numero = 0;
> >>
> >>   int len = 0;
> >>   while (payloadsize) {
> >>       len = av_parser_parse(parser_context, c, &poutbuf, &poutsize,
> >>payload, payloadsize, frame_numero, frame_numero);
> >>
> >>       payload += len;
> >>       payloadsize -= len;
> >>
> >>       if (len < 0)
> >>           return;
> >>    
> >
> >  
> Hi.
> 
> >if(!poutsize)
> >    continue;
> >  
> 
> Less frames are saved but still presents the same problems :(
> 
> >and if this doesnt help then does it work if you dump the stuff to a file 
> >and
> >try to play that with ffmpeg or ffplay?
> >  
> 
> That's a good sugestion!!! If ffmpeg could play and decompress the movie 
> correctly should mean that the problem is in my code. There is only one 
> problem...
> I'm receiving packets through RTP (not using RTSP)... I have saved about 
> 160 h.263 packets... In order to pass that packets to ffmpeg what I have 
> to do? Merge all the packets into a single file? It will work? The file 
> doesn't need to have a special format?

yes ff* should be able to play h.263 if the frames are just concatenated

and you can generate a valid h.263 file for comparission with
ffmpeg -i any.avi -s 352x288 test.h263

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

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

End of ffmpeg-devel Digest, Vol 21, Issue 153
*********************************************




More information about the ffmpeg-devel mailing list