•   
  • 1
  • 3
  • 4
  • 5
  • 6
  • 7(current)
Stream address is not recognized
#91
(3 hours ago)Newbie268 Wrote:
(5 hours ago)phunkyfish Wrote:
(5 hours ago)Newbie268 Wrote:  

Tested 2 HD channels each ~30 sec: Stream and audio ok!

Tested 2 SD channels each ~30 sec: Stream and audio ok!
  

Just one note. I know, that it will get tedious. My tests let me recommend, to wait for 3 minutes. I have seen several scenarios, where the MagentaTV SSM streams failed after 2 Minutes 10 seconds (surprisingly this could be reproduced to the second).
Reply
#92
(3 hours ago)Newbie268 Wrote:
(4 hours ago)buers Wrote: So far I have/found no UDP source. If you have a legal source for sure I will test it. ;-)
Is it possible to do it on my own by using ffmepg as a source? 
Sorry, I don't know an easy source either. I didn't think of UDP only. Actually I thought also of TCP. To me the errors in the log arej't necessarily dependent on UDP/TCP but might be caused by the pure mpegts (hwaccel) decoder. So, if you have tvheadend running and accessing it from Kodi with the same channel, this might be a test. (It should Transfer the same mpegts data by TCP, which then should be decoded by the same h264 hwaccel in ffmpeg. At least, that was my idea).

Enigma2 streamed channels might be another idea, if you have access. 

Perhaps, my idea is too complicated. You have tried to use a ffmpeg produced ts in Kodi, and that worked already. However, IIRC, you only tested HD there. 

But please stop me, @phunkyfish, if this won't make any sense. Will "normal" TCP provided mpegts in Kodi also be handled by ffmpeg?
Reply
#93
(55 minutes ago)buers Wrote: I tend to agree. But I know, that sometimes it is very easy to hit undefined situations (I would avoid it here). Certainly, I don't want to discuss that in detail. What explaination do you have for the spurious additional slash in the log of @Newbie268? "udp://@232.0.10.35:10000/?sources=87.141.215.251". There must be a logical explanation for basic string processing.

It's not spurious, it's in the original URL.
Maintainer of Enigma2 PVR addon: repo, docschangelog
How to create a full debug: here
Reply
#94
(30 minutes ago)buers Wrote:
(3 hours ago)Newbie268 Wrote:
(4 hours ago)buers Wrote: So far I have/found no UDP source. If you have a legal source for sure I will test it. ;-)
Is it possible to do it on my own by using ffmepg as a source?  
Sorry, I don't know an easy source either. I didn't think of UDP only. Actually I thought also of TCP. To me the errors in the log arej't necessarily dependent on UDP/TCP but might be caused by the pure mpegts (hwaccel) decoder. So, if you have tvheadend running and accessing it from Kodi with the same channel, this might be a test. (It should Transfer the same mpegts data by TCP, which then should be decoded by the same h264 hwaccel in ffmpeg. At least, that was my idea).

Enigma2 streamed channels might be another idea, if you have access. 

Perhaps, my idea is too complicated. You have tried to use a ffmpeg produced ts in Kodi, and that worked already. However, IIRC, you only tested HD there. 

But please stop me, @phunkyfish, if this won't make any sense. Will "normal" TCP provided mpegts in Kodi also be handled by ffmpeg? 

Everything is handled by ffmpeg.
Maintainer of Enigma2 PVR addon: repo, docschangelog
How to create a full debug: here
Reply
#95
(3 hours ago)Newbie268 Wrote:
(3 hours ago)Newbie268 Wrote:
(5 hours ago)phunkyfish Wrote:  
 
Just streamed in parallel in VLC--> No artefacts in VLC--> Seems not caused by the stream itself!
 
Good to have a confirmation for this. The same here - the streams are very reliable (according to VLC and to my test program). So we can rely on your results.

There is still a risk and a difference to VLC. From my Analysis of VLC source code, it really does understand the rtp protocol in combination with SSM. Ffmpeg Fails here. So we lie to ffmpeg, and tell it to assume UDP. Then ffmpeg is expecting "pure" mpegts. But the stream is rtp. The difference is (simplifying here): rtp has an additional 12 Bytes as Header. For MagentaTV, then 7 times a 188 Bytes Long ts will follow. So, Decoding from the start of the data must produce some garbage. TS can be detected by the first Byte, that has to be 0x47. Certainly, any Decoder will search for this marker, and skip garbage before the marker. However, the marker can, by coincidence, also be inside the rtp Header. I.e. inside the sequence number field or the timestamp. So a primitive garbage detection, that searches for the first 0x47 can fail with some small probability. Stuff like this will yield in typical "green Errors" and other block artifacts. A smarter garbage detector will look at 0x47 and test for 0x47 another 188 Bytes later. If not both match, the start of mpegts not found yet. Then, even with the wron protocol (pure UDP instead of rtp on UDP), basically no Errors will arise.

(Sorry, my English spelling might be bad enough already. When I type words inside the Forum Software here, random words are capitalized. I resign, correcting that).
Reply
  •   
  • 1
  • 3
  • 4
  • 5
  • 6
  • 7(current)
 
Thread Rating:
  • 1 Vote(s) - 5 Average



Logout Mark Read Team Forum Stats Members Help
Stream address is not recognized51