1193902 - unable to playback streams from MIT Media Lab

Status: RESOLVED DUPLICATE of bug 1244523

(Core :: Audio/Video: Playback, defect, P2)

Description

[(not reading bugmail) Nick Desaulniers [:\n]]

I'm unable to play videos from MIT Media Lab [0][1][2].  The file is being served with a Content-Type type of "video/mp4".  The codec info from ffmpeg -i is:


➜  tmp  ffprobe -hide_banner -i conversations-2014-10-30_h264_512x288.mov
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'conversations-2014-10-30_h264_512x288.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    creation_time   : 2015-04-21 20:16:20
    timecode        : 01:00:00:00
  Duration: 01:21:49.94, start: 0.000000, bitrate: 602 kb/s
    Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt709), 512x288, 508 kb/s, 29.97 fps, 29.97 tbr, 2997 tbn, 5994 tbc (default)
    Metadata:
      creation_time   : 2015-04-21 20:16:20
      handler_name    : Apple Video Media Handler
      encoder         : H.264
    Stream #0:1(eng): Data: none (tmcd / 0x64636D74) (default)
    Metadata:
      creation_time   : 2015-04-21 20:16:20
      handler_name    : Time Code Media Handler
      timecode        : 01:00:00:00
    Stream #0:2(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 88 kb/s (default)
    Metadata:
      creation_time   : 2015-04-21 20:16:20
      handler_name    : Apple Sound Media Handler
Unsupported codec with id 0 for input stream 1

I'm not sure what exactly Stream 0:1 is, but maybe we could be discarding unrecognized streams?

[0] https://www.media.mit.edu/
[1] https://www.media.mit.edu/video/view/conversations-2014-10-30
[2] http://video.media.mit.edu/media/play/conversations-2014-10-30_h264_512x288.mov

Comment 1

[(not reading bugmail) Nick Desaulniers [:\n]]

For example, if I strip out that data stream (0:1), it seems we can play the resulting file:

➜  tmp  ffmpeg -i conversations-2014-10-30_h264_512x288.mov -map 0:0 -map 0:2 -vcodec copy -acodec copy con3.mp4
➜  tmp  ffprobe -i con3.mp4 -hide_banner
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'con3.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.25.101
  Duration: 01:21:49.95, start: 0.000000, bitrate: 605 kb/s
    Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt709), 512x288, 508 kb/s, 29.97 fps, 29.97 tbr, 11988 tbn, 23976 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 88 kb/s (default)
    Metadata:
      handler_name    : SoundHandler


Unless I accidentally transcoded either audio or video streams, I'm quite sure that data stream is the issue.  Otherwise, we'll need someone from the media team to take a look, possibly with some NSPR logging.

Comment 2

[Jean-Yves Avenard [:jya]]

fixed by bug 1244523

Comment 3

[Jean-Yves Avenard [:jya]]

(In reply to (not reading bugmail) Nick Desaulniers [:\n] from comment #1)
> For example, if I strip out that data stream (0:1), it seems we can play the
> resulting file:
> 
> ➜  tmp  ffmpeg -i conversations-2014-10-30_h264_512x288.mov -map 0:0 -map
> 0:2 -vcodec copy -acodec copy con3.mp4

stripping out the track is not what caused this file to play, but that you incidentally remuxed the file into a mp4 container.
This would have changed in the metadata:
major_brand     : qt
to:
major_brand     : isom

into: