Serviio

Posted: **Fri Aug 02, 2019 8:39 am**

Hi,

I'm a user of the WMC and I record free DTV shows in WTV files. These files are supported by Serviio, and it really works. Thank you!

The current use of the Serviio that I do is when I'm travelling. Using a small Linux server and one small HD I can copy my recodings and see them with any DLNA player. In fact, that's with any Smart TV. The key thing is that Serviio TRANSMUXES the WTV files in realtime to MPEG-TS (even it calls it TRANSCODING, in fact it only copies the streams and changes the container, so isn't a real transcoding). And this works like a charm... except for the missing SEEK functionality.

So, after a lot of tests I feel some bug (or something unimplemented) exists. If I share a .TS file, then I can do FF and RF; but with .WTV files I can't. I tested it too with the VideoLAN UPNP client (last version) using the same profile as with the Smart TV (for convenience I use "Samsung TV C/D-series"). And I'm sure that the problem is not related with the "transcoding", because with other containers I can seek. Perhaps the problem is with the total time of the file that the transcoder inside the Serviio sever requires to know. If that's true, the problem can be fixed reading the correct time from WTV files.

As a tip I changed the profile with this simple modification:

Code::  <Video targetContainer="mpegts" targetACodec="ac3" forceInheritance="true"> <Matches container="wtv" aCodec="ac3" /> </Video> <Video targetContainer="mpegts" targetACodec="mp2" forceInheritance="true"> <Matches container="wtv" aCodec="mp2" /> </Video> <Video targetContainer="mpegts" targetACodec="ac3" aBitrate="384" forceInheritance="true"> <Matches container="wtv" /> </Video>

The first and second are for transmuxing all video formats with AC3 and MP2 audio, but the last is for transcoding any other audio format (for example when E-AC3, aka DD+).

I recommend to update all profiles adding support for WTV as not all have declared it, and because the transmuxing to MPEG-TS it's possible then all clients can to support WTV. Futhermore, I recommend to the developer to check every version with WTV files. It's quite simple: you can use testing files or generate them using FFMPEG -i test.ts ... copy -f wtv test.wtv; and use VLC as the client (for seeking).

Regards.

Posted: **Fri Aug 02, 2019 1:55 pm**

Trick Play (FF, rewind, resume) isn't available when transcoding/transmuxing into the TS container. There's an occasional player that it might work with, but in general no. To have trick play available, you have to use the HLS (appleplay) container. However, HLS doesn't support MPEG2 video, which is what your WTV files contain, so full transcoding is necessary. You can test this by using the Chaneru profile, which transcodes everything into HLS. The Roku profiles also use HLS, unless the source video is VC-1, in which case they use TS.

The reason you can seek with the TS file is because your TV supports that container, so no transmuxing is required. And VLC is capable of doing many magic things, so not a fair comparison with your TV.

You have added a destination audio codec (ac3) to all your WTV matches. This isn't necessary, since all WTV files will be in ac3 audio. That's the broadcast audio standard, so you shouldn't need to do anything there.

Posted: **Fri Aug 02, 2019 2:59 pm**

atc98092 wrote:You have added a destination audio codec (ac3) to all your WTV matches. This isn't necessary, since all WTV files will be in ac3 audio. That's the broadcast audio standard, so you shouldn't need to do anything there.

Why you think I'm living in the States?
Many DVB broadcasts use mp2 and eac3, the ac3 codec isn't a regular thing here!
So stop to say: "all WTV files will be in ac3 audio".

Futhermore, now I understand that the FF/REW is not possible with MPEGTS and TRANSCODING with Serviio. OK, but that format *can* seek in many Smart TVs. So, I hope the developer of Serviio will support it at some point.

Regards.

Posted: **Fri Aug 02, 2019 7:53 pm**

wtvuser wrote:
atc98092 wrote:You have added a destination audio codec (ac3) to all your WTV matches. This isn't necessary, since all WTV files will be in ac3 audio. That's the broadcast audio standard, so you shouldn't need to do anything there.

Why you think I'm living in the States?
Many DVB broadcasts use mp2 and eac3, the ac3 codec isn't a regular thing here!
So stop to say: "all WTV files will be in ac3 audio".

Futhermore, now I understand that the FF/REW is not possible with MPEGTS and TRANSCODING with Serviio. OK, but that format *can* seek in many Smart TVs. So, I hope the developer of Serviio will support it at some point.

Regards.

Well, since you didn't identify your location, I made a guess. So I obviously guessed wrong. Don't get huffy about it.

It isn't something that the Serviio developer can change. It's up to the player to support trick play via a TS stream, not the server. Very few devices support it.

Posted: **Sat Aug 03, 2019 6:48 am**

atc98092 wrote:Well, since you didn't identify your location, I made a guess. So I obviously guessed wrong. Don't get huffy about it.

Don't worry! But, in any case, I like to comment that: ATSC is not a very common standard, compared to DVB. And AC3 is not the most common audio codec for DTV. So, any processing of WTV files must be done without making assumptions about the format used in the container.

atc98092 wrote:It isn't something that the Serviio developer can change. It's up to the player to support trick play via a TS stream, not the server. Very few devices support it.

Ummm... I don't agree 100%. If a player supports seeking with TS files, then it can support it with transcoding. What I'm remarking is that: with current WTV transcoding to TS (MPEGTS) the player never can seek. So, some improvement can be done as the limitation isn't the player. Don't you think so?

Regards.

Posted: **Sat Aug 03, 2019 9:30 pm**

wtvuser wrote:
atc98092 wrote:Well, since you didn't identify your location, I made a guess. So I obviously guessed wrong. Don't get huffy about it.

Don't worry! But, in any case, I like to comment that: ATSC is not a very common standard, compared to DVB. And AC3 is not the most common audio codec for DTV. So, any processing of WTV files must be done without making assumptions about the format used in the container.

atc98092 wrote:It isn't something that the Serviio developer can change. It's up to the player to support trick play via a TS stream, not the server. Very few devices support it.

Ummm... I don't agree 100%. If a player supports seeking with TS files, then it can support it with transcoding. What I'm remarking is that: with current WTV transcoding to TS (MPEGTS) the player never can seek. So, some improvement can be done as the limitation isn't the player. Don't you think so?

Regards.

Again, depending on location ATSC is very common. For example, the entire North American continent is ATSC, and the audio is always AC3. I agree in different geographical areas the rules change. That's why it really helps when you identify where you are.

Yes, your player can trick play with TS files. But when that TS file is streamed via DLNA the rules change. That's why I believe the developer can't do anything about it. But Zip would have to confirm that, since he's the developer.

Posted: **Sun Aug 04, 2019 7:52 am**

atc98092 wrote:Yes, your player can trick play with TS files. But when that TS file is streamed via DLNA the rules change. That's why I believe the developer can't do anything about it. But Zip would have to confirm that, since he's the developer.

Hi,

I repeat it another time: Check it with the VLC as the UPnP/DLNA Client. Using it with a TS file shared by Serviio over DLNA you CAN seek (If you don't believe me, please try it yourself). So, the Serviio server has the path to make the improvement of WTV files with SEEK when transcoding. Here the problem is not the client, nor the target format. The problem is the server that not supports seeking when transcoding with some formats.

In any case, thank you for this good DLNA server. It's one of the best in the world!

Posted: **Sun Aug 04, 2019 11:44 pm**

I also said earlier, VLC is a highly capable player, and can do things that many other players cannot do. Trick play with TS files is one of them. Again, it's the player that determines what can be done with the file. And with few exceptions (VLC being one) trick play only works when transcoded files use the HLS format.

I completely agree that Serviio is a terrific product. But I take no credit for it. I'm just another end use like yourself, perhaps with a bit more experience with it. Zip is the one and only person that deserves the praise for Serviio.

Posted: **Mon Aug 05, 2019 7:32 am**

atc98092 wrote:I also said earlier, VLC is a highly capable player, and can do things that many other players cannot do. Trick play with TS files is one of them. Again, it's the player that determines what can be done with the file. And with few exceptions (VLC being one) trick play only works when transcoded files use the HLS format.

Sorry, I don't agree because:

- If the VLC can seek with TS files over DLNA, then other clients can do it.
- If other players can seek with TS files over DLNA, then the problem is Serviio with WTV transcoded files to TS and not the TS format.
- Futhermore, the VLC is not the only player that can seek with TS files over DLNA.

Please, don't assume that I'm indicating that all players can seek with TS files DLNA. I know that at time the support is low. But, as some can support it, then it's good to support seek with transcoded files to TS too.

In summary: the Serviio server can be enhanced to support seek with WTV transcoded files.
Regards.

Posted: **Tue Aug 13, 2019 2:11 pm**

There are 2 ways DLNA supports seeking:
- byte based
- time based

For transcoded files Serviio supports only time-based seeking, which almost no renderer supports (Sony TVs do AFAIK).

Byte seek cannot work, because we don't know at the beginning of the transcoding job how big a file (how many bytes) the resulting file will be, so cannot offer the renderer the available byte ranges.

Obviously this is not a problem on non-transcoded (eg native mpegts) files, as we know the exact file size beforehand.

Posted: **Wed Aug 21, 2019 9:55 am**

zip wrote:There are 2 ways DLNA supports seeking:
- byte based
- time based

For transcoded files Serviio supports only time-based seeking, which almost no renderer supports (Sony TVs do AFAIK).

Byte seek cannot work, because we don't know at the beginning of the transcoding job how big a file (how many bytes) the resulting file will be, so cannot offer the renderer the available byte ranges.

Obviously this is not a problem on non-transcoded (eg native mpegts) files, as we know the exact file size beforehand.

Hi ZIP,

Thank you for the explanation.
All you explain is more or less what I had read in the forums and the documentation.
However, take note about this:

- At time Serviio supports TIME based seek with transcoded content.
- But in my tests Serviio DOESN'T support TIME based seek with WTV files.
- You can check this using VLC as the DLNA Client: it supports TIME based seek, but it can't seek with WTV files from Serviio.

And regarding the BYTE seek VS TIME seek, please think on this "hack":
- You can remux _ANY_ VBR inside a CBR mpegts if the max bitrate of the VBR stream is less than the CBR.
- Then you can determine the BYTE position based on the TIME, as it's a deterministic function (because the CBR).
- And to remux VBR inside of a CBR you only need to add NULL stuff.

So, perhaps you like to explore that hack, as you can manually (in your code) get the ffmpeg transcoded stream in VBR and add on-the-fly the NULL stuff to convert it to CBR. After that the functions for convert from TIME to BYTE are possible.

Regards.

Posted: **Fri Aug 23, 2019 2:24 pm**

wtvuser wrote:- But in my tests Serviio DOESN'T support TIME based seek with WTV files.
- You can check this using VLC as the DLNA Client: it supports TIME based seek, but it can't seek with WTV files from Serviio.

Have you got any detailed log for this scenario?

wtvuser wrote:And regarding the BYTE seek VS TIME seek, please think on this "hack":
- You can remux _ANY_ VBR inside a CBR mpegts if the max bitrate of the VBR stream is less than the CBR.
- Then you can determine the BYTE position based on the TIME, as it's a deterministic function (because the CBR).
- And to remux VBR inside of a CBR you only need to add NULL stuff.

So, perhaps you like to explore that hack, as you can manually (in your code) get the ffmpeg transcoded stream in VBR and add on-the-fly the NULL stuff to convert it to CBR. After that the functions for convert from TIME to BYTE are possible.

Interesting. You could request an enhancement for that.
Cheers.

Serviio

WTV files and SEEK (FF/FR)

WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)

Re: WTV files and SEEK (FF/FR)