I saw that vlc gets the decoded image back from the graphics cards when using hardware acceleration, e.g. VAAPI. So I thought this should also work as encoding accelerator, so the CPU only has to encode, not decode the video and cause at least some speedup, especially for large video files encoded into small files. I'm using the GMA500 poulsbo chipset for this test with 1,6 Ghz Atom(TM) CPU Z530.
Benchmarking VLC Encoding/Transcoding Speed
If you need to benchmark how fast vlc transcodes a certain file with certain settings, it's a bit tough. It doesn't seem to have any way to display the frames per second (fps) during encoding and no benchmark option as mplayer. A good way to work around this is to check how long it takes vlc to encode a certain file for a few seconds, e.g.
time vlc --stop-time 25 (...) vlc://quit.
e.g. time vlc --stop-time 25 /D/MVI_6615.MOV --sout "#transcode{width=384,height=288,vcodec=h264,acodec=vorbis}:standard{access=file,mux=mkv,dst=test.mkv}}" --sout-x264-crf=24 --sout-transcode-threads=2 vlc://quit
This encodes for 25 seconds and then quits and displays the time it took. Make sure to have vlc://quit at the very end of the command line and after your input file. The "user" value is what matters, this shows how long it kept the cpu occupied. Of course this only works on Unix systems. Also be aware that the second time the input file comes from cache, so only use the values from the second or later encodings for comparison.
time vlc --stop-time 25 (...) vlc://quit.
e.g. time vlc --stop-time 25 /D/MVI_6615.MOV --sout "#transcode{width=384,height=288,vcodec=h264,acodec=vorbis}:standard{access=file,mux=mkv,dst=test.mkv}}" --sout-x264-crf=24 --sout-transcode-threads=2 vlc://quit
This encodes for 25 seconds and then quits and displays the time it took. Make sure to have vlc://quit at the very end of the command line and after your input file. The "user" value is what matters, this shows how long it kept the cpu occupied. Of course this only works on Unix systems. Also be aware that the second time the input file comes from cache, so only use the values from the second or later encodings for comparison.
About lost messages in Google mail
This morning, at 8 AM I received a message In my Gmail inbox. About 5 PM I started writing a reply to the message on my smartphone. I wrote about six sentences and when I was about to finish the e-mail and checked back to the original message. And it had disappeared.
The only thing left from it is the part saying: reply to the message from ... sent ... .
The draft of the reply is still in my inbox and marked important. So I thought there should be enough reference for recovery and contacted Google about it and I have already received a reply: there's nothing they can do about it.
So please, be aware Google does not guarantee 100% reliability in their e-mail service. You may get a very very important e-mail and if you have no other copy it may be completely gone - forever. If you need that get another provider. Back up your email you receive there regularly.
And let me quote:
"Because there's unfortunately no more we can do to try to recover these messages, we won't be able to respond to future inquiries."
Maybe they removed the beta label to early...
PS: with two step authentication I think it's not very likely someone would break into my account to delete a private message of a student...
Subscribe to:
Posts (Atom)