Serviio

My Serviio & ffmpeg expertise is limited to what I have gleaned over the last 3 weeks using this forum as a guide.

I recenty purchased my 1st. "smart" TV - Panasonic Viera (TX-L42E30B 2011) and I've been exploring its DLNA capabilities.
I particulary wanted to be able to use my Panny to access a growing library of movies stored on a networked server (Intel i7 quad 12GB Windows 7 ultimate x64).
I eventualy came upon Serviio which appears to meet my needs far better than other software free/fee that I looked at.

Most of my movies are stored as MKV files of varying quality and size.
I'm very pleased to say that with the advice and guidance within this forum, I've been able to play most movies using native support on the TV using a very slightly tweaked version of cerberus' profile (viewtopic.php?f=13&t=5119).
I have previously remuxed each MKV file (using MKVMerge - painless and quick) to remove any header compression as I understand that DLNA does not support header compression.

I've even found that the Panny has native support for subtitles and plays them fine as long as I don't transcode them!

So what's my problem?
Normally the Panny happily handles these movies very well including pause, restart, fast forward and fast reverse. However, for just a few movies, these navigation functions do not work. For these movies, pause works, but resume, fast forward or fast reverse will result in restarting the movie from its beginning.
After inspecting these problem MKV files (with MediaInfo) I've concluded that it is only MKV files that were originally encoded with "Overall Bit Rate Mode=Variable" that cause a problem. This may be a specific problem with my Panny, but I think its just a transport stream restriction?

So what do I want?
I really like the fact that Serviio presents 95% of my library to play native on the TV - that helps my network and keeps my server cool!
Ideally
>I would like an option in the Serviio profile so that I can select transcoding just for MKV files with "Variable Overall Bit Rate Mode".
>Now I realise this would probably involve additional inspection of the MKV file.
>I threw together a batch script using the command line version of MediaInfo to run through my library and identify all my problem MKV files.
Or 2nd best
>A method of providing a "user exit" which would hand over to a user written script where the decision to re-render or not can be made.

ps - here's a tested quick and dirty native ffmpeg cmd that rerenders to a reasonable quality and removes "Variable Bit Rate Mode" ...
ffmpeg.exe -i "input_file_path\filename.mkv" -y -threads 6 -async 1 -vcodec libx264 -coder 1 -flags +loop -cmp +chroma -partitions -parti8x8+parti4x4+partp8x8+partp4x4-partb8x8 -me_method hex -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -b_strategy 1 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -wpredp 2 -vf "pad=max(iw\,ih*16/9):max(ih\,iw/16*9):(ow-iw)/2:(oh-ih)/2:black[out]" -acodec ac3 -ab 192k -ac 6 -copyts -scodec copy -map 0 "output_file_path\filename.MKV"

pps - above padding options provided by Illico within this forum.

Use the same technique as I use for refresh and invoke a modified ffmpeg.bat See the refresh plugin and the wiki entry

Hi jhb50, thankyou for your update.

I did come across your excellent work when I was reviewing the forum and one of the early tasks I did was to take a leaf out of your book and write a small ffmpeg script wrapper - all it initially did was to write a log entry to a file with the parameters passed to it from Serviio, and then issue the ffmpeg.exe cmd on behalf of Serviio.

Well what I found was that for locally held files (ie my library sitting on the same server as the Serviio code), Serviio does not invoke ffmpeg to present the MKV file to the TV when they are natively supported by the TV. It only does so, when the active profile requests a remux/rerender. I don't know how Serviio presents these natively supported files to the TV, but it isn't using ffmpeg that I can see.

So I can't see how an ffmpeg wrapper can help - ffmpeg never gets called.
If I force Serviio to call ffmpeg (by using Serviio's profile interface) then I can happily handle the 5% of files that I want to rerender within an ffmpeg wrapper, but I'm then left with the 95% of files that I don't want to rerender 'cos the TV can handle them natively - and I'm not sure how to present these to the TV - ie how does Serviio do it?

Regards.

Why not setup the profile to mux them anyway (which takes minimal resource) and that way everything goes to ffmpeg.

Hi jhb50, thanks again for your update.

Well I guess muxing all the good ones and rendering all the bad ones might be a pragmatic solution were it not for bugs in ffmpeg remux.

1> about 5% of my "good" MKV files won't remux using ffmpeg due to this ffmpeg bug ...
> ([matroska @ 0000000004768a10] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 2054 >= 2054)
> these files happly remux with MKVMerge but not with ffmpeg.

2> just remuxing with ffmpeg distorts the aspect ratio of the movie (reported elsewhere).
> so ffmpeg remux is not "benign" and over a large range of movies, a significant proportion get messed up.

3> I also "feel", and this may just be me being picky, that Serviio goes out of its way to not interfere with media that can be presented to the target device for
> native rendering on the device so ... I think it would be neater and in keeping and not to preprocess them with ffmpeg wherever possible.

Kind regards

Could you try adding this on the command line used ?
-copytb 1

Hi Illico, kind of you to join the conversation.

I tried -copytb 1 and incidentally also tried -copytb 0 & -copytb -1
I wasn't sure where to place it on the cmd line so I tried before -i and after
and I'm sad to report that each failed in the identical way

Regards

are you using the FFmpeg distributed with Serviio?

Hello zip,

In several places within this forum, people reported outstanding ffmpeg issues, so I decided to download and install the latest ffmpeg from the ffmpeg site.

So in answer to your question - No these ffmpeg mux errors were raised when using a later version of ffmpeg than the one shipped with Serviio (see ffmpeg header in console log 1 below).

However, I did see these errors before replacing ffmpeg. So just to make sure that I'm not leading anyone astray here, I have just replaced ffmpeg with the original ffmpeg.exe shipped with Serviio win 0.6.2 and reproduced the problem (see console log 2 below).

Remember, these errors only occur for about 5% of my MKV files - and that this is only an issue we are discussing here, because jhb50 suggested a strategy of remuxing all my mkv files as part of a possible solution to some real-time navigation errors.

And before I leave this post, it would be remiss of me not to thank you for this excellent project.

Thank you and kind regards

FFmpeg distributed with Serviio has a patch for this FFmpeg bug. Obviously they haven't fixed it yet.

Nor do they have any plans to fix it. The trouble is that the ffmpeg devs doesn't consider this a ffmpeg bug, but rather a case of a corrupt video, and as such they have no interrest in 'fixing' it.

My personal workaround is to just ignore the 'non monotonically increasing dts ...'. I've no idea if this may have any bad side-effects, but I haven't noticed any.

that's basically what I'm doing