Spaceboy 2493 Posted November 29, 2017 Share Posted November 29, 2017 The source is iptv. recently emby is successfully recording programs from iptv but they do not always play from recorded tv. i have observed this on android tv and the web client. web client says something about a compatible stream cannot be found. The files play fine in the films and tv app on windows so are very vanilla. logs server.txt ffmpeg 1.txt ffmpeg 2.txt ffmpeg 3.txt Link to comment Share on other sites More sharing options...
Luke 37062 Posted November 29, 2017 Share Posted November 29, 2017 can you provide one of these for testing? thanks. Link to comment Share on other sites More sharing options...
Spaceboy 2493 Posted November 29, 2017 Author Share Posted November 29, 2017 can you provide one of these for testing? thanks. i can https://www.dropbox.com/s/94ajb4fp1lj9s9w/Eggheads%20S19E58.ts?dl=0 Link to comment Share on other sites More sharing options...
Luke 37062 Posted November 30, 2017 Share Posted November 30, 2017 @@Waldonnis, any thoughts on this file? i can't seem to come up with a successful set of arguments to get ffmpeg to transcode it. thanks. Link to comment Share on other sites More sharing options...
Spaceboy 2493 Posted November 30, 2017 Author Share Posted November 30, 2017 It has been working fine until recently... how is it different from one that does play? I’m watching exactly the same show from today and it’s playing fine. 1 Link to comment Share on other sites More sharing options...
Spaceboy 2493 Posted November 30, 2017 Author Share Posted November 30, 2017 one that works https://www.dropbox.com/s/fjrdqur50d9wp4w/Eggheads%20S19E59.ts?dl=0 Link to comment Share on other sites More sharing options...
Spaceboy 2493 Posted November 30, 2017 Author Share Posted November 30, 2017 4th show of the night failed Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted November 30, 2017 Share Posted November 30, 2017 ffmpeg really hates this file. I know why (sps/pps are either missing or deeper in the file than is being probed), but trying to get it to transcode may be challenging. Basically, some of the h.264 parameters aren't where they should be in the file, so the decoder doesn't know what to do. Playback does work with some players, but it's likely because they can buffer enough of the video stream to find or determine the information on their own. I'll see what I can think of to get this working. How is IPTV being recorded any way? Is it just saving the stream out as-is? Link to comment Share on other sites More sharing options...
markyp 21 Posted November 30, 2017 Share Posted November 30, 2017 Luke, Is this similar to what I’m seeing? Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted November 30, 2017 Share Posted November 30, 2017 (edited) Looks like increasing analyzeduration worked as I expected, but I had to go up to 8secs (-analyzeduration 8M) to get it to work. It adds a bit of delay to the remuxing/transcoding/whatever, but it's hardly noticeable. Eight seconds is a long time to encounter sps/pps, but if the stream saving was started in between the periodic inclusion of the extradata, then it makes some sense. What I don't know is what the maximum time could be for extradata inclusion (I haven't looked at the specs in a while). It's possible 8 seconds may not be enough in some cases, but at least it's a starting point. I should run this file through h264_analyze to see more info on the sps/pps/nal, but need to compile it first since I can't find the binary I had before. Do note that the audio begins in that stream before the video, so you'll hear talking before seeing a picture. Edit - here's the command line I used (just a simple remux): ffmpeg -analyzeduration 8M -i "Eggheads S19E58.ts" -c copy test.mkv Edited November 30, 2017 by Waldonnis Link to comment Share on other sites More sharing options...
Luke 37062 Posted November 30, 2017 Share Posted November 30, 2017 That's interesting. I tried 10M within the server and couldn't get it to transcode to HLS. Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted November 30, 2017 Share Posted November 30, 2017 That's interesting. I tried 10M within the server and couldn't get it to transcode to HLS. Transcoding may require more options. I'll poke at it. Remuxing is easier, so I started with that. Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted November 30, 2017 Share Posted November 30, 2017 (edited) Increasing the max_muxing_queue_size works for transcoding, although I don't know what a good value may be (I just used 9999 as a catch-all). ffmpeg -analyzeduration 8M -i "Eggheads S19E58.ts" -max_muxing_queue_size 9999 -c:v libx264 -c:a aac test.mkv Edit: This is because there are several seconds of audio before the first video frame. Usually, the muxer waits for one of each. Edited November 30, 2017 by Waldonnis Link to comment Share on other sites More sharing options...
Luke 37062 Posted December 1, 2017 Share Posted December 1, 2017 Interesting, thanks. Any thoughts on the potential side effects of that? Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted December 1, 2017 Share Posted December 1, 2017 The only thing I can think of is an additional delay in the start of transcoding, but only if both audio and video aren't present up until that point. The default, I believe, is one second, so adding additional queue size just extends that. I wouldn't use 9999, though...best to find something reasonable and just reject streams that fall outside of it so you can figure out if something's going wrong in the recording process. I'm curious as to how this happened in the first place. If IPTV recording is just saving the stream as is at an arbitrary start point in a continuous stream, I guess it's inevitable as every source stream could be constructed a little differently and you couldn't count on the start of the recording containing the sps/pps data (plus sparse video packets compared to audio isn't uncommon either in my experience). As for increasing the analyze duration, that will definitely slow the start of a transcode, since it's probing even farther (default is 5s, I believe; 8s isn't too much farther, but that's a lot of packets to probe when both audio and video are present). It shouldn't be terribly noticeable on many systems, but more meager systems would probably notice it more (rpi, NAS, etc). Link to comment Share on other sites More sharing options...
Spaceboy 2493 Posted December 2, 2017 Author Share Posted December 2, 2017 so as this still isnt working and the options being discussed seem like they will worsen things even if they are fixed (longer startup times) perhaps its time to think outside the box a bit. is this happening because i am recording to ts? there is virtually no information on re-encoding to mkv in the forum or on the wiki but might trying this solve my problem? my experience to date has been that its probably best to leave these options off where the reasons for using them arent clear. i also note you removed the options to recode to mp4 and to preserve the original video stream. what are the pros and cons of converted to mkv? if there are no cons why isnt this default behaviour? Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted December 3, 2017 Share Posted December 3, 2017 so as this still isnt working and the options being discussed seem like they will worsen things even if they are fixed (longer startup times) perhaps its time to think outside the box a bit. is this happening because i am recording to ts? there is virtually no information on re-encoding to mkv in the forum or on the wiki but might trying this solve my problem? my experience to date has been that its probably best to leave these options off where the reasons for using them arent clear. i also note you removed the options to recode to mp4 and to preserve the original video stream. what are the pros and cons of converted to mkv? if there are no cons why isnt this default behaviour? When I talk about longer startup times, I'm more speaking from a "non-wallclock" perspective. I doubt you'd even notice the delay in most cases for a single stream or two, but it adds up when dealing with many streams (think 10+, maybe even more) and it's something Luke and ebr can test to determine what the impact will be from their perspective as developers. Probing 8s of video and audio takes more time than probing 5s...how much is largely up to the machine. On my IB i5, we're talking sub-0.5s - so small that I wouldn't have noticed if I didn't time the operation, but it is more delay nonetheless. This isn't a container problem, so recording to ts doesn't matter - it's the audio and video streams themselves. The codec "headers" are only present in the video part of the file periodically...and they contain info that the decoder would need to know to be able to decode the h.264 stream. By default, ffmpeg probes the first 5s of the video to find this info, but in your stream's case, it wasn't until after the 7s mark where the needed info was stored, which is why it coughed up an error - it couldn't find the info it needed to do anything with the stream. Allowing it to probe further into the file is all that's being proposed by increasing the analyzeduration portion. The other part of the issue at hand is that your stream had several seconds of audio (by timestamp) before the first frame of video was encountered (it's actually the same issue as above since the video didn't even start until a tad past 7s in). By default, I think the muxer will tolerate a 1s difference before it errors out. Increasing the max_muxing_queue_size just increases that tolerable difference. When you play back the original file on a player that can handle it, you will probably notice that audio begins first, followed by the start of the video a tad later...this is the delay that needs to be accounted for. Re-encoding or remuxing this file wouldn't have made any difference either - in fact, it probably would've failed with the same error for the same reasons as above. I couldn't even do a simple remux to mkv without altering the analyzeduration, and the max_muxing_queue_size was needed to allow a transcode/re-encode to work, again for the same reasons as above. It's nothing you or the server did, from what I can tell - it's just how the file was created/saved combined with how live streams are packaged. 1 Link to comment Share on other sites More sharing options...
Spaceboy 2493 Posted December 3, 2017 Author Share Posted December 3, 2017 (edited) thanks, i'm just not sure why this is happening all of a sudden? i've been using the same iptv provider for a while and only noticed these problems in the last few weeks. i don't observe any particular delays in the startup of audio and video in live tv from the same source. actually thats probably not true, i've just checked some live tv streams and the video and audio start together but the video is frozen for a while, 7 seconds sounds reasonable. when the audio gets up the right video frame the video and audio continue in sync. i just want to make sure that you are not trying to compensate for something funky with emby's making of these files when the focus should be on fixing the recording method. And i think my update above confirms this, there is no similar problem with the same streams in kodi and the fact that the stream starts with a video frame that is 7 seconds ahead of the audio suggests its the way that emby is creating these files. Edited December 3, 2017 by Spaceboy Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted December 3, 2017 Share Posted December 3, 2017 I'll admit there may be a better way of handling recording of IPTV, but I honestly don't know how it's being done currently, so I couldn't suggest a change (and I'm no Emby developer anyway - just a regular person trying to make things work with a funky file ). This isn't the first time I've seen a file like this, though, which is why it didn't take me long to figure out what to do with it...and none of those other files were made by Emby. I never really looked at why this occurs specifically since it never happened to me personally and I don't have the need to record/save live stream segments, but I can think of a few reasons why it could happen. Link to comment Share on other sites More sharing options...
Luke 37062 Posted December 3, 2017 Share Posted December 3, 2017 Probably due to cutting the stream at an arbitrary point, right? Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted December 4, 2017 Share Posted December 4, 2017 Probably due to cutting the stream at an arbitrary point, right? That would be my guess. The video might have had a longer segment length or GOP as well, so the first video keyframe wasn't found right away compared to audio. Link to comment Share on other sites More sharing options...
Spaceboy 2493 Posted December 4, 2017 Author Share Posted December 4, 2017 @@Luke one significant disadvantage i can see from switching to recode to mkv, recordings do not seem to show in the recorded tv library until they are complete. so you can't watch in progress recordings Link to comment Share on other sites More sharing options...
Luke 37062 Posted December 5, 2017 Share Posted December 5, 2017 @@Luke one significant disadvantage i can see from switching to recode to mkv, recordings do not seem to show in the recorded tv library until they are complete. so you can't watch in progress recordings In order to ensure things just work, we're pretty close to saying that playback of in-progress recordings when using the conversion feature is not going to be supported. So that is one disadvantage. We can try some of these things that waldonnis has suggested here to see if that helps. Link to comment Share on other sites More sharing options...
Waldonnis 148 Posted December 5, 2017 Share Posted December 5, 2017 There is a less-talked-about restriction as well with Matroska (mkv) - it doesn't seem to store certain types of caption/teletext streams, in my experience. It's usually not a problem, as most people don't use the embedded captions and most are horribly transcribed, but something to check into if you do. I'll admit that I haven't looked into it too deeply, since I don't care about or see teletext too often, but could probably find a couple files locally that I can double-check with if desired. Link to comment Share on other sites More sharing options...
Spaceboy 2493 Posted December 5, 2017 Author Share Posted December 5, 2017 In order to ensure things just work, we're pretty close to saying that playback of in-progress recordings when using the conversion feature is not going to be supported. So that is one disadvantage. We can try some of these things that waldonnis has suggested here to see if that helps. thats a shame because I haven’t had any issues with recordings starting since making this switch. Playback startup is much much quicker too, less than a second down from almost 10. And there is nothing that be done about making the files in the first place in .ts? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now