[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vp / vr / w / wg / wsg / wsr / x / y ] [Home]
4chanarchives logo
What does /g/ think about WebP ?
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.

You are currently reading a thread in /g/ - Technology

Thread replies: 142
Thread images: 15
File: Webp-logo-wordmark.svg.png (18 KB, 182x219) Image search: [Google]
Webp-logo-wordmark.svg.png
18 KB, 182x219
https://developers.google.com/speed/webp/
>uses predictive coding to encode an image, the same method used by the VP8 video codec

here some example images
https://koyaanis.com/webp/sfw/

on one image the filesize went down by 85%, see:
https://koyaanis.com/webp/sfw/compression%206%20quality%2090/519531.jpg
https://koyaanis.com/webp/sfw/compression%206%20quality%2090/519531.webp
>>
File: 1459343831606.jpg (30 KB, 500x283) Image search: [Google]
1459343831606.jpg
30 KB, 500x283
>>54735334
In trash it goes. Use JPEG.
>>
>>54735334
>convert image to webp(use predictive coding and other OP buzwords)
>convert webp to jpg
profit
>>
>>54735414
why?
>>
old news, we bpg and flif now
>>
>>54735459
Because image format should not include own compressor in the first place. Read about farbfeld.

also
>Developed by Google

and they are known for being CIA nigger scums
>>
>>54735488
>and they are known for being CIA nigger scums
then why is webm supported?
>>
Webp is a joke, >>54735465 this

PS: regular webm can be used for images
>>
you can actually use BPG in production right now using their javascript library.

there's absolutely no way to use webp in production
>>
>>54735506
chrom(e|ium) supports webp
>>
>>54735498
holy WEBM is blessed by a saint RMS spirit

It was initially developed by OK companies, and only after that Google tortoise maggots joined.
>>
>>54735499
>webm can be used for images
>>
>>54735512
Everything else doesn't, so derp.
>>
>>54735506
Are you implying there are no polyfills for webp? Because that's entirely wrong.

http://webpjs.appspot.com/
>>
>>54735537
sure. but that's not what you said
>>
>>54735547
I said production, and you confirmed me by saying only one browser supports it.
>>
>>54735551
>absolutely no way
>oh, except that one browser fucking everyone uses
>>
File: 1464180576338.webm (23 KB, 300x188) Image search: [Google]
1464180576338.webm
23 KB, 300x188
>>54735520
>>
>>54735334
>https://developers.google.com/speed/webp/
>How WebP Works
>Predictive coding uses the values in neighboring blocks of pixels to predict the values in a block, and then encodes only the difference.
Well, that is pretty much how any lossless audio/video/image compression works. They try to make a best guess by exploiting what we know about the data and then save the error.

I hoped they would explain what model they use to predict the image.

>>54735520
Video codecs usually incorporate a fully featured image codec (used for I-frames). h.265 is for example also an extremely efficient image codec. It's pretty simple to just tell the video codec to encode a single still image.
>>
Part of my anime pictures collection is in webp. I save a few gigabytes thanks to it.
>>
>>54735569
I also forgot to mention that this is 99% the same as an actual webp
>>
File: 1464180905.webm (104 KB, 436x284) Image search: [Google]
1464180905.webm
104 KB, 436x284
>>54735569
are you actually serious right now?
>>
>>54735561
>one browser

Once again you've confirmed my statement about it not being production ready.
>>
>>54735591
A webp is that, except with the controls disabled/hidden. (Which can already be done with the <video> tag)
>>
>>54735611
I refuse to believe
>>
File: out.webm (8 KB, 600x634) Image search: [Google]
out.webm
8 KB, 600x634
>>54735591
Maybe a different frame rate helps.
>>
>>54735591
Hit the pause button lol
>>
File: a.webm (243 KB, 524x410) Image search: [Google]
a.webm
243 KB, 524x410
>>54735591
>>
>>54735595
what do you think production ready means?
>>
>>54735653
Shit mate.. I could also use any other video codec, hevc for example and just hide the controls. But in the end its still a video and not an image
>>
>>54735685
Works on the majority of browsers, Chrome isn't >50%.
>>
File: 6sided_dice.jpg (561 KB, 1320x909) Image search: [Google]
6sided_dice.jpg
561 KB, 1320x909
>>54735711
Webm is a video in the end and not an animated gif
>>
>>54735716
that's not what it means
>>
>>54735733
It's one of the criteria of production-ready
>>
>>54735334
>no firefox support
>>
>>54735730
i know thats my point. i want image formats for images and video formats for videos
>>
>>54735569
>Dat CPU spike.
>>
>>54735768
This
>>
>>54735763
There's no real difference, image codecs and video codecs have always been used interchangeably with the user not noticing a difference

>motion jpeg
>webp
>animated gif
>>
>>54735414
If jpeg could just have transparency though
>>
File: 1462422156140.jpg (46 KB, 960x720) Image search: [Google]
1462422156140.jpg
46 KB, 960x720
>>54735800
>lossy transparency

Thank god that never happened.
>>
>>54735785
Don't forget the adventures of mozilla with apng.

That said: What's the current status on webm + transparency
>>
>>54735785
gifs are a category of their own. also they are shit.
>motion jpeg
first time i heard of this
>webp
thats an image format
>>
>>54735833

Is this a rebuttal attempt or you're just stating your ignorance?
>>
>>54735818
There would be no point in having a "lossy" alpha channel, it wouldn't work properly.
>>
>>54735833
There's no difference. Considering images are a subset of videos (with a single frame and no audio stream) it's weird to me that they are separate. I get that it's a good idea to keep the file extensions separate, but the codecs probably shouldn't be.
>>
>>54735849
>Is this a rebuttal attempt or you're just stating your ignorance?
I just openened a webp as a webm. it didnt work. what else do i need to do?
>>
>>54735334
you can already use webp and webm in any modern browsers.
if the formats are not supported you can use a fallback action.
for example.

<video width="320" height="240" controls>
<source src="movie.webm" type="video/mp4">
<source src="movie.mp4" type="video/ogg">
Your browser does not support the video tag.
</video>


the browser will then either use the webm or mp4 video depending on what is supported.
assets will be loaded as necessary to boot.

the same works with the <picture> tag. this will load either the webp image or the gif/jpg/png or whatever. and only load the one that is necessary.
>>
>>54735853
that's not true
>>
>>54735875
>.webm -> video/mp4
>.mp4 -> video/ogg

nice shitposting
>>
>>54735875
now try movie.webm type image/webp
>>
>>54735853
The alpha channel is literally no different from the R, G or B channel. Compressing it works the exact same way.
>>
>>54735909
i coppied the example from the MDN and forgot to edit hte second part
im so sorry for causing a fourth holocaust senpai.
>>
>>54735591
Why this doesn't happen to me? Even if I click on Play it doesn't do anything at all.
>>
Webp is the ultimate solution to jpeg(higher compression in lossy mode, transparency), png(higher compression in lossless mode) and gif(truecolor, better compression, open format). Why isn't it still used by default everywhere is beyond me.
>>
>>54737197
it's not used everywhere because it's not supported everywhere
it's not supported everywhere because it's not used everywhere
>>
>>54737295
Chrome based browsers support it(Chrome's data saving mode converts pictures from http sites to webp). Failfox quickly falls into oblivion. Safari shouldn't matter that much because then webm wouldn't be supported as well.
>>
>>54735768
9% to 70% haha (Intel Pentium wolfdale)
>>
>>54735822
It exists but last I saw it only works on chrome.
>>
>>54737295
>it's not used everywhere because it's not supported everywhere
you mean the same way webm wasnt supported? just force it and itll happen within 2 days..
>>
>>54735569
Firefox really doesn't like these, CPU spiked while it was open.
>>
>>54741913
>>54735591
>>
File: apple.webm (3 MB, 512x384) Image search: [Google]
apple.webm
3 MB, 512x384
>>54735822
Here's one
>>
>>54742491
In firefox the seekbar doesn't change at all, it's just stuck at the start.
>>
>>54742753
But apparently pausing the "video" still works. If you press pause the CPU goes back to normal
>>
>>54742812
its not a "video" its a video. seriously are you guys trolls?
>>
>>54735853
huh
>>
>>54735465
>>54735499

Not OP.
I (and a few others...) did test all those. Thoroughly.
bpg is worse in any standard test (performed on a standard set of images, ~800MB)
flif is a fucking joke. Sometimes it's better, sometimes it's worse, problem is that when it's worse, it's awfully worse.
webp and lossless webp perform best.

Also
>>54735499
>webm for images
Your ignorance is so blissfully elegant. Video and images use different colour spaces. That's why -lossy- webp had to be forked from vp8 (the code is anyway almost identical). Lossless webp in an unprecedented achievement and its sources are completely different.
>>
>>54743041
s/Lossless webp in an/Lossless webp is an/
>>
>>54737197
That is very easy to answer: Webp is way too high complexity compared to stuff like JPG or PNG. It's not like the only computers de and encoding images are some neckbeard's gaymen computers with an i7 in it. It's also used in very low performance devices. JPG is a completely sufficient tradeoff between computation time and quality, especially as storage is less and less of an issue.
>>
>>54743011
It's a single frame, it's at least as much an image as it is a video. The fact that the web browser interprets it as a video and tries to loop it over and over again doesn't change that.
>>
>>54743041
>Your ignorance is so blissfully elegant. Video and images use different colour spaces.
Care to elaborate?
>>
>>54743058
>we'll still use mp3, jpg, pdf, png in 2050
Not the neckbeard you're arguing with; I'm not fighting these kind of sad truths. Something epochal* has to happen to help us getting rid of those legacies.
>storage is so cheap
>tradeoff
I'm not really convinced from those arguments


* I wouldn't be surprised if Apple or a company like Apple (see: a monopoly - Google? - ) finally shoves a new standard down everyone's throats. For greater good.
>>
>>54743075
>It's a single frame, it's at least as much an image as it is a video
Do you know what a video is? Its when you have a file with the extension mp4/webm/avi/mkv etc and that is playable using a video player using codecs made for videos.
what you are looking at is a video, not a picture
>>
>>54743113
Those formats are doing their jobs very satisfactory, and there's little reason to replace them. Less and less by the day. There is hardware produced that specifically takes care of those formats, there are server encoding PNGs all the time etc. Those things add up and in the end there is little momentum for a new format. It would ultimately cost more — a LOT more. There's zero economical interest.
>>
>>54735334
How do you encode them?
>>
>>54743154
It's just a matter of implementation. Videos are just sequences of images. It's not big deal to add a still image mode to video codecs.
>>
>>54743154
A video is a series of images(referred to as frames) that are displayed in a manner that simulates movement. When there's only one frame in a video webp and webm are basically identical aside from the container formats, the difference is how the data is interpreted by software.
>>
>>54743278
>Videos are just sequences of images.
[...] that were bound together in a video format and is meant to be played

>>54743299
>A video is a series of images(referred to as frames) that are displayed in a manner that simulates movement.
i cant believe you guys are actually trying to teach me what videos are. I know they are a bunch of images. but the difference is that
A.) images are usually of higher quality
B.) images are STILL, and not still as in "a paused video" but they are merely a completely static thing, which leads us to:
C.) they consume a lot less to no cpu power (see posts above when anons complained about cpu spikes in that "webm image"
D.) images and video file extensions are there so you can differentiate between them.. imagine if people started using webm as image extension. how would you tell the difference between videos and images ? You wouldnt, you cant.

>webp and webm are basically identical
says who? I havent looked through the source, of course, but i dont think you have either. I dont think they are identical in any way other than they use the same algorithm for compression
>>
>>54735818
Isn't GIF lossy?
>>
>>54743391
Converting to gif may be lossy but gif is considered a lossless format. Gif is lossless if an image has 256 colors or less.
>>
>>54743385
>[...] that were bound together in a video format and is meant to be played
Information is meant to do shit. It's just a matter of interpretation by software.

>A.) images are usually of higher quality
Video codecs usually support everything from blocky shit to lossless. So, no worries.

>B.) images are STILL, and not still as in "a paused video" but they are merely a completely static thing, which leads us to:
So what? A video with a single frame is a still image. What is the exact problem? ALL Video codecs incorporate all capabilities to encode still images. The first video codecs where literally build around JPEG.

>C.) they consume a lot less to no cpu power (see posts above when anons complained about cpu spikes in that "webm image"
What makes you think that? That's just a wrong assumption.

>D.) images and video file extensions are there so you can differentiate between them.. imagine if people started using webm as image extension. how would you tell the difference between videos and images ? You wouldnt, you cant.
That is valid. But it's not really a problem. Just allow for two different file extension to differentiate between the two. So no problem.

> I dont think they are identical in any way other than they use the same algorithm for compression
They are literally the same shit just with a few different bits in the header you idiot.

>>54743391
GIF is lossless as long as the image is 8 bit. For higher depth images it is of course lossy. There are also lossy encoders available, but it's not a feature specified in the standard, but rather an exploit of how GIF encodes images.
>>
>>54743041
$ wget https://i.4cdn.org/g/1464179337366.png -O OP_logo.png
$ ffprobe OP_logo.png
[...]
Stream #0:0: Video: png, rgba(pc), 182x219 [SAR 2835:2835 DAR 182:219], 25 tbr, 25 tbn, 25 tbc
$ cwebp OP_logo.png -o OP_logo.webp
[...]
Stream #0:0: Video: webp, yuva420p(tv, bt470bg/unknown/unknown), 182x219, 25 tbr, 25 tbn, 25 tbc
$ ffmpeg -i OP_logo.png -vcodec libvpx OP_logo_vp8.webm
$ ffprobe OP_logo_vp8.webm
[...]
Stream #0:0: Video: vp8, yuv420p, 182x219, SAR 1:1 DAR 182:219, 25 fps, 25 tbr, 1k tbn, 1k tbc (default)
$ ffmpeg -i OP_logo.png -vcodec libvpx-vp9 OP_logo_vp9.webm
$ ffprobe OP_logo_vp9.webm
[...]
Stream #0:0: Video: vp9 (Profile 1), gbrp(pc, gbr/unknown/unknown), 182x219, SAR 1:1 DAR 182:219, 25 fps, 25 tbr, 1k tbn, 1k tbc (default)
$ cwebp -lossless OP_logo.png -o OP_logo_lossless.webp
$ ffprobe OP_logo_lossless.webp
[...]
Stream #0:0: Video: webp, argb, 182x219, lossless, 25 tbr, 25 tbn, 25 tbc
$ bpgenc -lossless OP_logo.png OP_logo_lossless.bpg
$ flif -e OP_logo.png OP_logo.flif
$ stat -c '%s %n' OP_*
12810 OP_logo.flif
11978 OP_logo_lossless.webp
18382 OP_logo.png
8198 OP_logo_vp8.webm
7761 OP_logo_vp9.webm
5278 OP_logo.webp
>>
>>54743154
in b4 >gif is an image and not a video
>>
>>54743385
>B.) images are STILL, and not still as in "a paused video" but they are merely a completely static thing, which leads us to:
>C.) they consume a lot less to no cpu power (see posts above when anons complained about cpu spikes in that "webm image"
The reason why the video uses so much power is that it's being interpreted the wrong way. They would consume the same amount if they were being interpreted the same way. The browser doesn't view that file as an image which is what it is it sees it as a video and the way the vidoe is set up it's designed to loop when it finishes. The webm finishes immediately because it's just one frame so it tries to loop and it probably does this thousands of times a second which is why it's using so much CPU time. It actually doesn't have to use that much CPU though it's just being interpreted the wrong way.


>I dont think they are identical in any way other than they use the same algorithm for compression
"Webp" is just a VP8 I-frame. The primary difference between webp and a single frame vp8/webm video is the container and the file extension.

http://antimatter15.com/wp/2010/10/weppy-javascript-shim-for-webp-on-chrome-6-and-firefox-4-0/
>>
>>54743106
>>54743278
>Videos are just sequences of images.
Video is never rgb.
https://stackoverflow.com/questions/21484579/rgb-frame-encoding-ffmpeg-libav
>>
>>54743494
>Information is meant to do shit. It's just a matter of interpretation by software.
software cant interpret or think on its own.

>So what? A video with a single frame is a still image.
nope. an image is an image. a video is a video. try changing an image file test.jpg to test.avi. not gonna happen

>What makes you think that? That's just a wrong assumption.
Its a fact. I had the problem with my own computer and other anons did too in here.

>They are literally the same shit just with a few different bits in the header you idiot.
tell me how to change the header of an image file to make it viewable in a video player

>>54743541
Fuck gif. gif is stupid. it was removed from the internet

>>54743564
>The webm finishes immediately because it's just one frame so it tries to loop and it probably does this thousands of times a second which is why it's using so much CPU time. It actually doesn't have to use that much CPU though it's just being interpreted the wrong way.
But if you give it more than 1 frame then it becomes a series of images again thus a video.
>>
>>54743194
>It would cost more
>economical interest in slowing down progress
sure, the same happens with e.g. the energy sector (we're actively slowly down the adoption of techs that could be more convenient if we switched to them en masse)
That's why I wrote that something "epochal" has to happen. Every now and then a revolution is needed to quit stagnation
>>
>>54743533
oops, correction
$ bpgenc -lossless OP_logo.png -o OP_logo_lossless.bpg
$ stat -c '%s %n' OP_*
12810 OP_logo.flif
19954 OP_logo_lossless.bpg
11978 OP_logo_lossless.webp
18382 OP_logo.png
8198 OP_logo_vp8.webm
7761 OP_logo_vp9.webm
5278 OP_logo.webp

>what does this mean
in the lossless championship, bpg performs worse, flif performs better than png but worse than lossless webp.
in the lossy championship.... webp wins over vp8 and vp9. The conversion to vp8 and vp9 lost the alpha channel, retained in webp. In lossless webp, both rgb and alpha channel are preserved.

TL;DR
webp.
>>
>>54743533
>>54743676
I found these to be the best for encoding webp's

$ cwebp -q 90 -m 6 -v INPUT.jpg -o OUTPUT.webp


-q can go up to 100 and -m to 6 (its the highest compression thus taking the longest time to encode)
>>
>>54743573
lossy images usually neither. Shouldn't be too hard to implement it differently anyway.

>>54743595
>software cant interpret or think on its own.
Software is doing whatever we program it to do. If tell it to treat a video with a single frame like an image, it will do that.

>nope. an image is an image. a video is a video. try changing an image file test.jpg to test.avi. not gonna happen
Because it's not implemented that way. But you could with no disadvantages whatsoever.

>Its a fact. I had the problem with my own computer and other anons did too in here.
No it's not a fact. Video codecs are usually implemented extremely efficiently.

>tell me how to change the header of an image file to make it viewable in a video player
It is up to implementation. See everything people have written before in this thread. If you save a video with a single video stream and a single frame in it and introduce some flag in the header of the container that declares a still image, that would work without any problems whatsoever.

>But if you give it more than 1 frame then it becomes a series of images again thus a video.
Yeah but you just don't. I'm starting to think your posts are bait, you sound like you are acting retarded.
>>
>>54743722
>cwebp has switches
yes, we did test all those. -m 6 is not always a good idea and it does not always lead to the better results - it can lead to a single better results, but on a large batch work -m 3 performed better
>-q 100
just go -lossless or -near_lossless
>>
>>54743041
>Video and images use different colour spaces.
. . .
>>
>>54743573
>Video is never rgb.
Categorically, blatantly and trivially false
>>
>>54743759
>Software is doing whatever we program it to do
yes and we programed cwebp to encode to images and whatever else to encode to videos

>If tell it to treat a video with a single frame like an image, it will do that.
nope. it will treat a single frame video like a video. thats why its called video

>Because it's not implemented that way
nope.

>No it's not a fact. Video codecs are usually implemented extremely efficiently.
webp and webm have the same compression, if thats what you mean. and it has become a fact that moment i checked my cpu usage

>See everything people have written before in this thread.
I have

>If you save a video with a single video stream and a single frame in it and introduce some flag in the header of the container that declares a still image, that would work without any problems whatsoever.
obviously you havent read the thread. i was the FIRST one to try that out in my browser, and it did not work because images are not videos

>Yeah but you just don't. I'm starting to think your posts are bait, you sound like you are acting retarded.
whether you give it 1 frame or 100 doesnt make a differnce. its a video with 1 frame
>>
>>54743595
>try changing an image file test.jpg to test.avi. not gonna happen
>tell me how to change the header of an image file to make it viewable in a video player
try renaming test.jpg to test.png and seeing if it gets parsed by a PNG decoder, you dumb piece of shit

>Its a fact. I had the problem with my own computer and other anons did too in here.
works fine in my image viewer
>>
>>54743904
Name a single standard video format using RGB.
Protip: you can't.
>>
>>54743925
>try renaming test.jpg to test.png and seeing if it gets parsed by a PNG decoder, you dumb piece of shit
i dont know what "parsed" means. also why call me a dumb piece of shit? im sorry i think you are the one who missed the point that .jpg to .avi is actually image -> video and .jpg to .png is actually image -> image. of course it will work chaning it from png to jpg. because both are images. lol youre really stupid
>>
>>54743906
>>54743958
Retarded or bait, either way, I see no point explaining this stuff to someone without even the most basic understanding of video codecs and file formats in general.
>>
>>54743943
MPEG-2
MPEG-4 Part 10 (AVC / H.264)
HEVC / H.265
VP8
VP9
Ogg Theora
etc.

need more?
>>
>>54744007
None of those use RGB. Do you want to try again?
>>
>>54744027
Who gives a shit? Fucking JPG doesn't use RGB and nobody gives a shit.
>>
>>54744071
>I was wrong
No need to apologize.
>>
File: just get out troll.webm (3 MB, 1918x1038) Image search: [Google]
just get out troll.webm
3 MB, 1918x1038
>>54743997
>>
>>54744027
>None of those use RGB.
λ convert rose: rose.png
λ ffmpeg -i rose.png -colorspace rgb rose.h264
...
λ mediainfo rose.h264
...
Color space : RGB
...


Why do I even bother replying to clueless morons?
>>
>>54744103
>look at me forcing RGB colorspace
That's not a standard video format. I can force any video format in non-standard ways.
You were wrong, no need to apologize.
>>
>>54744103
>>54744148
and btw, that's gbrp.
>>
>>54744097
On the off chance you're not trolling and are just genuinely stupid, that shows you're wrong. It still opens correctly because all those programs detect the type from the header. You can see that in media info and the warning from irfanview.
>>
>>54744198
What?
>>
>>54735334
>no support in other browsers (like apng on firefox)
>no thumbnail
>no native support to view
>needs to convert into another file to open in a program
>>
File: rgb.png (58 KB, 1316x395) Image search: [Google]
rgb.png
58 KB, 1316x395
>>54744123
>imagemagick
>ffmpeg
????

>That's not a standard video format.
Have you actually read any of the relevant standards or are you pulling shit out of your ass?
>>
>>54744198
not even the anon(s?) you're arguing with, but that webm is just a display of your own stupidity.
>>
>>54744097
Now rename it to .avi and open it in IrfanView
>>
>>54744256
Im done doing testings. otherwise you give me hard proof or you can fuck off.
>>
File: mvi.png (10 KB, 412x725) Image search: [Google]
mvi.png
10 KB, 412x725
>>54744264
>Hard proof
Hard proof of what? That I the file extension has zero relevance on my image viewer's ability to view images?
>>
>>54744294
>opens an image with a player
>Exiting ...
>>
>>54744208
>>54744243
That was directed at this idiot
>>54743906
>>54743958
who seems to think that all image formats are special, and that you can convert between them by changing the extension.

>>54744243
>not even the anon(s?) you're arguing with
I wasn't part of the argument either, that was my first post.
>>
>>54744325
That's why I have this in my config

[extension.png]
pause
[extension.jpg]
pause
[extension.jpeg]
pause
[extension.tiff]
pause
[extension.ppm]
pause
[extension.pnm]
pause
[extension.webp]
pause

(I just added the last one)
>>
>>54744359
>who seems to think that all image formats are special, and that you can convert between them by changing the extension.
i dont think that. im merely using your own logic. you think think images are videos and videos are images just because your video player can open it. im just doing exactly what you are doing.

can you now finally step aside the damn header and go into the actual process of how a webp and webm is made on its mainpart / body ?
>>
>>54744394
>can you now finally step aside the damn header and go into the actual process of how a webp and webm is made on its mainpart / body ?
WebP is just a VP8 keyframe with a RIFF header slapped on it
>>
>>54735334
this is just plain stupid, we already have modern jpeg, which works amazing for real life pictures; for everything else we have png with allows for lossless compression.
>>
>>54744473
>A WebP file contains either a still image (i.e., an encoded matrix of pixels) or an animation.
funny how they even distinguish images from animations. now just think of videos.


>>54744518
jpgs are larger
>>
>>54744394
>you think think images are videos and videos are images
Videos are just sequences of images. If you have a video with 1 frame, you could just treat it like an image.
>>
>>54744365
I just realized I could get rid of that ‘pause’ profile list and do this instead:

function check_image(event)
frames = mp.get_property_number("estimated-frame-count")

if (frames <= 1) then
mp.set_property_bool("pause", true)
end
end

mp.register_event("file-loaded", check_image)
>>
>>54744237
>I don't know the difference between rgb, rgba, gbrp, YUV; nor why YUV exists
>I've found by chance this ITU draft on h264 mentioning GBR - and in the Annex E there's something about R,G,B and D
>I can totally encode a video in sRGB; RGB is actually a standard and convenient way to encode a video
you never encoded a video in your own life, isn't it.

>>54744518
>this technology is better, but we can ditch it and ADD MORE CORES
>>
>>54744640
RGB = red, green, blue
RGBA = red, green, blue, alpha
GBRP = green, blue, red (planar)
YUV = luma (y by convention from XYZ) and chroma (u/v)
>why YUV exists
Multiple reasons. Primarily due to less redundancy between planes as well as lessened importance of chroma planes.

>you never encoded a video in your own life, isn't it.
I work on video software you dumb sack of shit.

Do you have an actual point?
>>
>>54744575
>Videos are just sequences of images. If you have a video with 1 frame, you could just treat it like an image.
no. since youre all just bullshitting im gonna read up the documentation myself and make up my own mind
>>
>>54744791
>no.
yes. That's literally what my media viewer does.

If the source only contains 1 frame, it gets treated as an image file.
>>
>>54744704
>less redundancy
that's a quite euphemistically way to say it. Using RGB would be hell. That's why RGB is never used in video formats, even if you can cast bizarre colour spaces.
>I work on video software
Ahahaha - sure, so you never encoded a video in your own life because you were too busy working on this video software isn't it

vp9 is the only video codec who recognized the still image and applied gbrp ( >>54743533 ); on an actual video it would have used yuv.
>>
File: yesyoucan.webm (216 KB, 1272x580) Image search: [Google]
yesyoucan.webm
216 KB, 1272x580
>>54735334
>https://developers.google.com/speed/webp/faq#server-side_content_negotiation_via_accept_headers
>http://caniuse.com/#feat=webp
There's no reason for a webmaster not to serve webp to master race clients.
>>
>>54744956
>Using RGB would be hell.
It's only about 30% larger (judging by a quick and informal test)

λ ffmpeg -i ~/test.mp4 -to 0:10 -colorspace rgb -c:v libx265 -pix_fmt gbrp -crf 20 test-rgb.mkv
...
λ ffmpeg -i ~/test.mp4 -to 0:10 -colorspace bt709 -c:v libx265 -pix_fmt yuv444p -crf 20 test-yuv.mkv
...
λ ll test-*.mkv
-rw-r-----. 1 nand nand staff_u:object_r:user_tmpfs_t 35Mb May 26 02:54 test-rgb.mkv
-rw-r-----. 1 nand nand staff_u:object_r:user_tmpfs_t 27Mb May 26 02:55 test-yuv.mkv


>Ahahaha - sure, so you never encoded a video in your own life because you were too busy working on this video software isn't it
You can believe whatever you want to believe, but if you want to be taken seriously, present facts.

>vp9 is the only video codec who recognized the still image
VP9 is a standard, it can't “recognize” shit. I think you're talking about libvpx/FFmpeg?

>claims to be some sort of encoding "expert"
>doesn't realize the difference between a standard and an implementation
>>
>>54745124
Also, for completeness' sake

λ ffmpeg -i ~/test.mp4 -to 0:10 -colorspace ycocg -c:v libx265 -pix_fmt yuv444p -crf 20 test-ycocg.mkv
...
λ ll test-*.mkv
-rw-r-----. 1 nand nand staff_u:object_r:user_tmpfs_t 35Mb May 26 02:54 test-rgb.mkv
-rw-r-----. 1 nand nand staff_u:object_r:user_tmpfs_t 27Mb May 26 03:02 test-ycocg.mkv
-rw-r-----. 1 nand nand staff_u:object_r:user_tmpfs_t 27Mb May 26 02:55 test-yuv.mkv


(YCoCg is the colorspace you would actually pick for encoding RGB data losslessly)
>>
>>54745124
>judging by a quick and informal test
So, you are really clueless. No, size is blasted out of proportions if you convert to RGB. And no, you're proving nothing.
>test-rgb.mkv
That's a yuv444p.
>test-yuv.mkv
and that's a yuv444p as well.

On which software are you working? So I can avoid it in the future.

>VP9 is a
codec. VP8 is a codec. VP8L is a codec. Their bitstream are standardized (ty Capt. Obvious). Obviously I'm talking of the sane defaults in the default (suggested) use of the libvpx encoder.

>>54745219
>YCoCg is the colorspace you would actually pick for encoding RGB data losslessly
That's yuv444p too! Something else to show me?
>>
>>54735414
JPEG and PNG are both great in their respective categories. But I don't know why anyone would convert an image from a PNG to a JPEG for no reason.
https://imgs.xkcd.com/comics/standards.png
>>
>>54735591
>having loop enabled
That's your fault.
>>
>>54745309
>That's a yuv444p.
λ ffprobe test-rgb.mkv
...
Stream #0:0: Video: hevc (Rext), gbrp(tv, gbr/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn (default)


Why do I keep responding to cheap bait by a clueless moron?

>On which software are you working? So I can avoid it in the future.
mpv

feel free to avoid it, I don't give a shit. I don't need idiotic users like you
>>
>>54745393
Even rgba and gbrp inputs produce yuv444p with that cli. And I've libx265 and ffmpeg compiled from git.
Why do you need to lie that much?
>>
>>54745474
>yuv444p
>bgrp
You realize these are just tags, right? The only things that matter for encoding efficiency:

1. Channel depth (how many channels / how many bits per channel)
2. The raw image contents

#1 is the same for all 24-bit 4:4:4 planar formats (grbp and yuv444p)

#2 is independent of the video compressor since video codecs just operate on the raw numbers fed to them.

You can pass RGB data to an encoder and call it YUV if you want to. As long as the decoder on the other end understands to treat the bits that come out as RGB instead of BT.709 YCbCr or whatever.

In the case of FFmpeg, #1 is controlled by
-pix_fmt
(which also controls the channel order, but channel order does not matter for efficiency) and #2 is controlled by
-colorspace
.

For the test-rgb.mkv clip, the pix_fmt was set to rgb24 (which is a 24-bit planar, 8 bits per pixel, channels in-order) and the colorspace was set to rgb (which means the raw image data stored in the file is gamma-compressed rgb).

>And I've libx265 and ffmpeg compiled from git.
That's cool, me too, but compiling from git doesn't help you actually understand shit apparently.

You realize you're talking to somebody who has literally written parts of FFmpeg, right?
>>
File: 519531.jpg (102 KB, 1920x1080) Image search: [Google]
519531.jpg
102 KB, 1920x1080
what's wrong witchu?
>>
>>54745577
>You realize you're talking to somebody who has literally written parts of FFmpeg, right?
Ahahaha pls anon that's really weird humour.

>You can pass RGB data to an encoder and call it YUV if you want to
In this purely fictional scenario the data is interpreted as YUV
>As long as the decoder on the other end understands to treat the bits that come out as RGB
Does not compute and does not make sense. I seriously hope you realize that none of the options you offered instructed the codec in that way.
>For the test-rgb.mkv clip, the pix_fmt was set to rgb24
and even with -pix_fmt rg24, you get a yuv444p
>just tags
and you are supposed to be a {mpv,ffmpeg} developer? oh my
>>
>>54745749
>Does not compute and does not make sense.
It's okay, these things don't have to make sense to everybody. Video technology is too hard for people like the Firefox developers, after all.
>>
>>54743041
>Video and images use different colour spaces.
most common video uses YUV 4:2:0, most common jpeg images use YUV 4:2:0 as well
jpeg can do 4:2:2 and 4:4:4, but so can some video codecs, such as H.264
Thread replies: 142
Thread images: 15

banner
banner
[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vp / vr / w / wg / wsg / wsr / x / y] [Home]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
If a post contains personal/copyrighted/illegal content you can contact me at [email protected] with that post and thread number and it will be removed as soon as possible.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com, send takedown notices to them.
This is a 4chan archive - all of the content originated from them. If you need IP information for a Poster - you need to contact them. This website shows only archived content.