I want to encode some videos in H264 and H265, and I would like to ask for help in order to chose the adequate options in x264/x265.
My first priority is video quality. Lossless would be the best quality for example
My second priority is fast decoding speed (ie: I would like faster decoding without sacrificing quality)
fast decoding for me means that the decoding machine would use less CPU resources reading the resulting video
Less RAM consumption would be a plus
Latency is not important
I don't care that much if the output file ends up bigger. Also, encoding speed is not important
I'm aware of the option -tune fastdecode in both x264 and x265. But apparently the quality gets a bit worse using it.
For x264:
-tune fastdecode is equivalent to --no-cabac --no-deblock --no-weightb --weightp 0 (My source is x264 --fullhelp)
Which options preserve quality ?
For x265:
-tune fastdecode is equivalent to --no-deblock --no-sao --no-weightp --no-weightb --no-b-intra (according to x265 doc)
Again, which options preserve quality ?
I tried to read some documentation on these options, but I'm afraid I'm too stupid to understand if they preserve quality or not.
To explain further what I mean by "preserving quality":
I don't understand what the cabac option does exactly. But let's say for example that it adds some extra lossless compression, resulting in a smaller video file, but the decoding machine would need to do extra work to decompress the file
In that case, the --no-cabac option would skip that extra compression, resulting in no loss of quality, with a bigger file size, and the decoding machine would not need to decompress the extra compression, saving CPU work on the decoding side
In this scenario, I would like to add the --no-cabac option, as it speeds up decoding, while preserving quality.
I hope I could get my point across
Can anyone help me pick the right options ?
Thanks in advance
As #O.Jones illuded to "it depends" is the best answer you're going to get. As the author of Compressarr, I can tell you figuring the answer to that question, per video, takes hours.
Basically, encode the video (using best guess values), check it for SSIM against the original. Decide what percentage of similarity is acceptable. (Above 98% is supposed to be an imperceivable difference) Check your file size and repeat with new options as necessary. You can get away with using samples, so you don't have to do the whole thing, but then the final SSIM is only a guess.
Or just use Compressarr and let it automate all that for you. :D
Related
I have a server talking to a mobile app, and this app potentially does thousands of requests per day. I don't care that much about performance in this particular case, so saving some miliseconds isn't as big as a concern as saving bandwidth - especially since I'm paying for it.
(1) What is the advantage of using JSON over binary here, when bandwidth is a much bigger deal than performance? I mean, I have read some people saying that the size difference between raw data and JSON isn't really that much - and that might as well be partially true, but when you have thousands of daily requests being made by hundreds of thousands of users, merely doubling the amount of bytes will have a huge impact on bandwidth usage - and in the end, on the server bill.
Also, some people said that you can easily alter the JSON output format, while changing the binary serialization might be a little more complicated. Again, I agree, but shouldn't it be a little more complicated than that? Like, what are the odds that we're gonna change our format? Will the ease of change make up for JSON's bandwidth excess?
(2) And finally, I stumbled upon this link while doing some research on this topic, and in the summary table (Ctrl + F, 'summary') it says that the JSON data size is smaller than the actual binary data? How is that even possible?
I would very much appreciate some answers to these questions.
Thank you in advance.
thousands of requests per day
that's ... not really a lot, so most approaches will usually be fine
What is the advantage of using JSON over binary here, when bandwidth is a much bigger deal than performance?
JSON wouldn't usually have an advantage; usually that would go to binary protocols - things like protobuf; however, compression may be more significant than choice of protocol. If you want meaningful answers, however, the only way to get that is to test it with your data.
If bandwidth is your key concern, I'd go with protobuf, adding compression on top if you have a lot of text data in your content (text compresses beautifully, and protobuf simply uses UTF8, so it is still available for compression).
it says that the JSON data size is smaller than the actual binary data?
JSON contains textual field names, punctuation (", :, ,), etc - and all values are textual rather than primitive; JSON will be larger than good binary serializers. The article, however, compares to BinaryFormatter; BinaryFormatter does not qualify as a good binary serializer IMO. It is easy to use and works without needing to do anything. If you compare against something like protobuf: protobuf will beat JSON every time. And sure enough, if we look at the table: JSON is 102 or 86 bytes (depending on the serializer); protobuf-net is 62 bytes, MsgPack is 61, BinaryFormatter is 669. Do not conflate "a binary serializer" with BinaryFormatter. I blame the article for this error, not you. MsgPack and Protocol Buffers (protobuf-net) are binary serializers, and they come out in the lead.
(disclosure: I'm the author of protobuf-net)
I am going to be working on self-chosen project for my college networking class and I just had a couple questions to help get me started in the right direction.
My project will involve creating a new "physical" link over which data, in the form of text, will be transmitted from one computer to another. This link will involve one computer with a webcam that reads a series of flashing colors (black/white) as binary and converts it to text. Each series of flashes will simulate a packet of data. I will be using OSX an the integrated webcam in a Macbook, the flashing computer will either be windows or osx.
So my questions are: which programming languages or API's would be best for reading live webcam data and analyzing the color of a certain area as well as programming and timing the flashes? Also, would I need to worry about matching the flash rate of the "writing" computer and the frame capture rate of the "reading" computer?
Thank you for any help you might be able to provide.
Regarding the frame capture rate, Shannon sampling theorem says that "perfect reconstruction of a signal is possible when the sampling frequency is greater than twice the maximum frequency of the signal being sampled". In other words if your flashing light switches 10 times per second, you need a camera of more than 20fps to properly capture that. So basically check your camera specs, divide by 2, lower the resulting a little and you have your maximum flashing rate.
Whatever can get the frames will work. If the light conditions in which the camera works are gonna be stable, and the position of the light on images is gonna be static then it is gonna be very very easy with checking the average pixel values of a certain area.
If you need additional image processing you should probably also find out about OpenCV (it has bindings to every programming language).
To answer your question about language choice, I would recommend java. The Java Media Framework is great and easy to use. I have used it for capturing video from webcams in the past. Be warned, however, that everyone you ask will recommend a different language - everyone has their preferences!
What are you using as the flashing device? What kind of distance are you trying to achieve? Something worth thinking about is how are you going to get the receiver to recognise where within the captured image to look for the flashes. Some kind of fiducial marker might be necessary. Longer ranges will make this problem harder to resolve.
If you're thinking about shorter ranges, have you considered using a two-dimensional transmitter? (given that you're using a two-dimensional receiver, it makes sense) and maybe have a transmitter that shows a sequence of QR codes (or similar encodings) on a monitor?
You will have to consider some kind of error-correction encoding, such as a hamming code. While encoding would increase the data footprint, it might give you overall better bandwidth given that you can crank up the speed much higher without having to worry about the odd corrupt bit.
Some 'evaluation' type material might include you discussing the obvious security risks in using such a channel - anyone with line of sight to the transmitter can eavesdrop! You could suggest in your writeup using some kind of encryption, a block cipher in CBC would do, but would require a key-exchange prior to transmission, so you could think about public key encryption.
I am trying to encode a stream using x264 (by feeding individual images), but what's unusual is that I already have some motion information for my frames. I know exactly which areas have been modified in each frame, and I know where motion has occurred in the frame.
Is there a way to feed x264 my own motion information? I'd like to give it motion vectors for given areas in the frame, and somehow tell it that certain areas in the frame are guaranteed to not have had any motion in them.
I think this might significantly improve the performance of the encoding (because I'm allowing the codec to completely skip the motion estimation phase), and should also somewhat increase quality in cases where the encoder's motion estimation algos might have missed the motion that actually occurred.
Do I need to modify the encoder in order to do this, or is this supported in the existing API?
Short answer: No you can't feed in your motion estimation data to x264.
Long Answer: IIRC, x264 does it's work by being fed in the raw frame, with no extra data. To accommodate the motion estimation data you have, you'd have to modify the x264 source code to accomplish this.
You may be able to find what you need within common\mvpred.c or encoder\me.c. I'm not sure how many of the x264 developers actually visit Stack overflow (I know one of their lead developers has an account here) but you can try talking to them through their usual channels on their IRC channel or on the doom9 forums.
doom9: http://forum.doom9.org/forumdisplay.php?f=77
doom10:http://doom10.org/index.php?board=5.0 IRC:
irc://irc.freenode.net/x264 and irc://irc.freenode.net/x264dev
Mailing list: http://mailman.videolan.org/listinfo/x264-devel
I wish I could give you more information, but unfortunately I'm not particularly well versed in the code base. The developers are always willing and able to help anyone wishing to work on x264 though.
Are there any compression algorithms -- lossy or lossless -- that have been specifically adapted to deal with real-world (messy and invalid) HTML content?
If not, what characteristics of HTML could we take advantage of to create such an algorithm? What are the potential performance gains?
Also, I'm not asking the question to serve such content (via Apache or any other server), though that's certainly interesting, but to store and analyze it.
Update: I don't mean GZIP -- that's obvious -- but rather an algorithm specifically designed to take advantage of characteristics of HTML content. For example, the predictible tag and tree structure.
Brotli is a specialized HTML/english compression algorithm.
Source: https://en.wikipedia.org/wiki/Brotli
Unlike most general purpose compression algorithms, Brotli uses a
pre-defined 120 kilobyte dictionary. The dictionary contains over
13000 common words, phrases and other substrings derived from a large
corpus of text and HTML documents.[6][7] A pre-defined dictionary can
give a compression density boost for short data files.
I do not know of "off-the-shelf" compression library explicitly optimized for HTML content.
Yet, HTML text should compress quite nicely with generic algorithms (do read the bottom of this answer for better algorithms). Typically all variations on Lempel–Ziv perform well on HTML-like languages, owing to the highly repeatitive of specific language idioms; GZip, often cited uses such a LZ-based algoritm (LZ77, I think).
An idea to maybe improve upon these generic algorithms would be to prime a LZ-type circular buffer with the most common html tags and patterns at large. In this fashion, we'd reduce the compressed size by using citations from the very first instance of such a pattern. This gain would be particularly sensitive on smaller html documents.
A complementary, similar, idea, is to have the compression and decompression methods imply (i.e. not send) the info for other compression's algorithm of an LZ-x algorithm (say the Huffman tree in the case of LZH etc.), with statistics specific to typical HTML being careful to exclude from characters count the [statistically weighted] instances of character encoded by citation. Such a filtered character distribution would probably become closer to that of plain English (or targeted web sites' national languge) than the complete HTML text.
Unrelated to the above [educated, I hope] guesses, I started searching the web for information on this topic.
' found this 2008 scholarly paper (pdf format) by Przemysław Skibiński of University of Wrocław. The paper's abstract indicates a 15% improvement over GZIP, with comparable compression speed.
I may be otherwise looking in the wrong places. There doesn't seem to be much interest for this. It could just be that the additional gain, relative to a plain or moderately tuned generic algorithm wasn't deemed sufficient enough to warrant such interest, even in the early days of Web-enabled cell phones (when bandwidth was at quite a premium...).
About the only "lossy" I am willing to deal with in HTML content, messy or not, is whitespace flattening. This is a typical post-publish step that high volume sites perform on their content, also called flattening.
You can also flatten large Javascript libs using the YUI compressor, which renames all Javascript vars to short names, removes whitespace, etc. It is very important for large apps using kits like ExtJS, Dojo, etc.
Is gzip compression not sufficient for your needs? It gives you about 10:1 compression ratio, not only with HTML contents but also with JavaScript, CSS etc. files, and is readily available on most servers or reverse proxies (e.g. Apache's mod_deflate, Nginx's NginxHttpGzipModule etc.) and all modern browsers (you can instruct both Apache and Nginx to skip compression for specific browsers based on User-Agent.)
You'll be surprised how close gzip compression comes to optimal. Some people have suggested minifying your files; however, unless your files contain lots of comments (which the minifier can discard completely, i.e. what you probably referred to as "lossy" -- but something you probably don't want to do with HTML anyway, not unless you're sure that none of your <script> or <style> tags are inside HTML comments <!-- --> to accommodate antediluvian browsers), remember that minifying achieves most of its gains from a technique similar to (yet more limited than) DEFLATE -- so expect a minified file to be larger or much larger than a gzipped original (particularly true with HTML, in which you are stuck with W3C's tags and attributes, and only gzip can help you there), and that gzipping a minified file will give you minimal gain over gziping the original file (again, unless the original file contained lots of comments which can be safely discarded by a minifier.)
Use S-expressions instead, saves you a number of characters per tag :)
if i understand your question correctly what you need is gz compression, which is available pretty easily with Apache.
Run your code thru some HTML minificator/obfuscator that removes as much markup as possible, then let your web server compress it with gzip.
No, there are not any HTML-specific compression algorithms, because the general-purpose ones have proved adequate.
The potential gains would come from knowing ahead of time the likely elements of an HTML page - you could start with a predefined dictionary that would not have to be part of the compressed stream. But this would not give a noticeable gain, as compression algorithms are extraordinarily good at picking out common sub-expressions on the fly.
You would usually use a common algorithm like gzip which is supported by most browsers through the HTTP protocol. The Apache documentation shows how to enable mod_deflate without breaking the browser support of your website.
Additionally you can minimize static HTML files (or do that dynamically).
You could consider each unique grouping (i.e. tags & attribs) as a symbol, determine a minimum symbol count and re-encode using Shannon's entropy; this would generate one large blob of bytes with maximal compression. I will say that this may not be much better than gzip.
I am trying to find out if there are any principles in defining which pages should be gzip-compressed and to draw a line when to send plain html content.
It would be helpful if you guys can share the decisions you took in gzip-compressing a part of your project.
A good idea is to benchmark, how fast is the data coming down v.s. how well compressed is it. If it takes 5 seconds to send something that went from 200K to 160K it's probably not worth it. There is a cost of compression on the server side and if the server gets busy it might not be worth it.
For the most part, if your server load is below 0.8 regularly, I'd just gzip anything that isn't binary like jpegs, pngs and zip files.
There's a good write up here:
http://developer.yahoo.com/performance/rules.html#gzip
Unless your server's CPU is heavily utilized, I would always use compression. It's a trade-off between bandwidth and CPU utilization, and webservers usually have plenty of spare CPU cycles to spare.
I don't think there's a good reason not to gzip HTML content.
It takes very little CPU power for big gains in loading speed.
There's one notable exception: There's a bug in Internet Explorer 6, that makes all compressed content turn up blank.
Considering there is a huge gain on the size of the HTML data to download when it's gzipped, I don't see why you shouldn't gzip it.
Maybe it uses a little bit of CPU... But not that much ; and it's really interesting for the client, who has less to download. And it's only a couple of lines in the webserver configuration to activate it.
(But let your webserver do that : there are modules like mod_deflate for the most used servers)
As a semi-sidenote : you are talking about compressing HTML content pages... But stop at HTML pages : you can compress JS and CSS too (they are text files, and, so, are generally compressed really well), and it doesn't cost much CPU either.
Considering the big JS/CSS Frameworks in use nowadays, the gain is probably even more consequent by compressing those than by compressing HTML pages.
We made the decision to gzip all content since spending time determining what to gzip or what not to gzip did not seem worth the effort. The overhead of gzipping everything is not significantly higher than gzipping nothing.
This webpage suggests:
"Servers choose what to gzip based on
file type, but are typically too
limited in what they decide to
compress. Most web sites gzip their
HTML documents. It's also worthwhile
to gzip your scripts and stylesheets,
but many web sites miss this
opportunity. In fact, it's worthwhile
to compress any text response
including XML and JSON. Image and PDF
files should not be gzipped because
they are already compressed. Trying to
gzip them not only wastes CPU but can
potentially increase file sizes."
If you care about cpu time, I would suggest not gzipping already compressed content. Remember when adding complexity to a system that Programmers/sys admins are expensive, servers are cheap.