Re: [FFmpeg-soc] [PATCH 1/5] Use av_clip_int16() in FIX15(). Output will differ now in some cases, but the AC3 regtest is unchanged.
On Wed, Nov 17, 2010 at 02:58:40AM +, Ronald S. Bultje wrote: > Hi, > > On Wed, Nov 17, 2010 at 2:37 AM, Justin Ruggles > wrote: > > +/** convert float in range [-1..1] to int16_t in range [-32768..32767] */ > > +#define FIX15(a) ((int16_t)av_clip_int16((int)(a * (float)(1 << 15 > > -32768, so you might want to update the comment. Huh? He did. > Also, is the cast at > the start needed (int16_t)? Shouldn't be, and removing it might well result in faster code. However, in the description of this patch for example I missed an explanation of why, I guess here it is for speed reasons. Could you please look at the commit messages when committing and make sure they explain why you are making changes (and in this case also why output might change and why you think it does not matter)? Just saying you use av_clip_int16 is a bit pointless, that is quite obvious from the patch ;-) ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] G.723.1 Encoder: Compute adaptive codebook contribution, obtain residual
On Sat, Aug 21, 2010 at 08:29:12AM -0400, Ronald S. Bultje wrote:
> >> +if (pitch_lag == PITCH_MIN)
> >> +pitch_lag++;
> >> +else
> >> +pitch_lag = FFMIN(pitch_lag, PITCH_MAX - 5);
Btw. Michael lately request this kind of thing to be written
as
if () {
...
} else
...
I.e. using {} where it does not use up extra code lines.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc] libavsequencer [PATCH] Initial implementation of main AVSequencer public API header file
On Sat, Jul 10, 2010 at 07:49:31PM +0200, Sebastian Vater wrote: > > Particularly > > uint16_t volume_left; > > uint8_t volume; > > Changing volume_left & volume_right to 16.16 fixed point would be a good > idea, though. > > Normal single channel volume is from 0-255 since that is the volume > range in the trackers. You'll have to know it in the end, but I think having different representations and ranges for the volume is going to be very confusing for most people trying to understand the code. Also converting 0-255 range to 16.16 should just be something like (v << 8) + (v >> 7) ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc] libavsequencer [PATCH] Initial implementation of main AVSequencer public API header file
On Sat, Jul 10, 2010 at 07:24:56PM +0200, Vitor Sessak wrote: > On 07/10/2010 07:00 PM, Justin Ruggles wrote: > > > >Sebastian Vater wrote: > > > >>+/** Default volume boost level. 65536 equals to 100% which > >>+ means no boost. */ > >>+uint32_t volume_boost; > >>[...] > >>+/** The current volume boost level. 65536 equals to 100% which > >>+ means no boost. */ > >>+uint32_t volume_boost; > >>+ > >>+/** Left channel volume level. 256 is full volume. */ > >>+uint16_t volume_left; > >>+ > >>+/** Right channel volume level. 256 is full volume. */ > >>+uint16_t volume_right; > >>[...] > >>+/** Current volume for this channel which ranges from 0 (muted) > >>+ to 255 (full volume). */ > >>+uint8_t volume; > >>+ > >>+/** Current stereo panning level for this channel (where 0-127 > >>+ indicate left stereo channel panning, -128 is central stereo > >>+ panning and -127 to -1 indicate right stereo panning). */ > >>+int8_t panning; > > > >Why all these arbitrary integer scales? Why not floating point or > >AVRational instead? > > I don't think floating point is a good idea, let's try to keep > everything bit-identical across archs if possible. You could still go with something more consistent, like 16.16 fixed-point or AVRational. Particularly uint16_t volume_left; uint8_t volume; ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5821 - libavfilter/vf_overlay.c
On Sun, Jun 06, 2010 at 01:19:58AM +0200, Stefano Sabatini wrote: > > It works fine here now. > > Anyway the problem is another one, try with a MPEG video based codec > and you should see. What I'm observing is that the overlay is applied > to the source filter *before* the motion compensation, the > (weird|funny) result is that the logo tends to stain the image > sort-alike ink as the video scrolls. Actually that means that the overlay was applied to the reference. Usually that means someone didn't respect that they are not allowed to modify some buffer and should have made a copy instead. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] libavfilter audio work - qualification task
On Mon, Apr 05, 2010 at 08:11:26PM +0200, Stefano Sabatini wrote: > On date Monday 2010-04-05 19:32:59 +0200, Reimar Döffinger encoded: > > On Mon, Apr 05, 2010 at 07:11:50PM +0200, Stefano Sabatini wrote: > > > > For the deinterlace filter, do we want just a vf_* wrapper for > > > > imgconvert functions or should the code be ported to the > > > > vf_deinterlace filter? > > > > > > It should be ported, lavfi should not depend on lavc (that is it > > > should be usable without any libavcodec installed). > > > > Uh, any of the advanced deinterlace filters and some more of MPlayer's > > filters depend on lavc. > > I don't think Michael will accept if you propose to duplicate half the > > snow encoder in lavfi. > > So except for basic functionality I don't see that much point in avoid > > a dependency on lavc if it duplicates more than just a few lines of > > code. > > Yes of course some filter may depend on lavc. As for what regards the > deinterlacing implemented in imgconvert.c it looked to me simple > enough to not require to add a dependancy just for that, also I think > that feature (as well as cropping/padding in lavc) is going to be > deprecated. Sure, I don't object to your "conclusion", just the reasoning you gave seemed not quite right to me, the above seems like a better one to me. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] libavfilter audio work - qualification task
On Mon, Apr 05, 2010 at 07:11:50PM +0200, Stefano Sabatini wrote: > > For the deinterlace filter, do we want just a vf_* wrapper for > > imgconvert functions or should the code be ported to the > > vf_deinterlace filter? > > It should be ported, lavfi should not depend on lavc (that is it > should be usable without any libavcodec installed). Uh, any of the advanced deinterlace filters and some more of MPlayer's filters depend on lavc. I don't think Michael will accept if you propose to duplicate half the snow encoder in lavfi. So except for basic functionality I don't see that much point in avoid a dependency on lavc if it duplicates more than just a few lines of code. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [PATCH] Add fade filter to libavfilter
On Wed, Mar 31, 2010 at 05:25:38PM -0400, Brandon Mintern wrote:
> On Wed, Mar 31, 2010 at 5:19 PM, Michael Niedermayer wrote:
> > On Wed, Mar 31, 2010 at 01:23:29AM -0400, Brandon Mintern wrote:
> >> On Wed, Mar 31, 2010 at 12:43 AM, Brandon Mintern
> >> wrote:
> >> > I am happy to present my first-ever open source code contribution, a
> >> > "fade" filter for libavfilter!
> >> [snip]
> > [...]
> >
> >> +static void draw_slice(AVFilterLink *link, int y, int h, int slice_dir)
> >> +{
> >> + FadeContext *fade = link->dst->priv;
> >> + AVFilterPicRef *in = link->cur_pic;
> >> + AVFilterPicRef *out = link->dst->outputs[0]->outpic;
> >> + uint8_t *inrow, *outrow;
> >> + int i, j, plane;
> >> +
> >> + /* luma plane */
> >> + inrow = in-> data[0] + y * in-> linesize[0];
> >> + outrow = out->data[0] + y * out->linesize[0];
> >> + for(i = 0; i < h; i ++) {
> >> + for(j = 0; j < link->w; j ++)
> >> + outrow[j] = (uint8_t) ((float) inrow[j] * fade->fade_factor +
> >> 0.5);
> >
> > please avoid floats, it makes regression testing unneccesarily hard
> > Its probably ok to use floats/doubles in init, but it feels wrong
> > at the pixel level
> >
> > anyway, real review and approval left to vitor or bobby
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Thanks for the feedback. The line you indicated is actually just an
> explicit cast that I can remove if you'd like. However, the
> floating-point arithmetic is being used to calculate the new pixel
> values and round them to the nearest uint8_t. I can instead stick to
> integer arithmetic, but then the numbers will be truncated instead of
> rounded. Do you have another suggestion? Is AVRational (I think that's
> what it called) something I should be using instead?
Fixed-point arithmetic, i.e. the least significant bit does not mean
1 but e.g. 1/16.
In this case something like
int_fade_factor = (int)(fade_factor * (1 << 16));
outrow = (inrow * int_fade_factor + (1 << 15)) >> 16;
Of course that's just to give you an idea, you have to make sure
there won't be any integer overflows etc.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] soc qualification
On Sat, Mar 27, 2010 at 10:24:26AM -0700, Sumit Sarkar wrote: > >> > iii) AACS implementation > >> > >> Talk to the respective mentors (Kostya & Reimar) on IRC or via email. > > > > I am unfortunately almost never on IRC currently. > > The problem with the AACS task is that it was originally meant to cover > > HD-DVD and BluRay, however I feel we might have trouble getting HD-DVD > > samples. > > For BluRay the infrastructure to pass the key to the proper layer (stream > > layer IMO here) is not even there. > > So if you want to do this task I would suggest coming up with a design > > of how the decryption would fit into FFmpeg and a minimal "demo" > > implementation as far as you can get as a qualification task. > > If others have comments that would be welcome, because I haven't thought > > about this proposed task since over a year and am no longer 100% sure > > about it anymore. > > Thanks for the response, I am a newbie and would feel scared on a > project where the expert > is not sure of the project. I have started looking at the code only. Well, I am not an expert for AACS, not at all. However the reason why I am unsure is that BluRay only, basic AACS alone seems too little work for a whole SoC project - implementing CSS is one of the suggestions around that. But given all that, should we maybe move AACS to tier 2? > I would like to do a video project (not an audio project) and > preferably not a Microsoft standard one. Well, AACS does not really have much to do with video :-). There is mostly encoders left in that area, which I considered always a bit harder than decoders. > Please advise which project would be a good fit and also the > corresponding qualification task. I haven't discussed it with the other developers and honestly it depends most of all on what interests you, but maybe finishing the Dirac decoder and encoder as project with getting the existing Dirac decoder integrated? Note that this depends on finding someone willing to mentor that task, I don't know Dirac. Luca (B)? Reimar ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] soc qualification
On Sat, Mar 27, 2010 at 12:29:39PM -0400, Ronald S. Bultje wrote: > On Sat, Mar 27, 2010 at 12:26 PM, Sumit Sarkar wrote: > > iii) AACS implementation > > Talk to the respective mentors (Kostya & Reimar) on IRC or via email. I am unfortunately almost never on IRC currently. The problem with the AACS task is that it was originally meant to cover HD-DVD and BluRay, however I feel we might have trouble getting HD-DVD samples. For BluRay the infrastructure to pass the key to the proper layer (stream layer IMO here) is not even there. So if you want to do this task I would suggest coming up with a design of how the decryption would fit into FFmpeg and a minimal "demo" implementation as far as you can get as a qualification task. If others have comments that would be welcome, because I haven't thought about this proposed task since over a year and am no longer 100% sure about it anymore. Reimar ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5551 - amr/amrnbdec.c
On Fri, Jan 01, 2010 at 08:50:23PM +0100, vitor wrote: > Author: vitor > Date: Fri Jan 1 20:50:23 2010 > New Revision: 5551 > > Log: > Instead of divising by a constant, multiply by its inverse. It's "dividing", not "divising" (which is confusing since it is so close to "devising"). ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha
On Mon, Dec 07, 2009 at 09:33:42PM +0100, Michael Niedermayer wrote: > On Mon, Dec 07, 2009 at 03:59:12PM +0100, Artur Bodera wrote: > > On Mon, Dec 7, 2009 at 2:08 PM, Michael Niedermayer wrote: > > > > > The issue is just that with arbitrary graphs its not so > > > easy to negotiate the format in a way that is scaleable and doesnt break > > > down to O(2^n) time > > > > > > > Just a friendly, novice, out-of-the-box suggestion from my side - how does > > DirectX / DirectShow handle that? > > I dont know, but if someone knows, iam interrested in that as well I don't really know for sure, but I think DirectShow does not have any scale/colourspace conversion filters, at least not by default, and a lot of codecs implement internal conversions due to this. Which makes me suspect they haven't actually solved it. And I guess a few things are done via filter priorities in DirectShow, with a good chance of breaking if they are set wrong - at least in the Win98 times or so. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5188 - in concat/libavformat: pls.c xspf.c
On Thu, Aug 20, 2009 at 11:57:33AM +0200, gkovacs wrote: > Author: gkovacs > Date: Thu Aug 20 11:57:33 2009 > New Revision: 5188 > > Log: > switch back from unrolled string comparison loop to strncmp > > Modified: >concat/libavformat/pls.c >concat/libavformat/xspf.c > > Modified: concat/libavformat/pls.c > == > --- concat/libavformat/pls.c Thu Aug 20 11:23:55 2009(r5187) > +++ concat/libavformat/pls.c Thu Aug 20 11:57:33 2009(r5188) > @@ -60,7 +60,7 @@ static int pls_list_files(ByteIOContext > s[2] = s[3]; > s[3] = s[4]; > s[4] = c; > -if (s[0] == t[0] && s[1] == t[1] && s[2] == t[2] && s[3] == t[3] > && s[4] == t[4]) > +if (!strncmp(s, t, 5)) Obvious question: why strncmp? It is probably slower than memcmp and in difference to strcmp not any simpler... ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5186 - concat/libavformat/playlist.c
On Thu, Aug 20, 2009 at 11:18:37AM +0200, gkovacs wrote:
> Modified: concat/libavformat/playlist.c
> ==
> --- concat/libavformat/playlist.c Thu Aug 20 10:56:59 2009(r5185)
> +++ concat/libavformat/playlist.c Thu Aug 20 11:18:37 2009(r5186)
> @@ -111,6 +111,10 @@ void ff_playlist_split_encodedstring(con
> if (c == sep) {
> sepidx[len] = ts-s;
> sepidx = av_fast_realloc(sepidx, &buflen, ++len);
> +if (!sepidx) {
> +av_log(NULL, AV_LOG_ERROR, "av_fast_realloc error in
> ff_playlist_split_encodedstring\n");
> +continue;
Note that this leaks memory, the original pointer is still valid.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5184 - concat/libavformat/xspf.c
On Thu, Aug 20, 2009 at 10:56:55AM +0200, gkovacs wrote:
> +char t[] = " +char s[5] = {0};
> +char v[] = " +char u[9] = {0};
Bad names. And why not t and v "static const" ?
> +if (!fxml) {
> +s[0] = s[1];
> +s[1] = s[2];
> +s[2] = s[3];
> +s[3] = s[4];
> +s[4] = c;
> +if (s[0] == t[0] && s[1] == t[1] && s[2] == t[2] && s[3] == t[3]
> && s[4] == t[4])
> +fxml = 1;
> +}
> +if (!ftag) {
> +u[0] = u[1];
> +u[1] = u[2];
> +u[2] = u[3];
> +u[3] = u[4];
> +u[4] = u[5];
> +u[5] = u[6];
> +u[6] = u[7];
> +u[7] = u[8];
> +u[8] = c;
> +if (u[0] == v[0] && u[1] == v[1] && u[2] == v[2] && u[3] == v[3]
> && u[4] == v[4] &&
> +u[5] == v[5] && u[6] == v[6] && u[7] == v[7] && u[8] == v[8])
> +ftag = 1;
memmove and memcmp? strcmp would be possible, too, if you pad the s/u
arrays with a closing 0.
Or if you go for speed use a uint64_t
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5180 - als/alsdec.c
On Wed, Aug 19, 2009 at 11:14:25PM +0200, thilo.borgmann wrote: > Author: thilo.borgmann > Date: Wed Aug 19 23:14:25 2009 > New Revision: 5180 > > Log: > Zero raw_buffer during allocation. The most useful part of the commit message, the "why" is missing... ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5150 - als/alsdec.c
On Sun, Aug 16, 2009 at 02:55:17AM +0200, thilo.borgmann wrote: > Author: thilo.borgmann > Date: Sun Aug 16 02:55:16 2009 > New Revision: 5150 > > Log: > Allocate coefficient buffers dynamically. Hm? I think both before and after are dynamic allocations, you just allocate it on the heap instead of the stack... ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5127 - als/alsdec.c
On Sat, Aug 15, 2009 at 03:46:57PM +0200, Thilo Borgmann wrote: > > >> smp is the loop counter and can therefore not be put outside the loop. > >> For the convert assignment, this could have been true but since there > >> have to be two if's (if smp==progressive and if smp < progressive), it > >> has shown to be even slower than the two loop version. > > > > Not quite, you could move the convert = 1 and only that outside the > > loop. > > Maybe not really worth it though, it might use up one more register in > > the loop... > > I don't have an explanation, but that way benchmarked worse. It obfuscates things a bit for the compiler and probably it misses some optimization opportunities. You might see if this is better, but the variable "convert" should probably be named differently then convert = smp < progressive; max = convert ? smp : progressive; ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5127 - als/alsdec.c
On Sat, Aug 15, 2009 at 03:01:22PM +0200, Thilo Borgmann wrote:
>
> >> +unsigned int max, convert;
> >> ...
> >> +if (smp < progressive) {
> >> +max = smp;
> >> +convert = 1;
> >> +} else {
> >> +max = progressive;
> >> +convert = 0;
> >> +}
>
> >
> > Hmm...
> > tried
> > max = smp;
> > convert = 1;
> > outside the loop and inside
> > if (smp == progessive) {
> > max = progressive;
> > convert = 0;
> > }
> > ?
>
> smp is the loop counter and can therefore not be put outside the loop.
> For the convert assignment, this could have been true but since there
> have to be two if's (if smp==progressive and if smp < progressive), it
> has shown to be even slower than the two loop version.
Not quite, you could move the convert = 1 and only that outside the
loop.
Maybe not really worth it though, it might use up one more register in
the loop...
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5127 - als/alsdec.c
On Sat, Aug 15, 2009 at 02:36:35PM +0200, thilo.borgmann wrote:
> Author: thilo.borgmann
> Date: Sat Aug 15 14:36:35 2009
> New Revision: 5127
>
> Log:
> Merge two loops to reduce code duplication. Benchmark shows up to 2%
> less dezicyles for a single loop.
>
> Modified:
>als/alsdec.c
>
> Modified: als/alsdec.c
> ==
> --- als/alsdec.c Sat Aug 15 14:04:02 2009(r5126)
> +++ als/alsdec.c Sat Aug 15 14:36:35 2009(r5127)
> @@ -642,23 +642,25 @@ static int read_block_data(ALSDecContext
> if (ra_block) {
> unsigned int progressive = FFMIN(block_length, opt_order);
>
> -for (smp = 0; smp < progressive; smp++) {
> -y = 1 << 19;
> -
> -for (sb = 0; sb < smp; sb++)
> -y += lpc_cof[sb] * raw_samples[smp - (sb + 1)];
> +for (smp = 0; smp < block_length; smp++) {
> +unsigned int max, convert;
>
> -raw_samples[smp] -= y >> 20;
> -parcor_to_lpc(smp, quant_cof, lpc_cof);
> -}
> +if (smp < progressive) {
> +max = smp;
> +convert = 1;
> +} else {
> +max = progressive;
> +convert = 0;
> +}
>
> -for (; smp < block_length; smp++) {
> y = 1 << 19;
>
> -for (sb = 0; sb < progressive; sb++)
> +for (sb = 0; sb < max; sb++)
> y += lpc_cof[sb] * raw_samples[smp - (sb + 1)];
>
> raw_samples[smp] -= y >> 20;
> +if (convert)
> +parcor_to_lpc(smp, quant_cof, lpc_cof);
> }
Hmm...
tried
max = smp;
convert = 1;
outside the loop and inside
if (smp == progessive) {
max = progressive;
convert = 0;
}
?
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5121 - als/alsdec.c
On Sat, Aug 15, 2009 at 01:33:24PM +0200, thilo.borgmann wrote: > Author: thilo.borgmann > Date: Sat Aug 15 13:33:24 2009 > New Revision: 5121 > > Log: > Elaborate comment about aborting in case of a damaged stream. > > Modified: >als/alsdec.c > > Modified: als/alsdec.c > == > --- als/alsdec.c Sat Aug 15 13:28:10 2009(r5120) > +++ als/alsdec.c Sat Aug 15 13:33:24 2009(r5121) > @@ -518,7 +518,8 @@ static int read_block_data(ALSDecContext > else > sub_blocks = get_bits1(gb) ? 4 : 1; > > -// Do not continue in case of a damaged stream > +// do not continue in case of a damaged stream since > +// block_length must be evenly divisible by sub_blocks > if (block_length % sub_blocks) > return -1; Wouldn't it be nicer to print a warning and just decrease block_length to the next smaller multiple of sub_blocks? Depending on how the format is this might improve decoding of damaged streams (e.g. last block in an incomplete file). ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5119 - als/alsdec.c
On Sat, Aug 15, 2009 at 01:27:24PM +0200, thilo.borgmann wrote:
> Author: thilo.borgmann
> Date: Sat Aug 15 13:27:23 2009
> New Revision: 5119
>
> Log:
> Remove unnecessary braces.
>
> Modified:
>als/alsdec.c
>
> Modified: als/alsdec.c
> ==
> --- als/alsdec.c Sat Aug 15 13:25:03 2009(r5118)
> +++ als/alsdec.c Sat Aug 15 13:27:23 2009(r5119)
> @@ -486,11 +486,10 @@ static int read_block_data(ALSDecContext
> if (const_block) {
> unsigned int const_val_bits;
>
> -if (sconf->resolution == 2 || sconf->floating) {
> +if (sconf->resolution == 2 || sconf->floating)
> const_val_bits = 24;
> -} else {
> +else
> const_val_bits = avctx->bits_per_raw_sample;
> -}
Note that the {} of the if part do not add an extra line of code, so
e.g. Michael prefers to keep them.
Also this would IMO be simpler as
const_val_bits = sconf->resolution == 2 || sconf->floating ? 24 :
avctx->bits_per_raw_sample;
(mostly because it is obvious that in both paths const_val_bits is set.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5067 - spdif/spdif.c
On Thu, Aug 13, 2009 at 10:51:07PM +0200, Bartlomiej Wolowiec wrote:
> > > @@ -55,6 +57,10 @@ typedef struct IEC958Context {
> > > int pkt_size; ///< Length code (number of bits or
> > > bytes - according to data_type) int pkt_offset; ///<
> > > Repetition period of a data burst in bytes int (*header_info)
> > > (AVFormatContext *s, AVPacket *pkt);
> > > +#if !HAVE_BIGENDIAN
> > > +uint8_t *buffer;
> > > +int buffer_size;
> > > +#endif
> >
> > I'd be in favour of leaving this in unconditionally, even if it is
> > strictly speaking useless bloat on big endian.
>
> hmm.. so, what are the pros of leaving this unconditionally?
You don't need those #ifs, which in this case make out about half of the
code...
> >[...]
> > > @@ -237,13 +256,13 @@ static int spdif_write_packet(struct AVF
> > > #if HAVE_BIGENDIAN
> > > put_buffer(s->pb, pkt->data, pkt->size & ~1);
> > > #else
> > > -{
> > > -//XXX swab... ?
> > > -uint16_t *data = (uint16_t *) pkt->data;
> > > -int i;
> > > -for (i = 0; i < pkt->size >> 1; i++)
> > > -put_be16(s->pb, data[i]);
> > > +if (ctx->buffer_size < pkt->size) {
> > > +av_fast_malloc(&ctx->buffer, &ctx->buffer_size, pkt->size +
> > > FF_INPUT_BUFFER_PADDING_SIZE); +if (!ctx->buffer)
> > > +return AVERROR(ENOMEM);
> > > }
> > > +swab(pkt->data, ctx->buffer, pkt->size & ~1);
> > > +put_buffer(s->pb, ctx->buffer, pkt->size & ~1);
> > > #endif
> >
> > Btw. using
> > if (HAVE_BIGENDIAN) {
> > ...
> > } else {
> > }
> >
> > will ensure that compilation of both paths is checked on all builds, and
> > unless someone compiles with -O0 results in the same code.
>
> so why in other places in FFmpeg there are #if ? any pros of this ?
There are both. In theory, the if (...) variant can cause issues e.g.
when compiling with -O0 and shouldn't be used when not even the headers
and thus function prototypes are available.
Also some old code might use #if(def) where an if () might have been
more appropriate.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5076 - jpeg2000/j2kdec.c
On Thu, Aug 13, 2009 at 04:21:35PM +0200, jai_menon wrote:
> +if (seg_symbols) {
> +int val;
> +val = ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + MQC_CX_UNI);
> +val = (val << 1) + ff_mqc_decode(&t1->mqc, t1->mqc.cx_states +
> MQC_CX_UNI);
> +val = (val << 1) + ff_mqc_decode(&t1->mqc, t1->mqc.cx_states +
> MQC_CX_UNI);
> +val = (val << 1) + ff_mqc_decode(&t1->mqc, t1->mqc.cx_states +
> MQC_CX_UNI);
Hm.
int val = 0;
for (i = 0; i < 4; i++)
val = (val << 1) + ff_mqc_decode(&t1->mqc, t1->mqc.cx_states + MQC_CX_UNI);
?
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r5067 - spdif/spdif.c
On Thu, Aug 13, 2009 at 11:10:21AM +0200, bwolowiec wrote:
> Modified: spdif/spdif.c
> ==
> --- spdif/spdif.c Thu Aug 13 10:28:04 2009(r5066)
> +++ spdif/spdif.c Thu Aug 13 11:10:21 2009(r5067)
> @@ -29,6 +29,8 @@
> #include "libavcodec/ac3.h"
> #include "libavcodec/dca.h"
> #include "libavcodec/aac_parser.h"
> +#define __USE_XOPEN
> +#include
That needs a feature test, but I think it would be better to add a
DSPUtil function, similar to bswap_buf
> @@ -55,6 +57,10 @@ typedef struct IEC958Context {
> int pkt_size; ///< Length code (number of bits or bytes -
> according to data_type)
> int pkt_offset; ///< Repetition period of a data burst in
> bytes
> int (*header_info) (AVFormatContext *s, AVPacket *pkt);
> +#if !HAVE_BIGENDIAN
> +uint8_t *buffer;
> +int buffer_size;
> +#endif
I'd be in favour of leaving this in unconditionally, even if it is
strictly speaking useless bloat on big endian.
> @@ -186,6 +192,10 @@ static int spdif_header_aac(AVFormatCont
> static int spdif_write_header(AVFormatContext *s)
> {
> IEC958Context *ctx = s->priv_data;
> +#if !HAVE_BIGENDIAN
> +ctx->buffer_size = 0;
> +ctx->buffer = NULL;
> +#endif
pointless, the context is initialized to 0.
> +#if !HAVE_BIGENDIAN
> +IEC958Context *ctx = s->priv_data;
> +av_free(ctx->buffer);
> +#endif
av_freep
And in principle you can do that without #if, too.
> @@ -237,13 +256,13 @@ static int spdif_write_packet(struct AVF
> #if HAVE_BIGENDIAN
> put_buffer(s->pb, pkt->data, pkt->size & ~1);
> #else
> -{
> -//XXX swab... ?
> -uint16_t *data = (uint16_t *) pkt->data;
> -int i;
> -for (i = 0; i < pkt->size >> 1; i++)
> -put_be16(s->pb, data[i]);
> +if (ctx->buffer_size < pkt->size) {
> +av_fast_malloc(&ctx->buffer, &ctx->buffer_size, pkt->size +
> FF_INPUT_BUFFER_PADDING_SIZE);
> +if (!ctx->buffer)
> +return AVERROR(ENOMEM);
> }
> +swab(pkt->data, ctx->buffer, pkt->size & ~1);
> +put_buffer(s->pb, ctx->buffer, pkt->size & ~1);
> #endif
Btw. using
if (HAVE_BIGENDIAN) {
...
} else {
}
will ensure that compilation of both paths is checked on all builds, and
unless someone compiles with -O0 results in the same code.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Instability in AMR-NB
On Tue, Aug 04, 2009 at 05:22:17PM +0100, Colin McQuillan wrote: > But since the decoder is not bit-exact, how can I know that this has > solved the problem? I'd need a bound on the size of the error between > this decoder and the reference. Well... an obvious solution is to make the decoder bit-exact. Or otherwise I'd expect that the encoder is responsible for making sure the decoding error can not become too big in case of not-bit-exact decoders. Of course you have to keep the decoder to the specification and use the specified precision where one is specified. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Instability in AMR-NB
On Tue, Aug 04, 2009 at 01:32:00PM +0100, Colin McQuillan wrote: > I could set the excitation vector to zero whenever it is close it > zero, but this could be brittle. Should I just leave this as a bug? Is there any hint as to a recommended precision for the excitation vector? At the very least, treting denormals as 0 should be quite risk-free I guess... ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r4346 - in wmapro: wma3.h wma3dec.c
On Sun, May 31, 2009 at 10:32:55AM +0200, Sascha Sommer wrote:
> Hi,
>
> On Samstag, 30. Mai 2009, Benjamin Larsson wrote:
> > faust3 wrote:
> > > Author: faust3
> > > Date: Sat May 30 22:36:24 2009
> > > New Revision: 4346
> > >
> > > Log:
> > > use a sine table when calculating the decorrelation matrix
> > >
> > > Modified:
> > >wmapro/wma3.h
> > >wmapro/wma3dec.c
> > >
> > > Modified: wmapro/wma3.h
> > > =
> > >= --- wmapro/wma3.hSat May 30 21:22:28 2009(r4345)
> > > +++ wmapro/wma3.h Sat May 30 22:36:24 2009(r4346)
> > > @@ -93,6 +93,7 @@ typedef struct WMA3DecodeContext {
> > > MDCTContext mdct_ctx[BLOCK_NB_SIZES]; ///< MDCT context
> > > per block size DECLARE_ALIGNED_16(float, tmp[BLOCK_MAX_SIZE]); ///< imdct
> > > output buffer float* windows[BLOCK_NB_SIZES]; ///< window
> > > per block size +floatsin64[33]; ///<
> > > sinus table for decorrelation
> >
> > Maybe add a static table instead? Then 2 instances would share the table.
> >
>
> Is this a needed requirement? After reading the discussion from r18681, I'm
> not sure.
Since it's only slightly above 100 bytes per context IMO no. It might
still be a bit nicer though for users who decode many streams at once.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r3740 - mlp/mlpenc.c
On Tue, Sep 09, 2008 at 03:58:05AM +0200, ramiro wrote: > Author: ramiro > Date: Tue Sep 9 03:58:05 2008 > New Revision: 3740 > > Log: > Split a put_bits(32) into two put_bits(16). > > Modified: >mlp/mlpenc.c > > Modified: mlp/mlpenc.c > == > --- mlp/mlpenc.c (original) > +++ mlp/mlpenc.c Tue Sep 9 03:58:05 2008 > @@ -779,7 +779,8 @@ static void write_major_sync(MLPEncodeCo > * from samples that are stereo and have > * 44100Hz. */ > put_bits(&pb, 8, ctx->mlp_channels2); > -put_bits(&pb, 32, 0x8080); /* These values seem */ > +put_bits(&pb, 16, 0x); > +put_bits(&pb, 16, 0x8080); /* These values seem */ > put_bits(&pb, 8, 0x00 ); /* to be constants. */ The comments make much less sense like this, they really should be aligned. And do you know what the first 16 bits are? I find it quite confusing. Maybe some comment above all these saying "// the next 40 bits seem to be constant, their meaning is unknown" might be better. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Attention: FFMPEG bkeak License Agreement. You break the law
On Mon, Sep 08, 2008 at 08:12:59PM +0200, Diego Biurrun wrote: > On Mon, Sep 08, 2008 at 08:50:34AM +0400, Sergey Kochetkov wrote: > > Hello! > > Who the heck are you? Um, I think it is not nice not to include the person who wrote this in the "To:" but include [EMAIL PROTECTED] I somewhat have the feeling they have nothing at all to do with this, and while I am sure whoever is CEO has enough anti-SPAM measures, I think this is not too kind. Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] MXF muxer version 0.0.4
Hello,
On Fri, Aug 29, 2008 at 09:47:24AM -0700, Baptiste Coudurier wrote:
> > Index: libavformat/mxfenc.c
> > ===
> > --- libavformat/mxfenc.c(revision 15018)
> > +++ libavformat/mxfenc.c(working copy)
> > @@ -32,7 +32,10 @@
> > //#define DEBUG
> >
> > #include "mxf.h"
> > +#include
> >
> > +typedef wchar_t MXFUTF16String;
> > +
>
> You don't need that, you need to transform char * to utf-16.
I agree that these are not necessary, but the transform necessary
is from UTF-8 to UTF-16. But since (AFAICT) we do not have any
user-supplied strings but only hard-coded, pure-ASCII ones
that just means that you need to need a 0 byte before each character.
Also this:
> +static void mxf_write_utf16string(ByteIOContext *pb, const MXFUTF16String
> *value)
> +{
> +int i, size = wcslen(value) + 1;
> +for (i = 0; i < size; i++)
> +{
> +put_byte(pb, (value[i] >> 8) & 0xff);
> +put_byte(pb, value[i] & 0xff);
> +}
> +}
is just completely nonsense. This only gives UTF-16 by pure luck.
wchar_t and L"..." strings can be in any kind of encoding, but even if
you are lucky enough that they are unicode, just shifting and bit
masking does _not_ give valid UTF-16.
So as a quick solution please make it only handle ASCII but that
correctly (writing a 0 byte, then the ASCII value), and make it
clear in the documentation that it only works for ASCII (i.e. range 0
-127).
Greetings,
Reimar Döffinger
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] MXF muxer version 0.0.4
On Tue, Aug 26, 2008 at 09:59:12AM -0700, Baptiste Coudurier wrote: > zhentan feng wrote: > > [...] > > > > + > > +mxf_write_local_tag(pb, company_name_len, 0x3C01); > > +put_buffer(pb, "FFmpeg", company_name_len); > > Sorry for noticing it so late, but this is wrong, all strings in MXF are > in UTF-16. Ok, so I finally decided to look at it myself (should have done it the first time - nobody else seems to have bothered to check it during the discussion). First, more precisely it is UTF-16BE. Secondly, there (expectedly) is no need to 0-terminate the strings, so strlen would have been better than sizeof (saving a few bytes). Not that I think UTF-16 is even remotely a good choice they made there, and then not even making it compatible to the only other big user of it (Windows, which uses UTF-16LE). I also have to ask: Are you sure all strings are UTF-16? The way they express themselves in section 3.3 of 377m is extremely unclear to me: " Strings Strings are created from individual characters defined either as ISO 7-bit characters (as used in SMPTE RP210) requiring 1 byte per character, or as Unicode UTF-16 characters requiring 2 bytes per character. In the case of UTF-16 characters expressing ISO 7-bit characters, an inspection of every byte will show each 2-byte pair as a null byte and a character byte. Byte order is specified as fixed big endian. The number of bytes allocated to this string is given by the KLV encoding. There is no requirement to terminate each string with a zero value. However, if the length of the String information is less than the space allocated, the string shall be terminated with a zero value " Which sounds as if they could be either - though the tables all seem to say UTF16... Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2932 - mxf/mxfenc.c
On Wed, Jul 30, 2008 at 06:06:11PM +0200, spyfeng wrote: > Author: spyfeng > Date: Wed Jul 30 18:06:11 2008 > New Revision: 2932 > > Log: > remove av_random(). > use simple way to generate random number as uid. Why does the specification ask for a random number? Do the numbers you generate (which, to be precise are not at all random, just an obfuscated deterministic sequence) match that reason? Do they have to be so obfuscated to match that reason or would something simpler do as well, and possibly more reliably (like a constant value or and increasing number - note that a constant is a possible output of any true random number generator, does the spec have provisions for that case or do they just rely on luck like RTSP seems to do)? Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] mxfenc.c version 0.0.3
Hello, On Sat, Jul 26, 2008 at 10:38:11PM +0800, zhentan feng wrote: > I set breakpoint in ffmpeg.c:1662 and checked that I have stored the codec > type and code id correctly. > > codec_type = CODEC_TYPE_VIDEO, codec_id = CODEC_ID_MPEG4, pix_fmt = > PIX_FMT_YUV420P Then if the width and height are indeed optional, the mxf demuxer probably should set AVSTREAM_PARSE_HEADERS for each stream where they are not set. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] mxfenc.c version 0.0.3
On Sat, Jul 26, 2008 at 08:48:57PM +0800, zhentan feng wrote: > 2008/7/26 zhentan feng <[EMAIL PROTECTED]> > > > Hi > > > > 2008/7/25 Michael Niedermayer <[EMAIL PROTECTED]> > > > >> On Fri, Jul 25, 2008 at 09:19:11AM +0800, zhentan feng wrote: > >> > Hi, > >> > > >> > 2008/7/25 Michael Niedermayer <[EMAIL PROTECTED]>: > >> > > >> > > On Fri, Jul 25, 2008 at 01:44:47AM +0800, zhentan feng wrote: > >> > > > Hi, all > >> > > > I have fixed many bugs in mxfenc.c. Now it seems stucked at final > >> step. > >> > > > run test case as below: > >> > > > 1)./output_example test.mpg > >> > > > 2)./ffmpeg -i test.mpg test.mxf > >> > > > 3)./ffmpeg -i test.mxf test.avi > >> > > > stdout says: > >> > > > picture size invalid (0x0) > >> > > > Cannot allocate temp picture, check pix fmt > >> > > > >> > > I think you should paste the whole output of these ffmpeg commands > >> here. > >> [...] > >> > Input #0, mxf, from 'test.mxf': > >> > Duration: N/A, start: 0.00, bitrate: N/A > >> > >> > Stream #0.0, 1/25: Video: 0x, 25.00 tb(r) > >> > Stream #0.1, 1/44100: Audio: 0x > >> > >> looks like it has no clue about which codec it is. > >> > >> are you storing that? if yes why does the demuxer not read it correctly? > >> > > > > > sorry for the misoperation to send the last email. I write it here again: > > descriptor for mxf file is optional, I didn't write the descriptor, so the > width and height are zero as default. > Is it possible this reason of picture size invalid? The thing is that FFmpeg does not know which _codec_ was used, and I find it rather hard to imagine that that is optional, because e.g. raw RGB and raw BGR are impossible to distinguish without some identifier. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2836 - mxf/mxfenc.c
On Tue, Jul 22, 2008 at 06:29:03PM +0200, spyfeng wrote: > @@ -245,12 +246,17 @@ static int klv_encode_ber_length(ByteIOC > // long form > put_byte(pb, 0x80 + size); > i = size; > +tmp_buf = av_mallocz(size); > +if (!tmp_buf) > +return -1; AVERROR(ENOMEM) ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2831 - mxf/mxfenc.c
On Sun, Jul 20, 2008 at 03:24:09PM +0200, spyfeng wrote: > Author: spyfeng > Date: Sun Jul 20 15:24:08 2008 > New Revision: 2831 > > Log: > fix bugs for putting correct param into function put_buffer() > > > Modified: >mxf/mxfenc.c > > Modified: mxf/mxfenc.c > == > --- mxf/mxfenc.c (original) > +++ mxf/mxfenc.c Sun Jul 20 15:24:08 2008 > @@ -352,7 +352,7 @@ static int mxf_write_preface(AVFormatCon > > // write create date as unknown > mxf_write_local_tag(pb, 8, 0x3B02); > -put_buffer(pb, 0, 8); > +put_buffer(pb, "0", 8); Uh, that is still just as wrong as before. What exactly are you trying to do?? Actually, it probably is worse, because it can still segfault (the source buffer you pass is only two bytes long), but in addition the values are wrong, there is one byte that is '0' and one that is '\0' and then there is some random stuff, whatever constant the compiler placed after this. Did you maybe mean > put_be64(pb, 0); ? ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2824 - mxf/mxfenc.c
Hello,
On Sat, Jul 19, 2008 at 05:06:42AM +0200, spyfeng wrote:
> Author: spyfeng
> Date: Sat Jul 19 05:06:42 2008
> New Revision: 2824
>
> Log:
> modify output format long name
>
>
> Modified:
>mxf/mxfenc.c
>
> Modified: mxf/mxfenc.c
> ==
> --- mxf/mxfenc.c (original)
> +++ mxf/mxfenc.c Sat Jul 19 05:06:42 2008
> @@ -848,7 +848,7 @@ static int mux_write_footer(AVFormatCont
>
> AVOutputFormat mxf_muxer = {
> "mxf",
> -"material exchange file fromat",
> +NULL_IF_CONFIG_SMALL("MXF format"),
This does not match the current name in the demuxer.
It also is a bit silly, since the F in MXF stands already for format,
so now it says it is "Material eXchange Format format".
Greetings,
Reimar Döffinger
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2802 - mxf/mxfenc.c
4] = 0x18; > +klv->key[15] = 0x00; Same > +ref = type == MaterialPackage ? set_ref->package : & set_ref->package[1]; ref = set_ref->package; if (type == MaterialPackage) ref++; seems much more readable to me. > + klv->key[13] = 0x01; > +klv->key[14] = type == MaterialPackage ? 0x36 : 0x37; > +klv->key[15] = 0x00; As above. > +put_buffer(pb, klv->key, 16); > +klv_encode_ber_length(pb, dyn_size); > +put_buffer(pb, dyn_buf, dyn_size); And actually, since that whole sequence appears so often, a extra function for it might be a good idea. Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc] Don't copy padding_bug_score.
On Tue, Jul 15, 2008 at 04:19:29AM -0400, Alexander Strange wrote:
> ---
> libavcodec/mpegvideo.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> index 322cfc2..cb2d75f 100644
> --- a/libavcodec/mpegvideo.c
> +++ b/libavcodec/mpegvideo.c
> @@ -389,7 +389,6 @@ void MPV_update_picture_pointers(MpegEncContext *dst,
> MpegEncContext *src){
>
> //copy mpeg4 pts info
> memcpy(&dst->time_increment_bits, &src->time_increment_bits,
> (char*)&src->shape - (char*)&src->time_increment_bits);
> -dst->padding_bug_score = src->padding_bug_score;
>
> //memcpy(dst->mbintra_table, src->mbintra_table, mb_array_size);
> //FIXME why does copying this break decoding?
Useless subject. Esp. with one line changes there is very little point
in repeating _what_ the patch does, but the _why_ is critical.
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc] Remove dead code.
On Tue, Jul 15, 2008 at 04:19:27AM -0400, Alexander Strange wrote:
> ---
> libavcodec/framethread.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
> diff --git a/libavcodec/framethread.c b/libavcodec/framethread.c
> index a4bbad4..9aefe84 100644
> --- a/libavcodec/framethread.c
> +++ b/libavcodec/framethread.c
> @@ -188,8 +188,6 @@ void ff_report_decode_progress(AVFrame *f, int n)
>
> if (*progress >= n) return;
>
> -if (!USE_FRAME_THREADING(f->avctx)) {*progress = n; return;}
> -
> pthread_mutex_lock(&p->progress_mutex);
> *progress = n;
> pthread_cond_broadcast(&p->progress_cond);
Shouldn't that be merged with "Set decoding progress as high as possible
when multithreading is off", which is the patch that actually replaces
that code?
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Segmentation fault debug questions
On Mon, Jul 14, 2008 at 11:51:46PM +0800, zhentan feng wrote: > I have finished mxfenc.c for mxf muxer and complie it successfully without > warnings. > Certainly it still have a longway to go, so the first barrier is: > > the command lines: > > 1) make output_example Hm, try "make output_example_g" and use output_example_g if it works. Why can't you just use ffmpeg/ffmpeg_g instead of output_example? ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2740 - aacenc/aacenc.c
Hello, sorry I can not resist... On Tue, Jul 08, 2008 at 01:26:55PM +0200, kostya wrote: > Author: kostya > Date: Tue Jul 8 13:26:55 2008 > New Revision: 2740 > > Log: > That's one word, not two > > Modified: >aacenc/aacenc.c > > Modified: aacenc/aacenc.c > == > --- aacenc/aacenc.c (original) > +++ aacenc/aacenc.c Tue Jul 8 13:26:55 2008 > @@ -472,7 +472,7 @@ static void encode_section_data(AVCodecC > } > > /** > - * Encode scale factors. > + * Encode scalefactors. Is that AAC-specific? Because I really can't imagine that scalefactors is an English word, at most it would be scale-factors ... Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2719 - nellyenc/nellymoserenc.c
Hello,
On Mon, Jul 07, 2008 at 10:21:38PM +0200, Bartlomiej Wolowiec wrote:
> On poniedziałek, 7 lipca 2008, Robert Swain wrote:
> > 2008/7/7 bwolowiec <[EMAIL PROTECTED]>:
> > > Author: bwolowiec
> > > Date: Mon Jul 7 16:41:50 2008
> > > New Revision: 2719
> > >
> > > Log:
> > > use ff_sine_window_init
> > >
> > >
> > > Modified:
> > > nellyenc/nellymoserenc.c
> > >
> > > Modified: nellyenc/nellymoserenc.c
> > > =
> > >= --- nellyenc/nellymoserenc.c(original)
> > > +++ nellyenc/nellymoserenc.cMon Jul 7 16:41:50 2008
> > > @@ -116,10 +116,13 @@ static av_cold int encode_init(AVCodecCo
> > > dsputil_init(&s->dsp, avctx);
> > >
> > > /* Generate overlap window */
> > > -if (!sine_window[0])
> > > -for (i=0 ; i<256; i++) {
> > > -sine_window[i] = sin((i + 0.5) / 256.0 * M_PI) /8;
> > > +if (!sine_window[0]){
> > > +ff_sine_window_init(sine_window, 128);
> > > +for (i=0; i<128; i++) {
> > > +sine_window[i] /= 8.0;
> >
> > This isn't thread safe. You must merge the /8 into some other calculation.
>
> Hmm.. yes, you're right. Unfortunately, I don't see now where it can be
> calculated. If I don't calculate it in init I will have to calculate it
> additionally in every encode_tag, it isn't a good idea. Maybe it's better to
> use previous version and don't use ff_sine_window_init...? or maybe (in my
> opinion a bit unnatural) such a solution:
> ff_sine_window_init(tmp_sine_window, 128);
> for (i=0; i<128; i++) {
> sine_window[i] = tmp_sine_window[i] / 8.0;
> sine_window[255-i] = sine_window[i];
> }
Just use your original code on some per-thread buffer (stack or heap
depending on size) and then memcpy it over.
Greetings,
Reimar Döffinger
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc] Add choice of threading algorithm to AVCodecContext.
On Tue, Jun 17, 2008 at 02:04:43PM -0400, Alexander Strange wrote: > > On Jun 17, 2008, at 12:18 PM, Reimar Döffinger wrote: > > > On Mon, Jun 16, 2008 at 07:57:05PM -0400, Alexander Strange wrote: > >> > >> Use it to simplify USE_* macros. > >> FF_THREAD_AUTO needs to be handled better - even if a codec can > >> handle frame-threads, we still don't want to use them if there are > >> enough slices available. > > > > I also do not really like that this design does not allow to use both. > > E.g. when 16 core CPUs become common just one type may not be good > > enough ;-) > > Or to say it differently: I think the problem is not just with > > FF_THREAD_AUTO but in the design in general. > > You can't run out of threads for multiframes, but eventually I guess > it would be better to have x frame threads * x slice threads. Sounds > more useful for encoding, though; does anyone really need to decode > that fast? You can easily run out of memory or cache though, especially if you try some kind of direct rendering where all frames must fit into a DMA-enable memory range or similar. Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc] Add choice of threading algorithm to AVCodecContext.
On Mon, Jun 16, 2008 at 07:57:05PM -0400, Alexander Strange wrote: > > Use it to simplify USE_* macros. > FF_THREAD_AUTO needs to be handled better - even if a codec can handle > frame-threads, we still don't want to use them if there are enough slices > available. I also do not really like that this design does not allow to use both. E.g. when 16 core CPUs become common just one type may not be good enough ;-) Or to say it differently: I think the problem is not just with FF_THREAD_AUTO but in the design in general. Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Tips From The Hardened FFmpeg Veterans
On Wed, May 07, 2008 at 02:25:07AM +, compn wrote:
> Mike Melanson <[EMAIL PROTECTED]> writes:
> > * ccache (ccache.samba.org): This tool caches your compiled object
> > * valgrind (valgrind.org): Memory checker tool; it will point out when
> > These are the first 2 things I can think of. Other veterans, please jump in.
>
>
> as i'm sure michael will find slow/unoptimized code , dont forget start/stop
> timer.
For larger amounts of code, oprofile (http://oprofile.sourceforge.net/docs/)
can be
quite useful, too.
Also useful for optimizing is looking directly at what kind of mess the
compiler made this time.
gcc -S -o or objdump are good if AT&T syntax is fine for you. Otherwise
I can also recommend http://hte.sourceforge.net/ esp. since it comes
with an included assembler so you can also quickly hack things.
For debugging symbol/code sizes (probably less important in these cases)
I use a shell script with this:
objdump -t "$1" | grep "$2" | awk '{ print $5" "$6 }' | sort | less
First argument to the script is the name of the binary, second argument
is whatever you are looking for - e.g. a symbol name or "rodata" if
you want to look what is in the read-only data section.
Greetings,
Reimar Döffinger
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [PATCH] Splitted AVOption & AVClass part
On Sun, May 04, 2008 at 03:58:01PM +0200, Keiji Costantini wrote: > +#undef VE > +#undef DEFAULT IMO you can drop them now. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Specific Project Goals
Hello, On Sun, May 04, 2008 at 01:02:30AM +0530, Sisir Koppaka wrote: > From the debian package page, these seem to depend on CONNECT being made > available by the proxy and I am sure that that is blocked for us. Too bad. > git-format-patch and tunnelling through the public ssh computer are two good > ways that I'll try to use. If someone is root on a PC that can receive ICMP, http://www.cs.uit.no/~daniels/PingTunnel/ might be useful as well (or do they block ping as well??). While ptunnel is installed on my router, my firewall/DSL router can not forward ICMP :-(. And running the httptunnel server is not a big deal either though it is a bit of a pain in comparison. Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Specific Project Goals
On Sun, May 04, 2008 at 12:28:13AM +0530, Sisir Koppaka wrote: > On Sat, May 3, 2008 at 10:43 PM, Reimar Döffinger < > [EMAIL PROTECTED]> wrote: > > On Sat, May 03, 2008 at 06:58:42PM +0200, Reimar Döffinger wrote: > > > And a quick check on debian packages comes up with httptunnel, > > > connect-proxy, corkscrew all of which allow tunneling through a http > > > proxy. I would have to run that on my main PC though, so I could provide > > > that only about 14 hours/day max. > > > > I just noticed that these programs can actually tunnel an arbitrary tcp > > connection through http proxies, at least squid, without any special > > remote server. I always assumed that http proxies would regenerate the > > HTTP requests, and at least the one squid config I have does (at least > > sometimes) since it is configured to gzip-compress everything it > > receives before passing it on... > > Amazing how little one knows ;-) > > > Do you mean you can ssh through a proxy??? That would be extremely useful > here, but http-tunnel does seem to require an external computer, so were you > referring to corkscrew or some other program? Yes, corkscrew and connect-proxy are supposed to work with proxies that allow HTTPS without an extra server. As I understand it, it is mostly for use with ssh but could be used for other programs as well. If it can connect to other ports than 443 probably depends on the proxy configuration. I do not have any restrictive proxy here to test though... Greetings, Reimar Dðffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Specific Project Goals
On Sat, May 03, 2008 at 06:58:42PM +0200, Reimar Döffinger wrote: > And a quick check on debian packages comes up with httptunnel, > connect-proxy, corkscrew all of which allow tunneling through a http > proxy. I would have to run that on my main PC though, so I could provide > that only about 14 hours/day max. I just noticed that these programs can actually tunnel an arbitrary tcp connection through http proxies, at least squid, without any special remote server. I always assumed that http proxies would regenerate the HTTP requests, and at least the one squid config I have does (at least sometimes) since it is configured to gzip-compress everything it receives before passing it on... Amazing how little one knows ;-) Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Specific Project Goals
Hello, On Sat, May 03, 2008 at 10:00:45PM +0530, Sisir Koppaka wrote: > We can't do ssh directly from our machines but they provide access to a > public machine, from which we can ssh into the outside world. How do you access that public machine? Sit directly in front or? > I think this + > tunnelling would work but only this is a security risk because anyone can > login using the same public credentials. This is a viable option if someone > could offer tunnelling help. Depending on how their proxy handles https, simpler solutions probably exist as well. They might just let https directly through based on port alone, in which case you will be able to connect via ssh to my router (ssh -p443 hokum.dyndns.org), which I have not problem letting run 24/7. And a quick check on debian packages comes up with httptunnel, connect-proxy, corkscrew all of which allow tunneling through a http proxy. I would have to run that on my main PC though, so I could provide that only about 14 hours/day max. Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Specific Project Goals
On Sat, May 03, 2008 at 09:35:35PM +0530, Sisir Koppaka wrote: > A small note about the soc-repos, I'm not sure which thread to say this or > if this is too early, but I think I should inform early - Even Git cloning > under http doesn't work through the proxy net of my college. I don't have > any problems now using git since I'm at home but during the last month or > so, I will probably be back in college in my next semester, so it might > cause some problems then. SVN checkouts worked fine over http last time I > checked and I hope that it will not be compulsory to use Git. What kind of things do they allow? Can you use at least ssh? If yes I am sure a few of us can offer you to tunnel. In the worst case there is also tunnelling via DNS which I would assume at least one of us would be able to offer if it becomes necessary. And if your college offers computer-science courses you might try pointing out that blocking things like svn, ssh or git blocks some heavily education-related stuff, not to mention that filtering only works against the lazy people anyway... Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Hi there.......
On Fri, Apr 25, 2008 at 09:54:20PM +0200, Luca Barbato wrote: > Alexander Strange wrote: > > > Yeah, I've used git for x264. I really need to read the manual so I can > > find out what a 'commit-ish' is. > > > > Using the repository has some advantages over local git, though, like a > > backup outside of your house and other people being able to see how much > > work you've done without asking you. > > Working on finding a place for you to push it. Which in general terms (not in this case) is much, much simpler with git than SVN, all git really needs is a http server (though without ssh access it would be a pain). Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] [soc]: r2150 - libavfilter/graphparser.c
On Wed, Apr 23, 2008 at 08:03:27PM +0200, vitor wrote:
> Author: vitor
> Date: Wed Apr 23 20:03:27 2008
> New Revision: 2150
>
> Log:
> Simplify while(pad){pad--; etc} to while(pad--){etc}
Just because the log message to me is unclear on this: You did notice these
are not equivalent and it just does not matter for this code, right?
___
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Vivo qualification task
On Fri, Apr 11, 2008 at 01:22:24PM -0300, Marcondes Ricarte wrote: > How do I report my progress for you (mentors)? Just a reminder that the deadline is quite close (and there is always something that needs to be fixed), if you are still interested. Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] BFI
On Mon, Mar 31, 2008 at 01:32:52PM +0530, Sisir Koppaka wrote: > I've set the two FF_BUFFER_HINTS mentioned above, but how do we use the > same AVFrame? Currently I'm using an AVFrame declared within BFIContext, my > context structure. Do whatever the nuv.c decoder does, I think that is the easiest example. ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] BFI
On Sat, Mar 29, 2008 at 11:18:49AM +0530, Sisir Koppaka wrote: > Hi, > I'm passing the palette using extradata to the decoder. > 1)Do I have to do this for every frame? BFI has the same palette for all the > frames. Will extradata be refreshed to 0 after every frame by ffmpeg? No, extradata must remain unchanged over all the time. But please note (in case you are not aware) that extradata may not be endian specific (since that would break remuxing), so it might still make sense to make a copy in your decoder so you have the native-endian form ready (in case you set the palette every frame). > 2)I'm assuming that in the decoder, I have to put the palette into > data[1](based on the code that I read) and the frame's actual contents into > data[0]. Is this right? Yes. > 3) Do I have to set the palette in the decoder for every frame? Or will > doing it the first time suffice? If you set FF_BUFFER_HINTS_PRESERVE | FF_BUFFER_HINTS_REUSABLE and always use the same AVFrame: no. But you should only do this if there is a reason for it besides the palette, e.g. because previous frames are reused or whatever. Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] BFI
Hello, On Tue, Mar 25, 2008 at 11:35:44PM +0530, Sisir Koppaka wrote: > One more doubt :) > Is it necessary to set the palette once per frame in the decoder or doing it > once for all the frames will suffice? Palette behaves just like any other part of the frame (it is just another plane, no special handling really): If you set FF_BUFFER_HINTS_PRESERVE it will be the same as for the last frame, if not it is uninitialized initially and you have to set it again. And no, IMO you should not set FF_BUFFER_HINTS_PRESERVE just because of the palette. Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] BFI
On Tue, Mar 25, 2008 at 11:00:43PM +0530, Sisir Koppaka wrote: > Does calling av_new_packet or av_get_packet automatically send over the > packet to the decoder? Those functions are only one way to initialize an AVPacket. If your demuxers read function returns 0, the packet to which your got the pointer as argument to the read function will be queued (and somewhen passed on to the decoder). Greetings, Reimar Döffinger ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
