Video Production Stack Exchange is a question and answer site for engineers, producers, editors, and enthusiasts spanning the fields of video, and media creation. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a large set of jpgs that I want to convert to a video losslessly (or, at the very least, very close to losslessly as long as the encoding time isn't much higher than otherwise).

Naively, I would think that there should be some codec that can store each individual jpg frames as-is (without recompression), and perhaps achieve some nice compression by replacing some of the frames by just the information on the delta from the previous frame. In my case there are many sequences of frames which are identical to each other, or that have a tiny difference between them.

Is there some codec and suitable settings for ffmpeg that can achieve this?

share|improve this question
    
    
Also Related: avp.stackexchange.com/questions/7300/… – Friend Of George May 16 '13 at 20:36
1  
sequence-of-jpegs has been a codec for a LONG time. Digital cameras that don't use h.264 invariably record MJPEG, and video capture cards used to use it, I think. – Peter Cordes Jan 15 '15 at 9:44

Just mux the images

You can simply mux the JPG images to make a video:

ffmpeg -framerate 30 -i input%03d.jpg -codec copy output.mkv

Note that if you omit -framerate then a default of -framerate 25 will be applied to the input.

Lossless optimization

You can use jpegtran to perform lossless optimization on each frame which may provide significant file size savings:

mkdir outputdir
for f in *.jpg; do jpegtran -optimize -copy none -perfect -v "$f" > "outputdir/$f"; done

Now mux with ffmpeg as shown above.

Checking that it is actually lossless

The framehash muxer can be used to compare the unique hash of each frame to ensure that the result is truly lossless:

$ ffmpeg -i input%03d.jpg -f framehash -
stream_index, packet_dts, packet_pts, packet_duration, packet_size, hash
0,          0,          0,        1,   460800, 29bcc2db3726c7dfec1826c5740f603f
0,          1,          1,        1,   460800, b5fdc23d93cbd043dc2b9290dc8378f0
0,          2,          2,        1,   460800, ee0709942f24b458fd2380d134dcb59d
...

$ ffmpeg -i output.mkv -map 0:v -f framehash -
stream_index, packet_dts, packet_pts, packet_duration, packet_size, hash
0,          0,          0,        1,   460800, 29bcc2db3726c7dfec1826c5740f603f
0,          1,          1,        1,   460800, b5fdc23d93cbd043dc2b9290dc8378f0
0,          2,          2,        1,   460800, ee0709942f24b458fd2380d134dcb59d
...

In the above examples each associated frame for the input and output share the same hash ensuring that the frames are identical and that the output is lossless.

Also see

share|improve this answer
    
could you please clarify what the two framemd5 commands are supposed to achieve beyond merely listing the hashes? how would I get additional compression when identical frames are thus identified? – GJ. May 18 '13 at 8:54
1  
The hashes were included only to show you that the frames are the same as the individual images, so therefore achieving your requirement of storing "each individual jpg frames as-is (without recompression)". – LordNeckbeard May 18 '13 at 18:24
    
Posted an answer of my own with an untested idea for dropping the duplicate frames, to end up with a VFR MJPEG.mkv. VFR is the only way I can think of to take advantage of temporal redundancy with MJPEG. :P – Peter Cordes Jan 15 '15 at 10:05
    
Thanks for the framemd5 hint ! – malat Mar 25 '15 at 20:07
    
SSIM may be a quicker way to compare fidelity. – Mulvya Jun 22 at 20:22

This will output a lossless H.264 video where frames will use information from other frames

ffmpeg -f image2 -r 30 -i %09d.jpg -vcodec libx264 -profile:v high444 -refs 16 -crf 0 -preset ultrafast a.mp4

Explanation of options:

  • -f image2 - tells ffmpeg to select a group of images
  • -r 30 - tells ffmpeg to encode at 30 frames (or images) per second (change this to your desired framerate)
  • -i %09d.jpg - tells ffmpeg to use the images 000000000.jpg to 999999999.jpg as the input. Change the 9 in %09d.jpg to how many zeroes the names of your image sequence has. If your file names are, for example, img0001.jpg, then this would be expressed as img%04d.jpg
  • -vcodec libx264 - tells ffmpeg to output to a H.264 compliant file
  • -profile:v high444 - tells libx264 to use the High 4:4:4 Predictive Lossless profile, allowing lossless encoding
  • -refs 16 - tells libx264 to have 16 images stored in a buffer, so that they may be referenced by other images in the video
  • -crf 0 - tells libx264 to perform a lossless encode
  • -preset ultrafast - tells libx264 to prioritise encoding speed over output file size
  • a.mp4 - tells ffmpeg to save the output in an MP4 file called a.mp4. Change this to the file name and format that you wish to use
share|improve this answer
3  
A few notes: -f image2 is superfluous here. The image file demuxer should use -framerate instead of -r. libx264 will automatically choose the appropriate -profile for lossless, and the -preset will deal with -refs. – LordNeckbeard Jan 3 '15 at 22:55
    
-refs 5 at MOST, unless you know your content has identical images separated by several other ones, that might cause x264 to lose the reference before it gets to the duplicate. Higher than ultrafast makes little different in lossless mode, other than CABAC's ~10% gain over CAVLC (for a high cpu cost at the bitrates required for lossless). Seriously, on some live-action 720x480p60 (deinterlace output), superfast was 28GB, slower was 27GB. If encode time doesn't matter, but decode time does, make sure you avoid CABAC. Maybe even -tune fastdecode. Moderate ref count shouldn't hurt. – Peter Cordes Jan 17 '15 at 14:16
    
And if you have CPU to burn, you can even try -preset placebo for a few extra fractions of percent. – DrYak Jun 22 at 19:14
    
Also for completeness h265 also has its own lossless mode. -vcodec libx265 -x265-params lossless=1 is the equivalent option. (But in my experience (= recording of Powerpoint slideshow presentations), it isn't necessarily better, and it's much slower than h264) Stay tune for next year's AOMedia's AV1/IETF's NETVC1/Xiph's Daala/whatever it's going to be renamed by then...'s lossless mode – DrYak Jun 22 at 19:19

To expand on LordNeckbeard's answer, yes, just mux the JPEG data into an MJPEG video stream. That will be the smallest representation of the exact sequence of output images, even though MJPEG is a terribly inefficient codec by today's standards. (no temporal redundancy, and not even any intra prediction.

You can make a variable-framerate MJPEG video to take advantage of the duplicate images in your input.

ffmpeg -framerate 30 -i input%03d.jpg -vf mpdecimate -codec copy output.mkv  # doesn't work.

Hrm, this isn't going to work, since mpdecimate won't work on compressed data, and we can't let ffmpeg decode and then re-jpeg the image data without loss and CPU cost.

Maybe if you replaced duplicate jpg source files with empty files with that sequence number, or something?

Since this question isn't even recent, I'm not going to take the time to figure out how to do it unless someone replies to ask how. But since MJPEG can go into an mkv container, I'm sure it's possible to have a file that doesn't duplicate the jpeg data for repeated frames, but instead just doesn't have an output frame to decode until the sequence of duplicates is over.

Oh here's an idea:

ffmpeg -framerate blah -input blah -vf mpdecimate -f mkvtimestamp_v2 mpdecimate.timestamps

Then remove (or move aside) all the jpegs for frames that mpdecimate wants to drop (probably it has some logging options? Or -vf showinfo, and parse that, and move or hardlink only the frames that show up in its output, leaving behind the dropped JPEGs?). mux that to a MJPEG.mkv, then do something with mkvmerge to replace the frame timestamps in that with the timestamps from mpdecimate.timestamps.

If you were xcoding, instead of just muxing jpeg data to MJPEG, this would be MUCH easier, since you'd just use my first command with mpdecimate and any codec other than copy, and it would Just Work(tm).

I haven't tried any of this, since this was an old question. Also the reason I haven't filled in the gaps of how to actually filter your directory of jpegs based on mpdecimate output, or how to actually use the timestamp stream.

share|improve this answer

You can create an avi animation as a series of png images ( png is lossless so the jpeg => png conversion should not degrade your pictures ):

if your images a named img_0001.jpg

ffmpeg -r 25 -start_number 1 -f image2 -i "img_%04d.jpg" -vcodec png video.avi

where "25" is the frame rate you want in the resulting video. -start_number is not needed if it is 1, but it is useful if your first video number is not 1.

If you want to encode in mjpeg with highest quality command line is:

ffmpeg -r 25 -start_number 1 -f image2 -i "img_%04d.jpg" -vcodec mjpeg -qscale 1 video.avi

And the beauty of the thing is that you can convert the video back to a series a pictures:

ffmpeg -i video.avi "img_series_%04d.png"
ffmpeg -i video.avi "img_series_%04d.jpg"

etc...

share|improve this answer
    
This doesn't really meet the askers needs. He is looking for a way that the frame can be updated loselessly only when the image changes. This means the same image may be used more than once. Also jpeg by nature isn't lossless as I believe it uses jpeg compression even at max quality. – AJ Henderson May 17 '13 at 13:17
    
Actually I guess he was willing to have some compression, though I'm not sure how it is going to do on long sequences of the same frame. I still think a variable frame rate presentation format is what is needed though I'm not sure if ffmpeg supports any. – AJ Henderson May 17 '13 at 13:20
    
CorePNG is able to create P frames also. Usually jpeg is not a lossless compression, and I doubt mjpeg can create P frames. I agree I do not answer the question as it is asked, but I give a solution to have a lossless video with ffmpeg. – Olivier S May 17 '13 at 18:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.