Subtle HLS segmenting playback glitch

[Bryan Murphy]

I'm running into a problem using ffmpeg to segment files into HLS (m3u8)
format for playback on iOS devices. In the ffmpeg segmented version of
this file, there is a very subtle stutter just as the two adults walk
underneath the 9. This appears to be some kind of single-frame glitch.

The stutter always happen at HLS segment boundaries. When it happens it is
always visible on iOS devices (play it in Safari on an iPad) and only
sometimes visible in QuickTime on OSX.

I have never been able to reproduce this glitch using Apple's media file
segmenter and the glitch is not present in the source video.

I've tried various permutations of the segment list, segment duration, and
segment format settings when experimenting with ffmpeg and none
consistently address this issue across multiple videos. All they do is
move the glitch around depending on where the segment boundaries line up.

Here is a 30 second clip that exhibits this behavior. The input video
which does not have the glitch is here:

​https://s3.amazonaws.com/1d4326f61a9a4ed596de9e1a41d48413/input.ts

Here is the ffmpeg version which shows the glitch at 11 seconds just as the
two adults walk under the 9 on both iOS and QuickTime on OSX (version 10.4
(833.6)):

​https://s3.amazonaws.com/1d4326f61a9a4ed596de9e1a41d48413/ffmpeg/output.m3u8

And here is a version segmented with Apple's media file segmenter that does
not exhibit any issues.

​https://s3.amazonaws.com/1d4326f61a9a4ed596de9e1a41d48413/mediafilesegmenter/output.m3u8

Here is the complete ffmpeg output from segmenting the ts file:

$ ffmpeg -y -i ../input.ts -c copy -segment_list output.m3u8 -hls_list_size
0 -segment_time 10 -f segment 'output.m3u8.%03d.ts'
ffmpeg version 2.6.2 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  configuration: --disable-debug --disable-devices --disable-doc
--disable-ffplay --disable-ffserver --disable-shared --enable-gpl
--enable-libaacplus --enable-libfaac --enable-libfaac --enable-libfdk_aac
--enable-libmp3lame --enable-libtheora --enable-libvo-aacenc
--enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264
--enable-libxvid --enable-nonfree --enable-postproc --enable-pthreads
--enable-runtime-cpudetect --enable-version3
  libavutil      54. 20.100 / 54. 20.100
  libavcodec     56. 26.100 / 56. 26.100
  libavformat    56. 25.101 / 56. 25.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 11.102 /  5. 11.102
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
[h264 @ 0x20440e0] non-existing SPS 0 referenced in buffering period
    Last message repeated 1 times
Input #0, mpegts, from '../input.ts':
  Duration: 00:00:30.06, start: 1.415333, bitrate: 3982 kb/s
  Program 1
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B),
yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95
tbc
    Stream #0:1[0x101](und): Audio: aac (LC) ([15][0][0][0] / 0x000F),
48000 Hz, stereo, fltp, 120 kb/s
Output #0, segment, to 'output.m3u8.%03d.ts':
  Metadata:
    encoder         : Lavf56.25.101
    Stream #0:0: Video: h264 ([27][0][0][0] / 0x001B), yuv420p, 1280x720
[SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 23.98 tbr, 90k tbn, 23.98 tbc
    Stream #0:1(und): Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz,
stereo, 120 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[NULL @ 0x20440e0] non-existing SPS 0 referenced in buffering period
frame=  720 fps=0.0 q=-1.0 Lsize=N/A time=00:00:30.02 bitrate=N/A
video:12992kB audio:469kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
$

Can anybody help me understand what is going on here and how we can fix
this issue? It is particularly bad when using an iPad play high quality
high-motion video on a large format television.

[Carl Eugen Hoyos]

Is the issue reproducible with current FFmpeg git head?

[Bryan Murphy]

Yes, this is reproducible as of changeset 9ff5e7974a8fe32c3b595a481c06a41fa316a9ac which I built yesterday evening.

I can segment the input.ts file without any playback issues using both Wowza Media Server and tsMuxeR.

[Bryan Murphy]

For anybody else who may be running into this issue, we've had better success using ​Shaka Packager instead of FFmpeg to mux the video.