Roku 3 plays mkv(h.264), but not from serviio wo transcoding

Hi,
I have been using Serviio (currently on 1.5.2) for a while on an LG Blu-ray player.
I recently got a Roku 3 media player, and it was picked up properly by Serviio.

When I noticed FF and RW did not work on any files, I searched the forum and found out that the roku supposedly does not allow FF and RW on files being transcoded.
The profile that was automatically selected by Serviio for the roku was “roku media player” and that profile appears to transcode everything even the files that the roku cam play natively.

The roku site mentions that the supported formats are
Video — MKV (H.264), MP4 (H.264), MOV (H.264), WMV (VC-1, firmware 3.1 only)

Searching the forum, I then found a post from atc98092 with a modified improved profile.
viewtopic.php?f=5&t=17007&p=92108&hilit=+roku+fast+forward#p92108

I tested that and indeed that profile did not transcode mp4 files which I could then FF and RW.

BUT it still transcodes mkv (h.264) files that Roku can play natively, and I therefore can’t FF and RW these.

I confirmed that roku can play FF and RW mkv(h.264) by accessing them directly from a USB stick connected to the roku.
I then tried to remove the transcoding lines in the profile for matroska, but then I get an invalid file message when trying to play these file from Serviio on the roku.

Can someone shed a light on why roku cannot play an mkv(h.264) from Serviio if not transcoded, or if I made a mistake modifying the profile.

The lines I removed from atc98092 profile are below
In the section <Video targetContainer="mpegts" targetVCodec="h264" maxVBitrate="12000" targetACodec="ac3">
I removed
<Matches container="matroska" />
In the section <Video targetContainer="mpegts">
I removed
<Matches container="matroska" vCodec="h264" />

Thank you for any insight

--------------------------------------------------------------------
Below the details on one of the file I tested

General
Unique ID : 193184594577544619937749179449798564962 (0x9155FFE2737DAAD6A33A69C404281C62)
Complete name : H:\Alceste a bicyclette (2013).mkv
Format : Matroska
File size : 1.33 GiB
Duration : 1h 45mn
Overall bit rate : 1 808 Kbps
Encoded date : UTC 2013-05-15 12:08:54
Writing application : mkvmerge v6.0.0 ('Coming Up For Air') built on Jan 20 2013 09:52:00
Writing library : libebml v1.3.0 + libmatroska v1.4.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=4, N=27
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 45mn
Bit rate : 1 500 Kbps
Width : 704 pixels
Height : 396 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.224
Stream size : 1.07 GiB (80%)
Writing library : x264 core 112 r1834 a51816a
Encoding settings : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x1:0 / me=dia / subme=2 / psy=1 / psy_rd=0.00:0.00 / mixed_ref=0 /

me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=4 / sliced_threads=0 / nr=0 /

decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=3 / weightb=0 / open_gop=0 / weightp=2 /

keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=1500 / ratetol=1.0 / qcomp=0.60 / qpmin=10 /

qpmax=51 / qpstep=4 / ip_ratio=1.41 / aq=1:1.00

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 1h 45mn
Bit rate mode : Constant
Bit rate : 320 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 241 MiB (18%)
Language : French

Text
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : English

[atc98092]

Ah gee, I'm famous!

Your file looks like it should play. but there's one line that I'm not familiar with, Format Settings, GOP. Don't know if that's an issue.

All of my MKV files that are not MPEG2 video are Blu-Ray rips, so my material may not be the same as yours. What you seem to have is a Roku issue, not Serviio.

Remember that MKV is only a container, and the media within can have a vast array of audio and video codecs, along with captions. My suggestion is to ask about this on the Roku forum. They have several employees that monitor the groups, as well as people with more knowledge than I about what works with the Roku Media Player.

Also, one other thing you can test is using the Chaneru profile. This is also a Roku specific profile, designed for the Chaneru video player. Before Roku finally added their own DLNA player, this was the only player that worked with Serviio. It uses some different formatting than the Roku profile, and might make a difference. Never know!

It cant be a roku issue, because the same file plays fine on roku when accessed directly by the roku media player.

It is only if I access the file via serviio that I get the error.
This is why I wondered if just removing the "Matches container="matroska" ... lines in the profile was the right way to avoid the transcoding, or if I needed to change something else in the profile.

I will double check the chaneru profile

[DenyAll]

It appears you removed the correct lines - have you confirmed the file is still being transcoded (easiest way, check your transcoding temp folder for an .stf file while streaming that video).

What happens if you use the Generic Profile (this ensures no transcoding). Also ensure you have not turned on burning-in of subtitles as that will force transcoding.

If neither of the above help, try adding a matroska mime type:

under the <MediaFormatProfiles> line, add
<MediaFormatProfile mime-type="video/x-mkv">MATROSKA</MediaFormatProfile>

As an aside - the order that transcoding blocks and statements appear in a profile are important. The fact that you have a statement in the profile:

<Matches container="matroska" />

early in the profile will transcode all MKV files. It makes the latter statements:

<Matches container="matroska" aCodec="vorbis" />
and
<Matches container="matroska" vCodec="h264" />

superfluous, as these statements will never be reached (all MKV files would have been matched to the earlier statement). You should change the order of some of the transcode blocks to avoid this happening.

You also have some of the <Matches> statements in two blocks for the same conditions (eg. <Matches container="flv" /> appears twice - only the first one will be acted on).

So a bit of a cleanup (@scrambler - you would still remove the two "matroska" lines):

  Code:

<Transcoding>
     <Video targetContainer="mpegts" targetACodec="aac" aBitrate="320">
        <!-- <Matches container="matroska" aCodec="dca" /> -->
        <Matches container="matroska" aCodec="vorbis" />
        <Matches container="ogg" vCodec="mpeg4" />
        <Matches container="mp4" aCodec="lpcm" />
     </Video>
     <Video targetContainer="mpegts">
        <Matches container="matroska" vCodec="h264" />
        <Matches container="flv" vCodec="h264" />
     </Video>
    <Video targetContainer="mpegts" targetVCodec="h264" maxVBitrate="12000" targetACodec="ac3">
        <!-- <Video targetContainer="applehttp" targetVCodec="h264" targetACodec="aac"> -->
        <Matches container="asf" />
        <Matches container="mpegvideo" />
        <Matches container="mpeg" />

        <Matches container="mpegts" />
        <Matches container="matroska" />
        <Matches container="avi" />
        <Matches container="flv" />
        <Matches container="wtv" />
        <Matches container="ogg" />
        <Matches container="3gp" />
        <Matches container="rtp" />
        <Matches container="rtsp" />
        <Matches container="rm" />
     </Video>
     <Video targetContainer="asf" targetVCodec="wmv2" targetACodec="wmav2" maxVBitrate="15360" forceStereo="true">
        <Matches container="*" vCodec="mpeg2video" />
        <Matches container="*" vCodec="dvvideo" />
     </Video>
     <Audio targetContainer="mp3">
            <Matches container="*" />
     </Audio>
</Transcoding>

Thanks for the detailed answer, I really appreciate it.

First I need to apologize as the error was on my side. I had the impression that I could do edits in the profile.xml by stopping Serviio server from the Serviio console, editing/saving the file, then restart the Serviio server from the console.

Apparently that does not work and I have to do a full reboot for Serviio to take the new profile into account. Once I did that, my removal of the Matroska lines did stop the transcoding and Roku was able to FF and RW the Mkv (h.264) files.

I do take note of your remark on the order of the transcoding instruction. I did not know the first one was the prevalent one, I would have assumed that the last one would supersede whatever was before, so good to know.

This is actually also good for atc98092 who provided the revised profile, and who should correct it then

If you don’t mind and for my personal knowledge, can you explain (or point me to a place that does) the purpose and logic of the MediaFormatProfile instructions?

Now if only Roku could support FF and RW on transcoded file … as not being able to do that seriously cripples the user experience 

PS: I am also wondering why Serviio default Roku media player profile (RokuMPApp) is set to transcode formats that can be played directly by the Roku. Given that kills the FF and RW, it seems like a bad idea.

[DenyAll]

Good to see you got it going.

My layman's understanding is that the MediaFormatprofile statements map a DLNA media type (how DLNA renderer devices, such as your TV or the Roku Player, know what media type a file is) to a particular mime type (how your computer understands what type of media file it is). Its used in various scenarios that I can see:

• Some profiles use this to "fool" the DLNA device to think that one type of file is a different one; or more commonly
• Use this to map to DLNA types that that particular renderer needs to see. It seems many manufacturers implement their own variants of DLNA Media Types and are strict in only supporting those types even though they have varied from the standard. Some of this is understandable - matroska wasn't around when the DLNA standard was created - other times it is just a quirk of that device/manufacturer.

My disclaimer - all of this is just what I have gleamed looking through various comments on the forum - my understanding of this is rudimentary at best (and I may be quite wrong - hopefully someone with more intimate knowledge can help out with a more detailed understanding).

I am also wondering why Serviio default Roku media player profile (RokuMPApp) is set to transcode formats that can be played directly by the Roku.

The profiles are built by users of the forum, not by the developer (it would be impossible for him to have every device in order to test them). Once they get a certain level of acceptance by the user community zip adds them to the standard profile distributed with Serviio. So, it could be that the profile has elements that are wrong... however I think in this case that profile was built for an earlier version of the Roku - I suspect Roku 3 supports more formats natively than did the previous versions.

You may want to develop a specific Roku 3 profile tested against a range of media - there is a list of test media available on the forum that can assist with this.

[atc98092]

Hi Denyall!

I've discussed with a Roku programmer about some of those transcoding statements, and I think the main issue is they want it to play for everyone with the least amount of "tweaking" necessary. For that reason they are revising the default Roku profile to force all audio to stereo, in case the user isn't using an AV receiver. I disagree with that, as well as some of the other choices they have made. I can't remember how much of that profile I posted was mine and how much was theirs. That was a while ago, and I haven't even used a Roku in a while. Guess I need to look it over some more!

I agree that they are transcoding files that may not need it. The biggest reason (I believe) is that they are trying to support several levels of hardware, and some of the older ones may not be able to handle the higher bitrate files. My Roku 2 XS tops out around 16,000 Bps, while the Roku 3 can handle higher. Also, the Roku TV (a Roku built into a TV, not an external box) can handle MPEG2 video, while none of the external devices can decode it. So rather than having model specific profiles, they've gone with the lowest common denominator.

Thank for sharing your understanding of the mediaformatprofile instruction.

As for the default profile, it does make sense if indeed not all Roku support h.264 encoded files in mp4 and Mkv containers.
It is easy enough to remove all transcoding instructions applying to the supported formats.