Most recently was probably 2-3 months ago. What i mean by multiple consumers are ffprobe, followed by an emby ffmpeg process to transcode it, or an emby direct grab of the contents to send to an emby app, or an emby app hitting the next pvr url directly.Įvery-time in the past when we've tried to turn on probing to improve nextpvr, users have almost immediately reported problems. I've had to turn it off in the plugin because it seems the next pvr stream urls are not intended to have multiple consumers. Yea we do this per channel, however there's no probing for next pvr. For example, a user in the UK might get Channel 4 as MPEG2 over DVB-T, or H.264 over DVB-T. That said, the complication comes when a user might have a channel that can come from multiple source, so could get a different video codec depending on the tuner used. It could usually cache this info (NextPVR's front end does this). Emby probably just needs to know if it's H.264 or MPEG2 video. Would this not speed up switching/playback thereafter? If the transmission criteria changes and playback fails then a refresh of the channel specs could be performed to correct.Ĭhannels very rarely change the broadcast settings. Why then can't Emby capture and retain the transmission specs for each channel on the 1st time it is played and then use them on subsequent plays. My DVB-S tuner card always produces a 20Mb/s stream. I personally see that in AUS all SD channels are transmitted in MPEG2 format and ALL HD channels in H264. Question (might be a dumb one tho ): do the media specs change frequently on OTA broadcasts?.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |