FFmpeg 2.0 und softhddevice

I just grabbed latest softhddevice git c646007db1f68944b09d645636465b0ef973abec. Then grabbed latest ffmpeg git 1f7acf3cff0627c38f26f5a749389e156ab1fad0. ffmpeg was compiled with configure --disable-encoders --disable-muxers --enable-ffplay --enable-pic --enable-shared. After recompiling vdr & plugins, I get:

2013-07-21T00:17:57-07:00 [21102] loading plugin: /vdr/PLUGINS/lib/libvdr-softhddevice.so.2.0.0
2013-07-21T00:17:57-07:00 [21102] ERROR: libavcodec.so.55: cannot open shared object file: No such file or directory

If I compile ffmpeg 1.2.1 using the exact same configure line, there's no problem. Any ideas?

Hallo Johns,
ich habe den Rechner gerade nicht an, aber ich hatte glaube ich 55.7.108.

Wie wäre es mit
#ifndef FF_API_CODEC_ID
#define AVCodecId CodecId
#if !FF_API_CODEC_ID
#define AV_CODEC_ CODEC
...
#endif
#endif

Wenn's Dir zu viel Kompatibilitäts-Zeugs ist - kein Problem. Ich kann mit dem Patch leben.

Viele Grüße

Dominik

Gesendet von meinem iPad mit Tapatalk HD

jinx:
With "I never test ffmpeg GIT" johns means "You're on your own. FFmpeg GIT is unsupported"

jinx
Your problem is not directly related to what we discuss here. We talk about compilation problems with softhddevice.
You have to recompile softhddevice after installing ffmpeg git. This should cure the linker error.
If not, check the installed libs under /usr/local/lib.

Dominik

Gesendet von meinem iPad mit Tapatalk HD

Zitat von domml

Hallo Johns,
ich habe den Rechner gerade nicht an, aber ich hatte glaube ich 55.7.108.

Wie wäre es mit
#ifndef FF_API_CODEC_ID
#define AVCodecId CodecId
#if !FF_API_CODEC_ID
#define AV_CODEC_ CODEC
...
#endif
#endif

Alles anzeigen

Klappt so nicht.

#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(xx,yy,zzz) || defined(FF_API_CODEC_ID)
#endif

So müsste es gehen. Die Frage ist klappt es mit meinen "55.18.102"? Bzw. welche Version müsste man für xx.yy.zzz nehmen.
Alle alten ffmpeg Versionen bekommen die Anpassung und alle die alte API können.

Johns

Zitat von Copperhead

jinx:
With "I never test ffmpeg GIT" johns means "You're on your own. FFmpeg GIT is unsupported"

Johns has clearly stated he won't support ffmpeg git so what's the purpose of your reply? Maybe paying closer attention to the dialog between myself and domml would help in case you're confused as to who I replied to.

Zitat von domml

jinx
Your problem is not directly related to what we discuss here. We talk about compilation problems with softhddevice.
You have to recompile softhddevice after installing ffmpeg git. This should cure the linker error.
If not, check the installed libs under /usr/local/lib.

Recompiling vdr completely is always my last step so that error _is_ after ffmpeg git install -> vdr full recompile (meaning vdr-2.0.2 was removed, sources unpacked, everything compiled).

Zitat

2013-07-21T11:22:44-07:00 [2017] VDR version 2.0.2 started
2013-07-21T11:22:44-07:00 [2017] running as daemon (tid=2017)
2013-07-21T11:22:44-07:00 [2017] codeset is 'UTF-8' - known
2013-07-21T11:22:44-07:00 [2017] cTimeMs: using monotonic clock (resolution is 1 ns)
2013-07-21T11:22:44-07:00 [2017] loading plugin: /vdr/PLUGINS/lib/libvdr-eepg.so.2.0.0
2013-07-21T11:22:44-07:00 [2017] loading plugin: /vdr/PLUGINS/lib/libvdr-softhddevice.so.2.0.0
2013-07-21T11:22:44-07:00 [2017] ERROR: libavcodec.so.55: cannot open shared object file: No such file or directory
2013-07-21T11:22:44-07:00 [2017] deleting plugin: eepg
2013-07-21T11:22:44-07:00 [2017] exiting, exit code 2

~$ ls -la /usr/local/lib/libav*
-rw-r--r-- 1 root staff 107555314 Jul 20 23:37 /usr/local/lib/libavcodec.a
lrwxrwxrwx 1 root staff 23 Jul 20 23:37 /usr/local/lib/libavcodec.so -> libavcodec.so.55.18.102
lrwxrwxrwx 1 root staff 23 Jul 20 23:37 /usr/local/lib/libavcodec.so.55 -> libavcodec.so.55.18.102
-rwxr-xr-x 1 root staff 6964608 Jul 20 22:16 /usr/local/lib/libavcodec.so.55.18.102
-rw-r--r-- 1 root staff 1464310 Jul 20 23:25 /usr/local/lib/libavdevice.a
lrwxrwxrwx 1 root staff 23 Jul 20 23:37 /usr/local/lib/libavdevice.so -> libavdevice.so.55.3.100
lrwxrwxrwx 1 root staff 23 Jul 20 23:37 /usr/local/lib/libavdevice.so.55 -> libavdevice.so.55.3.100
-rwxr-xr-x 1 root staff 58144 Jul 20 22:16 /usr/local/lib/libavdevice.so.55.3.100
-rw-r--r-- 1 root staff 8520832 Jul 20 23:37 /usr/local/lib/libavfilter.a
lrwxrwxrwx 1 root staff 23 Jul 20 23:37 /usr/local/lib/libavfilter.so -> libavfilter.so.3.81.102
lrwxrwxrwx 1 root staff 23 Jul 20 23:37 /usr/local/lib/libavfilter.so.3 -> libavfilter.so.3.81.102
-rwxr-xr-x 1 root staff 697584 Jul 20 22:16 /usr/local/lib/libavfilter.so.3.81.102
-rw-r--r-- 1 root staff 29850090 Jul 20 23:37 /usr/local/lib/libavformat.a
lrwxrwxrwx 1 root staff 24 Jul 20 23:37 /usr/local/lib/libavformat.so -> libavformat.so.55.12.102
lrwxrwxrwx 1 root staff 24 Jul 20 23:37 /usr/local/lib/libavformat.so.55 -> libavformat.so.55.12.102
-rwxr-xr-x 1 root staff 1111272 Jul 20 22:16 /usr/local/lib/libavformat.so.55.12.102
-rw-r--r-- 1 root staff 1567396 Jul 20 23:37 /usr/local/lib/libavutil.a
lrwxrwxrwx 1 root staff 22 Jul 20 23:37 /usr/local/lib/libavutil.so -> libavutil.so.52.40.100
lrwxrwxrwx 1 root staff 22 Jul 20 23:37 /usr/local/lib/libavutil.so.52 -> libavutil.so.52.40.100
-rwxr-xr-x 1 root staff 237040 Jul 20 22:16 /usr/local/lib/libavutil.so.52.40.100

Alles anzeigen

So softhddevice wrongly thinks the lib is not there since we can see it actually is. Or am I not seeing something here? Thanks for your help Domml!

Zitat von jinx

So softhddevice wrongly thinks the lib is not there since we can see it actually is. Or am I not seeing something here? Thanks for your help Domml!

I expect you don't have /usr/local/lib in your /etc/ld.so.conf, or in one of the files in /etc/ld.so.conf.d/.

If this is true, then that is not an error of softhddevice, but yours.

Gerald

Zitat von gda

I expect you don't have /usr/local/lib in your /etc/ld.so.conf, or in one of the files in /etc/ld.so.conf.d/.

If this is true, then that is not an error of softhddevice, but yours.

Keep in mind, this problem doesn't occur with my old ffmpeg-1.2.1 compiled .deb (..I use Debian Testing..) so if that were the problem, the same error would occur. But to prove it:

Zitat

$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

$ cat /etc/ld.so.conf.d/*.conf
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

Alles anzeigen

The only difference I see is the version numbers; libavcodec.so.54.92.100 (1.2.1), libavcodec.so.55.18.102 (git).

Are there any other reasons softhddevice would think a file is missing that isn't?

Zitat von jinx

The only difference I see is the version numbers; libavcodec.so.54.92.100 (1.2.1), libavcodec.so.55.18.102 (git).

Did you call ldconfig after compile of libavcodec.so, or made a reboot?

Gerald

Zitat von gda

Did you call ldconfig after compile of libavcodec.so, or made a reboot?

Neither of those. I don't know anything about calling ldconfig (I've never had to do that before), and reboot wasn't necessary so I didn't do that. I pretty much only reboot after compiling a new kernel. Thanks for help!

Zitat von jinx

Neither of those. I don't know anything about calling ldconfig

Did you do it now?

Gerald

Zitat von gda

Did you do it now?

It seems that calling ldconfig fixed the problem, many thanks! Any idea why this was never required before? Maybe doing `dpkg -i` used to do it but no longer does?

Zitat von jinx

It seems that calling ldconfig fixed the problem, many thanks! Any idea why this was never required before? Maybe doing `dpkg -i` used to do it but no longer does?

The linux loader doesn't look in the directories that are in /etc/ld.so.conf.d/*, it looks in the file /etc/ld.so.cache. In this cache file it finds your old libavcodec.so pointing to /usr/lib. but the new files are in /usr/local/lib. So there is no hit.
ldconfig renews the cache. This is happening during a reboot too, this is why a reboot helps.

Gerald

Ich bin jetzt ein paar Tage unterwegs. Da kann ich nichts probieren. Ich kenne git nicht besonders gut. Mit CVS würde ich mit log/annotate versuchen herauszubekommen, wann sich die betreffende Zeile im ffmpeg sourcecode geändert hat. Vielleicht komme ich am Wochende dazu.

Grüße

Dominik

Gesendet von meinem iPad mit Tapatalk HD

Beim Testen ist mir aufgefallen, dass die ffmpeg Version 1.2.0 im Gegensatz zur 1.2.1 und 2.0 etwas besser beim Zurückspulen von Sky Aufnahmen mit dem softhddevice-plugin ist. Hatte eigentlich gehofft, dass das irgendwann mal so gut funzt wie mit dem xine-plugin. Scheint also nicht das alleinige Problem von ffmpeg zu sein...

Gruß
iNOB

Zitat von iNOB

Beim Testen ist mir aufgefallen, dass die ffmpeg Version 1.2.0 im Gegensatz zur 1.2.1 und 2.0 etwas besser beim Zurückspulen von Sky Aufnahmen mit dem softhddevice-plugin ist. Hatte eigentlich gehofft, dass das irgendwann mal so gut funzt wie mit dem xine-plugin. Scheint also nicht das alleinige Problem von ffmpeg zu sein...

Assuming the german translator was somewhat accurate, I can say that fast-forward/rewind mpeg2 and h264 recordings works perfectly with vdr-xine + xine-lib-1.2 (using vdpau). However, softhddevice fails to fast-forward/rewind correctly here. Or rather, it doesn't play from the correct place after having ffw/rew. For example, if I press rewind at a time of 00:04:00 (4mins), and rewind for 10 seconds, when I press play softhddevice does not play from 00:03:50 as you would expect. Instead it plays from 00:04:00. Vdr-xine had the same problem but Rnissl fixed it after sending him a sample. I did send a sample to Johns quite some time ago but maybe he forgot about it or just didn't bother to fix, I dunno. I thought about switching back to vdr-xine because of this problem but then I think about the 1.5GB of useless bloat-crap in xine-lib-1.2 when the only thing I need is vdpau. Here isn't the place to complain about linux dependency hell though.

This a problem with ffmpeg. But I have no problem with fast forward, only fast backward does no output with some streams.
The mplayer has no fast forward or fast backward, they never test this.
Some version works better, sometime the hardware decoder, sometime the software decoder.

xine has its own h264 vdpau decoder, which seems to work better. But I have no time and fun to implement it. It is very low on my Todo list.

Edit: what do you mean with jumps? 30s jumps forward and backward are working perfect.

Johns

Zitat von johns

This a problem with ffmpeg. But I have no problem with fast forward, only fast backward does no output with some streams.
The mplayer has no fast forward or fast backward, they never test this.
Some version works better, sometime the hardware decoder, sometime the software decoder.

xine has its own h264 vdpau decoder, which seems to work better. But I have no time and fun to implement it. It is very low on my Todo list.

Since vdr-xine already has a rock solid decoder, why not ask Rnissl permission to use it? It can only make softhddevice better & more usable for people. Or at least if the problem is inside ffmpeg, bring it to the attention of the ffmpeg devs. I'm actually surprised there would be any vdpau bugs in ffmpeg at this point.

The alternate h264 vdpau decoder is in xine, not vdr-xine plugin, and it is written by Christophe Thommeret (alternate because there are two, we use the alternate one).