I found the default setting of x264enc is very poor. Is there any way to get a good preset for it? I only saw speed-preset But this does not affect the quality much. Is there any think like following:
Presets:
"Profile Baseline"
"Profile High"
"Profile Main"
"Profile YouTube"
"Quality High"
"Quality Low"
"Quality Normal"
I am using pass=qual. The bitrate is used as max value. Is there any good preset can affect this value?
If you use pass=qual you should also set the quantizer property. Lower values result in higher quality/bitrate. In pass=qual the bitrate property is ignored.
Related
Background: I was testing a nfs-server with fio. And I find that no matter how much "iodepth" is set to fio. The nfs-server can only have "64 Inflight". So I just suspect that somewhere around "nfs protocol" limits the max concurrent(max io in flight).
fio command is
fio -numjobs=1 -iodepth=128 -direct=1 -ioengine=libaio -sync=1 -rw=write -bs=4k -size=500M -time_based -runtime=90 -name=Fiow -directory=/75
My nfs-server is based on ganesha, and got conclusion "64 Inflight" by using ganesha_stats.py.
So I have two options for now:
Study the calling-graph and read code to find the problem
I download linux kernel code, but struggle to . Which function/source file should I begin , maybe vfs.c:nfsd_write?
Tried to use 'perf' to trace calling-graph to speed up my code reading tour for linux kernel, but failed. Because 'perf report' shows shared library symbol without function name.
Learn the nfs protocol/mount cmd to seek the limit.
Can somebody can help me with this? :)
Assuming you're using NFSv4.1 (RFC 5661):
In NFSv4.1, the number of outstanding requests is bounded by the size of the slot table [...].
And in Linux:
#define NFS4_DEF_SLOT_TABLE_SIZE (64U)
It is the default for this module param:
module_param(max_session_slots, ushort, 0644);
MODULE_PARM_DESC(max_session_slots, "Maximum number of outstanding NFSv4.1 "
"requests the client will negotiate");
IIUC the total maximum for this is:
#define NFS4_MAX_SLOT_TABLE (1024U)
I'm working on a gstreamer application that uses x264enc element. According to the document below, there is no property to specify minimum key interval while there's key-int-max.
https://thiblahute.github.io/GStreamer-doc/x264-1.0/index.html?gi-language=c
On the other hand, there's --min-keyint property in FFmpeg option.
https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping
How to set minimum key interval to x264enc element of gstreamer?
Thanks in advance.
You may try the option-string property in x264enc:
option-string : String of x264 options (overridden by element properties)
flags: readable, writable
String. Default: ""
This basically hands of options to libx264. Unfortunately I forgot the syntax that you need to use here.. Could have been option-string=min-keyint=x but perhaps double checking the x264enc element's code should give some more hints here.
When executed with all logging enabled (e.g. test --log_level=all), a unit test created with the Boost Unit Test Framework will report how long an individual test case took with a message like this:
Leaving test case "testRecursiveSchedule"; testing time: 2196mks
The unit displayed there, mks, mystifies me. I understand that Meters-Kilograms-Seconds is a system for metric measurement, but Boost is clearly displaying a time measurement only. Shouldn't the unit in this case be ms if milliseconds or μs (or perhaps us) if microseconds? Is mks commonly understood as an abbreviation for microseconds?
Note that according to the Boost unit test framework source code, the unit displayed will be ms if the elapsed time happens to be evenly divisible by 1000, in which case it will be divided by 1000 before being displayed. That's consistent with the idea that mks is meant to imply microseconds.
But does it? Or is Boost being idiosyncratic here?
Here is my guess: mks means microseconds.
Gennadiy Rozental, the author of Boost.Test, is Russian-speaking, and in Russian microsecond is "микросекунда", abbreviated as "мкс", which can be transliterated as "mks". Sometimes I see "mks" accidentally appearing in works of Russian-speaking people.
The mechanism used to time the tests is
boost::timer tc_timer;
test_unit_id bkup = m_curr_test_case;
m_curr_test_case = tc.p_id;
unit_test_monitor_t::error_level run_result = unit_test_monitor.execute_and_translate( tc );
unsigned long elapsed = static_cast<unsigned long>( tc_timer.elapsed() * 1e6 );
Boost Timer is documented here and promises the following:
double elapsed() const // return elapsed time in seconds
{ return double(std::clock() - _start_time) / CLOCKS_PER_SEC; }
As you can see Boost Tests passes microseconds to the observer's test_unit_finish implementations:
BOOST_TEST_FOREACH( test_observer*, to, m_observers )
to->test_unit_finish( tc, elapsed );
And they indeed print it typically as:
if( elapsed % 1000 == 0 )
output << elapsed/1000 << "ms";
else
output << elapsed << "mks";
or raw microseconds for XML:
if( tu.p_type == tut_case )
ostr << "<TestingTime>" << elapsed << "</TestingTime>";
The effective accuracy depends on the system:
The abbreviation "mks" seems to be non-standard. There are many better alternatives. These would be acceptable: "microsecond(s)", "microsec(s)", and perhaps "micro-s".
Possibly, "µs" is not used as this might confuse systems that still fail to support Unicode correctly, and also noting that there is more than one codepoint for mu: MICRO SIGN at U+00B5, GREEK SMALL LETTER MU at U+03BC. But often, "us" is used instead, as an English 'u' resembles a Greek mu 'µ'. (On units other than the second, it can look less like a word; e.g. the word-like "us", "um", "ug", as compared to the less-word-like microfarad "uF".)
The use of "mks" has at least two other areas of confusion. One is that there is a metric but not-quite-SI system of units called MKS (after metre, kilogram, second). Another is that both "m" and "k" (or sometimes, "K") are already prefixes, so "mks" looks like "milli-kilo-second", which is just a second.
What follows is just speculation…
In the Boost Test sources, the only place that mentions "mks" is boost/test/impl/compiler_log_formatter.ipp in a very odd block of code, but there are no comments giving any clue as to the reason for the choice of "mks". (The code is odd as it changes units based on particular values being exactly roundable, thus failing to indicate precision correctly, and upsetting, about 0.1% of the time, any scripts expecting always to see "mks".)
Possibly the "mk" was to indicate "my-kroh" phonetically (with a hard 'k'), as "mc" might look like "my-sroh", but then "mcs" would also look like "milli-centi-seconds" anyway.
(The only other mention of "mks", in Boost 1.57.0, seems to be mks_system in libs/units/example/test_system.hpp which I'm guessing relates to Boost Unit and the MKS system of units mentioned above.)
I've a .MP4 file. I know MP4 file has some attributes such as: general bitrate,file size.
Video: Max bitrate,min bitrate,avg bitrate,size
Audio: Max bitrate,min bitrate,avg bitrate,size
I want to get the size(or maximum size) per minutes from above attributes.
Can anyone help me?
Thank so much
If the average bitrate is in bits per second (I think it is?), then you can get the "size per minute" like this:
sizePerMin = 60 * avgBitRate
Which will be the size per minute in bits. You can do similar for the max and min size per minute.
Here is an online video-file-size calculator, you can specify your settings, and run it:
http://www.dr-lex.be/info-stuff/videocalc.html
We have an MFC application that handles data with either MS-Access, Oracle or SQL-Server.
For a specific treatment, we have to use database transactions.
On Oracle or SQL-Server, everything is ok, but in MS-Access, we get the "File sharing lock count exceeded. Increase MaxLocksPerFile registry entry." message, as described here http://support.microsoft.com/kb/815281
The question is what is the maximum coherent value that I can put there?
I was thinking about setting this value programatically at the appplication statup...
Thanks
After doing some research, I didn't see any article mentioning a maximum value.
Theoretically, the value being a DWORD, we could put up to FFFFFFFF (hex) or 4294967295 (decimal), but I'm not sure if it's a coherent value.