I was wondering why the PS3 refused to show transcoded flac and ogg audio files as supported, so I started up wireshark and started exploring.
It seems that MediaTomb (svn 1656) sends protocolInfo= twice for each audio file. The first time is correct and shows the item to be "audio/x-wav", but the second time is the old source attribute value. It's this value the PS3 locks onto and says unsupported. To test this I forced both instances to be something the PS3 supports (audio/x-wav) and sure enough, the PS3 displayed the files as supported in the browser. However, it seems my method of forcing that overwrote whatever is used to actually trigger the transcode so MediaTomb tried to pass the actual flac in x-flac format to the PS3 when I tried to play it. Of course, that didn't go over so well. From the code it appears the mimetype is taken from the protocolinfo on more than one occasion, and I'm guessing that, combined with my forcing the protocolinfo to be "audio/x-wav" caused the transcode to fail to run.
Basically, it seems that second protocolInfo= just needs to be removed and it should work fine on the PS3. Perhaps somehow remove that attribute before calling element->appendElementChild(UpnpXML_DIDLRenderResource(url, res_attrs)); in cds_resource_manager.cc?
Also, sending the ext= as the original file extension may not be a good idea for transcoded items and the PS3 seems to operate fine without that attribute. Not sure how other systems will react to that missing.
The problem is the PS3, it simply will not play streamed wav files. Hacking around will not help; the PS3 will also not play MP3 files where it does not know the content length, which basically means that you can not listen to online streams/shoutcast.
You may be right regarding the .ext thing, I will have a look at it, but this is anyway only required as a hack for the broken TG100 firmware, other renderers ignore this.
I can't speak to the length issue, but I can promise you the reason the PS3 is listing all transcoded audio as Unsupported is because of protocolInfo being sent twice when MediaTomb should only be sending it once. I can supply the capture logs if you like, but when I forced both protocolInfo's to match the target transcode protocol it started displaying the files as supported and would attempt to play them. But, as I mentioned, Mediatomb extracts the mimetype from the protocolinfo for some reason at a couple points and with my crude force in there it decided it didn't need to transcode the files after all. And, of course, the PS3 won't actually play a .flac or .ogg, which is what MediaTomb tried to send rather than the transcoded stream.
Even ignoring the PS3 it looks to me like a bug in MediaTomb that the protocolInfo field is being sent twice for each transcoded audio listing during a Browse request.
I know that it lists the resources twice and this is absolutely OK - according to the specification you can have multiple resources per item, which can be in different format.
Of course not all players implement that correctly - a player which does not take that into account will only look at the first resource; for that we offer an option that can be set in the transcoding profile of the config.xml, we also have options to hide the original resource,i.e. to enforce that only the transcoded resource is sent. So no need to hack the code, the features are already there.
I hope the doc is up to date:
I see what you're saying. I didn't realize the hide option existed nor that multiple duplicate resource lists were allowed. Sorry about that.
Oddly, though, hiding the original or swapping the original to the first still results in Unsupported Data being displayed. Yet hiding the original seems to make ext= the target mimetype's value (for pcm at least.) Sadly, hiding the original also keeps the bitrate, sample frquency, etc from being passed. It does looks like the PS3 is flawed because it rejects files with differing protocolInfo fields when multiple are sent. But, it also needs something from the rest of the child resource attributes.
Even if there were some way to hide the fact it was transcoded and send the original file info along with the target protocolinfo to get it to display as supported when it went to play MediaTomb would have no way of knowing the end filesize, which as you mentioned, the PS3 requires. I guess there's no way to do it until either the PS3 eases up on how it handles things or until you implement some method of internally transcoding to have access to the rate info and guess at the ending filesize.
Believe me, we really tried things with other users on IRC, we tried faking the content length and ignoring the seek request, we know how to change the XML so the PS3 will request the file, but nothing helps - it will just not play it.
The only way to offer transcoded audio seems to be - a transcoding library that would deliver us the content length of the transcoded media (which would work for constant bitrate files), so yes - as you mentioned, this could only be done via an internal implementation. So.. for a later release :>
Regarding the multiple protocol info tags: as mentioned, some players ignore those and always take the first resource instead of looking at all available.
I just posted over here about my research into roughly the same topic:
I believe the fix is to do some fairly simple metadata copying for the artist, album, etc. In order to get the PS3 to play a .wav file it seems that all you really need is a file-length and a sample bitrate. Since the .flac files contain a compression ratio, you could even extract this, do a little math and come up with the uncompressed file size to plus/minus a percent or so.
Using Twonky 5.0 Beta 1, these seem to be working for flac and ogg (transcoding to LPCM):
ffmpeg -i $infile -f s16be $outfile
ffmpeg -i $infile -f s16be $outfile
Perhaps this will be useful for Mediatomb.
These are also working on the DirecTV HR20.
Can you please make a wireshark capture so we could have a look if they are somehow specifying the content length or not?
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.