Question about m3u video processing

[csadoian 36]

I bought a cheap streaming box that I can send video into via HDMI and the box will output several types of streams, including TS & HLS using http or rtsp.  At first I was using the IPTV plugin to view the stream, but I found that to be really unreliable and I could not record the stream in Emby, which is something I wanted to do.  So I created a M3U tuner and have a simple file that points to the rtsp output of the streaming box.  The m3u8 file basically looks like this:

#EXTINF:-1 group-title="Local",Local Video
rtsp://192.168.60.30/live/1_0

If there is no video being fed into the HDMI port the streaming box will output a static screen.  Using VLC I can see this screen just fine.  Using Emby it just spins and spins, black screen.  Once I start some video going into the box Emby can pick it up and play the stream, but at times it seems to just freeze up or abruptly stop.  Using VLC this does not happen.  The stream on VLC is steady and never drops.

I did a comparison test and will upload the resulting logs.

The ffmpeg log with f562 at the beginning is Emby attempting to decode the stream that is the "placeholder" screen (i.e. just a static jpg image being output by the box).  The other ffmpeg log is Emby successfully decoding the stream after I connected HDMI video to the streaming box (my laptop's desktop screen).  By looking at these logs can you tell me why Emby has a problem with the "static picture" stream as compared to the stream of an actual video signal going into the box?  I'm thinking that if I knew what Emby (or ffmpeg) doesn't like about the static stream it might help me figure out how to make the stream more reliable and less prone to dropping the video (or freezing up).

I'd tend to blame it on my cheap streaming box, but VLC seems to handle the stream just fine.

 

embyserver.txt ffmpeg-directstream-6e23ab44-fa9e-463a-8999-fd4a8aebd960_1.txt ffmpeg-directstream-f5626514-de00-47fd-ae7c-aa99a9d14780_1.txt

[Luke 42083]

Hi, what are you running Emby theater on?

[csadoian 36]

19 minutes ago, Luke said:

Hi, what are you running Emby theater on?

@LukeFor the logs I uploaded I was using Emby Theater for Linux 3.0.19 on Linux Mint 21.1.  However, it does the same thing on Emby Theater for Windows, the web app (in Windows 10) and Roku (beta).  On the Roku it gets to around 33% on the screen and then gives up.  The web client eventually gives me a Playback Error, no compatible streams are currently available.  I assume it's doing this because ffmpeg can't deal with something in the stream.  As stated in my original message, VLC has no problem playing the static stream.  It's rock solid.  I've streamed to VLC for over 5 hours without a hiccup.  Can't say that with Emby.  All the clients in Emby will play the stream *if* I actually feed an HDMI signal to the streaming box.

It's not that I actually need Emby to "see" the static stream, I would like to know what's upsetting either ffmpeg or Emby itself in hopes of making the stream more stable so I don't get random drops or freezes.  I do have some parameters I can play with on the streaming box, but so far nothing I have done has fixed this problem.

 

[Luke 42083]

Yea that is the question, what causes the hiccup.

 If you lower the quality setting to force a full transcode, how does that compare?

[csadoian 36]

1 hour ago, Luke said:

Yea that is the question, what causes the hiccup.

 If you lower the quality setting to force a full transcode, how does that compare?

Lowered the quality to 720p in Emby Theater (Windows) which forces a full transcode (log attached) but same results (spinning circle, black screen).  Meanwhile I can still view the stream with VLC.  I have attached some media info as reported by VLC.

 

ffmpeg-transcode-ac58d83d-1f11-42de-8268-f576e5003165_1.txt

[Luke 42083]

Is rtsp the only option? Does the source have an http output option?

[csadoian 36]

3 hours ago, Luke said:

Is rtsp the only option? Does the source have an http output option?

@LukeIt has several options, but I've tried both the http and rtsp (both low and high resolution) but they both act the same.  The rtsp option seems to be the most stable.

Did you guys make a change that would affect the m3u tuner?  Reason I ask is that, after you asked me the question about http I went to emby and tried to edit the m3u tuner I already had defined and nothing happens when I click on edit.  Tried Emby for Windows and the web client.  So I deleted the tuner and attempted to add a TV source, selected M3u and nothing happens.  If I select HD Homerun the dialog for that comes up.  What happened to prevent me from adding/editing my m3u tuner?  Do you need a server log?

 

Edit:  Ok, so it works when I go to the actual server and do the configuration there.  I could have sworn I was able to add/edit a m3u tuner from any one of my client machines on the same network, but I guess I was wrong.  I don't often log directly into my actual Emby server since it operates headless and I have to use Remote Desktop to access it.

 

Edited June 26, 2023 by csadoian

[Luke 42083]

Are you all set now?

[csadoian 36]

2 minutes ago, Luke said:

Are you all set now?

@LukeWell, the original problem I reported at the top of this thread still exists, but for the most part my setup is working.  Occasionally the remuxing (or transcoding as the case may be) appears to fail but Emby can sometimes recover from that automatically, sometimes not (i.e. I get a video freeze and I have to exit and re-select the stream).  I have made some recordings of 3+ hours without errors.  In another thread you had mentioned there will be another ffmpeg build in the upcoming 4.8 release, so perhaps that will improve things.  In any case, with this build it's working fine even with the occasional glitches so I'm good.  Thanks.