will wrote:Had you previously used Serviio 1.0 with ServiiGo (wasn't clear from your post). In MX Player, did you try switching to S/W (Fast) decoding? Original setting by default won't touch the video so no transcoding, medium/low obviously requires transcoding to a lower resolution. It may be that remuxing the videos will sort it out. Can you provide ffmpeg -i for a file.
Do they play fine using DLNA app to browse for content. There seems to be a difference in how MX Player and others detect videos when delivered from DLNA apps, although I'm not sure why or how as the headers are the same and so is the file when using Original. I may have to pester them to try it out and improve support. The only difference I can think of is that the CDS API web server doesn't support the Range requests that the built in android media subsystem uses (its something like it only supports giving a start and end, not just a start and asking for this start onwards), which is I think different to what the DLNA web server supports, so it errors and falls back to a different detection mechanisum and gets stuck. I'm only speculating though.
@zip have you had any more thoughts about seeking/range requests and the idea I had about using a hash that includes the transcoded filename for the ETag filed so that seeking can be supported for audio/video in the same way it is for DLNA? You said something about using a custom paramter to skip, but that would mean that I would have to build in a video player which is unlikely to happen any time soon in order to use it with ServiiGo.
I went strait from Serviio 0.6.2 to 1.0.1, so this is my first pass at getting all this working.
Here's the ffmpeg -i dump for one of the test videos:
- Code:
ffmpeg version N-42368-gbf53863 Copyright (c) 2000-2012 the FFmpeg developers
built on Aug 14 2012 00:58:12 with gcc 4.6.3
configuration: --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-nonfree --enable-postproc --enable-version3 --enable-x11grab --enable-libvpx --enable-librtmp --enable-libxvid
libavutil 51. 64.100 / 51. 64.100
libavcodec 54. 33.100 / 54. 33.100
libavformat 54. 15.102 / 54. 15.102
libavdevice 54. 1.100 / 54. 1.100
libavfilter 3. 1.100 / 3. 1.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 15.100 / 0. 15.100
libpostproc 52. 0.100 / 52. 0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Puss In Boots.m4v':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42isomavc1
creation_time : 2012-07-23 00:29:21
encoder : HandBrake 0.9.8 2012071800
Duration: 01:30:12.58, start: 0.000000, bitrate: 913 kb/s
Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 718x368 [SAR 32:27 DAR 1436:621], 742 kb/s, 23.98 fps, 59.94 tbr, 90k tbn, 180k tbc
Metadata:
creation_time : 2012-07-23 00:29:21
Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, s16, 164 kb/s
Metadata:
creation_time : 2012-07-23 00:29:21
Stream #0:2(eng): Subtitle: mov_text (tx3g / 0x67337874)
Metadata:
creation_time : 2012-07-23 00:29:21
Stream #0:3(und): Subtitle: mov_text (text / 0x74786574)
Metadata:
creation_time : 2012-07-23 00:29:21
The interesting thing is that ServiiGo reports the original and medium resolutions are the same, probably because I'm starting with SD sized video content.
Again, when testing on the local LAN/WLAN using BubbleUPnP on my android devices, I can stream without transcoding no problem. The main driver behind playing with ServiiGo and Serviio Pro is my desire to eliminate the separate server application to thunk DNLA traffic off the local LAN. I'm not aiming to enable internet access actually. I'm a bit of a security nut, so I'm actually using OpenVPN to allow remote access into my home network. The side effect of using OpenVPN for this is that VPN clients are kept on a separate subnet, so the DNLA servers can not be seen by a VPN client without help.
I repeated the tests via the VPN connection and found the same results.
As requested I did try forcing MXPlayer to drop to s/w (fast). When trying to stream "original" there was no difference. I did note that streaming in "medium" (again the same resolution) resulted in MXPlayer dropping to S/w (fast) automatically.
edit: one final interesting note - When streaming, it does look like something is spinning up an instance of ffmpeg. The command string (using pidstat) looks like its from my test stream, though the process lives on after I terminate the stream on the client end. The process is owned by the serviio user so it's being invoked by Serviio. This is rather undesirable since my little Atom based server isn't really up to the take of real time video transcoding
- Code:
02:00:39 PM PID %usr %system %guest %CPU CPU Command
02:00:39 PM 9414 0.54 0.00 0.00 0.54 1 ffmpeg -i /data/external/videos/Puss In Boots.m4v -y -threads 1 -copyts -c:v mpeg2video -b:v 1000k -maxrate:v 1000k -bufsize:v