Answers.Body: <p>The original video is an old, interlaced format.  At least, according to the line that says, &quot;smpte170m/bt470bg/bt709.&quot;  The SMPTE standard is available for purchase <a href="https://standards.globalspec.com/std/892300/SMPTE%20ST%20170M" rel="nofollow noreferrer">here</a>, but you can tell from the summary that it's interlaced.</p>
  <p>The second ffmpeg command is copying the format without re-encoding, or handling the interlacing, which isn’t supported on iOS.  The first set of commands work because the video is being re-encoded. Whether or not the video is automatically being de-interlaced, I can’t say without seeing, but I doubt it.  See my answer to <a href="https://video.stackexchange.com/questions/12980/how-to-see-if-a-video-file-is-progressive-or-interlaced/12982#12982">this question</a> to judge for yourself.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-28T17:16:28.903Z
Answers.Text: `smpte170m/bt470bg/bt709` only indicates colorimetry and nothing about scan.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-28T18:04:55.173Z
Answers.Text: The incompatibility  -- regardless of its nature -- is present in the original file.  The blue highlighting in the "Information Comparison" graphic illustrates the only differences between the files of which we know.  Of those differences, only the SMPTE spec is salient.  Sure, it's an educated guess, but there's really not much else to go on.
Answers.UserDisplayName: Jason Conrad
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-28T18:39:45.650Z
Answers.Text: The first string `smpte170m` refers to the colorspace, the 2nd `bt470bg` refers to the color primaries and the 3rd `bt709` to the transfer function (gamma). Interlacing, when detected, will be indicated by printing of the field order e.g. `top first`, after colorimetry.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-28T19:31:36.580Z
Answers.Text: So you're saying the original file follows the smpte170m color standard, but isn't interlaced.  I accept that.  But still, whatever incompatibility exists, is in the original file, which is why the -copy argument produces an incompatible file, and why re-encoding doesn't.
Answers.UserDisplayName: Jason Conrad
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-27T18:34:49.563Z
Answers.LastActivityDate: 2020-06-28T17:52:54.240Z
Answers.LastEditDate: 2020-06-28T17:52:54.240Z
Answers.UserDisplayName: Jason Conrad
Body: <p>I have an mp4 video file that I want to play it in iOS using avfoundation. Unfortunately, the file is not being played and save into the default gallery (photos) even it has <strong>h264</strong> video codec and <strong>aac</strong> audio codec. And it is only playable when I reencode it using ffmpeg. I want to know why the file only becomes playable after reencoding the video?</p>
  <h2>Not Playable(originalFile.mp4) vs Playable File(outputFile.mp4) Information Comparison</h2>
  <p><a href="https://i.sstatic.net/3Kf2g.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/3Kf2g.png" alt="enter image description here" /></a></p>
  <p><strong>File is playable with avfoundation when these commands are being applied:</strong></p>
  <ol>
  <li><p><code>ffmpeg -y -hide_banner -i originalFile.mp4 -f mp4 -vcodec h264 -vf scale=out_color_matrix=bt709 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -b:v 5703k -acodec aac -b:a 249k outputFile.mp4</code></p>
  </li>
  <li><p><code>ffmpeg -y -hide_banner -i originalFile.mp4 -f mp4 -vcodec h264 -acodec aac outputFile.mp4</code></p>
  </li>
  </ol>
  <p><strong>File is not playable with avfoundation when this command is being applied:</strong></p>
  <ol>
  <li><code>ffmpeg -y -hide_banner -i originalFile.mp4 -f mp4 -vcodec copy -acodec aac outputFile.mp4</code></li>
  </ol>
  <p><strong>originalFile.mp4 file link:</strong> <a href="https://drive.google.com/file/d/1-yZFL0EsLztMIfwU79Al6dv8gdwJyGAD/view?usp=sharing" rel="nofollow noreferrer">https://drive.google.com/file/d/1-yZFL0EsLztMIfwU79Al6dv8gdwJyGAD/view?usp=sharing</a></p>
  <p><strong>ffprobe streams of both files are here</strong>
  <a href="https://www.diffchecker.com/VgZL66QB" rel="nofollow noreferrer">https://www.diffchecker.com/VgZL66QB</a></p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-28T04:33:29.183Z
Comments.Text: **NOTE: I can't comment to Jason Conrad so I am posting it as an answer and will delete it.** How do we understand if a video is interlaced from the information FFMPEG provides us? In the above answer Jason Conrad mentions that "smpte170m/bt470bg/bt709." means its interlaced video. But this is just color space information. How does it mean interlace or progressive? Is it possible to share anymore details or URL to read further? Thanks very much for your answer.
Comments.UserDisplayName: Tahlil
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-28T18:45:06.643Z
Comments.Text: Share the full output of `ffprobe -show_streams` for both original file and outputfile.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-29T05:00:56.527Z
Comments.Text: @Gyan I've modified the question and now you can get the outputs of ffprobe streams  from there. Thanks.
Comments.UserDisplayName: Rabel Ahmed
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-29T05:22:42.743Z
Comments.Text: Only the colorimetry appears to be different. But that shouldn't stop playback. Nevertheless, try `ffmpeg -i originalFile.mp4 -c copy -color_primaries bt709 -color_trc bt709 -colorspace bt709 -movflags +faststart outputFile.mp4`
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-29T11:09:16.647Z
Comments.Text: @Gyan I've applied your suggested command but nothing has changed in the outputFile's information and the video isn't playable on iOS either. Can you suggest any special reads on colorimetry, please?
  Thanks.
Comments.UserDisplayName: Rabel Ahmed
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-29T12:38:35.507Z
Comments.Text: Since you're using 4.2.1, also add `-write_colr 1` and check.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-29T16:39:17.303Z
Comments.Text: @Gyan I've applied this command 
  
  `ffmpeg -i originalFile.mp4 -c copy -color_primaries bt709 -color_trc bt709 -colorspace bt709 -movflags write_colr outputFile.mp4` and still there is no difference between originalFile.mp4 and outputFile.mp4 information. Is it the appropriate command that you suggested to apply?
Comments.UserDisplayName: Rabel Ahmed
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-07-02T04:33:44.620Z
Comments.Text: @Gyan I've included originalFile.mp4 link in the question which file is not playable via iOS default video player or Avfoundation. Thanks.
Comments.UserDisplayName: Rabel Ahmed
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-07-02T09:51:59.653Z
Comments.Text: Link not accessible
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-07-02T13:49:18.313Z
Comments.Text: @Gyan The link should be accessible now.
Comments.UserDisplayName: Rabel Ahmed
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-07-03T05:02:32.487Z
Comments.Text: The H.264 video stream is stored using MBAFF coding, which is likely not supported in AVFoundation. You'll have to re-encode.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-07-03T15:18:07.113Z
Comments.Text: @Gyan How can we ensure that the video stream is stored using MBAFF coding? Thank you.
Comments.UserDisplayName: Rabel Ahmed
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-07-03T15:34:05.397Z
Comments.Text: How is original file generated?
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-07-03T17:20:10.963Z
Comments.Text: Basically, we've got this file from one of our users!
Comments.UserDisplayName: Rabel Ahmed
Tags: <video><ffmpeg><ios>
Title: A specific MP4 file is not playable with avfoundation in iOS
UserDisplayName: Rabel Ahmed
ThreadText: # A specific MP4 file is not playable with avfoundation in iOS
  
  (Asked by: username_0 on 2020-06-22)
  
  I have an mp4 video file that I want to play it in iOS using avfoundation. Unfortunately, the file is not being played and save into the default gallery (photos) even it has **h264** video codec and **aac** audio codec. And it is only playable when I reencode it using ffmpeg. I want to know why the file only becomes playable after reencoding the video?
  
  ## Not Playable(originalFile.mp4) vs Playable File(outputFile.mp4) Information Comparison
  
  [![enter image description here](https://i.sstatic.net/3Kf2g.png)](https://i.sstatic.net/3Kf2g.png)
  
  **File is playable with avfoundation when these commands are being applied:**
  
  1. `ffmpeg -y -hide_banner -i originalFile.mp4 -f mp4 -vcodec h264 -vf scale=out_color_matrix=bt709 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -b:v 5703k -acodec aac -b:a 249k outputFile.mp4`
  2. `ffmpeg -y -hide_banner -i originalFile.mp4 -f mp4 -vcodec h264 -acodec aac outputFile.mp4`
  
  **File is not playable with avfoundation when this command is being applied:**
  
  1. `ffmpeg -y -hide_banner -i originalFile.mp4 -f mp4 -vcodec copy -acodec aac outputFile.mp4`
  
  **originalFile.mp4 file link:** <https://drive.google.com/file/d/1-yZFL0EsLztMIfwU79Al6dv8gdwJyGAD/view?usp=sharing>
  
  **ffprobe streams of both files are here**
  <https://www.diffchecker.com/VgZL66QB>
  
  **Tags:** video, ffmpeg, ios
  
  > **Comments:**
  > **username_1**: **NOTE: I can't comment to username_3 username_3 so I am posting it as an answer and will delete it.** How do we understand if a video is interlaced from the information FFMPEG provides us? In the above answer username_3 username_3 mentions that "smpte170m/bt470bg/bt709." means its interlaced video. But this is just color space information. How does it mean interlace or progressive? Is it possible to share anymore details or URL to read further? Thanks very much for your answer.  
  > **username_2**: Share the full output of `ffprobe -show_streams` for both original file and outputfile.  
  > **username_0**: @username_2 I've modified the question and now you can get the outputs of ffprobe streams  from there. Thanks.  
  > **username_2**: Only the colorimetry appears to be different. But that shouldn't stop playback. Nevertheless, try `ffmpeg -i originalFile.mp4 -c copy -color_primaries bt709 -color_trc bt709 -colorspace bt709 -movflags +faststart outputFile.mp4`  
  > **username_0**: @username_2 I've applied your suggested command but nothing has changed in the outputFile's information and the video isn't playable on iOS either. Can you suggest any special reads on colorimetry, please? Thanks.  
  > **username_2**: Since you're using 4.2.1, also add `-write_colr 1` and check.  
  > **username_0**: @username_2 I've applied this command   `ffmpeg -i originalFile.mp4 -c copy -color_primaries bt709 -color_trc bt709 -colorspace bt709 -movflags write_colr outputFile.mp4` and still there is no difference between originalFile.mp4 and outputFile.mp4 information. Is it the appropriate command that you suggested to apply?  
  > **username_0**: @username_2 I've included originalFile.mp4 link in the question which file is not playable via iOS default video player or Avfoundation. Thanks.  
  > **username_2**: Link not accessible  
  > **username_0**: @username_2 The link should be accessible now.  
  > **username_2**: The H.264 video stream is stored using MBAFF coding, which is likely not supported in AVFoundation. You'll have to re-encode.  
  > **username_0**: @username_2 How can we ensure that the video stream is stored using MBAFF coding? Thank you.  
  > **username_2**: How is original file generated?  
  > **username_0**: Basically, we've got this file from one of our users!  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2020-06-27. Score: 1
  
  The original video is an old, interlaced format. At least, according to the line that says, "smpte170m/bt470bg/bt709." The SMPTE standard is available for purchase [here](https://standards.globalspec.com/std/892300/SMPTE%20ST%20170M), but you can tell from the summary that it's interlaced.
  
  The second ffmpeg command is copying the format without re-encoding, or handling the interlacing, which isn’t supported on iOS. The first set of commands work because the video is being re-encoded. Whether or not the video is automatically being de-interlaced, I can’t say without seeing, but I doubt it. See my answer to [this question](https://video.stackexchange.com/questions/12980/how-to-see-if-a-video-file-is-progressive-or-interlaced/12982#12982) to judge for yourself.
  
  > **Comments:**
  > **username_2**: `smpte170m/bt470bg/bt709` only indicates colorimetry and nothing about scan.  
  > **username_3**: The incompatibility  -- regardless of its nature -- is present in the original file.  The blue highlighting in the "Information Comparison" graphic illustrates the only differences between the files of which we know.  Of those differences, only the SMPTE spec is salient.  Sure, it's an educated guess, but there's really not much else to go on.  
  > **username_2**: The first string `smpte170m` refers to the colorspace, the 2nd `bt470bg` refers to the color primaries and the 3rd `bt709` to the transfer function (gamma). Interlacing, when detected, will be indicated by printing of the field order e.g. `top first`, after colorimetry.  
  > **username_3**: So you're saying the original file follows the smpte170m color standard, but isn't interlaced.  I accept that.  But still, whatever incompatibility exists, is in the original file, which is why the -copy argument produces an incompatible file, and why re-encoding doesn't.  
  
  ---
  
  