I need to extract information about motion vectors and DC coefficients from an MPEG4 video. I've searched relevant sites and topics and I found that a good solution is to work with the code of ffmpeg codec. Especially the ff_print_debug_info function in libavcodec/mpegvideo.c calculates relevant information.
However, I'm new on the C/C++ field and if there is any example code that describes or explains how to extract MVs and DC coefficients that would be very helpful.
In the more recent version I use (FFmpeg 0.10.2 from http://ffmpeg.org/download.html) there is another file mpeg4videodec.c. Is there any chance to retrieve the needed information by this code?
Check out this piece of code: http://www.princeton.edu/~jiasic/cos435/motion_vector.c
It gives the basic idea of accessing motion vectors withing ffmpeg-decoded frame.
As for DC coefficients, I don't see any other way than to inject your own code into the decoder to dump coefficients as you decode.
Related
I know that one can extract the motion vectors from an h264 encoded via by first setting the flag
av_dict_set(&opts, "flags2", "+export_mvs", 0);
then you can query the side-data for the motion vectors by doing this
sd = av_frame_get_side_data(frame, AV_FRAME_DATA_MOTION_VECTORS);
When I looked online to see if you can do something similar with HEVC encoded videos, I wasn't able to find any information. All I found was this by the definition of "AV_FRAME_DATA_MOTION_VECTORS"
Motion vectors exported by some codecs (on demand through the
export_mvs flag set in the libavcodec AVCodecContext flags2 option).
The data is the AVMotionVector struct defined in
libavutil/motion_vector.h.
but there was no information on exactly which codecs export this motion vector information. How would I go about finding this out?
If I'm not mistaken h264 is the only codec to print Motion Estimation Vectors.
I would suggest trying out the video filter mestimate.
Also, if you want to have a better ideia what's going on in ffmpeg, check the function ff_print_debug_info2 in libavcodec/mpegvideo.c
I'm trying to find out fast motion estimation algorithm used in vp9, kindly help me out. As no documentation is available although it's open source but I couldn't find anything relevant.
As with typical video standards, there is no motion estimation algorithm in VP9, the standardized parts are the bitstream and how to decode it. Of course the encoders implement some motion estimation algorithm(s) (usually configurable so the user can choose their speed/quality trade-off), but since the standard doesn't cover encoders that is not part of VP9. For the decoder it does not matter how motion vectors were chosen, it only matters what the result was.
You can get the latest version of the standard from this website.
In libvpx in vp9_mcomp.c, it is visible which algorithms that specific encoder uses, which includes several diamond searches (with varying accuracy/time trade-offs including N-step diamond search), two hexagon-based searches, square search, and even exhaustive search. There's integral projection motion estimation in it too but it seems to be used only in a special case.
I used to check and adjust the quality of my video encodings with an Avisynth script calculating the SSIM index. For some reason, since moving to Windows 10, the performance is much lower.
Then I found out about the ffmpeg ssim filter, which runs at least ten times faster.
But I have these issues:
I can't find what algorithm is used by either method or what are the differences,
More importantly, when I plot the results of each method for a number of video files, the corrrelation is virtually zero. With the avisynth SSIM, I find a good correlation between the h.264 CRF factor (as expected), but that correlation disappears with the ffmpeg SSIM.
Has anyone verified whether the ffmpeg SSIM filter really works?
EDIT: I need to investigate further on the second point. I actually found no correlation for ffmpeg over a small sample of different videos, however, there is an excellent correlation for both methods between CRF and SSIM for a single video sample.
I am learning video processing and I have successfully implemented a video encoder based on JPEG algorithm (for spartial redundancy) and block matching algorithm (for temporal redundancy).
Now I am asked to discuss the PSNR behavior with respect to the bit-rate for different quality factors and block sizes.(Provide a graph)
The question made me so confused about what would be included in the graph and how to display such properties on a graph.
Can anyone give me some ideas?
Please forgive me if my English is poor.
Thank you very much!
The PSNR as a function of the bitrate is generally a concave function.
When you encode a video with your encoder, you get a PSNR value and a bitrate value. To get a curve, you need to vary your "quality factor", generally this can be the quantization parameter (QP).
Now you get multiple pairs (PSNR, bitrate), which allows you to plot the curves.
If you have to plot for different block sizes, you will need different curves.
Example below:
I have a motion-JPEG 2000 file that I need to determine if the creator used lossless compression to create it based on the file itself. I do not have the raw video data to compare to, and I do not have the source code of the application used to produce the file.
Based on what I have found, it looks like the best I can do is check the wavelet filter (biorthogonal 3/5) and the quantization step size (1), and assume lossless if those conditions are true.
Any suggestions on how to check for lossless compression are greatly appreciated. My working environment is MATLAB or Java, but any hints for other platforms will be helpful.
You can use ffmpeg for this purpose. Download it from here: https://ffmpeg.org/. After you installed the software and added its source folder to WIN path, you can simply do the following:
ffprobe Test.mj2
The output then shows you many details about the video, including its possible
losslessness.
See the following example output
It is possible to use 5/4 wavelet and quantization step of 1, and still truncate the code stream during encoding to get a lossy result. This is still a valid JPEG 2000 images. So, the only way of checking for lossless is to compare with original.