#!/bin/sh -x
# $1 - input video file, e.g. video.mp4
# $2 - timestamp, e.g. 00:33
# $3 - output image file, e.g. output.jpg
ffmpeg -ss $2 -i $1 -vframes 1 -q:v 2 $3
#!/bin/sh -x
# $1 - input file, e.g. input.mp4
ffmpeg -i "$1" -q:v 2 %06d.jpg
ffmpeg -f image2 -framerate 30 -i %06d.jpg -c:v libx264 out.mp4
@rlan
My first bullet was asking what you want to do in the first place. It looks to me you want to modify just <2> of the video and not anywhere else. May be there is another road. For example, instead of concat, get all frames for the entire video, then make the modification to <2> frames, then assemble all frames back to a video.
So for this above, you are exactly right. I can write all frames, modify <2> and make a full video out of all frames. But here my question is that why is the color/luma difference happening and how can we solve that.
Lets simplify the problem: 1. take a video, 2. write the frames 3. read the frames to make it a video.
Now: the starting video and the new encoded video will have slight luma differences. I want to know why is this happening and how can i solve for this. I am not a ffmpeg pro so need help here. My gut feel is that while writing the frames (png) to disk colorspace conversion from yuv420p to rgb takes place and reverse happens when we encode the frames back to mp4. So is there some parameter which i am missing while encoding back, etc?