Calculate GOP size MP4 - mp4

I found a solution to calculate the GOP size of a H264 file.
However when I change the input.h264 to mp4. I get an error that says invalid data.
ffprobe -show_frames input.h264 | grep pict_type
How can I perform this command line instruction with mp4 video files?

Related

ffplay keep video/audio sync when using select filter

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.

What kind of encoder is suitable for AVIREAD in Matlab?

I have a raw video (no header, just Y-channel).
I want do some denoise algorithm on this video.
I convert this raw video by useing ffmpeg with several encoders.
But fail to open with function AVIREAD.
Error using aviread, Unable to locate decompressor to decompress video stream
r210 Uncompressed RGB 10-bit
v210 Uncompressed 4:2:2 10-bit
v308 Uncompressed packed 4:4:4
v410 Uncompressed 4:4:4 10-bit
y41p Uncompressed YUV 4:1:1 12-bit
yuv4 Uncompressed packed 4:2:0
mjpeg MJPEG (Motion JPEG)
ffmpeg -f rawvideo -vcodec rawvideo -s 1920x1080 -r 25 -pix_fmt gray -i WKA00002.y -c:v v308 WKA00002_UnCompAVI.avi
What kind of encoder is suitable for AVIREAD in Matlab?
Thanks a lot
AVIREAD has been removed from the latest versions of MATLAB. Use VIDEOREADER instead.
Motion JPEG AVI is supported by VideoReader.
if you want to try other formats, first check that the file can be opened using Windows Media Player? If so, use VideoReader to try and read the file. If this does not work, can you provide a link to the file that you are using?
Hope this helps.
Dinesh

Apple Quick Time Mov Files Slow Down Playback Rate Via Command Line

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

Are there better option for a smaller file size than .aiff to be used with AVAudioPlayer?

I'm using AVAudioPlayer to play a short one or two syllables word in my app. Currently there are 250 .aiff files and each of the file is roughly 88KB to 125KB each. Currently my ipa file is at 29Megs and I am trying to find the best way to reduce the size so user don't have to have a wifi to download it.
Each of the sound clip is 1 to 2.5 seconds long. I don't need to pause, rewind, fast forward etc.
Based on what I read so far AVAudioPlayer only play aiff, wav or caf and none of those are compressed. Any recommendation on what I can do? Thank you.
CAF files can be compressed, using either lossy or lossless algorithms. If you're using the command line afconvert utility to convert, you could try:
afconvert -f caff -d ima4 audiofile.wav (for IMA4 compression)
afconvert -f caff -d aac audiofile.wav (for AAC compression)
There's also a -b parameter that allows you to set the output bit rate, and a bunch of other options. The man page is basically empty but the full array of possibilities are listed in QA1534.

ffmpeg vstats problems, Missing frames and misleading information!

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!