Downgrading a package (ffmpeg) and all its dependencies automatically

kox · 2017-11-29 17:52:26

I have a problem with ffmpeg. Back in May 2017 I made some recordings of my screen and everything was fine. Now (at least since October) .mp4 (h264) recordings don't play in most browsers. I have no idea how could I ever solve this problem, other than rolling back ffmpeg and everything it requires to a version from May 2017. I could (and I will) submit a bug, but I need it as fast as possible to record videos for my website.

So I downloaded ffmpeg-1:3.3-6-x86_64.pkg.tar.xz from https://archive.archlinux.org/packages/f/ffmpeg/ and tried to install it. I got errors however:
warning: cannot resolve "libnetcdf.so=11-64", a dependency of "ffmpeg"
warning: cannot resolve "libx265.so=116-64", a dependency of "ffmpeg"
:: The following package cannot be upgraded due to unresolvable dependencies:
ffmpeg

Is there a tool or a method that would automatically resolve all dependencies needed for the downgrade?

eschwartz · 2017-11-29 17:57:39

yes, you can use archive.archlinux.org as a back-in-time repository, by using the following in your mirrorlist (and replacing the year/month/day with whatever you want):

Server = https://archive.archlinux.org/repos/2017/11/29/$repo/os/$arch

kox · 2017-11-29 18:03:12

Great, thanks. Once I install the old ffmpeg and all its dependencies, is it possible to change the mirror back to the recent one and prevent ffmpeg and its dependencies from being upgraded on Pacman -Syu ?

eschwartz · 2017-11-29 18:28:46

It is "possible", but doing so will just break everything that depends on any of those packages... which I would think is worse than those packages having a working ffmpeg that simply has one broken feature.

kox · 2017-11-29 18:48:07

Yes, I have downgraded only these packages and no videos would play at all. I guess I will install a new os for video recording and have it frozen to May 2017.

eschwartz · 2017-11-29 19:28:51

FWIW mp4 files play fine for me in Firefox, so if you could provide more details about this bug and/or file an upstream bugreport then that would sort of help a lot.... you're saying it was broken at least a month ago but still didn't file a bug? How will it ever get fixed?

kox · 2017-11-29 21:30:45

I know, I should have. Perhaps it would get solved by now. I have so many things on my head now that time just flies and one month ago is like 3 days ago to me. The videos play fine on my computer, but they won't on Chrome Android, Windows 10 Edge, Mac OS Safari.

I recorded with SimpleScreenRecorder, and I tried manually as well:
ffmpeg -video_size 1366x768 -framerate 60 -f x11grab -i :0.0 -c:v libx264 -crf 0 -preset ultrafast output.mkv
ffmpeg -i output.mkv -vcodec libx264 -preset slow -crf 22 -threads 0 video.mp4

This is an example recording made with SimpleScreenRecorder:
https://storage.googleapis.com/cohesive … _test4.mp4

I just tested it, it plays on Chrome on Linux, but won't play on Android Chrome (and probably Edge, Safari as well).

teckk · 2017-11-29 22:17:20

That 6 second video is 14Mb.
-crf 0 This is way overkill. -crf 18 is about average.
-framerate 60 This is overkill too. DVD is 30

ffprobe https://storage.googleapis.com/cohesive-signal-7550/capture_test4.mp4
...
  encoder         : Lavf57.83.100
  Duration: 00:00:06.23, start: 0.000000, bitrate: 19097 kb/s
    Stream #0:0(und): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuv420p(tv, bt709), 1366x768 [SAR 1:1 DAR 683:384], 19096 kb/s, 60.16 fps, 60 tbr, 15360 tbn, 120 tbc (default)
    Metadata:
      handler_name    : VideoHandler

19096 kb/s.

Try something a little lighter and see what you get.

ffmpeg -t 00:00:10 -f x11grab -r 24 -s 1366x768 -i :0.0 -c:v libx264 -b:v 1200k -s 683x384 output.mp4

That's 10 seconds and it is 950k
Or

ffmpeg -t 00:00:10 -f x11grab -r 24 -s 1366x768 -i :0.0 -c:v libx264 -crf 10 -preset veryslow -s 683x384 output2.mp4

Or even

ffmpeg -t 00:00:10 -f x11grab -r 24 -s 1366x768 -i :0.0 -c:v libx264 -b:v 2500k -s 800x450 output3.mp4

Edit:
I tried to play those .mp4 on an android phone and they would not.

This would though, on the stock media player that came with the phone. x263

ffmpeg -t 00:00:10 -f x11grab -r 24 -s 1366x768 -i :0.0 -b:v 1200k -movflags +faststart -s 704x576 output.3gp

Last edited by teckk (2017-11-29 22:51:53)

Xyne · 2017-11-29 23:07:57

kox wrote:

Is there a tool or a method that would automatically resolve all dependencies needed for the downgrade?

Just FYI, ala-config (in the alatools package) can be used as a wrapper around Pacman (or another Pacman wrapper) to install packages and their dependencies from any point in time tracked by the Arch Linux Archive. It's mostly meant for users to step through upgrades on outdated systems to handle manual interventions, or to install new packages when you can't do a full system upgrade and don't want to do a partial upgrade, but downgrading (some) packages works too.

As already stated in this thread, downgrading some packages leads to an inconsistent system (partial downgrade = partial upgrade) and is neither recommended nor supported. It should only ever be used for a very temporary quickfix and only if you are sure that you won't break criticial system components.

DrZaius · 2017-11-30 00:29:27

kox wrote:

ffmpeg -i output.mkv -vcodec libx264 -preset slow -crf 22 -threads 0 video.mp4

Add "-pix_fmt yuv420p" so it will use a widely compatible pixel format. This is your main issue.
Add "-movflags +faststart" output option so it can begin playback before it is completely downloaded by the viewer (assuming progressive download).
Remove "-threads 0". Threads are automatic.

Your machine is probably fast enough to not require the two step process, so the example becomes:

ffmpeg -video_size 1366x768 -framerate 60 -f x11grab -i :0.0 -c:v libx264 -crf 22 -preset slow -pix_fmt yuv420p -movflags +faststart output.mp4

If it's too slow to encode in realtime (refer to the console output) use a faster preset.

No need to downgrade. If you still have problems show your actual ffmpeg command and the complete console output, and format it with the code tag to make it easier to read.

Last edited by DrZaius (2017-11-30 00:34:19)

DrZaius · 2017-11-30 00:41:34

teckk wrote:

Try something a little lighter and see what you get.
ffmpeg -t 00:00:10 -f x11grab -r 24 -s 1366x768 -i :0.0 -c:v libx264 -b:v 1200k -s 683x384 output.mp4

x11grab options are -framerate instead of -r and -video_size instead of -s. Avoid using -b:v with x264 unless you need to target a specifc output file size, and if you need to do that use two passes. Use -crf instead. A value of 0 is lossless, 17 or 18 is visually lossless, 23 is default. 10 is wasteful: either use 0 or ~18. See FFmpeg Wiki: H.264 Encoding for more info.

kox · 2017-12-01 15:25:24

Thank you a lot DrZaius! You can't imagine how much time you have saved me. I thought I would have to rerecord all videos but I can just convert them from mkv I already have.

So it was most likely a problem with SimpleScreenRecorder using incorrect config for ffmpeg, not ffmpeg itself.

@teckk I don't know if 60 FPS is overkill. My monitor refresh rate is 60 and I'm showing my application on these videos, so the video must be best quality possible.

By the way, I use this command to convert to .webm:

ffmpeg -i video.mkv -c:v libvpx -crf 18 -b:v 1M -c:a libvorbis video.webm

Are any improvements needed here? Is -movflags +faststart also applicable for .webm?

Last edited by kox (2017-12-01 21:33:35)

DrZaius · 2017-12-01 19:05:43

kox wrote:

I don't know if 60 FPS is overkill. My monitor refresh rate is 60 and I'm showing my application on these videos, so the video must be best quality possible.

60 fps is just fine if you're recording some games and would be better than the default rate of 25 (if you omitted -framerate). Depends on what you're recording.

kox wrote:

By the way, I use this command to convert to .webm:
ffmpeg -i video.mkv -c:v libvpx -crf 18 -b:v 1M -c:a libvorbis video.webm

You forgot the code tag.

kox wrote:

Are any improvements needed here?

You can use libvpx-vp9 instead of libvpx and libopus instead of libvorbis. Note that encoding to VP9 is slow but you'll get a much smaller output file size. See FFmpeg Wiki: VP9 Encoding for more info. There's a VP8 version too if you want to use libvpx instead but I wouldn't if you can handle VP9 encoding slowness.

kox wrote:

Is -movflags +faststart also applicable for .webm?

No. Ignore that for WebM.

kox · 2017-12-02 11:11:41

Thanks again!

Arch Linux

#1 2017-11-29 17:52:26

Downgrading a package (ffmpeg) and all its dependencies automatically

#2 2017-11-29 17:57:39

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#3 2017-11-29 18:03:12

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#4 2017-11-29 18:28:46

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#5 2017-11-29 18:48:07

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#6 2017-11-29 19:28:51

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#7 2017-11-29 21:30:45

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#8 2017-11-29 22:17:20

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#9 2017-11-29 23:07:57

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#10 2017-11-30 00:29:27

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#11 2017-11-30 00:41:34

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#12 2017-12-01 15:25:24

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#13 2017-12-01 19:05:43

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

#14 2017-12-02 11:11:41

Re: Downgrading a package (ffmpeg) and all its dependencies automatically

Board footer