Update to FFMPEG 7

[kpirnie 4]

Think this may solve alot of issues with live tv channels taking so long to load...

[Neminem 1516]

Why ?

[kpirnie 4]

2 minutes ago, Neminem said:

Why ?

The version used is 7 years old, and is incredibly outdated at this point.  There have been numerous security fixes along with performance enhancements over the last 7 years.

[Neminem 1516]

Does that prof its better ?

[Happy2Play 9780]

But the dev already peace mills what they want into Emby's build.  But in the end only the devs can truly comment.

[ebr 16169]

Our version is not 7 years old.  We have cherry-picked updates as well as added our own customizations.

[Anielarias 25]

it seems emby has is own proxying/cashing stuff. can u allow to turn that off since i already have my own proxy. that will fix the 5 second load time for live channel for as compared to vlc 1 second load?

[emveepee 132]

On 11/8/2024 at 4:06 PM, ebr said:

Our version is not 7 years old.  We have cherry-picked updates as well as added our own customizations.

In theory a users of an open source product could do their own port at their own risk, but published source disappears or hidden away.  I am still waiting for this (and no beta software and libmpv are not excluded) yes I know I can request it by mail and you can charge us but gIven how essential ffmpeg and libmpv are to Emby's success its a shame how you feel you need to do this.
 

 

[Chillout 110]

They added fast channel load time in a beta version a while back but had to roll it back because it was causing problems for some people.

Hopefully they revisit this at some point because it was a major improvement.

 

[Anielarias 25]

8 hours ago, Chillout said:

They added fast channel load time in a beta version a while back but had to roll it back because it was causing problems for some people.

Hopefully they revisit this at some point because it was a major improvement.

 

do u know what version that was?

[Chillout 110]

4.8.0.65b

[Anielarias 25]

i wonder if i could downgrade to check this out

[ebr 16169]

Once we get past 4.9, we'll start testing a new Live TV infrastructure that should have improvements in this (and many other areas).

[kpirnie 4]

On 11/8/2024 at 4:06 PM, ebr said:

Our version is not 7 years old.  We have cherry-picked updates as well as added our own customizations.

Great.

Welp, sorry then, I assumed that the last access time was the last time it was compiled... which in the docker container shows as

-rwxr-xr-x 1 root root 923472 Aug 21  2017 ffmpeg

 

[Happy2Play 9780]

4 minutes ago, kpirnie said:

Great.

Welp, sorry then, I assumed that the last access time was the last time it was compiled... which in the docker container shows as

-rwxr-xr-x 1 root root 923472 Aug 21  2017 ffmpeg

 

That does not look like Emby ffmpeg.  As I believe platforms will have a system ffmpeg and a Emby ffmpeg.

But what version does that show as you should have something like this.

    "ProgramVersion": {
        "Version": "5.1-emby_2023_06_25",
        "Copyright": "Copyright (c) 2018-2022 softworkz for Emby Llc",
        "Compiler": "gcc 12.2.0 (Rev10, Built by MSYS2 project)",

 

[Anielarias 25]

2 hours ago, ebr said:

Once we get past 4.9, we'll start testing a new Live TV infrastructure that should have improvements in this (and many other areas).

that is great but can u add an option to disable emby proxing/ caching and cal it a day? like I said I already have my proxy.

[Luke 42077]

47 minutes ago, Anielarias said:

that is great but can u add an option to disable emby proxing/ caching and cal it a day? like I said I already have my proxy.

Hi, what proxying are you referring to? there isn't any.

[Anielarias 25]

3 minutes ago, Luke said:

Hi, what proxying are you referring to? there isn't any.

yes there is. or at least something is going on that makes the live tv load slow as compared to vlc. here all the option i get but not an option to turn it off

Edited November 10, 2024 by Anielarias

[kpirnie 4]

On 11/8/2024 at 4:06 PM, ebr said:

Our version is not 7 years old.  We have cherry-picked updates as well as added our own customizations.

ffmpeg version 5.1-emby_2023_06_25 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC
built with gcc 10.3.0 (crosstool-NG 1.25.0)

 

[kpirnie 4]

5 hours ago, Luke said:

Hi, what proxying are you referring to? there isn't any.

Emby doesn't proxy, however, unless you know to enable Direct Play, it does transcode... and it's heavy... very heavy.

There's no reason why it needs to even take 3-5 seconds to load a live TV channel with Direct Play.

Hence, I do believe an upgraded version of FFMPEG will help greatly with that.. thus why this thread was initially in the Feature Request.  No clue why you all decoded to move it... rediculously... since it is a feature request.

[denz 501]

12 hours ago, Chillout said:

4.8.0.65b

Can’t t find would loved to try it. Hopefully early in new year the new beta cycle starts as this one seems not exciting very low postings users don’t seem interested. 

[kpirnie 4]

18 hours ago, Happy2Play said:

That does not look like Emby ffmpeg.  As I believe platforms will have a system ffmpeg and a Emby ffmpeg.

But what version does that show as you should have something like this.

    "ProgramVersion": {
        "Version": "5.1-emby_2023_06_25",
        "Copyright": "Copyright (c) 2018-2022 softworkz for Emby Llc",
        "Compiler": "gcc 12.2.0 (Rev10, Built by MSYS2 project)",

 

I use linux for my media server
Also, like I said... the Docker container

[Anielarias 25]

17 hours ago, Anielarias said:

yes there is. or at least something is going on that makes the live tv load slow as compared to vlc. here all the option i get but not an option to turn it off

to add more to this. there is defiantly some cashing going on because a cold channel would take like 5 seconds to sap, yet, if i start a second of the same already playing channel it would then be fast to sap (like 1 second)

Edited November 11, 2024 by Anielarias

[Carlo 4560]

15 hours ago, kpirnie said:

There's no reason why it needs to even take 3-5 seconds to load a live TV channel with Direct Play.

It not a straight up comparison on time when you test using a player vs a multi-user DVR that streams to clients/players
One has a very simply job of taking what it receives and renders it on the screen and that's it. It can start to display as soon as it receives the first bytes.

At a high level the server on the other hand has to start receiving the content (starting the process below), probe the stream to understand it's structure, such as what tracks are present, what codec is used for each trac, what type of audio tracks are present including the language of the audio. if needs to probe the actual video track for a short bit to see if the content is interlaced, what the refresh rate is, as well as if closed capture info is present in the video (US), etc. Some Regions/countries use Closed Captioning which is embedded in the video stream, while other regions/countries use actual subtitles. It also has to determine what the bitrates of the tracks are as well as the overall bitrate. It's likely checking other things as well but these are some of the main things it needs know before the server can stream content to a client.

It has started to "record" the stream regardless of if an actual scheduled recording.
It then needs to see if there is an actual schedule recording for the channel. It does need to check to see if an actual recording is scheduled.

The server is doing multiple things for the stream. If there are multiple users watching the same channel or a recording it "shares" the stream with the different processes so only 1 channel is used on the tuner.

For any client tuned to the channel it compares the client capabilities to the MetaInfo just gathered to see if the client supports the codecs, which audio tracks will be used if a language preference is set, it the stream is interlaced, it checks to see if the client can deinterlace itself or it deinterlacing is needed on the server side. It has to check the requested resolution/bitrate set on the client to see if it needs transcoding, it checks to see if the client needs the stream repackaged, etc... These are all things done before sending anything to a client.  The above is not specifically the order things take place in but just a general overview of the major steps it needs to do.

The server can then transcode, remux, or direct stream the content to the client.

The server is still "recording" the channel to support trick play for the client, or to allow another person to tune the channel and be able to start at current time or the earliest time it has from recording the channel.

3 hours ago, Anielarias said:

to add more to this. there is defiantly some cashing going on because a cold channel would take like 5 seconds to sap, yet, if i start a second of the same already playing channel it would then be fast to sap (like 1 second)

This should be clear at this point why it's faster if starting a second channel. The time-consuming part of stream startup is already complete.  Also, there was no actual "tuning" of a channel as it wasn't needed.  You're actually sharing the same stream already obtained by the server.

As an example: Assume a server has a 4-channel hardware tuner or an IPTV subscription allowing 4 simultaneous streams.
A household using convention IPTV software like Tivimate, Smarters or even VLC has 4 clients all watching a sports game on NBC. Each client connects directly to the source and gets its own stream.  All 4 streams are now in use with 0 "tuners" or streams available to use.

The same 4 clients are replaced with Emby Theater. All 4 clients are watching the same game on NBC. Emby Server connect to the source tuner to receive the NBC stream one time.  It distributes the stream with all 4 Theater clients.  1 tuner is in use with 3 available tuners for the system to use.  It could still record another game on FOX, a reality TV show on MTV and still have 1 tuner free to use.

The new Live TV infrastructure ebr mentioned a few posts up is faster across the board. It's quite noticeable when tuning a new channel. It also adds a few addition tricks that many OTA users will appreciate. To make it easy to understand when broadcast OTA a multiple is used. That's a fancy way of saying a bunch of channels is packed into a specific amount of bandwidth and broadcast as one signal.  Not always but typically will be a group of channels with the same channel number, ie 6.1 through 6.8. The new architecture accesses many OTA tuners at a lower level instead of using the http stream.  It requests the complete multiplex and splits it on the server into its different channels. A few immediate benefits come from this. It's a bit quicker to pull the data this way. if any other channels on the same multiplex are used it doesn't use a different connect or tuner.  The channel has already been separated from the multiplex and ready to use. The actual channel requested by a client will get probed first as it's needed first but once complete the other channels from the multiplex will get probed for their metadata.  On some systems with resources and threads to spare it can be done in parallel.  So now if a channel is requested by another client that is part of that same multiplex the server will already have it available to use. It can quickly compare the client capabilities and resolution/bitrate, requested audio quickly to either start transcoding or start sending a direct playable version right away.

 

[Anielarias 25]

i haven’t read ur entire answer but the fact that u are saying that the second of the same already playing channel doesn’t need as long as the first time around for said channel and that 2 or more of the same channel will only take 1 cxn back to the provider tells me there is some proxying going on. i simply would like an option to turn that off since as am already using a proxy before it hits emby, which would explain why it takes 5 seconds to tune into a channel.