Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
libavformat 54 or later needed (was: VLC Jerky Playback) #24
Downloading e.g "Livet på Operan" in highest resolution (1280 x 720, HLS) from svtplay.se works like a charm, but playback in VLC feels a bit jerky for the video; a little bit like what you get when converting from 23.xx fps to 25.
Are there FFMpeg parameters that could be tampered with?
teve -l claims the used ones are -absf aac_adtstoasc
Thank you for reporting! Some research shows that VLC is known to often perform poorly with MP4 files. More specifically, decoding H.264 video streams requires a lot of processor time, and efficiency really isn't one of VLC:s stronger suits. The following is one of many possible solutions found in the VideoLAN forums:
That said, the codecs used by a typical SVT Play video should be reported like this by VLC:
In the future, teve might get some recoding capabilities, i.e. a few presets aimed at device compatibility or slower computers (at the cost of time and size or quality).
The aac_adtstoasc bitstream filter is necessary when copying the HLS audio streams into MP4 files. There are no other FFmpeg bitstream filters relevant to these streams.
The suggested fix fixes another problem I had that is tenth-of-second framedrops for H.264 streams, thank you very much for that pointer, but this problem is more subtle; as I said like if you resampled from 23.976 frames per second to 25 using a stupid resampler.
I have tried to download HDS instead and it selects the best quality stream which is also 1280x720 H.264 25 fps and that downloaded stream plays fine in VLC.
The problem is peculiar. I have remuxed the .mp4 container into .mkv using MkvToolnix and the problem persists. But if I demux with MP4Box into separate files and then mux either with MkvToolnix to .mkv or with MP4Box .mp4 the problem disappears and the video plays as smooth in VLC as the HDS downloaded. From the outside (VLC codec info) the streams looks to be the same kind but there is apparently some subtle difference.
The only way this still could be teve's problem is if this is a FFMpeg muxing pecularity that could be worked around using some interesting parameter. Other than that since remuxing fixes the problem, this looks like Somebody Elses Problem.
Oh, and I think getting recoding capabilities into teve should be very low prio since there are other programs that do it good, and teve need only help by making it possible to select stream to download. I would very much prefer to be able to download from e.g urplay.se.
That's interesting, and considering that de- and remuxing seems to fix the file, I have to admit I might have been too quick to write it off as a player problem. (I've very rarely used VLC since I ditched it in favor of MPlayer in 2006, so I really don't know what to expect from it nowadays.)
I would still like to make this problem go away, though, and I cannot seem to reproduce it, so I was hoping you could try two diffs.
This first diff below tells FFmpeg to mux HLS streams into AVI files instead of MP4. If the problem is located in FFmpeg's MP4 muxing code, this might help.
diff --git a/download.scm b/download.scm index 91d317c..6b8e35d 100644 --- a/download.scm +++ b/download.scm @@ -81,7 +81,8 @@ ((stream-ref 'filename-extension stream)) (swf-path-ext) ((case (stream-ref 'stream-type stream) - ((hls hds) "mp4") + ((hls) "avi") + ((hds) "mp4") ((wmv mms) "wmv") (else #f))) (url-path-ext)
The next diff removes the audio bitstream filter, which means FFmpeg doesn't modify the audio stream before putting it on disk. Note that the first diff must already be applied for this to work, as FFmpeg refuses to mux ADTS audio streams into MP4 containers (or FLV ones, for that matter).
diff --git a/sites/svt.scm b/sites/svt.scm index 9c108d4..59bedb5 100644 --- a/sites/svt.scm +++ b/sites/svt.scm @@ -109,9 +109,6 @@ (make-stream-value 'subtitles subtitles) (make-stream-value 'view-at play-path) (make-stream-value 'live is-live) - (if (eq? 'hls (stream-ref 'stream-type stream)) - (make-stream-value 'ffmpeg-parameters - "-bsf:a aac_adtstoasc")) (if (eq? 'rtmp (stream-ref 'stream-type stream)) (make-stream-value 'swf-player (force swf-player)))))))
Also, I would really appreciate being able to compare the output of running
Last things first; here is a diff of the logs:
I notice there is a slight difference in the bitrate...
I'll get back later with the result of applying the code diffs...
Ok. Results from after applying the diffs, testing download, and more strange findings...
When playing the problematic .mp4 file in Aviedemux 2.5 there is no jerking apart from Avidemux's
Produced .avi files behave as follows:
Diff 1 has no jerking and no sound in VLC, no sound in Mplayer and hangs in Avidemux.
Thanks! The first thing I notice is this:
That's old. You are using an even older version of FFmpeg than I am (2013-03-19/libavformat 54.63.104). I believe your problem will go away if you get hold of a more recent version of FFmpeg. (Also, note that VLC might use libavformat for playback.)
After updating, the AVI files produced after applying the above diffs should work too.
That's what I got with OpenBSD 5.3 plain: ffmpeg-20121026p2 (Feb 25 2013 libavformat 53.32.100).
OpenBSD 5.4 is in the mail so I will do a binary upgrade when it arrives. It will be too much work
My VLC is o.t.o.h on a Windows machine and it's the latest 2.1.0 Rincewind.
Thank you very much for your support!
Thanks! I'm looking forward to see if moving to a more recent ffmpeg actually helps.
You're probably right about the dominoes, but I haven't looked into it since I'm usually on a snapshot. (Though I'm currently stuck in the past, since the 64-bit time_t thing scares me a bit.)
Yes. A more recent ffmpeg did the trick.
The binary upgrade to OpenBSD 5.4 went without problems. pkg_add -u did take some time. A binary
The upgrade took ffmpeg to git-N-50573-gfc5c81c 2013-07-22 libavformat 54.63.104,
Problem gone! Sorry for the noise. Thank you for your support!
Great! I wouldn't really classify this as "noise" at all, since we've pinpointed the version of libavformat needed. I've had reports of a similar playback problem with the HDS streams downloaded by AdobeHDS.php. Even though that process does not involve FFmpeg, libavformat was probably for playing the streams (or, it should be said, the HDS stuttering could be a separate issue).
That libavformat version 54 or above is needed should be documented in the troubleshooting section of the README. I'm changing the labelling of this issue from 'question' to 'documentation'.
Oh, and UR Play is issue #3.