ffmpeg usage?

[tdiguy 99]

I am curious about something i noticed in the log file for how emby uses ffmpeg at least on my pi.

for live tv streaming i noticed a option of -threads 0

Is it set to that because using more than 1 thread for live tv creates issue?

[maegibbons 1287]

-threads 0 actually means "Auto" and that usually means MAX

 

I have seen some of your other logs and your ffmpeg performance was not great anyways.

 

If you specify -threads 1 then it will only use one processor etc.  This may not be enough for stutter free playback.

 

So you need to experiment with this figure to balance load on the system overall.

 

Krs

 

Mark

[tdiguy 99]

Good to know, thank you.

I think i am asking a bit much for the pi to stream live tv and transcode it to a web browser flawlessly. But it works pretty well for what it is.

[maegibbons 1287]

You are... but if it provides you with pleasure then all is good!.

 

Did you see the post about omx_mpeg2video settings in latest beta?

 

https://emby.media/community/index.php?/topic/51545-32333-omx-mpeg2video/&do=findComment&comment=495376

 

Krs

 

Mark

[tdiguy 99]

Yes I did in an indirect way i actually helped out with that. 

https://emby.media/community/index.php?/topic/51504-rpi-specific-request/

 

Finding that tiny command was a pain in the neck. It did not make as big an impact as the hardware mp4 encoding / decoding did. I am wondering now if i should do a even split with my pi's memory and see if that will help. I mean after all with this its now trying to decode a mpeg2 and encode it into mp4 in 256megs of memory. At the very least that would mean a lot of writing to swap right?

[maegibbons 1287]

Yeah such little RAM is a real killer in your situation...  Good luck anyway.

 

Krs

 

Mark

[tdiguy 99]

I have been asking around on the raspberry forums about hardware decoding and my use of ffmpeg. It turns out the video decoding is not what is slowing the pi down amazingly well at least not using the hardware decoding.

Here is an example:

pi@raspberrypi:/media/emby/ffmpeg-stuff/FFmpeg $ sudo ./ffmpeg -c:v mpeg2_mmal -i The\ Big\ Bang\ Theory\ S11E02\ The\ Retraction\ Reaction-1.ts -codec:v:0 h264_omx -c:a copy out.mp4
ffmpeg version git-2017-09-30-148c8e8 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1) 20170516
  configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-libvpx --enable-libopus --enable-librtmp --enable-libmp3lame --enable-gpl --enable-omx --enable-omx-rpi --enable-version3 --enable-decoder=mpeg2_mmal --enable-mmal
  libavutil      55. 77.101 / 55. 77.101
  libavcodec     57.106.104 / 57.106.104
  libavformat    57. 82.102 / 57. 82.102
  libavdevice    57.  9.101 / 57.  9.101
  libavfilter     6.106.100 /  6.106.100
  libswscale      4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
[mpegts @ 0x281aee0] PES packet size mismatch
    Last message repeated 1 times
Input #0, mpegts, from 'The Big Bang Theory S11E02 The Retraction Reaction-1.ts':
  Duration: 00:32:00.26, start: 56540.601733, bitrate: 2683 kb/s
  Program 131
    Stream #0:0[0x8c0]: Video: mpeg2video ([2][0][0][0] / 0x0002), yuv420p(top first), 320x240, 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x8c1](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2[0x8c2](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s
File 'out.mp4' already exists. Overwrite ? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (mpeg2_mmal) -> h264 (h264_omx))
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[mpeg2_mmal @ 0x28217b0] Changing output format.
[h264_omx @ 0x29b17e0] Using OMX.broadcom.video_encode
[mp4 @ 0x2823040] track 1: codec frame size is not set
Output #0, mp4, to 'out.mp4':
  Metadata:
    encoder         : Lavf57.82.102
    Stream #0:0: Video: h264 (h264_omx) (avc1 / 0x31637661), yuv420p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc57.106.104 h264_omx
    Stream #0:1(eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
frame=  443 fps=145 q=-0.0 Lsize=    1085kB time=00:00:15.00 bitrate= 592.0kbits/s dup=114 drop=0 speed=4.93x
video:372kB audio:705kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.702063%

with audio decoding taken out of the picture look at that thing rip! I am used to seeing 1x on a file to file transcode without audio transcoding this thing is ripping along at nearly 5x!

Not sure what, if anything can be done on this front honestly. I would love to hear an opinion on this though, can audio transcoding be skipped at least on live tv?

[tdiguy 99]

I am fiddling around with this a little bit now and transcoding with libmp3lame for audio seems far better performance wise. The file is still transcoding so i dont know what its going to sound like yet. I am curious, if i did not compile ffmpeg with aac and only gave it libmp3lame would it work or throw an error with emby?

[tdiguy 99]

This is my latest result without hardware decoding for mpeg2. It really seems that the thing slowing the pi down greatly was audio transcoding.

pi@raspberrypi:/media/emby/ffmpeg-stuff/FFmpeg $ sudo ./ffmpeg -i The\ Big\ Bang\ Theory\ S11E02\ The\ Retraction\ Reaction-1.ts -c:a libmp3lame -c:v h264_omx out.mp4
ffmpeg version git-2017-09-30-148c8e8 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1) 20170516
  configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-libfdk-aac --enable-libvpx --enable-libopus --enable-librtmp --enable-libmp3lame --enable-gpl --enable-omx --enable-omx-rpi --enable-version3 --enable-decoder=mpeg2_mmal --enable-mmal
  libavutil      55. 77.101 / 55. 77.101
  libavcodec     57.106.104 / 57.106.104
  libavformat    57. 82.102 / 57. 82.102
  libavdevice    57.  9.101 / 57.  9.101
  libavfilter     6.106.100 /  6.106.100
  libswscale      4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
[mpeg2video @ 0x38b93b0] Invalid frame dimensions 0x0.
    Last message repeated 1 times
[mpegts @ 0x38b4ee0] PES packet size mismatch
    Last message repeated 1 times
Input #0, mpegts, from 'The Big Bang Theory S11E02 The Retraction Reaction-1.ts':
  Duration: 00:32:00.26, start: 56540.601733, bitrate: 2683 kb/s
  Program 131
    Stream #0:0[0x8c0]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3], Closed Captions, 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x8c1](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2[0x8c2](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s
File 'out.mp4' already exists. Overwrite ? [y/N] y
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_omx))
  Stream #0:1 -> #0:1 (ac3 (native) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
[h264_omx @ 0x390bab0] Using OMX.broadcom.video_encode
Output #0, mp4, to 'out.mp4':
  Metadata:
    encoder         : Lavf57.82.102
    Stream #0:0: Video: h264 (h264_omx) (avc1 / 0x31637661), yuv420p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc57.106.104 h264_omx
    Stream #0:1(eng): Audio: mp3 (libmp3lame) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp
    Metadata:
      encoder         : Lavc57.106.104 libmp3lame
frame=  223 fps= 84 q=-0.0 Lsize=     294kB time=00:00:07.40 bitrate= 325.1kbits/s dup=70 drop=0 speed= 2.8x

[Luke 42077]

It could be, yea.

[tdiguy 99]

Is there any way i can test out using libmp3lame on a live stream?

Just from a single file transcoding standpoint it seems pretty quick by comparison. I am curious how it will compare to a more realistic test. It seems like both libmp3lame and -libfdk-aac are both less resource intensive than what ffmpeg uses by default.

[Luke 42077]

The upcoming Emby Server 4.2 will have h264_omx built-in for Raspberry Pi hardware encoding. Thanks guys.

[Luke 42077]

Not yet, but soon. They're on the way.