gmane.comp.video.ffmpeg.devel

Re: Files crashing FFmpeg

Baptiste Coudurier — 2008-12-04T03:53:01

Here is my report for the few files I had the time to analyze, advices welcome.

Re: [PATCH] E-AC-3 spectral extension

Justin Ruggles — 2008-12-04T03:41:59

applied I have simplified things by committing a change that prevents decoding subsequent blocks in a frame after an invalid block is found. It was pointless to try anyways. This way it doesn't matter if invalid values are in the context since the decoder will always re-read them before using them in the next frame. This doesn't only apply to the first block. If channel_in_spx is false in a block, then first_spx_coords is reset to 1 for that channel. That way a bit can be saved if channel_in_spx is true in a subsequent block of the same frame. One of the other variables could be reused for this same purpose, but it would be much less clear.. (e.g. s->spx_coords[ch][0] = -1). I like it better with its own variable though. fixed. I went through this very carefully to make sure it was correct for only coupling, only spectral extension, or both. fixed. I didn't think it did, but after checking C99, I found I was wrong. I have changed it to MIN_INT24 and MAX_INT24. Aurel is right, sqrt(pow

Re: [PATCH] AAC: type puns for 16 bit floatingpointrounding

Uoti Urpala — 2008-12-04T03:30:17

Yes GCC does guarantee that it will work (all the accesses use unionvalue.field syntax with the same union). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel< at >mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Re: [PATCH] AAC: type puns for 16 bit floating pointrounding

Måns Rullgård — 2008-12-04T03:13:57

That test isn't portable. However, I think it's safe to assume IEEE754 floats. I doubt anyone will ever run FFmpeg on a VAX, and it's already broken on Cray since we assume two's complement signed integers. The ENABLE_* symbols are always defined. Use HAVE_ or CONFIG_ with #ifdef. Are this things safe under strict aliasing rules?

[PATCH] AAC: type puns for 16 bit floating pointrounding

Alex Converse — 2008-12-04T02:44:50

Hi, Attached is the remaing patch from the AAC Main series with the rounding functions rewritten as suggested to do arithmetic in the integer domain rather than the floating point domain. A configure check has been added as suggested but I'm not happy with it. Any input on this is greatly appreciated. Regards, Alex Converse _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel< at >mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Re: [PATCH] RDT/Realmedia patches #2

Ronald S. Bultje — 2008-12-04T02:43:04

Hi, On Tue, Dec 2, 2008 at 8:45 AM, Ronald S. Bultje gmail.com> wrote: Ping2. Ronald

Re: [PATCH]Allow pnm files

Michael Niedermayer — 2008-12-04T00:51:07

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

Re: [FFmpeg-cvslog] r15994 -trunk/libavcodec/armv4l/dsputil_vfp.S

Måns Rullgård — 2008-12-04T00:49:11

UAL != NEON, even if binutils seems to think so. I find gcc inline assembler more difficult to read and work with. Separating it also allows FFmpeg to be built with the ARM RVCT compiler, which gives faster code. I don't care about that. Nobody is stopping them using a modern binutils version. The version in that SDK is completely useless by the looks of it. I would say anything supported by binutils 2.19 is permissible. I can't think of any reason to keep using an older version.

Re: [PATCH] Fix flush_pkt warning in ffplay.c

Baptiste Coudurier — 2008-12-04T00:25:00

Hi, Stefano Sabatini wrote: Set destruct_packet then to free 'data'.

[PATCH] Fix flush_pkt warning in ffplay.c

Stefano Sabatini — 2008-12-04T00:12:06

Hi, this fixes the warning: ffplay.c: In function ‘main’: ffplay.c:2875: warning: assignment discards qualifiers from pointer target type Regards.

Re: [FFmpeg-cvslog] r15994 -trunk/libavcodec/armv4l/dsputil_vfp.S

Siarhei Siamashka — 2008-12-04T00:11:04

Still probably it is preferable to use legacy syntax in this file for a few reasons: 1. Better compatibility with older versions of binutils which do not know about NEON, but support VFP perfectly fine 2. ARMv5 Architecture Reference Manual uses legacy syntax (it is much more easily available for everyone than ARMv7 manual) 3. VFP11 VectorFloating-point Coprocessor Technical Reference Manual uses legacy syntax (it has VFP11 pipeline description which is good to have when doing optimizations) Also I'm curious about the rationale for converting these VFP functions from gcc inline assembly embedded in .c file into .S file? Having some short summary of rules/recommendations for doing ARM assembly optimizations in FFmpeg can help to avoid confusion when submitting patches. You must have some reasons, but just looking from the outside, the last changes may seem somewhat chaotic and not always obviously beneficial. Also we have iPhone users who sometimes try to compile FFmpeg and have problems: http://www.nabbl

[PATCH] libavfilter-soc: fix ffplay.c memleak

Stefano Sabatini — 2008-12-03T23:47:27

On date Sunday 2008-11-30 19:58:16 +0100, Stefano Sabatini encoded: The attached patch fixes the memleak (which I introduced fixing a crash) occurring when a raw video decoder is used. It does so redefining the function get_video_frame(), which won't immediately free the data in the packet (which could be used for example by the raw decoder to contain the frame data), but returns a shallow copy to the packet just extracted from the input packet queue. The packet is then freed just after the use of the corresponding frame. [...] Regards.

[PATCH] Fix AAC prediction in when used inconjunction with the CPE

Alex Converse — 2008-12-03T23:27:56

Hello, It appears that I neglected to test my AAC predicition implementation with streams that a CPE with a common window or intensity stereo. The attached patch fixes this. This should fix the am02 series of reference streams. Note: I chose to deviate from the textual description of the interaction between prediction and intensity stereo given in 14496-3:2005 for parity with the reference software. From 14496-3: For scalefactor bands coded in intensity stereo the corresponding predictors in the right channel are switched to "off" thus effectively overriding the status specified by the prediction_used mask. The update of these predictors is done by feeding the intensity stereo decoded spectral values of the right channel as the "last quantized value" xrec(n-1). These values result from the scaling process from left to right channel as described in the pseudo code. However in reference files adifdec.c and intensity.c, pre-intensity right channel values are sent into prediction. Regards, Alex Converse _

[PATCH]Allow pnm files

Carl Eugen Hoyos — 2008-12-04T01:06:54

Hi! I've heard rumours there are ppm files in the wild having pnm suffix. Please comment, Carl Eugen Index: libavformat/img2.c =================================================================== --- libavformat/img2.c(Revision 15995) +++ libavformat/img2.c(Arbeitskopie) < at >< at > -45,6 +45,7 < at >< at > { CODEC_ID_PNG , "png"}, { CODEC_ID_PNG , "mng"}, { CODEC_ID_PPM , "ppm"}, + { CODEC_ID_PPM , "pnm"}, { CODEC_ID_PGM , "pgm"}, { CODEC_ID_PGMYUV , "pgmyuv"}, { CODEC_ID_PBM , "pbm"}, _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel< at >mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Re: Files crashing FFmpeg

Jason Garrett-Glaser — 2008-12-03T21:06:03

Yes, though I haven't seen much from him for quite a while (he seems to be quite busy with Google). Dark Shikari

Re: [FFmpeg-cvslog] r15994 -trunk/libavcodec/armv4l/dsputil_vfp.S

Måns Rullgård — 2008-12-03T20:32:05

Yes, but that file only uses VFPv2 instructions. The machine code is the same. The instruction mnemonics match those used in the manual. To me that makes a difference.

Re: Files crashing FFmpeg

Måns Rullgård — 2008-12-03T20:28:10

Are you aware that skal is an FFmpeg committer?

Re: [FFmpeg-cvslog] r15994 -trunk/libavcodec/armv4l/dsputil_vfp.S

matthieu castet — 2008-12-03T20:27:22

Doesn't vfp also present on core without neon (armv5 for example) ? What's the benefit of using this syntax ? Matthieu

Re: Files crashing FFmpeg

compn — 2008-12-03T20:29:07

skal's word is good then. thanks for the info. hope google comes to its senses one day. -compn

Re: Files crashing FFmpeg

Måns Rullgård — 2008-12-03T19:52:59

Could they be persuaded to give us changes they've made if we promise not to tell anyone where they came from?

Re: [PATCH] Enhance ffmpeg.c:opt_default()

Stefano Sabatini — 2008-12-03T18:59:20

On date Sunday 2008-11-30 23:27:50 +0100, Michael Niedermayer encoded: The main problem with this is that as I see it, you need to map each index to an error string, *and* you can't provide specifics information (e.g. "unvalid value: x must be > min and < max"). What about something like: int av_set_string3(void *obj, const char *name, const char *val, const AVOption **o_out); ? We could use it like: const AVOption *o; if (av_set_string3(.., &o) < 0) { if (!o) fprintf(stderr, "Option not found\n"); else fprintf(stderr, "Option found but invalid value\n"); } logging the error message with av_log(), which is also consistent with the rest of libav*. Regards.