Use more threads for decoding MTS

[Andreas Girgensohn]

When processing MTS video with my application that uses FFmpeg to decode each video frame, the performance does not increase past two threads and seems to decrease slightly with eight threads (two quad-core CPUs, Intel Xeon E5440). This may be due to the interlaced video. In contrast, another H.264 video (movie trailer in 1080p) makes use of all eight threads.

The test video is the one linked from ticket #993: ​http://file.meyersproduction.com/hg10/00009.MTS.zip

​http://trailers.apple.com/trailers/wb/harrypotterandthedeathlyhallowspart2/

I ran each test three times with 1, 2, 4, and 8 threads and show the median time as reported by csh time.

The 35.54 second MTS is decoded 2.54 times faster than real-time with one thread and 3.78 times faster than real-time with two threads. The 148.68 second MOV is decoded 4.21 times faster than real-time with one thread and 17.89 times faster than real-time with eight threads.

It would be great if MTS could be decoded as fast as the H.264 MOV.

MTS

1: 13.857u 0.057s 0:13.98 99.4%    0+0k 0+0io 0pf+0w
2: 15.375u 0.142s 0:09.41 164.8%   0+0k 0+0io 0pf+0w
4: 15.931u 0.162s 0:09.44 170.4%   0+0k 0+0io 0pf+0w
8: 16.718u 0.181s 0:11.90 141.9%   0+0k 0+0io 0pf+0w

MOV

1: 34.964u 0.142s 0:35.28 99.4%    0+0k 0+0io 0pf+0w
2: 37.914u 0.281s 0:20.07 190.2%   0+0k 0+0io 0pf+0w
4: 41.643u 0.435s 0:14.44 291.3%   0+0k 0+0io 0pf+0w
8: 45.341u 0.535s 0:08.31 551.9%   0+0k 0+0io 0pf+0w

MTS

ffprobe version N-40739-ge556121 Copyright (c) 2007-2012 the FFmpeg developers
  built on May 16 2012 11:07:59 with gcc 4.6.3 20120306 (Red Hat 4.6.3-2)
  configuration: 
  libavutil      51. 53.100 / 51. 53.100
  libavcodec     54. 21.101 / 54. 21.101
  libavformat    54.  5.100 / 54.  5.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 74.100 /  2. 74.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 11.100 /  0. 11.100
[h264 @ 0x2dc00e0] Increasing reorder buffer to 1
[mpegts @ 0x2dbc220] max_analyze_duration 5000000 reached at 5003333
Input #0, mpegts, from '/tmp/00009.MTS':
  Duration: 00:00:36.54, start: 0.766967, bitrate: 6884 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1440x1080 [SAR 4:3 DAR 16:9], 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, s16, 256 kb/s

MOV

ffprobe version N-40739-ge556121 Copyright (c) 2007-2012 the FFmpeg developers
  built on May 16 2012 11:07:59 with gcc 4.6.3 20120306 (Red Hat 4.6.3-2)
  configuration: 
  libavutil      51. 53.100 / 51. 53.100
  libavcodec     54. 21.101 / 54. 21.101
  libavformat    54.  5.100 / 54.  5.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 74.100 /  2. 74.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 11.100 /  0. 11.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/tmp/hp7part2-tlr2_h1080p.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2011-09-02 01:14:21
    comment         : Encoded and delivered by apple.com/trailers/
    comment-eng     : Encoded and delivered by apple.com/trailers/
    copyright       : © 2011 Warner Bros. Pictures. All Rights Reserved
    copyright-eng   : © 2011 Warner Bros. Pictures. All Rights Reserved
    title           : Harry Potter and the Deathly Hallows - Part 2
    title-eng       : Harry Potter and the Deathly Hallows - Part 2
  Duration: 00:02:28.69, start: 0.000000, bitrate: 9636 kb/s
    Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x816, 9532 kb/s, 23.98 fps, 23.98 tbr, 2997 tbn, 5994 tbc
    Metadata:
      creation_time   : 2011-09-02 01:14:21
      handler_name    : Apple Alias Data Handler
    Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, s16, 98 kb/s
    Metadata:
      creation_time   : 2011-09-02 01:14:21
      handler_name    : Apple Alias Data Handler
    Stream #0:2(eng): Data: none (tmcd / 0x64636D74)
    Metadata:
      creation_time   : 2011-09-02 01:14:21
      handler_name    : Apple Alias Data Handler
      timecode        : 00:59:58:21
Unsupported codec with id 0 for input stream 2

[Carl Eugen Hoyos]

Is there any reason to assume that the exact same H264 stream is in both your mts and your mov sample? If not, why do you believe that multi-core speedup should be the same for a mov stream that was encoded by Apple specifically for decoding on multi-core CPU's and a (more general purpose) Bluray stream?

Unrelated: Please always post the output of your ffmpeg command line (if you are not reporting a ffprobe bug).

[reimar]

More importantly give you exact FFmpeg command line. If like someone else in a different issue (can't find it now) use thread_type slices that behaviour is exactly as intended.

[Michael Niedermayer]

Different videos can behave differently in terms of multithreading scalability, If you belive the difference you see is not just random difference between encoders and input material then please reopen this ticket and elaborate