2

I have file.avi which contains a h264 video:

$ ffmpeg -i file.AVI
Input #0, avi, from 'file.AVI':
  Duration: 00:00:20.61, start: 0.000000, bitrate: 1530 kb/s
    Stream #0:0: Video: h264 (Main) (H264 / 0x34363248), yuv420p, 640x480, 1459 kb/s, 18 fps, 18 tbr, 18 tbn, 36 tbc
    Stream #0:1: Audio: mp2 (P[0][0][0] / 0x0050), 44100 Hz, stereo, s16p, 64 kb/s

When I convert to a mp4 container using:

ffmpeg -i file.AVI -vcodec copy -acodec copy test.mp4

This produces the following file:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.40.101
  Duration: 00:00:20.72, start: 0.000000, bitrate: 1515 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x480, 1455 kb/s, 18 fps, 18 tbr, 18432 tbn, 36864 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 44100 Hz, stereo, s16p, 64 kb/s (default)
    Metadata:
      handler_name    : SoundHandler

The output mp4 file plays in chromium using html5 but is choppy / stutters as it plays.

The file plays smooth in firefox, and also in the desktop viewer (Totem), but I need it to play smooth in chromium.

Are there any ffmpeg flags I need to set to achieve this, or is it something inherently wrong with Chromium?

Note: if I re-encode the file with ffmpeg -i file.AVI test2.mp4 the result works fine in Chromium, but I can't do this (for speed) I'd like to just re-package the h264 video... which almost works.

EDIT: The choppy playback occurs on both Linux (Ubuntu) and Windows and in both Chrome and Chromium.

EDIT 2: Full output from command (note, using flag -an to remove the possibility it's an audio issue.)

Input #0, avi, from 'file.AVI':
  Duration: 00:00:20.61, start: 0.000000, bitrate: 1530 kb/s
    Stream #0:0: Video: h264 (Main) (H264 / 0x34363248), yuv420p, 640x480, 1459 kb/s, 18 fps, 18 tbr, 18 tbn, 36 tbc
    Stream #0:1: Audio: mp2 (P[0][0][0] / 0x0050), 44100 Hz, stereo, s16p, 64 kb/s
[mp4 @ 0x1734d80] Codec for stream 0 does not use global headers but container format requires global headers
Output #0, mp4, to 'test.mp4':
  Metadata:
    encoder         : Lavf56.40.101
    Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 640x480, q=2-31, 1459 kb/s, 18 fps, 18 tbr, 18432 tbn, 18 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[mp4 @ 0x1734d80] pts has no value
    Last message repeated 370 times
frame=  371 fps=0.0 q=-1.0 Lsize=    3664kB time=00:00:20.61 bitrate=1456.2kbits/s    
video:3661kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.066175%

Notes:

  • Adding -fflags +genpts removes the [mp4 @ 0x1734d80] pts has no value error, but does not improve the playback.
  • Adding -flags:v +global_header removes the [mp4 @ 0x1734d80] Codec for stream 0 does not use global headers but does not improve the playback
  • Setting the tbc output using -r ## does not improve playback
  • Setting tbn using -video_track_timescale ## does not improve playback
  • Show the complete console output from the command, not just an excerpt. Also, provide a link to the input file if possible. Why does the input show mp2 audio and the output mp3? – llogan Sep 15 '17 at 6:13
  • The audio is odd as I'm using -acodec copy I assumed it was just repackaging. I'll see if I'm allowed to share the actual file. Thanks. – Trees4theForest Sep 15 '17 at 11:49
  • Can you show the complete console output? Do you have a link to a file so we can attempt to duplicate the issue? – llogan Sep 15 '17 at 17:05
1

As of the date of your post, this was already a reported bug. You stated that you had this problem both in Windows and Ubuntu. For Windows at least there was a reported workaround:

For Chrome: Navigate to chrome://flags

Enable "Enable D3D11 Windows"

Chromium uses switches instead. It appears that the corresponding switch for Chromium is -d3d11See: https://peter.sh/experiments/chromium-command-line-switches/ for more switches to modify Chromium`s behavior. Perhaps these will help you reach a solution that you are happy with. Since other players and browsers are capable of playing the same file smoothly, it doesn't seem logical (at least to me) to blame the encoding.

This is likely no longer necessary as the aforementioned bug was reported Fixed and closed Oct 2015 (at least on Windows)

EDIT: Since Firefox and totem use gstreamer plugins, it would appear that you may be able to resolve this issue by adding a gstreamer backend to chromium. It appears that this approach was first announced by the Samsung Open Source Group July 6, 2015 and that there is a github project here./ChromiumGStreamerBackend) Further information and details on how to implement this approach can be found here.

  • Thanks for the sleuthing - but that flag is not available (at least in Ubuntu chromium). I'd suspect a bug fixed and closed in 2015 is not the culprit. – Trees4theForest Oct 4 '17 at 11:42
  • @Trees4theForest As of the first edit in your question it's clear that this problem occurred in Chrome as well. If not a bug in the browsers mentioned, Where do you think the problem lies if not with the player. I hope you don't mind me quoting you. "The file plays smooth in firefox, and also in the desktop viewer (Totem)" – Elder Geek Oct 4 '17 at 12:01
  • I agree it's an issue with the browser. I was not aware of the command-line flags (thanks for the list) but unfortunately d3d11 is not the culprit. (I also tried a variety of GPU / video flags, none of which helped). – Trees4theForest Oct 4 '17 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.