FFmpeg: Implement image thumbnails #8583
Conversation
fritsch
force-pushed
the
ffmpeg-image-thumbnails
branch
from
a675366
to
38acc08
Compare
| return new CFFmpegImage(); | ||
|
|
||
| return new CXImage(strMimeType); | ||
| return new CFFmpegImage(); |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
fritsch
force-pushed
the
ffmpeg-image-thumbnails
branch
5 times, most recently
from
69ab3d0
to
f8a0dcc
Compare
|
very nice, die cxImage die. |
|
We are not done yet - sadly this mjpeg encoder only eats YUVJ420P which is deprecated ... so I am foucking arround with sws_scale to alter the range of YUV420P |
fritsch
force-pushed
the
ffmpeg-image-thumbnails
branch
3 times, most recently
from
cd153bc
to
18da43d
Compare
|
any speed differences + or - ? |
|
Just implemented for now - I did not make any tests yet concerning speed. |
fritsch
force-pushed
the
ffmpeg-image-thumbnails
branch
from
18da43d
to
969fc0e
Compare
|
Original (463 KB): SWS_Rescaled (correct color set - last patch, 281 KB): SWS_Rescaled (wrong color set - without the last patch, 253 KB): |
fritsch
force-pushed
the
ffmpeg-image-thumbnails
branch
from
4c08e72
to
0b4c5a4
Compare
|
I skimmed through it, nice work! 👍 |
fritsch
force-pushed
the
ffmpeg-image-thumbnails
branch
from
0b4c5a4
to
f22a6d4
Compare
|
@ace20022 yeah - thx for starting it :-) |
|
I am ready to clean up after this is in. the question is: do we want to keep CJpegIO. as it has nothing to do with cximage, and we can not drop libjpeg dependency anyway. |
|
@stefansaraev we still need to do some benchmarking - quality wise, file size wise and speed wise. I think I'd like to keep CXImage in there for the first time (but deactivate it) Edit: or not - it can always come back :-) |
|
my question is for cjpegio. not cximage ;) |
|
Agree with @fritsch, jpegs are handled different iirc, because cjpegio is ways faster, at least there's a comment somewhere. So we need extensive tests on all platforms. |
|
I am pretty new into this "Image stuff" just came into this while emailing with @ace20022 two days ago - others more into the code need to tell us. |
|
sure @ace20022 I am for keeping cjpegio and evenualy removing cximage. but it's up to you guys. |
|
since master is undergoing major construction, nuke out cximage, keep jpgio/gifio and use ffmpeg for everything else. if you keep cximage and fallback to it, you will never find/fix issues. |
|
@davilla: can you provide some numbers with: http://sprunge.us/WEKV on top applied? Here are some results from my testing rigs (all debug build): http://sprunge.us/QEWc Computing Time: 30.426772 ms Width: 1920 Height: 1080 |
|
JpegIO: http://sprunge.us/VWDT Computing Time: 28.715415 ms Width: 1920 Height: 1080 Not that bad at all :-) |
|
JpegIO Image (352 KB): It's 1.5 times bigger than ours. |
|
Then all fine ... I only read the addon code for libraw, sorry for that. So yes - then we have a solution for the kodi clue part. Sorry! |
|
FFmpeg's Decode method has a scaling method: fritsch@c9ed88e so whenever the given texture targets are too small images are rescaled, so if it's going through that, they are rescaled. Though there is a little overhead (one additional full copy) that could be solved by static ImageScaler, that btw. FFmpegImage could then reuse again. |
That's what I had in mind.This could also be an addon, probably not, or? |
|
Yes. We also have encoders that user internal ffmpeg contexts. So an addon depending on sws_scale is doable. Lifetime of buffers, especially resulting buffers need to be discussed but I think @notspiff already has thought through a possible poc that would help us in that regard. |
|
looks fine depends wise. Not sure if ffmpeg needs external libs for mjpeg or png, but we have at least libpng available. If it needs libpng, then you should add it to ffmpeg depends in https://github.com/xbmc/xbmc/blob/master/tools/depends/target/Makefile#L103 |
|
@wsnipex thx for looking, I think it is not needed: https://ffmpeg.org/general.html#Image-Formats it does it internally. |
v1: Initial implementation v2: Use av_frame_get_color_range instead of manual parsing
v1: Initial commit v2: Add description v3: probe it's cheap v3: use mimetype later (broken files) v4: also detect tiff - we love tiff
fritsch
force-pushed
the
ffmpeg-image-thumbnails
branch
from
ca1d5b2
to
407f1c5
Compare
stefansaraev
added
Type: Feature
|
jenkins build this please |
FFmpeg: Implement image thumbnails
| @@ -153,6 +153,8 @@ CFLAGS="$CFLAGS" CXXFLAGS="$CXXFLAGS" LDFLAGS="$LDFLAGS" \ | |||
| --enable-libvorbis \ | |||
| --enable-muxer=ogg \ | |||
| --enable-encoder=libvorbis \ | |||
| --enable-encoder=png \ | |||
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
|
mhhh jpegio was nuked now and we still link kodi against libjpeg for darwin here: https://github.com/xbmc/xbmc/blob/master/tools/darwin/Configurations/App.xcconfig.in#L28 What am i missing? |
|
@Memphiz this PR did not nuke it, though @stefansaraev do you have an idea? |
|
huh. I missed that as jenkins built all fine. will add to #8772 |
|
it wouldn't show up as an error. the library is there (needed by texturepacker) and the linker simply doesn't import any symbols since there are no references. |
|
Nope texturepacker is native :D |
|
true that. my point is still valid though ;) other platforms have been pruned (configure does things properly and have no hard coded link list afaik). |
This brings the visionary PR of @ace20022 another step further. With this in place we can basically kick all other image dependencies we have and just use the ffmpeg one.
Happy for a thourough review.