[FFmpeg-trac] #4901(undetermined:new): mjpeg codec ignores -threads 1

[FFmpeg]

#4901: mjpeg codec ignores -threads 1
-------------------------------------+-------------------------------------
             Reporter:  jvd66        |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug:
 It seems to be impossible to get the mjpeg codec to use only 1 thread:
 How to reproduce:
 {{{
 % strace -e trace=clone ffmpeg -loglevel debug -i a_video.avi -threads 1
 -threads:1 1 -threads:v 1 -vf null -af null -f mjpeg -threads 1
 -threads:p:mjpeg 1 -vframes 1 -ss 00:00:10.000 -threads 1 -threads:1 1
 -threads:d 1 -threads:a 1 -threads:v 1 -threads:s 1 -threads:t 1
 -threads:#0 1 -threads:p:mjpeg 1 -an -y a_video.jpg 2>&1 | egrep
 'cores|clone'
 detected 8 logical cores
 clone(child_stack=0x7f826370dfd0,
 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f826370e9d0, tls=0x7f826370e700,
 child_tidptr=0x7f826370e9d0) = 4602
 clone(child_stack=0x7f8262f0cfd0,
 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f8262f0d9d0, tls=0x7f8262f0d700,
 child_tidptr=0x7f8262f0d9d0) = 4603
 clone(child_stack=0x7f826270bfd0,
 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f826270c9d0, tls=0x7f826270c700,
 child_tidptr=0x7f826270c9d0) = 4604
 clone(child_stack=0x7f8261f0afd0,
 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f8261f0b9d0, tls=0x7f8261f0b700,
 child_tidptr=0x7f8261f0b9d0) = 4605
 clone(child_stack=0x7f8261709fd0,
 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f826170a9d0, tls=0x7f826170a700,
 child_tidptr=0x7f826170a9d0) = 4606
 clone(child_stack=0x7f8260f08fd0,
 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f8260f099d0, tls=0x7f8260f09700,
 child_tidptr=0x7f8260f099d0) = 4607
 clone(child_stack=0x7f8260707fd0,
 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f82607089d0, tls=0x7f8260708700,
 child_tidptr=0x7f82607089d0) = 4608
 clone(child_stack=0x7f825ff06fd0,
 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f825ff079d0, tls=0x7f825ff07700,
 child_tidptr=0x7f825ff079d0) = 4609
 clone(child_stack=0x7f825f705fd0,
 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f825f7069d0, tls=0x7f825f706700,
 child_tidptr=0x7f825f7069d0) = 4610
 %

 FFMPEG VERSION :
 ffmpeg 2.2.16 with no patches, built for RHEL-6.4 on an x86_64 with
 gcc-5.2.0
 (for newer CPU optimization support, optimized for Haswell architecture,
 with
  CFLAGS: '-march=x86-64 -mtune=haswell -O3 -g' ) .

 }}}

 This is a regression from ffmpeg 0.8.5 ,  which uses only 1 thread given
 the
 same effective arguments, and is about 288% more efficient:

 example ffmpeg-2.2.16 time measurement:

 $ time_hi_res ffmpeg -i a_video.avi -vf null -af null -f mjpeg -vframes 1
 -ss 00:00:10.000 -an -y a_video.jpg
 ...
 [elapsed]=0.192097 [cpu%]=119.34 [sys]=0.008992 [user]=0.220266
 [rss]=30540 [csw]=378 [vcsw]=296 [fltmaj]=0 [fltmin]=7241 [inblk]=0
 [outblk]=8 [exit]=0

 example ffmpeg-0.8.5 time measurement:

 $ time_hi_res ffmpeg-0.8.5 -i a_video.avi -vf null -af null -f mjpeg
 -vframes 1 -ss 00:00:10.000 -an -y a_video.jpg
 ...
 [elapsed]=0.057240 [cpu%]=99.83 [sys]=0.003985 [user]=0.053159 [rss]=15704
 [csw]=1 [vcsw]=218 [fltmaj]=0 [fltmin]=3969 [inblk]=0 [outblk]=0 [exit]=0


 (time_hi_res is a bash shell loadable built-in that is similar to the time
  built-in but uses clock_gettime() to make high resolution time
 measurements,
  and uses getrusage() to print out the 'struct rusage' fields shown above)
 .


 "Efficiency" calculations:
  ffmpeg 2.2.16 / ffmpeg 0.8.5 :
     elapsed time  : 0.192097/0.066678 = 2.880965, or @ 288%
     user cpu time : 0.220266/0.053159 = 4.143531, or @ 414%

 These results are confirmed by the average of many runs of the mjpeg
 codec.

 Please , is there any way of getting the mjpeg codec to use only one
 thread?

 It is very difficult to convince my company to move to using
 ffmpeg-2.2.16,
 which we'd like to do for many obvious reasons, when confronted with
 performance results such as those above .

 Patches should be submitted to the ffmpeg-devel mailing list and not this
 bug tracker.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4901>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker