I am succesfully processing my video into x264. I am happy with the output and file size I am generating, but the video seems to take as long as the video is to process.
For example, if the video is 10 seconds long, it will take 10 seconds to process the video, etc...
Even if I put -crf 50, it will take the same time. I find this odd behaviour.
Note: I am using FFmpeg with FFmpegKit (React Native): https://github.com/tanersener/ffmpeg-kit
I am using full-gpl in order to be able to encode to x264. I am not sure what is wrong here or if this is normal behaviour?
Here is my FFmpeg command I am executing:
`-y -i ${media.path} -c:v libx264 -preset veryfast -tune fastdecode -crf 20 -vf "crop=1350:1080, scale=960:780" -c:a copy -movflags faststart ${path}`
I appreciate all the help I can get here to speed this up / fix this issue.
Cheers!
Related
I want to generate some trace file from disk IO, but the problem is I need the actual input data along with timestamp, logical address and access block size, etc.
I've been trying to solve the problem by using the "blktrace | blkparse" with "iozone" on the ubuntu VirtualBox environment, but it seems not working.
There is an option in blkparse for setting the output format to show the packet data, -f "%P", but it dose not print anything.
below is the command that i use:
$> sudo blktrace -a issue -d /dev/sda -o - | blkparse -i - -o ./temp/blktrace.sda.iozone -f "%-12C\t\t%p\t%d\t%S:%n:%N\t\t%P\n"
$> iozone -w -e -s 16M -f ./mnt/iozone.dummy -i 0
In the printing format "%-12C\t\t%p\t%d\t%S:%n:%N\t\t%P\n", all other things are printed well, but the "%P" is not printed at all.
Is there anyone who knows why the packet data is not displayed?
OR anyone who knows other way to get the disk IO packet data with actual input value?
As far as I know blktrace does not capture the actual data. It just capture the metadata. One way to capture real data is to write your own kernel module. Some students at FIU.edu did that in this paper:
"I/O deduplication: Utilizing content similarity to ..."
I would ask this question in linux-btrace mailing list as well:
http://vger.kernel.org/majordomo-info.html
I am using Bluez4 to sink Audio from an iphone 5 to a Raspberry pi audio output.
The default settings for BLuez 4 A2DP appear to be S16_LE, 44,1kHz Stereo.
Similar to other posts about Bluez, I can't catch Select_Configuration DBus messages in order to change the sample rate dynamically. Instead I decided to try to find the default A2DP sample rate in the BLuez Stack.
Does anyone know where the default sample rate is set? My first thought was that it was in the BLuez/audio/ folder but nothing appears to change the default 44.1kHz sample rate.
Now I'm very curious to know where it is set.
Currently using this: sudo ./a2dp-alsa --sink | aplay -c 2 -r 44100 -f S16
would like to use this sudo ./a2dp-alsa --sink | aplay -c 2 -r 16000 -f S16
I came across these lines in a2dp-alsa.c
/* Initialise connection to ALSA */
g_handle = audio_init("hw:0,0", 48000);
maybe its hard coded in a2dp-alsa - not parameterizable
I am trying to encode a video from raw YUV to MPEG-2 using the ffmpeg API.
My problem is that the API-generated file is approx. 1.7 times bigger than the equivalent files generated by ffmpeg itself.
I use the quantization parameter (via qmin and qmax) instead of the bitrate.
The API-version is basically:
//...
pCodecCtx->pix_fmt = PIX_FMT_YUV420P;
pCodecCtx->qmin = 3;
pCodecCtx->qmax = 3;
pCodecCtx->time_base.num = 1;
pCodecCtx->time_base.den = 30;
avcodec_open(pCodecCtx, avcodec_find_encoder(CODEC_ID_MPEG2VIDEO));
//...
while(/*...*/) {
avcodec_encode_video(pCodecCtx, pOutbuf, outbufSize, pPicture);
//..
}
//...
For ffmpeg itself, I use the command:
ffmpeg -s 352x288 -r 30 -i foreman_352x288.yuv -f mpeg2video -vcodec mpeg2video -r 30 -pix_fmt yuv420p -qmin 3 -qmax 3 foreman.m2v
Why does the API-generate file achieve a bitrate of 5212 kb/s and the file generated by ffmpeg for the same qp a bitrate of 3047 kb/s??
(Even more puzzling is that the smaller ffmpeg version has a slightly higher PSNR, 40.49 dB vs. 40.02 dB).
Are there any other relevant parameters that I missed? Does the ffmpeg actually respect the quantization parameter?
When using the ffmpeg API, the picture type (I-frame, P-frame, etc.) needs to be set manually for each frame. By default, ffmpeg will make every frame an I-frame.
The solution is to set the picture type before encoding a frame (here for a GOP size of 12):
//...
while(/*...*/) {
if(pCodecCtx->frame_number % 12)
pPicture->pict_type = AV_PICTURE_TYPE_P;
avcodec_encode_video(pCodecCtx, pOutbuf, outbufSize, pPicture);
//...
}
//...
Note that setting pCodecCtx->gop_size before the encoding does not help.
I am monitoring a log file by doing "TAIL -n -0 -F filename". But this is taking up a lof of CPU as there are many messages being written to the logfile. Is there a way, I can open a file and read new/few entries and close it and repeat it every 5 second interval? So that I don't need to keep following the file? How can I remember the last read line to start from the next one in the next run? I am trying to do this in nawk by spawning tail shell cmd.
You won't be able to magically use less resources to tail a file by writing your own implementation. If tail -f is using resources because the file is growing fast, a custom version won't help any if you still want to view all lines as they are being written. You are simply limited by your hardware I/O and/or CPU.
Try using --sleep-interval=S where "S" is a number of seconds (the default is 1.0 - you can specify decimals).
tail -n 0 --sleep-interval=.5 -F filename
If you have so many log entries that tail is bogging down the CPU, how are you able to monitor them?
Hallo.
I have a big video file. ffmpeg, tcprobe and other tool say, it is an h264-stream in an AVI-container.
Now i'd like to cut out small chunks form the video.
Problem: The index of the video seam corrupted/destroyed. I kind of fixed this via mplayer -forceidx -saveidx <IndexFile> <BigVideoFile>. The Problem here is, that I'm now stuck with mplayer/mencoder which can use this index file via -loadidx <IndexFile>. I have tried correcting the index like described in man aviindex (mplayer -frames 0 -saveidx mpidx broken.avi ; aviindex -i mpidx -o tcindex ; avimerge -x tcindex -i broken.avi -o fixed.avi), but this didn't fix my video - meaning that most tools i've tested couldn't search in the video file.
Problem: I cut out parts of the video via following command: mencoder -loadidx in.idx -ss 8578 -endpos 20 -oac faac -ovc x264 -sws 9 -lavfopts format=mp4 -x264encopts <LotsOfOpts> -of lavf -vf scale=800:-10,harddup in.avi -o out.mp4. Now here the problem is, that some videos are corrupted at the beginning. I think this is because the fact, that i do not necessarily cut at keyframe.
Questions:
What is the best way to fix the index of an avi "inline" so that every tool can again work as expected with it?
How can i split at the keyframes? Is there an mencoder-option for this?
Are Keyframes coming in a frequency? How to find out this frequency? (So with a bit of math it should be possible to calculate the next keyframe and cut there)
Is ther perhaps some completely other way to split this movie? Doing it by hand is no option, i've to cut out 1000+ chunks ...
Thanks a lot!
https://spreadsheets.google.com/ccc?key=0AjWmZ0umsuZHdHNzZVhuMTkxTHdYbUdCQzF3cE51Snc&hl=en lists the various options available for splitting accurately.
I would attempt to use avidemux to repair the file before doing anything. You may also have better results using an MP4 Based Container than AVI.
As for ensuring your specified intervals are right at the keyframe, I would suggest encoding with FFMPEG with the: -g 1 option before using the split below to ensure every frame is in fact a keyframe. FFMPEG refers to keyframs as GOP or Groups of Pictures instead.
ffmpeg -i input.avi -g 1 -vcodec copy -acodec copy out.avi
Then multiple splits (with FFMPEG) :
ffmpeg -i input.avi -ss 00:00:10 -t 00:00:30 out1.avi -ss 00:00:35 -t 00:00:30 out2.avi
Some more options to try:
x264 Mapping FFMPEG encoding in linux