[Ffmpeg-devel] Re: ffmpeg-devel Digest, Vol 19, Issue 239

Paul paul.pham
Mon Oct 30 03:31:21 CET 2006 

Hi, i have use these files, apiexample.c and output_example.c,
if i use the codes sample in encode audio sample then the output file is
work().
but now, i would like to use audio buffer that i captured from Directsound
application, encode this buffer (PCM codec) to MP2 (MP2 codec) using FFMPEG.
I did check the output file and see that it was encoded but the data (what i
can hear) of the output file is not correct...

anyone can help me???
----- Original Message -----
From: <ffmpeg-devel-request at mplayerhq.hu>
To: <ffmpeg-devel at mplayerhq.hu>
Sent: Sunday, October 29, 2006 12:09 AM
Subject: ffmpeg-devel Digest, Vol 19, Issue 239


> 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: encode audio with FFMPEG ...  Please help me
>       (Michael Niedermayer)
>    2. Re: [PATCH]: A/V sync on nsv streams. (Michael Niedermayer)
>    3. Re: [PATCH proposal] Reuse UDP socket v2 (Michael Niedermayer)
>    4. Re: ARCH_X86 vs ARCH_X86_32 vs ARCH_X86_64 (Reimar D?ffinger)
>    5. Re: RTP patches & RFC (Michael Niedermayer)
>    6. Re: ARCH_X86 vs ARCH_X86_32 vs ARCH_X86_64
>       (Dominik 'Rathann' Mierzejewski)
>    7. Re: ARCH_X86 vs ARCH_X86_32 vs ARCH_X86_64 (Reimar D?ffinger)
>    8. Re: ARCH_X86 vs ARCH_X86_32 vs ARCH_X86_64
>       (Dominik 'Rathann' Mierzejewski)
>    9. Re: Re: [Ffmpeg-devel] RTP patches & RFC (Guillaume POIRIER)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 28 Oct 2006 12:07:17 +0200
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] encode audio with FFMPEG ...  Please help
> me
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20061028100716.GD1768 at MichaelsNB>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> On Sat, Oct 28, 2006 at 04:47:47PM +0700, Paul wrote:
> > I have used DirectSound for recording wave file from microphone.
> >
> > I create a thread to run recording,.... Inside recording function, i
have pbCaptureData (type is IDirectSoundBuffer) to get sound data in
real-time.
> >
> > And i also write these codes (in recording function) to encode audio and
then write to file
> >
> > .....
> > DWORD out_size ;
> > out_size = avcodec_encode_audio(c, outbuf, outbuf_size,
(short*)pbCaptureData);
> > fwrite(outbuf, 1, out_size, outputfile);
> > ....
> > (Note: Before call above, i set outbuf_size = 10000; and outbuf =
(unsigned char*)malloc(outbuf_size); i used codec is MP2... )
> > ....
> > But the outputfile  (output file) is not correct. Althought the output
file was encoded, but data not correct.
> >
> > I donot know where i am wrong??? Anyone can help me fix...
> >
> > Or anyone can show me source sample for encoding from exist file (wave
format) to MP2.
>
> see libavcodec/apiexample.c and output_example.c
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 28 Oct 2006 12:51:18 +0200
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] [PATCH]: A/V sync on nsv streams.
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20061028105116.GE1768 at MichaelsNB>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> On Sat, Oct 28, 2006 at 03:23:28AM +0200, elupus wrote:
> > > > Since the demuxer provides no other means of knowing sync
> > > between audio and
> > > > video I suppose it could make sence to use a timebase wich
> > > would give this
> > > > completly correct, if video has timebase a/b, then use
> > > 1/(1000b) for audio,
> > > > and set dts to frame*1000*a + sync*b. Would that be acceptable?
> > >
> > > yes, besides what idiot designed nsv?
> > >
> > > [...]
> > > --
> > > Michael     GnuPG fingerprint:
> > > 9FF2128B147EF6730BADF133611EC787040B0FAB
> > >
> > > In the past you could go to a library and read, borrow or
> > > copy any book
> > > Today you'd get arrested for mere telling someone where the library is
> > >
> >
> > Alright, here is an updated patch which does as given above. Had some
> > initial issues with int's overflowing, but the current abit uggly way
works
> > good. It keeps sync on the samples I've tried. It does generate rather
huge
> > timestamps thou. 1000*1001*frames, but it should be within the margin
for a
> > 64bit int.
>
> patch looks ok
>
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 28 Oct 2006 12:53:36 +0200
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] [PATCH proposal] Reuse UDP socket v2
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20061028105336.GF1768 at MichaelsNB>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> On Sat, Oct 28, 2006 at 11:09:00AM +0200, Thijs Vermeir wrote:
> > Hello,
> >
> > On 27-okt-06, at 20:35, Guillaume POIRIER wrote:
> > >>...
> > >>this should be optional and disabled by default
> > >
> > >...
> >
> > Here is a new patch with this issue applied.
>
> looks ok
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 28 Oct 2006 14:22:58 +0200
> From: Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>
> Subject: Re: [Ffmpeg-devel] ARCH_X86 vs ARCH_X86_32 vs ARCH_X86_64
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20061028122258.GA6872 at 1und1.de>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello,
> On Wed, Oct 25, 2006 at 06:56:19PM +0200, Diego Biurrun wrote:
> > On Mon, Oct 16, 2006 at 11:14:05PM +0200, Diego Biurrun wrote:
> > > And here is the corresponding patch for MPlayer, testing on x86_64
very
> > > welcome as well.
> >
> > Reimar, maybe you can test this?
>
> Needs attached patch, nothing else seemed to cause problems. IMO apply,
> if any other issues appear they can be fixed quickly.
>
> Greetings,
> Reimar D?ffinger
> -------------- next part --------------
> Index: mp3lib/sr1.c
> ===================================================================
> --- mp3lib/sr1.c (revision 20488)
> +++ mp3lib/sr1.c (working copy)
> @@ -31,7 +31,7 @@
>
>  #include "libvo/fastmemcpy.h"
>
> -#ifdef ARCH_X86
> +#ifdef ARCH_X86_32
>  #define CAN_COMPILE_X86_ASM
>  #endif
>
> Index: mp3lib/Makefile
> ===================================================================
> --- mp3lib/Makefile (revision 20488)
> +++ mp3lib/Makefile (working copy)
> @@ -7,7 +7,7 @@
>  CFLAGS  = -I.. $(OPTFLAGS)
>
>  SRCS = sr1.c
> -ifeq ($(TARGET_ARCH_X86),yes)
> +ifeq ($(TARGET_ARCH_X86_32),yes)
>  SRCS += decode_i586.c
>  ifeq ($(TARGET_MMX),yes)
>  SRCS += decode_MMX.c dct64_MMX.c tabinit_MMX.c
>
> ------------------------------
>
> Message: 5
> Date: Sat, 28 Oct 2006 15:47:00 +0200
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] RTP patches & RFC
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20061028134700.GG1768 at MichaelsNB>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> On Fri, Oct 27, 2006 at 08:11:04PM -0500, Ryan Martell wrote:
> >
> > On Oct 27, 2006, at 11:56 AM, Ryan Martell wrote:
> > >On Oct 27, 2006, at 5:53 AM, Michael Niedermayer wrote:
> > >>>Once those are applied, I'll add the rtp modification patch.
> >
> > Here's the rtp modification patch...
> >
> > This is adjustments to my dynamic protocol stuff (needed as i got
> > further into it).  All of this has been seen before here.  I replaced
> > the goto with a separate function.
> >
> > I went over this closely with vim.  I really hope i got everything!
>
> looks ok
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 28 Oct 2006 17:48:14 +0200
> From: Dominik 'Rathann' Mierzejewski <dominik at rangers.eu.org>
> Subject: Re: [Ffmpeg-devel] ARCH_X86 vs ARCH_X86_32 vs ARCH_X86_64
> To: ffmpeg-devel at mplayerhq.hu
> Message-ID: <20061028154814.GB4926 at rathann.pekin.waw.pl>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Saturday, 28 October 2006 at 14:22, Reimar D?ffinger wrote:
> > Hello,
> > On Wed, Oct 25, 2006 at 06:56:19PM +0200, Diego Biurrun wrote:
> > > On Mon, Oct 16, 2006 at 11:14:05PM +0200, Diego Biurrun wrote:
> > > > And here is the corresponding patch for MPlayer, testing on x86_64
very
> > > > welcome as well.
> > >
> > > Reimar, maybe you can test this?
> >
> > Needs attached patch, nothing else seemed to cause problems. IMO apply,
> > if any other issues appear they can be fixed quickly.
> >
> > Greetings,
> > Reimar D?ffinger
>
> > Index: mp3lib/sr1.c
> > ===================================================================
> > --- mp3lib/sr1.c (revision 20488)
> > +++ mp3lib/sr1.c (working copy)
> > @@ -31,7 +31,7 @@
> >
> >  #include "libvo/fastmemcpy.h"
> >
> > -#ifdef ARCH_X86
> > +#ifdef ARCH_X86_32
> >  #define CAN_COMPILE_X86_ASM
> >  #endif
>
> That seems wrong. Semantically, it implies that X86_64 cannot compile
X86_ASM.
>
> R.
>
> --
> MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 28 Oct 2006 18:06:32 +0200
> From: Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>
> Subject: Re: [Ffmpeg-devel] ARCH_X86 vs ARCH_X86_32 vs ARCH_X86_64
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20061028160632.GA9878 at 1und1.de>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hello,
> On Sat, Oct 28, 2006 at 05:48:14PM +0200, Dominik 'Rathann' Mierzejewski
wrote:
> > > -#ifdef ARCH_X86
> > > +#ifdef ARCH_X86_32
> > >  #define CAN_COMPILE_X86_ASM
> > >  #endif
> >
> > That seems wrong. Semantically, it implies that X86_64 cannot compile
X86_ASM.
>
> That's exactly how it was before. And in general X86_64 actually can not
> compile normal X86 asms, e.g. some opcodes were removed etc.
>
> Greetings,
> Reimar D?ffinger
>
>
> ------------------------------
>
> Message: 8
> Date: Sat, 28 Oct 2006 18:18:06 +0200
> From: Dominik 'Rathann' Mierzejewski <dominik at rangers.eu.org>
> Subject: Re: [Ffmpeg-devel] ARCH_X86 vs ARCH_X86_32 vs ARCH_X86_64
> To: ffmpeg-devel at mplayerhq.hu
> Message-ID: <20061028161806.GA5619 at rathann.pekin.waw.pl>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Saturday, 28 October 2006 at 18:06, Reimar D?ffinger wrote:
> > Hello,
> > On Sat, Oct 28, 2006 at 05:48:14PM +0200, Dominik 'Rathann' Mierzejewski
wrote:
> > > > -#ifdef ARCH_X86
> > > > +#ifdef ARCH_X86_32
> > > >  #define CAN_COMPILE_X86_ASM
> > > >  #endif
> > >
> > > That seems wrong. Semantically, it implies that X86_64 cannot compile
X86_ASM.
> >
> > That's exactly how it was before. And in general X86_64 actually can not
> > compile normal X86 asms, e.g. some opcodes were removed etc.
>
> You mean X86_32 asm, but the define name does not specify that.
> I'm just pointing out an inconsistency.
>
> Regards,
> R.
>
> --
> MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
>
>
> ------------------------------
>
> Message: 9
> Date: Sat, 28 Oct 2006 19:09:48 +0200
> From: "Guillaume POIRIER" <poirierg at gmail.com>
> Subject: Re: Re: [Ffmpeg-devel] RTP patches & RFC
> To: "FFmpeg development discussions and patches"
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID:
> <4e03026a0610281009u259dfc2dsbff74eea7611da90 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> On 10/28/06, Ryan Martell <rdm4 at martellventures.com> wrote:
> >
> > On Oct 27, 2006, at 11:56 AM, Ryan Martell wrote:
> > > On Oct 27, 2006, at 5:53 AM, Michael Niedermayer wrote:
> > >>> Once those are applied, I'll add the rtp modification patch.
> >
> > Here's the rtp modification patch...
>
> Could you please detail a little bit what this patch is supposed to
> do? I'd need that to have a commit message that actually means
> something.
>
> I also note that you haven't put any comment before function
> :rtsp_next_attr_and_value()
>
> Please fix this, and I'll apply your patch (yes, I'm being pedantic,
> but I figure it just makes the world a better place).
>
> Guillaume
> --
> With DADVSI (http://en.wikipedia.org/wiki/DADVSI), France finally has
> a lead on USA on selling out individuals right to corporations!
> Vive la France!
>
>
> ------------------------------
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
> End of ffmpeg-devel Digest, Vol 19, Issue 239
> *********************************************

More information about the ffmpeg-devel mailing list