New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libavformat 54 or later needed (was: VLC Jerky Playback) #24

Closed
RaimoNiskanen opened this Issue Oct 13, 2013 · 10 comments

Comments

Projects
None yet
2 participants
@RaimoNiskanen

RaimoNiskanen commented Oct 13, 2013

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

/ Raimo

@simio

This comment has been minimized.

Show comment
Hide comment
@simio

simio Oct 14, 2013

Owner

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:

If you're having trouble with your high definition videos and they're encoded with the H.264 codec then you might want to try this: Preferences -> (tab) Input / Codecs -> (tab) Other codecs -> FFmpeg -> (tick "Advanced options" box) in the drop-list next to "Skip the loop filter for H.264 decoding" select "All", save and restart VLC.

That said, the codecs used by a typical SVT Play video should be reported like this by VLC:
vlc-codec
If this is what you see, and your computer is fast enough to cope with your current VLC playback configuration, everything should work fine.

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.

Owner

simio commented Oct 14, 2013

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:

If you're having trouble with your high definition videos and they're encoded with the H.264 codec then you might want to try this: Preferences -> (tab) Input / Codecs -> (tab) Other codecs -> FFmpeg -> (tick "Advanced options" box) in the drop-list next to "Skip the loop filter for H.264 decoding" select "All", save and restart VLC.

That said, the codecs used by a typical SVT Play video should be reported like this by VLC:
vlc-codec
If this is what you see, and your computer is fast enough to cope with your current VLC playback configuration, everything should work fine.

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.

@RaimoNiskanen

This comment has been minimized.

Show comment
Hide comment
@RaimoNiskanen

RaimoNiskanen Oct 20, 2013

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.

RaimoNiskanen commented Oct 20, 2013

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.

@simio

This comment has been minimized.

Show comment
Hide comment
@simio

simio Oct 20, 2013

Owner

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 mplayer -v -identify -frames 0 $file on a problematic MP4 file, and the output of running the same command on a copy of the file which you have fixed by de- and remuxing it. Any subtle differences might actually show up there.

Owner

simio commented Oct 20, 2013

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 mplayer -v -identify -frames 0 $file on a problematic MP4 file, and the output of running the same command on a copy of the file which you have fixed by de- and remuxing it. Any subtle differences might actually show up there.

@RaimoNiskanen RaimoNiskanen reopened this Oct 21, 2013

@RaimoNiskanen

This comment has been minimized.

Show comment
Hide comment
@RaimoNiskanen

RaimoNiskanen Oct 21, 2013

Last things first; here is a diff of the logs:

$ diff -u0 mplayer.log.hls.mp4 mplayer.log.hls_remux.mp4 
--- mplayer.log.hls.mp4 Mon Oct 21 21:43:59 2013
+++ mplayer.log.hls_remux.mp4   Mon Oct 21 21:44:48 2013
@@ -19 +19 @@
-CommandLine: '-v' '-identify' '-frames' '0' '/mnt/livet-pa-operan_1av5.hls.mp4'
+CommandLine: '-v' '-identify' '-frames' '0' '/mnt/livet-pa-operan_1av5.hls_remux.mp4'
@@ -25 +25 @@
-get_path('livet-pa-operan_1av5.hls.mp4.conf') -> '/home/raimo/.mplayer/livet-pa-operan_1av5.hls.mp4.conf'
+get_path('livet-pa-operan_1av5.hls_remux.mp4.conf') -> '/home/raimo/.mplayer/livet-pa-operan_1av5.hls_remux.mp4.conf'
@@ -27 +27 @@
-Playing /mnt/livet-pa-operan_1av5.hls.mp4.
+Playing /mnt/livet-pa-operan_1av5.hls_remux.mp4.
@@ -29,2 +29,2 @@
-[file] File size is 1226048296 bytes
-STREAM: [file] /mnt/livet-pa-operan_1av5.hls.mp4
+[file] File size is 1217550141 bytes
+STREAM: [file] /mnt/livet-pa-operan_1av5.hls_remux.mp4
@@ -38,8 +38,9 @@
-[mov,mp4,m4a,3gp,3g2,mj2 @ 0x20ce8ee0]ISO: File Type Major Brand: isom
-[h264 @ 0x2db65f20]err{or,}_recognition separate: 1; 1
-[h264 @ 0x2db65f20]err{or,}_recognition combined: 1; 10001
-[aac @ 0x2db65f20]err{or,}_recognition separate: 1; 1
-[aac @ 0x2db65f20]err{or,}_recognition combined: 1; 10001
-[aac @ 0x2db65f20]Unsupported bit depth: 0
-[h264 @ 0x2db65f20]no picture 
-[mov,mp4,m4a,3gp,3g2,mj2 @ 0x20ce8ee0]All info found
+[mov,mp4,m4a,3gp,3g2,mj2 @ 0x23805ee0]ISO: File Type Major Brand: isom
+[h264 @ 0x283fcf20]err{or,}_recognition separate: 1; 1
+[h264 @ 0x283fcf20]err{or,}_recognition combined: 1; 10001
+[aac @ 0x283fcf20]err{or,}_recognition separate: 1; 1
+[aac @ 0x283fcf20]err{or,}_recognition combined: 1; 10001
+[aac @ 0x283fcf20]Unsupported bit depth: 0
+[h264 @ 0x283fcf20]no picture 
+[h264 @ 0x283fcf20]no picture 
+[mov,mp4,m4a,3gp,3g2,mj2 @ 0x23805ee0]All info found
@@ -74 +75 @@
-VIDEO:  [H264]  1280x720  24bpp  25.000 fps  2699.6 kbps (329.5 kbyte/s)
+VIDEO:  [H264]  1280x720  24bpp  25.000 fps  2680.2 kbps (327.2 kbyte/s)
@@ -80 +81 @@
- minor_version: 512
+ minor_version: 1
@@ -82,2 +83,2 @@
-ID_CLIP_INFO_VALUE1=512
- compatible_brands: isomiso2avc1mp41
+ID_CLIP_INFO_VALUE1=1
+ compatible_brands: isomavc1
@@ -85,5 +86,8 @@
-ID_CLIP_INFO_VALUE2=isomiso2avc1mp41
- encoder: Lavf53.32.100
-ID_CLIP_INFO_NAME3=encoder
-ID_CLIP_INFO_VALUE3=Lavf53.32.100
-ID_CLIP_INFO_N=4
+ID_CLIP_INFO_VALUE2=isomavc1
+ creation_time: 2013-10-19 16:11:03
+ID_CLIP_INFO_NAME3=creation_time
+ID_CLIP_INFO_VALUE3=2013-10-19 16:11:03
+ encoder: My MP4Box GUI 0.4.9.1 By Matt Bodin
+ID_CLIP_INFO_NAME4=encoder
+ID_CLIP_INFO_VALUE4=My MP4Box GUI 0.4.9.1 By Matt Bodin
+ID_CLIP_INFO_N=5
@@ -92 +96 @@
-ID_FILENAME=/mnt/livet-pa-operan_1av5.hls.mp4
+ID_FILENAME=/mnt/livet-pa-operan_1av5.hls_remux.mp4
@@ -95 +99 @@
-ID_VIDEO_BITRATE=2699576
+ID_VIDEO_BITRATE=2680176
@@ -121,2 +125,2 @@
-[h264 @ 0x2db65f20]err{or,}_recognition separate: 1; 30001
-[h264 @ 0x2db65f20]err{or,}_recognition combined: 1; 30001
+[h264 @ 0x283fcf20]err{or,}_recognition separate: 1; 30001
+[h264 @ 0x283fcf20]err{or,}_recognition combined: 1; 30001
@@ -131,3 +135,3 @@
-[aac @ 0x2db65f20]err{or,}_recognition separate: 1; 1
-[aac @ 0x2db65f20]err{or,}_recognition combined: 1; 10001
-[aac @ 0x2db65f20]Unsupported bit depth: 0
+[aac @ 0x283fcf20]err{or,}_recognition separate: 1; 1
+[aac @ 0x283fcf20]err{or,}_recognition combined: 1; 10001
+[aac @ 0x283fcf20]Unsupported bit depth: 0

I notice there is a slight difference in the bitrate...
I also remember that when I tried to remux using just MkvToolnix from .mp4 to .mkv it complained
about the stream containing negative timestamps that was adjusted.

I'll get back later with the result of applying the code diffs...

RaimoNiskanen commented Oct 21, 2013

Last things first; here is a diff of the logs:

$ diff -u0 mplayer.log.hls.mp4 mplayer.log.hls_remux.mp4 
--- mplayer.log.hls.mp4 Mon Oct 21 21:43:59 2013
+++ mplayer.log.hls_remux.mp4   Mon Oct 21 21:44:48 2013
@@ -19 +19 @@
-CommandLine: '-v' '-identify' '-frames' '0' '/mnt/livet-pa-operan_1av5.hls.mp4'
+CommandLine: '-v' '-identify' '-frames' '0' '/mnt/livet-pa-operan_1av5.hls_remux.mp4'
@@ -25 +25 @@
-get_path('livet-pa-operan_1av5.hls.mp4.conf') -> '/home/raimo/.mplayer/livet-pa-operan_1av5.hls.mp4.conf'
+get_path('livet-pa-operan_1av5.hls_remux.mp4.conf') -> '/home/raimo/.mplayer/livet-pa-operan_1av5.hls_remux.mp4.conf'
@@ -27 +27 @@
-Playing /mnt/livet-pa-operan_1av5.hls.mp4.
+Playing /mnt/livet-pa-operan_1av5.hls_remux.mp4.
@@ -29,2 +29,2 @@
-[file] File size is 1226048296 bytes
-STREAM: [file] /mnt/livet-pa-operan_1av5.hls.mp4
+[file] File size is 1217550141 bytes
+STREAM: [file] /mnt/livet-pa-operan_1av5.hls_remux.mp4
@@ -38,8 +38,9 @@
-[mov,mp4,m4a,3gp,3g2,mj2 @ 0x20ce8ee0]ISO: File Type Major Brand: isom
-[h264 @ 0x2db65f20]err{or,}_recognition separate: 1; 1
-[h264 @ 0x2db65f20]err{or,}_recognition combined: 1; 10001
-[aac @ 0x2db65f20]err{or,}_recognition separate: 1; 1
-[aac @ 0x2db65f20]err{or,}_recognition combined: 1; 10001
-[aac @ 0x2db65f20]Unsupported bit depth: 0
-[h264 @ 0x2db65f20]no picture 
-[mov,mp4,m4a,3gp,3g2,mj2 @ 0x20ce8ee0]All info found
+[mov,mp4,m4a,3gp,3g2,mj2 @ 0x23805ee0]ISO: File Type Major Brand: isom
+[h264 @ 0x283fcf20]err{or,}_recognition separate: 1; 1
+[h264 @ 0x283fcf20]err{or,}_recognition combined: 1; 10001
+[aac @ 0x283fcf20]err{or,}_recognition separate: 1; 1
+[aac @ 0x283fcf20]err{or,}_recognition combined: 1; 10001
+[aac @ 0x283fcf20]Unsupported bit depth: 0
+[h264 @ 0x283fcf20]no picture 
+[h264 @ 0x283fcf20]no picture 
+[mov,mp4,m4a,3gp,3g2,mj2 @ 0x23805ee0]All info found
@@ -74 +75 @@
-VIDEO:  [H264]  1280x720  24bpp  25.000 fps  2699.6 kbps (329.5 kbyte/s)
+VIDEO:  [H264]  1280x720  24bpp  25.000 fps  2680.2 kbps (327.2 kbyte/s)
@@ -80 +81 @@
- minor_version: 512
+ minor_version: 1
@@ -82,2 +83,2 @@
-ID_CLIP_INFO_VALUE1=512
- compatible_brands: isomiso2avc1mp41
+ID_CLIP_INFO_VALUE1=1
+ compatible_brands: isomavc1
@@ -85,5 +86,8 @@
-ID_CLIP_INFO_VALUE2=isomiso2avc1mp41
- encoder: Lavf53.32.100
-ID_CLIP_INFO_NAME3=encoder
-ID_CLIP_INFO_VALUE3=Lavf53.32.100
-ID_CLIP_INFO_N=4
+ID_CLIP_INFO_VALUE2=isomavc1
+ creation_time: 2013-10-19 16:11:03
+ID_CLIP_INFO_NAME3=creation_time
+ID_CLIP_INFO_VALUE3=2013-10-19 16:11:03
+ encoder: My MP4Box GUI 0.4.9.1 By Matt Bodin
+ID_CLIP_INFO_NAME4=encoder
+ID_CLIP_INFO_VALUE4=My MP4Box GUI 0.4.9.1 By Matt Bodin
+ID_CLIP_INFO_N=5
@@ -92 +96 @@
-ID_FILENAME=/mnt/livet-pa-operan_1av5.hls.mp4
+ID_FILENAME=/mnt/livet-pa-operan_1av5.hls_remux.mp4
@@ -95 +99 @@
-ID_VIDEO_BITRATE=2699576
+ID_VIDEO_BITRATE=2680176
@@ -121,2 +125,2 @@
-[h264 @ 0x2db65f20]err{or,}_recognition separate: 1; 30001
-[h264 @ 0x2db65f20]err{or,}_recognition combined: 1; 30001
+[h264 @ 0x283fcf20]err{or,}_recognition separate: 1; 30001
+[h264 @ 0x283fcf20]err{or,}_recognition combined: 1; 30001
@@ -131,3 +135,3 @@
-[aac @ 0x2db65f20]err{or,}_recognition separate: 1; 1
-[aac @ 0x2db65f20]err{or,}_recognition combined: 1; 10001
-[aac @ 0x2db65f20]Unsupported bit depth: 0
+[aac @ 0x283fcf20]err{or,}_recognition separate: 1; 1
+[aac @ 0x283fcf20]err{or,}_recognition combined: 1; 10001
+[aac @ 0x283fcf20]Unsupported bit depth: 0

I notice there is a slight difference in the bitrate...
I also remember that when I tried to remux using just MkvToolnix from .mp4 to .mkv it complained
about the stream containing negative timestamps that was adjusted.

I'll get back later with the result of applying the code diffs...

@RaimoNiskanen

This comment has been minimized.

Show comment
Hide comment
@RaimoNiskanen

RaimoNiskanen Oct 21, 2013

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
normal lack of playback smoothness.

Produced .avi files behave as follows:

Diff 1 has no jerking and no sound in VLC, no sound in Mplayer and hangs in Avidemux.
Diff 2 has no jerking and no sound in VLC, sound in Mplayer and rotten(chopped) sound in Avidemux
that indicates codec AAC with a Constant Bit Rate of 0 kBit/s at 48000 Hz, no duration nor size.
Codec info in VLC says the sound track is MPEG AAC (mp4a) stereo 48000 Hz with AAC-filesuffix: SBR (?),
and that is what VLC codec info says for both working, problematic and remuxed files too.

RaimoNiskanen commented Oct 21, 2013

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
normal lack of playback smoothness.

Produced .avi files behave as follows:

Diff 1 has no jerking and no sound in VLC, no sound in Mplayer and hangs in Avidemux.
Diff 2 has no jerking and no sound in VLC, sound in Mplayer and rotten(chopped) sound in Avidemux
that indicates codec AAC with a Constant Bit Rate of 0 kBit/s at 48000 Hz, no duration nor size.
Codec info in VLC says the sound track is MPEG AAC (mp4a) stereo 48000 Hz with AAC-filesuffix: SBR (?),
and that is what VLC codec info says for both working, problematic and remuxed files too.

@simio

This comment has been minimized.

Show comment
Hide comment
@simio

simio Oct 22, 2013

Owner

Thanks! The first thing I notice is this:

-ID_CLIP_INFO_NAME3=encoder
-ID_CLIP_INFO_VALUE3=Lavf53.32.100

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.

Owner

simio commented Oct 22, 2013

Thanks! The first thing I notice is this:

-ID_CLIP_INFO_NAME3=encoder
-ID_CLIP_INFO_VALUE3=Lavf53.32.100

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.

@RaimoNiskanen

This comment has been minimized.

Show comment
Hide comment
@RaimoNiskanen

RaimoNiskanen Oct 22, 2013

That's what I got with OpenBSD 5.3 plain: ffmpeg-20121026p2 (Feb 25 2013 libavformat 53.32.100).
My mplayer-20120725 is SVN-r35048 in the same installation.

OpenBSD 5.4 is in the mail so I will do a binary upgrade when it arrives. It will be too much work
to source upgrade via ports just to get a newer ffmpeg as I assume massive dependency domino
so my little installation would have to build for days... To get teve running I have installed a total
of 119 packages (a few might be unrelated, a bunch are due to Firefox) plus source installation
of chicken-scheme.

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!

RaimoNiskanen commented Oct 22, 2013

That's what I got with OpenBSD 5.3 plain: ffmpeg-20121026p2 (Feb 25 2013 libavformat 53.32.100).
My mplayer-20120725 is SVN-r35048 in the same installation.

OpenBSD 5.4 is in the mail so I will do a binary upgrade when it arrives. It will be too much work
to source upgrade via ports just to get a newer ffmpeg as I assume massive dependency domino
so my little installation would have to build for days... To get teve running I have installed a total
of 119 packages (a few might be unrelated, a bunch are due to Firefox) plus source installation
of chicken-scheme.

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!

@simio

This comment has been minimized.

Show comment
Hide comment
@simio

simio Oct 22, 2013

Owner

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.)

119 packages sounds like an insane amount! I've half-maintained a private OpenBSD port of Chicken since forever. It's available here now. There's also one in the openbsd-wip repo.

Owner

simio commented Oct 22, 2013

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.)

119 packages sounds like an insane amount! I've half-maintained a private OpenBSD port of Chicken since forever. It's available here now. There's also one in the openbsd-wip repo.

@RaimoNiskanen

This comment has been minimized.

Show comment
Hide comment
@RaimoNiskanen

RaimoNiskanen Oct 27, 2013

Yes. A more recent ffmpeg did the trick.
I stashed your patch suggestions and did run my originally compiled teve executable. First before
upgrading I downloaded something else from svtplay since the videos I have been struggling with
have expired, then after upgrading. The file downloaded before upgrading jerks, and the one
after plays smooth like anything.

The binary upgrade to OpenBSD 5.4 went without problems. pkg_add -u did take some time. A binary
upgrade does not delete any old libraries so I did not touch my source installation of Chicken Scheme
nor my compilation of teve.

The upgrade took ffmpeg to git-N-50573-gfc5c81c 2013-07-22 libavformat 54.63.104,
the latter same as yours.

Problem gone! Sorry for the noise. Thank you for your support!
Keep up the good work (especially urplay.se if I get a vote).

RaimoNiskanen commented Oct 27, 2013

Yes. A more recent ffmpeg did the trick.
I stashed your patch suggestions and did run my originally compiled teve executable. First before
upgrading I downloaded something else from svtplay since the videos I have been struggling with
have expired, then after upgrading. The file downloaded before upgrading jerks, and the one
after plays smooth like anything.

The binary upgrade to OpenBSD 5.4 went without problems. pkg_add -u did take some time. A binary
upgrade does not delete any old libraries so I did not touch my source installation of Chicken Scheme
nor my compilation of teve.

The upgrade took ffmpeg to git-N-50573-gfc5c81c 2013-07-22 libavformat 54.63.104,
the latter same as yours.

Problem gone! Sorry for the noise. Thank you for your support!
Keep up the good work (especially urplay.se if I get a vote).

@simio

This comment has been minimized.

Show comment
Hide comment
@simio

simio Oct 27, 2013

Owner

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'.

Thank you!

Oh, and UR Play is issue #3.

Owner

simio commented Oct 27, 2013

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'.

Thank you!

Oh, and UR Play is issue #3.

@simio simio closed this in 993fe7b Oct 27, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment