PATCH: FFT test infastructure

This first patch makes the reference transforms look the same, so they
can be folded into a table easily.

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

Re: PATCH: FFT test infastructure

On 7/31/07, Marc Hoffman <mmhoffm <at> gmail.com> wrote:
> This first patch makes the reference transforms look the same, so they
> can be folded into a table easily.

Sorry last had an interface bug.

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

Re: Understanding motion vectors from ff_print_debug_info()

On Sun, 29 Jul 2007, Pravin Bhat wrote:
> Loren Merritt wrote:
>>
>> Sub-sampling is where you delete some of the samples, leaving lower
>> resolution. That is not happening here.
>> Motion vectors are specified to fractional-sample precision, e.g a vector
>> of (0.5, 0) means translate the video by half a pixel (interpolating
>> between samples in the reference frame).
>> quarter_sample=1 means the precision is 0.25, and the alternative is 0.5.
>> The numbers in motion_val[] are fixed-point representations of those
>> fractional vectors.
>
> Great. That explains a lot!
> How does one obtain the precision of the motion vectors for a given
> codec. For example, AVFrame.motion_subsample_log2 is set (hopefully)
> based on the codec used to decode the frame. Is there a similar field
> that tells you the precision value used by the codec?

As you said, s->quarter_sample. But that's not in the public API, and it
can't even be derived from the codec name since some codecs make qpel
optional.

>>> What worries me is that the addition of that '1' is conditional and I
>>> don't understand when not to add that '1'. For example
>>> ff_print_debug_info() uses the following formula:
>>> (s->mb_width << mv_sample_log2) + (s->codec_id == CODEC_ID_H264 ? 0 : 1)
>>
>> otoh, ffh264 uses some optimizations that require the addresses of
>> individual motion vectors to be aligned, and it doesn't benefit from
>> the dummy values.

Re: dvi_adpcm (0x0011) audio conversion problems

>>======== At 2007-07-30, 21:01:10 you wrote: ========
>>
>>On Sun, Jul 29, 2007 at 12:44:36PM -0500, kent.elyue <at> gmail.com wrote:
>>>>  Thank you for the reply. I have uploaded the avi file to
>>>> the /MPlayer/incoming/ directory. The file name is T000A11C.AVI
>>>> Thanks for looking into this.
>>>
>>>fixed
>>>
>>>[...]
>>>-- 
>>>Michael     GnuPG fingerprint:
>>>9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>>
>>Wow. That was fast. Thank you. Please pardon my ignorance though. I
>>assume that "fixed" means that the source code has been updated, but
>>I'm not sure how I go about getting an updated windows executable to
>>use. 
>>
>>Thank you again,
>>-kent

>ask the person who built your ffmpeg executable to build you a new one.

>-compn

Thank you.
-kent

Re: Fixpoint FFT optimization, with MDCT and IMDCT wrappers for audio optimization

Hi

On Mon, Jul 30, 2007 at 10:33:16PM -0400, Marc Hoffman wrote:
[...]
> I will do it if it makes sense right now I don't see it being the most
> efficient. Lets get through the basic acceptance and when you and I
> decide to move forward we can talk about more efficient mechanisms for
> general machines.  (I'm not going anywhere so even if you accept this
> we can change it in the future).
> 
> The split radix is not the most efficient way to do things on the
> BlackFin machine.  It has to do with all the extra pointer stuff you
> need to maintain.  On other machines this is more efficient.  Not to
> go into this too much anyways I agreed earlier to implement this for
> us (ffmpeg-devel) and I will just not right now.  I really want to see
> if I/we can get one audio codec to work in fixEDpoint and achieve high
> quality I think this is what you/we really care about anyways.

iam not sure what extra pointers you are talking about
if you are thinking of a recursive implementation which gets 3 pointers
to the 3 input parts this is unacceptable the current cooley tukey FFT
also isnt written by passing pointers recursively around

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin

Re: PATCH: FFT test infastructure

Hi

On Tue, Jul 31, 2007 at 11:29:06PM -0400, Marc Hoffman wrote:
> On 7/31/07, Marc Hoffman <mmhoffm <at> gmail.com> wrote:
> > This first patch makes the reference transforms look the same, so they
> > can be folded into a table easily.
> 
> Sorry last had an interface bug.

looks ok

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

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

Re: [PATCH] mjpegb interlaced decoding fix

Hi

Michael Niedermayer wrote:
> Hi
> 
> On Sun, May 13, 2007 at 03:41:22PM +0200, Baptiste Coudurier wrote:
>> Hi
>>
>> For mjpegb_bottom.mov on mplayerhq/incoming
>>
>> It seems that decoder currently decodes twice the first field, since
>> it uses buf and not buf_ptr which is incremented for second field:
>>
>>  if (s->bottom_field && second_field_offs)
>>  {
>>       buf_ptr = buf + second_field_offs;
>>       second_field_offs = 0;
>>       goto read_header;
>>       }
>>
>> http://developer.apple.com/documentation/QuickTime/QTFF/QTFFChap3/chapter_4_section_2.html
>>
>> "Start Of Scan offset
>>     The offset, in bytes, from the start of the field data to the start
>> of scan data."
> 
> patch ok
> 

Applied.

[PATCH] fix mjpegb bottom field first

Hi

$subject. Same test is done for mjpeg.

Fixes MJPEGB.mov on mplayerhq.

--

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312

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

[PATCH] udp multicast address selection

Hi,

Situation:
-> looking at multicast stream on 226.255.0.5:3000 with ffmpeg or other program
-> start to look at another multicast stream with ffmpeg (226.255.0.10:3000)

Problem:
ffmpeg takes all data from port 3000 and does not filter on the
multicast address.

This patch should fix this problem.

Gr,
Thijs

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

Re: [PATCH] Move H.264 DSP functions from dsputil.c to h264dsp.c

Hi

On Mon, Jul 30, 2007 at 03:53:52PM +0200, Panagiotis Issaris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Sat, Jul 28, 2007 at 08:35:32PM +0200, Panagiotis Issaris wrote:
> >> Hi
> >>
> >> Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> On Sat, Jul 28, 2007 at 12:40:08PM +0200, Panagiotis Issaris wrote:
> >>>   
> >>>> Hi,
> >>>>
> >>>> Panagiotis Issaris wrote:
> >>>>     
> >>>>>> Michael Niedermayer wrote:
> >>>>>>   
> >>>>>>     
> >>>>>>         
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> On Fri, Jul 27, 2007 at 06:04:18PM +0200, Panagiotis Issaris wrote:
> >>>>>>> [...]    
> >>>>>>>