Hi,
2016-05-30 15:09 GMT+02:00 Paul B Mahol <one...@gmail.com>:
Hi,
2016-05-30 15:09 GMT+02:00 Paul B Mahol <one...@gmail.com>:
>> ffmpeg seems to have libavutil/qsort.h, but I don't even know how much
>> effort is needed to use it here.
>
> Changed, doesn't help but maybe will for other archs.
I have no idea why it is present, but it made sense to me to reuse
whatever ffmpeg already has.
>> That's somewhat similar to png paeth, except not actually reusable. I
>> wonder if there's something in libavcodec that could be reused, in
>> which case moving it to the hdsp context would be nice)
>
> Our Huffyuv decoder is still missing gradient prediction...
I'd say neither does the encoder, so it's not "specified" in any
public "version" (whether the 15yo ones or the ffvhuff ones).
It's a matter of creating a new version with it for smaller filesizes.
But I bet users are all over those newer codecs (utvideo&co) and
haven't looked/won't look back at vhuffyuv&co if this predictor and
slices were implemented there.
>>> + } else if (pred == MEDIAN) {
>> [...]
>>> + } else {
>>
>> So, that's maybe a detail at this point, and you want to move quickly
>> to other stuff, but:
>> would you like to look at e.g. huffyuvdec or pngdec for a code that is
>> not as nice looking, but more cache-friendly?
>>
>> Basically, you move the first line out of the loops, and then do
>> sequentially, per row in the loop, bitstream reading, reconstruction
>> (residual+prediction) and any post-processing...
>
> Just tried, didn't help much here.
Hmm, was that single-threaded decoding? Also, the VLC decoding is
slower than needed (again, see huffyuvdec and generate_joint_tables),
so that may not show up.
Anyway, whatever temporary patch you had probably became invalid after
you implemented interlaced encoding, so that's kind of moot.
>>> + for (i = 0; i < p->height; i++) {
>>> + for (x = 0; x < p->width; x++) {
>>> + b[x] += g[x];
>>> + r[x] += g[x];
>>> + }
btw, isn't that add_bytes from HuffYUVDSPContext ? ie:
hdsp->add_bytes(b, g, p->width);
etc
Except for this (and pending Piotr's fuzzing cases), looks fine.
--
Christophe
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
