Sony BDP-S370 (DLNA-compatible with new firmware M03.R.567)

[infidel]

Transcoding will always fail for me too btw - that's not a regional problem.

I guess WorldOfHurt would be able to tell us whether transcoded data gets routed through his patch.

[infidel]

Mezzmo played everything! avchd, mp4, wmv etc, almost all of which displayed as M2TS. My one .ts file showed up as MPEG but played very choppy, otherwise results were excellent. Definitely wireshark material

[patters]

You won't get anything useful out of The BDP with UPnP Inspector but it's useful to probe how other DLNA servers offer up the content.

[patters]

Awesome. I'm out at the moment but I'll hopefully have time to do some tinkering later or tomorrow before work.

[WorldOfHurt]

Transcoding will always fail for me too btw - that's not a regional problem.

I guess WorldOfHurt would be able to tell us whether transcoded data gets routed through his patch.

In a word? No.

Honestly, I don't know how the transcoded stuff can work with a byte-range-style renderer like the BDPS370.

The server stores no state between requests. So when the renderer asks for a byte-range not starting from 0, the transcoder process would have to start again from the start of the file and stream the output (throwing away the result) until it gets to the start point for streaming. When the next range request came in, this process would have to happen again from the start. Since the transcoding occurs in near-real-time, you can imagine the repeated restarting is not going to give very smooth replay - each range is going to take as long to produce as the total of all its predecessors!

There is possibly scope for someone to write something asynchronous that continues transcoding past the end of the range requested, cacheing the result somewhere, so subsequent range requests would not have to restart the transcoding process. That asks a lot of questions though. What if the renderer stops rendering? How does PMS know to stop the transcoding and delete the cached file? Transcoding is a tough job, so the server could end up buckling under the requirements of multiple asynchronous transcoding processes.

I would prefer to offline-transcode the files rather than go through all that, I'm afraid...

[infidel]

You're the expert, WoH. How about patters' suggestion to mimic the Mezzmo approach:

I found a new DLNA server yesterday (Mezzmo - free 15 day trial) which seems to list all mkv/mp4/m4v streams as m2ts but actually sends them with the correct DLNA type for the real media clips when you play then (video/x-matroska etc.)... which works! It can play HD H.264 mkv and mp4 files with no stutter.

do you think this is feasible?

[patters]

I can see that Mezzmo sets the media protocolInfo value in the res tag to something like:
http-get:*:video/x-matroska:*

but it doesn't set any of the DLNA settings like DLNA.ORG_OP=11 to allow time/range seeking for instance

...whereas Serviio uses:
http-get:*:video/x-matroska:DLNA.ORG_PN=MATROSKA;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=81100000000000000000000000000000

I've been trying to understand why none of the PS3MS folders show any content when browsed with UPnP Inspector apart from the Web one (which is really limiting my testing). Any ideas?

[infidel]

Any indication as to how Mezzmo gets the BDP-S370 to see files as M2TS?
...
Well, I took the plunge and upnp-inspectored mezzmo too, noting a couple of things:

• mezzmo is transcoding. There's an ffmpeg binary plus an %APPDATA%\Conceiva\Mezzmo\TranscodingFiles folder under which one finds .mzt files which are transcode caches ('ffmpeg -i' will id the streams, and you can play some of them back by adding the appropriate extension, e.g. '.mpg')

• mezzmo uses some mime-types new to me:
  vob -> video/mp2p
  mp4 -> video/mp4v-es
  ts,mts,m2ts -> video/vnd.dlna.mpeg-tts

[patters]

Mezzmo can transcode but I'm not sure it does so systematically for the BDP. Why would it set the protocolInfo dlna mime for video/x-matroska if it was transcoding mkv?

There seems to be a difference in the mime types that are declared in the .conf files (which are used to sort the files for directory browse operations) and the official dlna ones which get used in protocolInfo (for actual playback) which you posted examples of above. I saw those yesterday and tried using them in the .conf to no avail. Looking at DLNAresource.java it looks like it can't deal with some of them (like Matroska) because there's a lot of conditional code which was written mostly for the PS3's capabilities. I really need PS3MS to show up properly in UPnP Inspector to troubleshoot it though. I can't get files to show up as m2ts on the BDP - even real m2ts files. If I specify video/mpeg they just show up as MPEG in the BDP's UI. So it does look like a change will be required in DLNAresource.java.

WorldOfHurt - do you know why some of the XML has tag characters encoded (&gt; etc.)? Looking at a SOAP request pulled from Wireshark I can see it's not done consistently there are still many < and > chars in there. Could this be what's upsetting UPnP inspector?

[infidel]

Sort of systematic transcoding, I'd say. I cleared mezzmo's TranscodingFiles folder and played 7 files, which generated 5 .mzts:

-mezzmo mime-types video/mp4v-es, video/x-ms-wmv generated .mzts containing MPEG4 Video (H264)
-mezzmo mime-type video/x-matroska (containing mpeg4 and aac) generated an .mzt with ac3 audio only
-mezzmo mime-type video/vnd.dlna.mpeg-tts which displayed as MPEG generated an .mzt containing MPEG2
-mezzmo mime-type video/vnd.dlna.mpeg-tts (including avchd) which displayed as M2TS generated no .mzts

all the .mzts contain much longer portions than the segment I actually played back. You're right, mime-types vary but it actually seems to deliver either MPEG4 or MPEG2.