On Tue, Oct 01, 2013 at 11:51:40AM +0200, Maxim Polijakowski wrote: > [...] > >>--- a/libavcodec/atrac3.c > >>+++ b/libavcodec/atrac3.c > >>@@ -417,90 +412,32 @@ static int decode_tonal_components(GetBitContext *gb, > >> static int decode_gain_control(GetBitContext *gb, GainBlock *block, > >> int num_bands) > >> { > >>- int i, cf, num_data; > >>+ int i, b; > >> int *level, *loc; > >>- for (i = 0; i <= num_bands; i++) { > >>- num_data = get_bits(gb, 3); > >>- gain[i].num_gain_data = num_data; > >>- level = gain[i].lev_code; > >>- loc = gain[i].loc_code; > >>+ for (b = 0; b <= num_bands; b++) { > >>+ gain[b].num_points = get_bits(gb, 3); > >>+ level = gain[b].levcode; > >>+ loc = gain[b].loccode; > >>- for (cf = 0; cf < gain[i].num_gain_data; cf++) { > >>- level[cf] = get_bits(gb, 4); > >>- loc [cf] = get_bits(gb, 5); > >>- if (cf && loc[cf] <= loc[cf - 1]) > >>+ for (i = 0; i < gain[b].num_points; i++) { > >>+ level[i] = get_bits(gb, 4); > >>+ loc [i] = get_bits(gb, 5); > >>+ if (i && loc[i] <= loc[i-1]) > >> return AVERROR_INVALIDDATA; > >> } > >> } > >>- /* Clear the unused blocks. */ > >>- for (; i < 4 ; i++) > >>- gain[i].num_gain_data = 0; > >>+ /* Clear unused blocks. */ > >>+ for (; b < 4 ; b++) > >>+ gain[b].num_points = 0; > > > >Is there a reason to rename the counter variables? It seems rather > >arbitrary and complicates the diff. > > Yes, the reason for rename this variable is to make it look more > "standard" and readable. What does that "cf" stand for? "Core > Foundation" or "close file"? > "i" is unambiguous and clear, isn't it?
Yes, we usually use 'i' and 'j' as counter variables. > The above mentioned changes look rather trivial IMHO so I wonder if > someone else could fix them all and push the patches. Taking in > consideration the amount of work I'm currently doing in order to > provide Libav with support for several other obscured and > proprietary formats, fixing such things again and again wastes alot > of my time and keep me away from doing perhaps more important stuff. And I'm helping you by doing all the postprocessing on ATRAC3+ :) I could do all the work myself directly, but I choose to review your patches so that in the future the postprocessing work is reduced while you adapt a bit more to the modern libav style and workflow. If we get to that point, things will go much more smoothly. I'll fix up and split/rebase this patchset later today. Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel