I am by no means an expert with ffmpeg. But I'm finding it strange that the the time to create a gif and trim that section is increasing so much based on the size of the video since I am always grabbing only three seconds.
I am using flutter FFmpeg.
-ss 0:00:01.000000, -i /data/user/0/com.example.example/cache/image_picker1475407716366431469.mp4 -t, 0:00:03.000000 -avoid_negative_ts make_zero, -vf fps=10,scale=320:-1:flags=lanczos,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse, -loop 0
Is there a command to make sure that ffmpeg doesn't concentrate on the entire video, and only concentrates on the three seconds I am getting in -t, so that the time doesn't increase greatly based on the video size. Or is this just normal for ffmpeg. Does it have to parse the entire video, before creating the gif.
I found a solution for anyone else looking. For some reason its much faster to just trim the original video and then make a gif. So just running '-c:v copy ' on the original video and then running the above command cut the processing time on a 3 minute video down from 1 minute 40 seconds to 10 seconds.
Related
I'm trying to play/skip some clips of a video using ffplay. My first approach to skip say frames 100 to 400 was:
ffplay -vf "select='lte(n\,100)+gte(n\,400)'" -i INPUT
this skips the desired frames, however it also freezes the video during the skipped frames. I tried to fix this by modifying the video presentation time stamp (PTS) with the setpts option:
ffplay -vf "select='lte(n\,100)+gte(n\,400)',setpts='PREV_OUTPTS'" -i INPUT
this seems to work (stills freeze a bit, guess is because of buffering), but now the audio is out of sync. I've tried applying a select filter and modifying the PTS on the audio as well
ffplay -vf "select='lte(n\,100)+gte(n\,400)',setpts='PREV_OUTPTS'" -af "aselect='lte(n\,100)+gte(n\,400)',asetpts='PREV_OUTPTS'" -i INPUT
this skips some audio frames, but still out of sync. I've tried with the aresample=async=10000 option with similar results. Moving some/all of the filters to the output (placing them after the -i INPUT) doesn't work either.
Does someone know how to skip parts of a video using ffplay? Many thanks
Audio frame numbers != video frame numbers. AAC audio generated by FFmpeg's encoder is 1024 samples per frame, so a 48kHz stream has 48000/1024 = 46.875 audio frames per second. Other codecs may have different rates.
Use t instead of n, and generate a continuous series of timestamps.
ffplay
-vf "select='lte(t\,4)+gte(t\,16)',setpts=N/FRAME_RATE/TB"
-af "aselect='lte(t\,4)+gte(t\,16)',asetpts=N/SR/TB"
-i INPUT
I assume a video frame rate of 25 fps. Modify accordingly.
I am new to MATLAB, I have few videos of ~100GB each (10hrs duration). I want to calculate some features on every nth frame of the video. I have followed this code But my computer sleeps for just finding number of frames in one video. i.e.
nFrames = get(vidObj, 'NumberOfFrames');
Is there any faster way to process huge videos like I have as this seems to be very slow. Also I have tried looking in internet but didnt find any reasonable solution.
Thanks in advance.
Matlab is dogslow,so you can use ffmpeg instead. Your specific functionality being kept aside, you can extract individual images from a video using below command:
ffmpeg -i input.mp4 -vf fps=60 out%d.png
Ffmpeg video processing is way faster compared to Matlab video processing.
I am looking for commmandline to slow down Quick Time formated MOV files. Most likely using FFMPEG. I do not mind converting to MP4 format either.
To slow down your video, you have to use a multiplier greater than 1:
ffmpeg -i input.mov -filter:v "setpts=2.0*PTS" output.mov
I am not sure if this works right now.
batch slow down .mov speed (No answer here either)
Almost impossible without full reencoding (or transcondig).
If the source is video only, it can be easily done by simple hex editing. Just change the track timescale value in the MDHD box =>
http://wiki.multimedia.cx/?title=QuickTime_container#mdhd
The lower timescale the slower play rate.
I've tested it works as following:
1) find out current frame rate with Mediainfo tool
2) Open the file with HxD
3) Recklessly search 'mdhd'
4) Between 'mdhd' and 'hdlr', find 16 bit big endian hex representation of frame rate and change it
I'm not sure but this kind of hacking seems not supported by ffmpeg.
But if it also has audio track, changing its timescale will produce noisy sound, therefore reencoding is unavoidable.
Transcoding is rather straightforward work. I'd recommend HandBreak or other GUI frontends.
Use this line
ffmpeg -i input.mkv -filter_complex "[0:v]setpts=0.5*PTS[v];[0:a]atempo=2.0[a]" -map "[v]" -map "[a]" output.mkv
I used this link
https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20video
I am trying to read many video files from a database and process them. I am using Matlab and my problem is that when I want to read a 10 minutes long full HD video I should wait so much and my computer stops performing well. I use this command
VideoReader('movie.mp4')
I have seen that it takes 47 seconds to read a 30 seconds long video in the same format. I do not need to load all frames into my memory I just need 11 frames for each step of my process and really got stock here. Any help will be appreciated.
Also here is my output when I run this command
disp(videoObj);
output:
Summary of Multimedia Reader Object for 'movie.mp4'.
Video Parameters: 30.00 frames per second, RGB24 1280x720.
1482 total video frames available.
By the way I am running my code on Matlab R2014a and my OS is ubuntu 14.0.4.
Siavash,
The long loading time is because the entire file is scanned to determine the number of frames. This process is necessary to support frame indexed based access. In R2014b and higher, the frame counting during construction has been disabled. Additionally, you can seek to specific locations in the file using the CurrentTime property and use the hasFrame/readFrame methods for reading to avoid this performance penalty
Dinesh
I'm using version R2015b and I find the same slow processing of mp4 files with the VideoReader and readFrame functions. However, I find that those functions perform much faster on an avi file than an mp4, so I first convert the mp4 to avi using an independent program from https://www.ffmpeg.org. I don't know why there's such a difference in speed between the two...perhaps someone from MATLAB can provide some insight into that question.
The Problem I have is when using ffmpeg to encode a YUV using libx264 I don't get all the frame information in -vstats output. It raises the question of how reliable ffmpeg is, and therefore can any 'codec benchmark' review based on ffmpeg be trusted?
I am analysing codec's to determine how they perform. I am using ffmpeg and its -vstats option to look at an encoded movie frame by frame. the process I use:
RAW YUV -> bar-code each frame with frame number -> Bar-coded YUV
Bar-coded YUV -> encoded (e.g. with libx264) -> MKV -> Decoded to YUV
I can compare the two outputs ('Bar-coded YUV' & 'Decoded to YUV') using the bar-code in each frame. I can then compare, exactly, an original frame with an encoded frame using PSNR etc.
When encoding using libx264 and libdirac, there are some frame information which is missing. Other codecs, such as mpeg2video or even libvpx, don't have this problem.
I have found that libx264 vstats are missing for the first 40 to 50 frames. I have since proved that the missing information is actually the last 40 to 50 frames.
It also looks like ffmpeg calculates average bitrate based on the information in vstats. But as there is missing frames the average bitrate is less than what it should be.
Below are links to the average bitrate error example:
http://dl.dropbox.com/u/6743276/ffmpeg_probs/ffmpeg_av_bitrate_error.png
http://dl.dropbox.com/u/6743276/ffmpeg_probs/ffmpeg_av_bitrate_error.xlsx
Below is a link to the PSNR & f_size graph:
http://dl.dropbox.com/u/6743276/ffmpeg_probs/frame_mismatch.png
Below is a link to the output & command line options:
http://dl.dropbox.com/u/6743276/ffmpeg_probs/stderr.txt
I think this is also a bug, anyone clever enough to work it out might want to follow this tracker:
http://roundup.ffmpeg.org/issue2248
I have just discovered something which makes me very red in the face!! quite annoyed, but never mind :)
A fellow ffmpeg user pointed out that ffprobe should output more frame info, which it did. here is a link to his handy tip:
http://forums.creativecow.net/thread/291/71
Using this I found the following:
Actual average bitrate (ffprobe data): 8355.2776056338
Actual average bitrate (ffmpeg vstats data): 8406.23275471698
Ffmpeg -vstats avg_br: 7816.3
Reproduced above: 7816.32168421053
Ffmpeg standard error output 'bitrate=': 8365.8
Below is a link to my workings out:
http://dl.dropbox.com/u/6743276/ffmpeg_probs/ffprobe_vs_ffmpeg-vstats.xlsx
What I have discovered is I should have been using the average bitrate info from ffmpeg standard error output, it looks like the most reliable!