Re: [PATCH] QCELP decoder

Hi,
On Nov 30, 2008, at 7:50 AM, Michael Niedermayer wrote:

> On Sat, Nov 29, 2008 at 10:39:58AM -0800, Kenan Gillet wrote:
>> Hi all,
>>
>> sorry for the delay. I was waiting to resolve the parsing/decoding of
>> the bitrate/packet type issue.
>> Reynaldo and I agreed on IRC to live the parsing/decoding as it is  
>> for now.
>>
>> So here is round 13 of the qcelp decoder.
>> - QCELPContext was split so that it can be moved into qcelpdec.c and
>> only keep the unpacked data structure (QCELPFrame) in qcelpdata.h
>> - add doxy comments on QCELPFrame field
>> - simplify decode_gain_and_index for RATE_OCTAVE and IFQ
>> - rename qcelp_bits_per_rate into qcelp_unpacking_bitmaps_lengths
>> - use double in qcelp_lsp.c
>>
>> have a great day
>>
>> Kenan
>
>> Index: libavcodec/qcelp.h
>> ===================================================================
>> --- libavcodec/qcelp.h	(revision 0)
>> +++ libavcodec/qcelp.h	(revision 0)
>>  <at>  <at>  -0,0 +1,48  <at>  <at> 
>> +/*
>> + * QCELP decoder

Re: [PATCH] RDT/Realmedia patches #2

Hi,

On Sun, Nov 30, 2008 at 6:58 PM, Michael Niedermayer <michaelni <at> gmx.at> wrote:
> looks ok

Then the next patch makes an array of real-demuxer contexts per
PayloadContext. Like an RTSPStream and a RDTDemuxContext, a
PayloadContext (in RDT) represents a set of streams of identical
content, and can represent multiple AVStreams. Each should be
represented by its own real demuxer context, since things such as
audio codecs, bitrates and thus demuxer cache settings and state
differ per stream within a set.

Ronald

Index: ffmpeg-svn/libavformat/rdt.c
===================================================================
--- ffmpeg-svn.orig/libavformat/rdt.c	2008-11-30 20:51:48.000000000 -0500
+++ ffmpeg-svn/libavformat/rdt.c	2008-11-30 20:59:38.000000000 -0500
 <at>  <at>  -80,7 +80,7  <at>  <at> 
 }

 struct PayloadContext {
-    AVFormatContext *rmctx;
+    AVFormatContext *rmctx[MAX_STREAMS];
     uint8_t *mlti_data;
     unsigned int mlti_data_size;
     char buffer[RTP_MAX_PACKET_LENGTH + FF_INPUT_BUFFER_PADDING_SIZE];
 <at>  <at>  -173,7 +173,7  <at>  <at> 

Re: [PATCH] mingw memalign hack fix

David DeHaven wrote:
>>>>> +    diff = ((-(long)ptr - 1)&15) + 1;
>>>> intptr_t should be used instead of long.
>>> Agreed. I fixed av_malloc too...
>> still exploitable, besides your code cannot work at all
>> when "diff" changes the content of the buffer will not be where  
>> realign()
>> requires it to be.
>>
>> may i suggest that you first tell us which av_realloc() call is causig
>> problems, it likely should just be replaced by av_free() av_malloc()
> 
> 
> I understand your point about exploitability...
> 
> Geez, where do I start? The h.264 and ac3 decoders both use  
> av_realloc'd blocks frequently (either directly or through other  
> calls), those have been the two most annoying. I suppose I could track  
> down where all the reallocations are happening, might take some time  
> as we're preparing for a weekend of feasting on roasted bird :)

The only place I can see in the AC-3 decoder where unaligned memory
might possibly be used in SIMD code is in float_to_int16_interleaved().
 Although, if the documentation of avcodec_decode_audio2() is followed,
the output buffer needs to be aligned in order to guarantee proper
decoding.  Maybe ffmpeg doesn't adhere to that guideline...I haven't
checked.

-Justin

Re: [PATCH] RV40 Decoder - 2/3 - MC functions

On Sun, Nov 30, 2008 at 08:01:51PM +0100, Michael Niedermayer wrote:
> On Sun, Nov 30, 2008 at 08:07:15PM +0200, Kostya wrote:
> > On Sun, Nov 30, 2008 at 06:01:50PM +0100, Michael Niedermayer wrote:
> > [...]
> > > > 
> > > > That will work in these cases:
> > > > 1. I move RV40 luma MC to dsputil.c (not a good idea IMO)
> > > > 2. Make {put,avg}_pixels_xy2_c() non-static (not a good idea either)
> > > > 3. Initialize DSPContext inside function and call that function (ineffective)
> > > 
> > > what about
> > > func(abc) being in dsputil.c (where {put,avg}_pixels_xy2_c() is) and setting
> > > mc33 from there too, while leaving the others in rv40 specific files?
> > 
> > here
> 
> ugly but ok

applied

> as ive no idea ATM how to simplify it cleanly (what i mean with
> simplify here would be
> 1. merging it with h264 at source level
> 2. maybe trying some other system than having 1 function per each of the 16
>    cases (this also applies to h.264)

We have case 2 for H.264 and RV40 chroma MC currently.
IMO RV40 is not that important to slow down H.264 because of it.

> [...]

Re: seeking bug in theora codec libavcodec/vp3.c ?

On Sun, Nov 30, 2008 at 06:46:45PM -0500, David Conrad wrote:
> On Nov 30, 2008, at 5:06 PM, Chris Stones wrote:
> 
> > Where is seeking implemented, it does not seem to be codec  
> > specific.. i assume it is container specific ?
> 
> Yes, seeking is completely independent of codec in nearly all  
> containers. ogg is the only exception I'm aware of.

Mans has written up a little something about Ogg and timestamps:

http://hardwarebug.org/2008/11/17/ogg-timestamps-explored/

It's a good read.

Diego

Re: [PATCH] Improve documentation and error reporting for the -pass option

On date Sunday 2008-11-30 17:46:31 +0100, Michael Niedermayer encoded:
> On Sun, Nov 30, 2008 at 01:48:57PM +0100, Stefano Sabatini wrote:
> [...]
> > As for the ffmpeg.c patch is OK to commit that too?
> 
> i think so 

Both applied, thanks all for the review.
--

-- 
FFmpeg = Faboulous and Fundamental Merciful Philosofic Elastic Genius

Re: [PATCH] Fix compilation on OS/2

On Sat, Nov 29, 2008 at 10:55:44AM +0100, Diego Biurrun wrote:
> On Sat, Nov 29, 2008 at 10:54:42AM +0100, Diego Biurrun wrote:
> > On Fri, Nov 28, 2008 at 07:41:25PM -0800, Dave Yeo wrote:
> > > Hi, compilation on OS/2 currently dies here,
> > >
> > > gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I.  
> > > -I"/usr/src/FFmpeg" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -std=c99  
> > > -fomit-frame-pointer -march=athlon-tbird -g  
> > > -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization  
> > > -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual  
> > > -Wwrite-strings -Wtype-limits -O3 -fno-math-errno -fno-signed-zeros    -c 
> > > -o libavformat/udp.o libavformat/udp.c
> > > libavformat/udp.c: In function 'udp_read':
> > > libavformat/udp.c:459: error: storage size of 'tv' isn't known
> > > libavformat/udp.c:459: warning: unused variable 'tv'
> > > make: *** [libavformat/udp.o] Error 1
> > >
> > > Which is fixed by attached patch
> > 
> > Wrong mailing list, send this to ffmpeg-devel.
> 
> lol, sorry...

Anyway, the patch looks harmless enough, I will apply it by Wednesday if
nobody objects.

Diego

Re: seeking bug in theora codec libavcodec/vp3.c ?

On Sun, Nov 30, 2008 at 06:46:45PM -0500, David Conrad wrote:
> The correct place to fix this is in oggdec.c. I've been looking at  
> this but I haven't liked what I've come up with so far.

On March 19th I sent a patch concerning this to this list, unfortunately
it worked for no-one besides me and I did not test further yet.

Greetings,
Reimar Döffinger

Re: seeking bug in theora codec libavcodec/vp3.c ?

Please send it to me, I would love to take a look.

On 1 Dec 2008, 9:02 AM, "Reimar Döffinger" <
Reimar.Doeffinger <at> stud.uni-karlsruhe.de> wrote:

On Sun, Nov 30, 2008 at 06:46:45PM -0500, David Conrad wrote: 

> The correct place to fix this is in oggdec.c. I've been looking at > this 
but I haven't liked wh...
On March 19th I sent a patch concerning this to this list, unfortunately
it worked for no-one besides me and I did not test further yet.

Greetings,
Reimar Döffinger

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

Re: seeking bug in theora codec libavcodec/vp3.c ?

On Mon, Dec 01, 2008 at 10:02:09AM +0100, Reimar Döffinger wrote:
> On Sun, Nov 30, 2008 at 06:46:45PM -0500, David Conrad wrote:
> > The correct place to fix this is in oggdec.c. I've been looking at  
> > this but I haven't liked what I've come up with so far.
> 
> On March 19th I sent a patch concerning this to this list, unfortunately
> it worked for no-one besides me and I did not test further yet.

I mean this one specifically:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-March/043881.html