[PATCH] Remove imgconvert.c:avg_bits_per_pixel()
Hi, as in subject. Follows the difference between the avg_bits_per_pixel() and av_get_bits_per_pixel() (the second value comes from av_get_bits_per_pixel(), which is also right). bgr4_byte: 8 4 rgb4_byte: 8 4 yuva420p: 12 20 rgb555be: 16 15 rgb555le: 16 15 bgr555be: 16 15 bgr555le: 16 15 Regression test passed. Regards. -- FFmpeg = Fast & Frenzy Multipurpose Portable Ecumenical Ghost
On Sun, Jan 31, 2010 at 04:55:22PM +0100, Stefano Sabatini wrote:
Hi, as in subject.
Follows the difference between the avg_bits_per_pixel() and av_get_bits_per_pixel() (the second value comes from av_get_bits_per_pixel(), which is also right).
bgr4_byte: 8 4 rgb4_byte: 8 4 yuva420p: 12 20 rgb555be: 16 15 rgb555le: 16 15 bgr555be: 16 15 bgr555le: 16 15
Regression test passed.
[...]
@@ -882,7 +834,7 @@ if (pix_fmt_mask & (1ULL << i)) { loss = avcodec_get_pix_fmt_loss(i, src_pix_fmt, has_alpha) & loss_mask; if (loss == 0) { - dist = avg_bits_per_pixel(i); + dist = av_get_bits_per_pixel(&av_pix_fmt_descriptors[i]); if (dist < min_dist) { min_dist = dist; dst_pix_fmt = i;
your change is incorrect, this function selects the pix format that is most compact within the losses the user accepts. (should probably let the user specify how many bits he is willing to loose as well) after yor change it favors formats that are worse but not more compact [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
On date Sunday 2010-01-31 17:05:23 +0100, Michael Niedermayer encoded:
On Sun, Jan 31, 2010 at 04:55:22PM +0100, Stefano Sabatini wrote:
Hi, as in subject.
Follows the difference between the avg_bits_per_pixel() and av_get_bits_per_pixel() (the second value comes from av_get_bits_per_pixel(), which is also right).
bgr4_byte: 8 4 rgb4_byte: 8 4 yuva420p: 12 20 rgb555be: 16 15 rgb555le: 16 15 bgr555be: 16 15 bgr555le: 16 15
Regression test passed.
[...]
@@ -882,7 +834,7 @@ if (pix_fmt_mask & (1ULL << i)) { loss = avcodec_get_pix_fmt_loss(i, src_pix_fmt, has_alpha) & loss_mask; if (loss == 0) { - dist = avg_bits_per_pixel(i); + dist = av_get_bits_per_pixel(&av_pix_fmt_descriptors[i]); if (dist < min_dist) { min_dist = dist; dst_pix_fmt = i;
your change is incorrect, this function selects the pix format that is most compact within the losses the user accepts. (should probably let the user specify how many bits he is willing to loose as well) after yor change it favors formats that are worse but not more compact
I don't see how my change could have do that, I simply removed a wrong implementation of a function for computing the average bits per pixel with a correct one. Then we may agree that the logic of the function may be improved... Regards. -- FFmpeg = Freak and Fanciful Murdering Pitiful Exuberant Gadget
On date Monday 2010-02-01 00:36:16 +0100, Stefano Sabatini encoded:
On date Sunday 2010-01-31 17:05:23 +0100, Michael Niedermayer encoded:
On Sun, Jan 31, 2010 at 04:55:22PM +0100, Stefano Sabatini wrote:
Hi, as in subject.
Follows the difference between the avg_bits_per_pixel() and av_get_bits_per_pixel() (the second value comes from av_get_bits_per_pixel(), which is also right).
bgr4_byte: 8 4 rgb4_byte: 8 4 yuva420p: 12 20 rgb555be: 16 15 rgb555le: 16 15 bgr555be: 16 15 bgr555le: 16 15
Regression test passed.
[...]
@@ -882,7 +834,7 @@ if (pix_fmt_mask & (1ULL << i)) { loss = avcodec_get_pix_fmt_loss(i, src_pix_fmt, has_alpha) & loss_mask; if (loss == 0) { - dist = avg_bits_per_pixel(i); + dist = av_get_bits_per_pixel(&av_pix_fmt_descriptors[i]); if (dist < min_dist) { min_dist = dist; dst_pix_fmt = i;
your change is incorrect, this function selects the pix format that is most compact within the losses the user accepts. (should probably let the user specify how many bits he is willing to loose as well) after yor change it favors formats that are worse but not more compact
I don't see how my change could have do that, I simply removed a wrong implementation of a function for computing the average bits per pixel with a correct one.
So my question: what's wrong with the proposed change? Is avg_bits_per_pixel() supposed to be equivalent to av_get_bits_per_pixel() to av_get_bits_per_pixel() (in which case the change is correct), or is it something different? In the latter case what does it represent? Regards. -- FFmpeg = Fantastic Fantastic Maxi Pitiful Enchanting Game
On Fri, Jul 23, 2010 at 05:29:53PM +0200, Stefano Sabatini wrote:
On date Monday 2010-02-01 00:36:16 +0100, Stefano Sabatini encoded:
On date Sunday 2010-01-31 17:05:23 +0100, Michael Niedermayer encoded:
On Sun, Jan 31, 2010 at 04:55:22PM +0100, Stefano Sabatini wrote:
Hi, as in subject.
Follows the difference between the avg_bits_per_pixel() and av_get_bits_per_pixel() (the second value comes from av_get_bits_per_pixel(), which is also right).
bgr4_byte: 8 4 rgb4_byte: 8 4 yuva420p: 12 20 rgb555be: 16 15 rgb555le: 16 15 bgr555be: 16 15 bgr555le: 16 15
Regression test passed.
[...]
@@ -882,7 +834,7 @@ if (pix_fmt_mask & (1ULL << i)) { loss = avcodec_get_pix_fmt_loss(i, src_pix_fmt, has_alpha) & loss_mask; if (loss == 0) { - dist = avg_bits_per_pixel(i); + dist = av_get_bits_per_pixel(&av_pix_fmt_descriptors[i]); if (dist < min_dist) { min_dist = dist; dst_pix_fmt = i;
your change is incorrect, this function selects the pix format that is most compact within the losses the user accepts. (should probably let the user specify how many bits he is willing to loose as well) after yor change it favors formats that are worse but not more compact
I don't see how my change could have do that, I simply removed a wrong implementation of a function for computing the average bits per pixel with a correct one.
So my question: what's wrong with the proposed change?
Is avg_bits_per_pixel() supposed to be equivalent to av_get_bits_per_pixel() to av_get_bits_per_pixel() (in which case the change is correct), or is it something different?
In the latter case what does it represent?
after 6 month my memory says that you mixed up the sample precission aka what affects how many colors can be represented with how many bits are physically used per pixel. and ultimately the definition of functions dont matter that much, what matters is that functions still work and iirc this one broke some pixel format selection code. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
participants (2)
-
michaelni＠gmx.at -
stefano.sabatini-lala＠poste.it