[FFmpeg-user] FFMPEG failing in AWS Lambda

[Zaid Amir]

As I explained I tried both static and dynamic.. of course ldd does not work on static binaries.




Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: ffmpeg-user <ffmpeg-user-bounces at ffmpeg.org> on behalf of Carl Eugen Hoyos <ceffmpeg at gmail.com>
Sent: Tuesday, September 11, 2018 12:25:22 AM
To: FFmpeg user questions
Subject: Re: [FFmpeg-user] FFMPEG failing in AWS Lambda

2018-09-10 10:19 GMT+02:00, Zaid Amir <zaid.a at genie9.com>:
> Well its very likely I'm afraid.
>
> Below is the output when converting a single frame to jpg on my build
> environment, this fails when run in Lambda.
>
> ffmpeg version N-91639-g85c0064 Copyright (c) 2000-2018 the FFmpeg
> developers
>   built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-28)
>   configuration: --prefix=/home/ec2-user/ffmpeg_build
> --pkg-config-flags=--static
> --extra-cflags=-I/home/ec2-user/ffmpeg_build/include
> --extra-ldflags=-L/home/ec2-user/ffmpeg_build/lib --extra-libs=-lpthread
> --extra-libs=-lm --bindir=/home/ec2-user/bin --enable-gpl
> --enable-libfdk_aac --enable-libfreetype --enable-libmp3lame
> --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264
> --enable-libx265 --enable-nonfree

(The extra-libs look strange and would indicate a bug but cannot hurt.)

>   libavutil      56. 19.100 / 56. 19.100
>   libavcodec     58. 23.100 / 58. 23.100
>   libavformat    58. 17.103 / 58. 17.103
>   libavdevice    58.  4.101 / 58.  4.101
>   libavfilter     7. 26.100 /  7. 26.100
>   libswscale      5.  2.100 /  5.  2.100
>   libswresample   3.  2.100 /  3.  2.100
>   libpostproc    55.  2.100 / 55.  2.100
> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/ec2-user/f1.mp4':
>   Metadata:
>     major_brand     : isom
>     minor_version   : 512
>     compatible_brands: isomiso2avc1mp41
>     encoder         : Lavf57.83.100
>   Duration: 00:05:08.28, start: 0.000000, bitrate: 2693 kb/s
>     Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
> 1280x720 [SAR 1:1 DAR 16:9], 2555 kb/s, 50 fps, 50 tbr, 12800 tbn, 100 tbc
> (default)
>     Metadata:
>       handler_name    : VideoHandler
>     Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo,
> fltp, 128 kb/s (default)
>     Metadata:
>       handler_name    : SoundHandler
> Stream mapping:
>   Stream #0:0 -> #0:0 (h264 (native) -> mjpeg (native))
> Press [q] to stop, [?] for help
> [swscaler @ 0x361c080] deprecated pixel format used, make sure you did set
> range correctly
> Output #0, image2, to 'output.jpg':
>   Metadata:
>     major_brand     : isom
>     minor_version   : 512
>     compatible_brands: isomiso2avc1mp41
>     encoder         : Lavf58.17.103
>     Stream #0:0(und): Video: mjpeg, yuvj420p(pc), 1280x720 [SAR 1:1 DAR
> 16:9], q=2-31, 200 kb/s, 50 fps, 50 tbn, 50 tbc (default)
>     Metadata:
>       handler_name    : VideoHandler
>       encoder         : Lavc58.23.100 mjpeg
>     Side data:
>       cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
> frame=    1 fps=0.0 q=6.7 Lsize=N/A time=00:00:00.02 bitrate=N/A
> speed=0.0578x
> video:52kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> muxing overhead: unknown
>
> The ldd output is, of course this is only valid for the dynamically linked
> version which also fails on lambda even though the same binaries are
> available inside the lambda package and the ldd output is similar to the
> below:
>
>         linux-vdso.so.1 =>  (0x00007fffe2dde000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007ff6d47e1000)
>         libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007ff6d4545000)
>         libz.so.1 => /lib64/libz.so.1 (0x00007ff6d432f000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff6d4113000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00007ff6d3f0f000)
>         libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff6d3b8a000)
>         librt.so.1 => /lib64/librt.so.1 (0x00007ff6d3982000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007ff6d35b5000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007ff6d4ae3000)
>         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff6d339f000)

So you are not testing a "static binary" as you originally claimed
but a dynamic binary.

I start to suspect you do not want to report a portability issue
("my binary does not start because a library is missing") but
a usage issue, am I right? The reason this was unclear was
that you posted an emails explaining such a problem in your
first message.

Please test something like:
$ ffmpeg -f lavfi -i testsrc2 -vframes 10 out%2d.jpg

Then find out if you are really are reading the same file as
on your build machine.

Please learn what top-posting means and avoid it here.
And please remove your email footer.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".