PDA

View Full Version : DLNA Interoperability and Mimetype



smart
06-10-2011, 07:21 AM
Hello,

in general I have a working setup with Philips 42PFL7695K/02 and a AVM Fritzbox 7390 as a Mediaserver and Windows Media Server on a PC in the network. Most of the formats are working.

But there is one sensitivity. I see that xvid coded video files can be played by the TV when it is played directly from USB Stick at the TV. They are played when choosing Windows Media Server as a Mediaserver over the network. They are not played when choosing AVM Fritzbox 7390 Mediaserver as a UPnP Mediaserver source over the network.

I have debugged that with UPnP Developer Tools (http://opentools.homeip.net/dev-tools-for-upnp) and the tool "AV Media Controller" from this tools package.

The protocolInfo of the same video, from Windows Media Server says:
http-get:*:video/avi: DLNA.ORG_OP=01;DLNA.ORG_FLAGS=01500000000000000000 000000000000

The protocolInfo of the same video, from AVM Fritzbox 7390 Mediaserver says:
http-get:*:video/x-msvideo: DLNA.ORG_PN=AVI;DLNA.ORG_OP=01;DLNA.ORG_CI=0

I assume the different mime type as a source of the error.

So I have the questions:
Which mime type is expected for xvid coded files over the network?
Which is the correct mime type?
Should the Philips TV play files from mime type video/x-msvideo or should the AVM Fritzbox 7390 Mediaserver return another mime type?

As I can see, there is no hardware/software limition, since the video can be played over the network, but there is an incompatibility between different manufacturers. Please help to clarify those details.

MediaInfo of the video:

Format : AVI
Format/Info : Audio Video Interleave
Dateigröße : 700 MiB
Dauer : 1h 46min
Gesamte Bitrate : 919 Kbps

Video
ID : 0
Format : MPEG-4 Visual
Format-Profil : Advanced Simple@L5
Format-Einstellungen für BVOP : 2
Format-Einstellungen für Qpel : Nein
Format-Einstellungen für GMC : Keine warppoints
Format-Einstellungen für Matrix : Default (H.263)
Codec-ID : XVID
Codec-ID/Hinweis : XviD
Dauer : 1h 18min
Bitrate : 1 108 Kbps
Breite : 624 Pixel
Höhe : 336 Pixel
Bildseitenverhältnis : 1,857
Bildwiederholungsrate : 25,000 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.211
Stream-Größe : 620 MiB (89%)
verwendete Encoder-Bibliothek : XviD 1.2.1 (UTC 2008-12-04)

Audio
ID : 1
Format : MPEG Audio
Format-Version : Version 1
Format-Profil : Layer 3
Codec-ID : 55
Codec-ID/Hinweis : MP3
Dauer : 1h 46min
Bitraten-Modus : konstant
Bitrate : 96,0 Kbps
Kanäle : 2 Kanäle
Samplingrate : 48,0 KHz
Stream-Größe : 73,1 MiB (10%)
Ausrichtung : Ausgerichtet an Interleaves
Interleave, Dauer : 24 ms (0,60 Video-Frame)

smart
06-27-2011, 09:31 PM
When debugging this also with AVM, the manufacturer of Fritzbox 7390, we could find out, that the mimetype is not the root cause of the problem. They changed the mimetype, but it did not work.

I discovered, that the Fritzbox gives 00:00:00 as duration for the video. So there is a really bad message on the TV which does not really say the reason. What Gould the TV do if duration is 00:00:00? What would be the behaviour?

Philips
06-29-2011, 06:59 AM
Hi Smart

Sorry to hear about your experience. We are currently investigating your problem and will update you on the progress.
You will get a Message as soon as a Solution comes up.

Regards
ThEg

l00pu5
06-29-2011, 10:04 PM
Hello,

in general I have a working setup with Philips 42PFL7695K/02 and a AVM Fritzbox 7390 as a Mediaserver and Windows Media Server on a PC in the network. Most of the formats are working.

But there is one sensitivity. I see that xvid coded video files can be played by the TV when it is played directly from USB Stick at the TV. They are played when choosing Windows Media Server as a Mediaserver over the network. They are not played when choosing AVM Fritzbox 7390 Mediaserver as a UPnP Mediaserver source over the network.

I have debugged that with UPnP Developer Tools (http://opentools.homeip.net/dev-tools-for-upnp) and the tool "AV Media Controller" from this tools package.

The protocolInfo of the same video, from Windows Media Server says:
http-get:*:video/avi: DLNA.ORG_OP=01;DLNA.ORG_FLAGS=01500000000000000000 000000000000

The protocolInfo of the same video, from AVM Fritzbox 7390 Mediaserver says:
http-get:*:video/x-msvideo: DLNA.ORG_PN=AVI;DLNA.ORG_OP=01;DLNA.ORG_CI=0

I assume the different mime type as a source of the error.

So I have the questions:
Which mime type is expected for xvid coded files over the network?
Which is the correct mime type?
Should the Philips TV play files from mime type video/x-msvideo or should the AVM Fritzbox 7390 Mediaserver return another mime type?

As I can see, there is no hardware/software limition, since the video can be played over the network, but there is an incompatibility between different manufacturers. Please help to clarify those details.

MediaInfo of the video:

Format : AVI
Format/Info : Audio Video Interleave
Dateigröße : 700 MiB
Dauer : 1h 46min
Gesamte Bitrate : 919 Kbps

Video
ID : 0
Format : MPEG-4 Visual
Format-Profil : Advanced Simple@L5
Format-Einstellungen für BVOP : 2
Format-Einstellungen für Qpel : Nein
Format-Einstellungen für GMC : Keine warppoints
Format-Einstellungen für Matrix : Default (H.263)
Codec-ID : XVID
Codec-ID/Hinweis : XviD
Dauer : 1h 18min
Bitrate : 1 108 Kbps
Breite : 624 Pixel
Höhe : 336 Pixel
Bildseitenverhältnis : 1,857
Bildwiederholungsrate : 25,000 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.211
Stream-Größe : 620 MiB (89%)
verwendete Encoder-Bibliothek : XviD 1.2.1 (UTC 2008-12-04)

Audio
ID : 1
Format : MPEG Audio
Format-Version : Version 1
Format-Profil : Layer 3
Codec-ID : 55
Codec-ID/Hinweis : MP3
Dauer : 1h 46min
Bitraten-Modus : konstant
Bitrate : 96,0 Kbps
Kanäle : 2 Kanäle
Samplingrate : 48,0 KHz
Stream-Größe : 73,1 MiB (10%)
Ausrichtung : Ausgerichtet an Interleaves
Interleave, Dauer : 24 ms (0,60 Video-Frame)

Hi smart,

I've just tested a similar constellation as described (FritzBox 7240) and I'm able to reproduce this behaviour as well. However, the very same video files will run smoothly when playing them back via USB directly or by using any other DLNA DMS than the one of the AVM router (the AV media server of the UPnP dev tool should work for you as well).
The way it seems to me, the FritzBox gives invalidated parameters which brick the file's playback ability. Try feeding the affected video stream to the UPnP dev tools' AV renderer service after setting it up to accept video/x-msvideo MIME type: it won't play back at all.
However, a WMP12 instance does not seem to have problems with playing back those files.

After all, the FritzBox delivers a playback time of 0:00.00. I don't see any reason why the TV set should NOT have problems with that - it's an empty file for the TV set after all. I think that's were the issue originates. ANd this is supported by the fact that other DMS services are running fine and deliver correct file parameters.

smart
06-30-2011, 06:12 AM
@ Philips: Great! Thanks for looking into it.

@l00pu5: Right, Fritzbox delivers a duration="00:00:00". First I did not see that when inspecting the network traffic. I'm a beginner with DLNA protocols. I just saw the difference in the mimetype and I found users which had trouble with devices just refusing to play a file because of wrong mimetype (http://mediatomb.cc/). For mediatomb, you can define mappings from file ending to mimetype in case you have trouble with it.

As I said, there is a ticket open at AVM, where they are looking into the problem. So they changed the mimetype for such files to video/avi to test if that is the case. This is in the newest beta firmware 84.05.04-20071 (http://www.avm.de/de/Service/Service-Portale/Labor/7390_cebit_labor/labor_start_cebit_labor.php).

Seeing that this did not work, I had a second look at the network traffic. Then I saw that duration="00:00:00". I think, it is totally clear, that it does not make sense to play a file with 0 length. So this is a thing AVM should fix.

There is on thing Philips could/should improve: If trying to play the file, it says: "Ausführung nicht möglich. Nicht unterstützte Datei.". (English: "Execution not possible. Unsupported file"). A better message would be: "Length of the file is 00:00:00. Can't play the video." or: "Duration of the video is: 00:00:00. Can't play the video."

This would be better to understand and help to find the root causes of such problems.

smart
06-30-2011, 06:24 AM
@ l00pu5: We should not only focus on the duration, since we do not know, what is the problem of the TV playing the file. It can be, that the duration is the problem. But if this is fixed, the TV can also refuse playing the file because of the mimetype. So if we can make sure, that both mimetypes should be playable or it has to be one of the two, we can solve the problem quicker.

The message, the TV prints out, says that the file is unsupported. This made me first look at the mimetype. Because the mimetype describes it type. If the TV had printed out "zero length", I would have looked at the duration first.

So both devices are not perfect and the user has to check the interface. Fritzbox gives some strange values and the TV error messages which does lead in the wrong direction.

l00pu5
07-03-2011, 08:35 PM
@ l00pu5: We should not only focus on the duration, since we do not know, what is the problem of the TV playing the file. It can be, that the duration is the problem. But if this is fixed, the TV can also refuse playing the file because of the mimetype. So if we can make sure, that both mimetypes should be playable or it has to be one of the two, we can solve the problem quicker.

The message, the TV prints out, says that the file is unsupported. This made me first look at the mimetype. Because the mimetype describes it type. If the TV had printed out "zero length", I would have looked at the duration first.

So both devices are not perfect and the user has to check the interface. Fritzbox gives some strange values and the TV error messages which does lead in the wrong direction.

Hi smart,

here's what I think about this topic.

First of all, the error message "Nicht unterstützte Datei" seems to be somewhat generic. It should only indicate that there might be something wrong with the file without giving details too specific for most users. If something like "invalid playtime duration" would be given on top of that as an error message, I think this statement will actually go far beyond the average consumer's horizon (I am fully aware that there are exceptions, though). If the average user (one who's not familiar with the internals of UPnP/DLNA) gets confronted with such a message, I assume he wouldn't know what to do next even if he had all the details at his hands (when playing the file on a PC, the duration will probably be shown in the video player application, and the consumer would be blaming the TV instead - no point here).

However, I fully agree that a few more details / hints to point the consumer in the right direction would be nice to have.

Regarding the 2 different MIME types mentioned throughout this thread: Twonky actually uses video/x-msvideo when streaming AVI files which worked for me while investigating on this behaviour. I also provoked those 2 MIME types with the same file on a DMS (one of my own - I'm developing UPnP software, by the way) while the file remained playable. I think the MIME's are definitely out of the game since the TV would handle both types just fine.

smart
07-04-2011, 08:35 AM
Regarding the error message, I think adding a more specific detail to give support (Philips Support/Technical interested friends/Experienced users/Third party developers) won't make the TV look bad in the eyes of an inexperienced user.

It would be possible to combine the current generic message with some more details.

For the mimetypes, great that you were able to test that and reproduce that. I think, the mimetype is definitely out of the game, now.

Since you have a working test setup, would it be possible, that you can test the duration="00:00:00", without consuming too much time on your side?

I would be interested in hearing from your results!

Philips - Remko
07-08-2011, 09:18 AM
Hi smart,

Which software version do you have on your TV?

Thanks for your feedback!

Regards,

smart
07-08-2011, 01:44 PM
Firmware is: 0.140.37.0

smart
07-24-2011, 07:23 PM
Looking a little at other files, I saw that, there are other videos which are playable with the PhilipsTV, although the Fritzbox 7390 gives 00:00:00 as duration. So I would assume, with the logic of the mimetype, that this can't be the root of the problem.

@l00pu5: Your logic is not correct, that giving duration 00:00:00 should make any Player not play a file since it has 0 length.

There is also the file size given in the DLNA traffic, so the TV knows the files size. Then he knows that it is not empty, since file size is correct. Then the TV might wonder why duration is 00:00:00. But I do not know the implementation here.

So I'm asking me, what is the TV looking for to decide he can't play a file? Duration is 00:00:00 for some files which can be played. Changing the mimetype had no effect/no improvement.

The TV does flag the file as not playable with that x before I select it and try to play it. So I assume, that he does not read the file, it decides on metadata? Philips, can you please help on that?

l00pu5
07-25-2011, 08:07 AM
Looking a little at other files, I saw that, there are other videos which are playable with the PhilipsTV, although the Fritzbox 7390 gives 00:00:00 as duration. So I would assume, with the logic of the mimetype, that this can't be the root of the problem.

@l00pu5: Your logic is not correct, that giving duration 00:00:00 should make any Player not play a file since it has 0 length.

There is also the file size given in the DLNA traffic, so the TV knows the files size. Then he knows that it is not empty, since file size is correct. Then the TV might wonder why duration is 00:00:00. But I do not know the implementation here.

So I'm asking me, what is the TV looking for to decide he can't play a file? Duration is 00:00:00 for some files which can be played. Changing the mimetype had no effect/no improvement.

The TV does flag the file as not playable with that x before I select it and try to play it. So I assume, that he does not read the file, it decides on metadata? Philips, can you please help on that?

Hi smart,

now thing's are startin' to get veeery interesting.
Do you have any possibility to share a playable file with playback duration 0:00.00 (maybe you have one that is rather small)? I'd like to have a closer look at it - unfortunately I only have files that won't play back...

BTW: I was not saying that a zeroed playback duration should brick playback on any renderer - it MIGHT cause trouble (which is an option, though).

Regards,
l00pu5

smart
07-25-2011, 05:31 PM
Hello,

I have a file which can be played by the Philips TV from the Fritzbox 7390 MediaServer. Its duration field in the DLNA traffic packets is 00:00:00, given by the Fritzbox.
I found that out with Wireshark.

Real duration of the file is: 00:01:08, file size is round about 25MB.

MediaInfo:

Allgemein
Vollständiger Name : Z:\WD-2500BEVExternal-01\Public\Blu-ray Disc HD1080p.mov.mp4
Format : MPEG-4
Format-Profil : Base Media / Version 2
Codec-ID : mp42
Dateigröße : 24,4 MiB
Dauer : 1min 8s
Gesamte Bitrate : 3 002 Kbps
Kodierungs-Datum : UTC 2009-11-04 08:13:20
Tagging-Datum : UTC 2009-11-04 08:13:20
gsst : 0
gstd : 68823
gssd : B6DC1C00BHH1298153776069568
gshh : v24.lscache6.c.youtube.com

Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : High@L4.0
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für ReFrame : 3 frames
Format_Settings_GOP : M=1, N=60
Codec-ID : avc1
Codec-ID/Info : Advanced Video Coding
Dauer : 1min 8s
Bitrate : 2 889 Kbps
maximale Bitrate : 6 687 Kbps
Breite : 1 920 Pixel
Höhe : 800 Pixel
Bildseitenverhältnis : 2,40:1
Modus der Bildwiederholungsrate : konstant
Bildwiederholungsrate : 23,961 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.078
Stream-Größe : 23,5 MiB (96%)
Titel : (C) 2007 Google Inc. v08.13.2007.
Kodierungs-Datum : UTC 2009-11-04 08:13:21
Tagging-Datum : UTC 2009-11-04 08:13:21

Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format-Profil : LC
Codec-ID : 40
Dauer : 1min 8s
Bitraten-Modus : variabel
Bitrate : 110 Kbps
maximale Bitrate : 135 Kbps
Kanäle : 2 Kanäle
Kanal-Positionen : Front: L R
Samplingrate : 44,1 KHz
Stream-Größe : 921 KiB (4%)
Titel : (C) 2007 Google Inc. v08.13.2007.
Kodierungs-Datum : UTC 2009-11-04 08:13:20
Tagging-Datum : UTC 2009-11-04 08:13:21

If you have a good suggestion about exchanging that file, I'm open to that.

l00pu5
07-25-2011, 08:34 PM
Okay, I've had a closer look at the problem right now.
@ smart: thanks for providing the file, that really helped investigating this topic!

What I can tell right now is this:
When putting aside all generic parameters, the problem seems to be down to the protocolInfo string delivered by the AVM DMS.

Here's what I ended up with when comparing two files (1x non-playable via the FritzBox, 1x playable via the FritzBox despite the zeroed playback duration):
ITEM #1a (AVI / FB Media Server) -> not playable, crossed
upnp:class: object.item.videoItem
dc:title: 1956.12.15 - To Hare is Human (Jones) MM
Restricted: False
Media Class: object.item.videoItem
Object ID: 17_2
Parent ID: 17
contentUri: http://192.168.1.1:49100/mediapath/SanDisk-U3CruzerMicro-01/1956.12.15%20-%20To%20Hare%20is%20Human%20(Jones)%20MM.avi
duration: 00:00
protocolInfo: http-get:*:video/x-msvideo:DLNA.ORG_PN=AVI;DLNA.ORG_OP=01;DLNA.ORG_CI =0
size: 67416714

ITEM #1b (AVI / FUPPES 0.660) -> playable
upnp:class: object.item.videoItem
dc:title: 1956.12.15 - To Hare is Human (Jones) MM
Restricted: False
Media Class: object.item.videoItem
Object ID: 0000001B9D
Parent ID: 0000001B9C
contentUri: http://192.168.1.34:4852/MediaServer/VideoItems/0000001B9D.avi
duration: 07:02
protocolInfo: http-get:*:video/x-msvideo:*
size: 67416714

ITEM #2a (MP4 / FB Media Server) -> playable
upnp:class: object.item.videoItem
dc:title: Blu-ray Disc HD1080p.mov
Restricted: False
Media Class: object.item.videoItem
Object ID: 17_4
Parent ID: 17
contentUri: http://192.168.1.1:49100/mediapath/SanDisk-U3CruzerMicro-01/Blu-ray_Disc_HD1080p.mov.mp4
duration: 00:00
protocolInfo: http-get:*:video/mp4:DLNA.ORG_OP=01;DLNA.ORG_CI=0
size: 25637343

ITEM #2b (MP4 / FUPPES 0.660) -> playable
upnp:class: object.item.videoItem
dc:title: Blu-ray Disc HD1080p.mov
Restricted: False
Media Class: object.item.videoItem
Object ID: 000000147F
Parent ID: 0000001400
contentUri: http://192.168.1.34:4852/MediaServer/VideoItems/000000147F.mp4
duration: 01:08
protocolInfo: http-get:*:video/mp4:*
size: 25637343

What do we see here?
(1) both MIME types "video/x-msvideo" and "video/mp4" will be accepted by the TV when serving the files via FUPPES (I've tested the win32 build 0.660 that came pre-compiled from the official FUPPES homepage). => I conclude that the MIME type is not the issue here
(2) MIME type "video/mp4" will be accepted by the TV set when serving the file via the FritzBox DMS, despite the fact that the playback duration is still zeroed out. => I conclude that the playback duration being zeroed out is not the issue either (!)
(3) the only thing that differs is the DLNA.ORG_PN flag being "DLNA.ORG_PN=AVI" for the non-playable content served by the FritzBox

According to these facts, I conclude the following:
(1) the content will be playable if the flag "DLNA.ORG_PN=AVI" will not be included in the protocolInfo field by the AVM DMS (that's what most DMS applications currently do); I didn't observe this kind of behaviour with other DMS applications so far while this point was true for all of them (I think this more or less proves my theory here)
(2) the content's MIME type doesn't matter in this case
(3) the TV set SHOULD accept this content definition given in the flag (at least there's nothing that would in theory interfere with it since the set is capable of handling AVI containers)

smart
07-26-2011, 12:20 PM
@l00pu5: Thanks for this really deep and close look into the problem! Your finding sounds reasonable, understandable and very helpful here!

So from my point of view, I would say we have two device which try to follow one standard to be compliant. Currently they are not. I have really no idea, what the right way is on this to follow the standard or if this is not specified in the standard.

1. Philips TV has a sensitivity on the flag "DLNA.ORG_PN=AVI" in protocolInfo string. Seems that the TV thinks, it can't play the video due to this flag. So the question for Philips would be: "Is there a need for this sensitivity we do not see from our point of view? If there is no real need, can it be ignored to be more failure tolerant/follow the standard?"

2. Fritzbox 7390 adds the flag "DLNA.ORG_PN=AVI" in protocolInfo string although it is not needed/creates problems on some devices. The question for AVM would be: "Is it really necessary to add this flag? If there is no real need, can it be removed to be more failure tolerant/follow the standard?"

I think both devices should be modified to be as much compliant to other devices. So we have some work items:

1. I will update the ticket at AVM and try to point them to our results.
2. Philips, can you please have a closer look at the implementation regarding this flag? Are those posts sufficient or should we also open a ticket at local country support?

Thanks to everybody working on that!

l00pu5
07-26-2011, 01:25 PM
@l00pu5: Thanks for this really deep and close look into the problem! Your finding sounds reasonable, understandable and very helpful here!

So from my point of view, I would say we have two device which try to follow one standard to be compliant. Currently they are not. I have really no idea, what the right way is on this to follow the standard or if this is not specified in the standard.

1. Philips TV has a sensitivity on the flag "DLNA.ORG_PN=AVI" in protocolInfo string. Seems that the TV thinks, it can't play the video due to this flag. So the question for Philips would be: "Is there a need for this sensitivity we do not see from our point of view? If there is no real need, can it be ignored to be more failure tolerant/follow the standard?"

2. Fritzbox 7390 adds the flag "DLNA.ORG_PN=AVI" in protocolInfo string although it is not needed/creates problems on some devices. The question for AVM would be: "Is it really necessary to add this flag? If there is no real need, can it be removed to be more failure tolerant/follow the standard?"

I think both devices should be modified to be as much compliant to other devices. So we have some work items:

1. I will update the ticket at AVM and try to point them to our results.
2. Philips, can you please have a closer look at the implementation regarding this flag? Are those posts sufficient or should we also open a ticket at local country support?

Thanks to everybody working on that!

Hi smart,

no problem :)

While considering updating your AVM ticket, please also take note of this thread: http://www.ip-phone-forum.de/showthread.php?t=231967&page=1

This one describes the very same issue (at least according to the details given so far) with a Samsung TV. I guess having the FritzBox not include the DLNA.ORG_PN flag then would be the most simple solution since this automatically solves issues with all kinds of other devices that might be affected by this phenomenon.

l00pu5
07-26-2011, 07:17 PM
Hi guys,

seems like I have to refine my statements from before even further. I just tested several different versions of Twonky since I remember having heard rumors of Twonky 6.x pullin' off the same thing (non-playable video files which were working fine via USB).
Here are the results (BTW: I've tested the same 2 files that were mentioned in my previous posts).

Twonky 4.4 (Fujitsu-Siemens Activiy 150 NAS):
AVI: http-get:*:video/x-msvideo:* -> working since DLNA flag is not included
MP4: http-get:*:video/mp4:* -> working for obviously the same reason

Twonky 5.1.2 (Vaio VPCW12S1E @ Win 7 Starter):
AVI: http-get:*:video/x-msvideo:* -> working since DLNA flag is not included
MP4: http-get:*:video/mp4:* -> working for obviously the same reason

Twonly 6.0.34 (ThinkPad x100e @ Win XP Pro SP3):
AVI: http-get:*:video/x-msvideo:DLNA.ORG_PN=PV_DIVX_DX50;DLNA.ORG_OP=01;DL NA.ORG_FLAGS=01700000000000000000000000000000 -> flag is there, not working (crossed out in the TV's content browser)
MP4: http-get:*:video/mp4:DLNA.ORG_PN=AVC_MP4_HP_HD_AAC;DLNA.ORG_OP=01;D LNA.ORG_FLAGS=01700000000000000000000000000000 -> not working for the same obvious reason

So it seems like the rumors I've heard are true after all for the very same reason that bricks AVI playback via the AVM DMS (except that Twonky 6 won't make a difference between different container formats since the flag is always present for any content type).

l00pu5
07-26-2011, 07:21 PM
Look what I found: http://www.supportforum.philips.com/en/showthread.php?849-7605-8605-9705-DLNA-problem

This one might be connected to this thread - Twonky 6 is involved.

smart
07-27-2011, 07:52 AM
Hi,

I'm asking me, what is the meaning of this DLNA.ORG_PN flag. It seams something similar to file ending or mimetype. What does the standard say? Does the standard require it? Is it optional? If it is optional, what does this flag want the TV to do? Why is it added by the Fritzbox? Fritzbox should have a UPnP Server. Why are there DLNA flags?

Does somebody know some public documentation regarding that? How can a consumer say which vendor has a wrong implememtation? Or are both correct?

smart
07-27-2011, 06:39 PM
I have found a link to a document describing that there is a bug in WMS 11 which does not use the DLNA.ORG_PN field. The DLNA.ORG_PN is missing for AVI files.

http://www.ureader.com/msg/13971218.aspx

This explains also that the same video can be played from Windows Media Server but can't be played from Fritzbox 7390 Mediaserver. So when Microsoft updates this bug, one can't play the AVI files from Windows Media Server anymore, although it was able before. Just because the Philips TV ignores videos which are delivered with this flag which is a must in the dlna standard.

Philips, please comment on this.


In the case of WMS 11 for an AVI file, the fourth parameter (DLNA.ORG_PN) is
missing.

Example: <res
protocolInfo="http-get:*:video/avi:DLNA.ORG_OP=01;DLNA.ORG_CI=0">
Should be: <res
protocolInfo="http-get:*:video/avi:DLNA.ORG_PN=AVI;DLNA.ORG_OP=01;DLNA.ORG_CI=0">

This is a bug in the implementation of the DLNA protocol in WMS 11.


Reference document "DLNA Home networked device interoperability guidelines
(Part 1: Architecture and Protocols)"

It's a pity, I can't access the official documents because I'm not a member of the DLNA working group. Standard consumers also can't afford it. It cost $500,00. Before buying that, I would return my 2010 TV and spend that on top to get a new 2011 model.

smart
07-27-2011, 06:40 PM
@l00pu5: Do you have access to those documents?

smart
07-27-2011, 06:45 PM
@l00pu5: Would you be able to reproduce that with a official tested video codec from http://certification.dlna.org/certs/REG31680722.pdf . Like MPEG_PS_PAL?

I mean providing that file with adding the appropriate DLNA.ORG_PN flag?
If the TV won't play it then, there might be also an issue with the standardization process.

l00pu5
07-27-2011, 08:35 PM
@l00pu5: Do you have access to those documents?

I wish I had :rolleyes:
Although I'm developing a client-side UPnP library + a command-line UPnP diagnostic tool for *NIX platforms, I had to reverse-engineer most of the protocol specs myself.
Having this document would ease up the task for sure - that's why I'm only able to deliver assumptions here.

l00pu5
07-27-2011, 09:30 PM
@l00pu5: Would you be able to reproduce that with a official tested video codec from http://certification.dlna.org/certs/REG31680722.pdf . Like MPEG_PS_PAL?

I mean providing that file with adding the appropriate DLNA.ORG_PN flag?
If the TV won't play it then, there might be also an issue with the standardization process.

The TV just failed to playback an MPEG-1 PS file with protocolInfo http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_PAL;DLNA.ORG_OP=11, that was via PS3 media server. However, your file was again running fine, mainly due to the fact that the protocolInfo field looks like this: http-get:*:video/mp4:DLNA.ORG_OP=11; as you can see, the DLNA.ORG_PN was missing (that kinda confirms my theory that this flag bricks the playback).

I've verified with Serviio, where your file will be delivered with http-get:*:video/mp4:DLNA.ORG_PN=AVC_MP4_MP_HD_1080i_AAC;DLNA.ORG_O P=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=0150000000000000 0000000000000000.
Guess what happened - it didn't play back...

Some remarks about that:
(1) the Serviio session was not representative since the PN value ain't mentioned in the TV's DLNA certificate. Thus, it might be "correct" / intentional behavior that this file was rejected by the TV set.
(2) Serviio delivered multiple resources for one item, the other containing an URI to a thumbnail image (I've verified with Wireshark that the TV pulls the right URI) -> multiple resource descriptions might be another potential failure source
(3) the PS3 media server session is the only absolutely representative evidence here and it proved that the PN flag bricks playback. Twonky 6 ships the file only with http-get:*:video/mpeg:* where it worked.

smart
07-28-2011, 09:51 AM
@l00pu5: Great findings! I think we really get closer to the root cause!

I think, it is impressing, that those mpeg files won't play if adding the DLNA.ORG_PN flag. Since the certification of DLNA says it should play the file. Also it says (if I can believe the linked contect to the WMS 11 bug), that the DLNA.ORG_PN flag is a must.

Seems that the TV does not follow DLNA 1.5 spec as it is said in the data sheet.

I'm missing a comment from Philips side regarding that topic. Philips, please comment!

Philips - Thomas
07-28-2011, 10:15 AM
Hi smart,

we are investigating the issue since your first post, please see this posting (http://www.supportforum.philips.com/en/showthread.php?1754-DLNA-Interoperability-and-Mimetype&p=8671&viewfull=1#post8671). ;)
And we are still working on it.
We really appreciate the work from all of you in that case.
As soon as a Solution comes up, i will post it here.

Thanks
Thomas

smart
07-28-2011, 11:56 AM
Thanks for your comment! Sure, I have read your postings. Seems that I'm a little impatient...

pszafer
07-29-2011, 10:44 PM
Hello smart! and others ;)

I'm actually writing app UPnP Media Server to develop my master thesis.
I've had similar problem with my Phillips TV (32PFL8404H) and I was fighting for about 2 days with it and I now what is problem with mine tv set.

So I've got three files in directory:
1.avi,
2.mkv,
3.wmv,

directories was:
/home/zzz/Video/test/test2/*.*

and nothing shows up.

I was looking for everything in DIDL-Lite xml, DLNA tags etc.
With a lot of lucky I've found problem:
I moved 2.mkv to /home/zzz/Video/test/2.mkv
2 more files was still in /home/zzz/Video/test/test2/*.*

MKV cannot be played in my tv, but what weird directory test2 wasn't showed up.
So I've testing little bit more and now I know that if my Phillips tv-set have mimetype, which cannot be handled it doesn't looking deeper and doesn't show nothing!

So especially for phillips I will make one more upnp container with all multimedia files sorted by mimetypes.
You'll go into /mimetype/avi and it will shows up all avi files.

If you got other/better idea how to resolve this on server side without personalising server for every hardware (I had fighting with WMP11, WMP12, XBOX, Playstation, Samsung All Share, now Phillips, next will be LG).
I cannot understand why every manufacter implement Media Player in different way...

Regards

smart
07-31-2011, 03:59 PM
@pszafer: Thanks for your contribution.
Seems that you have another issue with the compatiblity of your 2009 TV model. But we should try not to mix those problems. Both things seem to have a seperate problem type.

smart
11-09-2011, 11:36 AM
Regarding the use of the DLNA.ORG_OP flag, this gives information on the supported advanced transport operations. It consists of two bytes, each are boolean values (0 or 1). First one says if time seek range is supported and second says if range http header is supported.
This is described under 7.3.11.4 in document "Digital Living Network Alliance Home Networked Device Interoperability Guidelines Version: 1.0".

If the Media Server does not support advanced transport streams, TV plays the file. If it supports it, TV does not play it. This does not really make sense, since the TV is not required to make use of advanced transport streams.

There is a document, leaked from DLNA, which gives those details on DLNA standard:
http://www.homemediaserver.ru/files/Doc/DLNA_Interoperability_Guidelines_v1%255B1%255D.0.p df

Just search for ORG_OP, to see the usage of those parameter.

smart
12-02-2011, 11:21 AM
Was the information passed to the development? Is it helpful? Is there an intermediate status of this?
What about the development priorities?

smart
12-12-2011, 09:17 PM
This problem still persists with newest firmware 0.140.44.0.

matthias
02-03-2012, 09:55 AM
Hi,

is this still is an issue?

I just tried to play an XVID on TV file through my Fritzbox 7390 DNLA server (FW 84.04.89), and it worked (also fast forward&backward), so I'm not sure I fully understand the problem.

Do you have a sample video file that I can test it with?


The XVID file:
Video
Format : MPEG-4 Visual
Format profile : Streaming Video@L1
Format settings, BVOP : Yes
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 21mn 45s
Bit rate : 989 Kbps
Width : 624 pixels
Height : 352 pixels
Display aspect ratio : 16/9
Frame rate : 23.976 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.188
Stream size : 154 MiB (88%)
Writing library : XviD 50

smart
02-03-2012, 11:31 AM
Thanks for your interest on this topic, matthias!

I will provide you a video for testing and I will check again with newest firmware 0.140.46.0.

It sounds like you have understood the problem. My xvid files were played when putting it on USB stick, but were not played when providing with Fritzbox 7390 Media server.

At a first rough look, I see a difference in the used codec:
Format-Profil : Advanced Simple@L5
Format-Einstellungen für BVOP : 2

But as far as I have understood the problem, it should be independent of the codec. Since the same xvid file gets played when using Windows Media Server.

Greets

smart
02-04-2012, 10:35 PM
I assume a fix for this problem would require an update of the integrated Opera browser. Assuming Philips purchased also the DLNA option for Opera TV.
Link: http://media.opera.com/media/b2b/tv/Opera-TV-DLNA-option.pdf

matthias
02-04-2012, 10:50 PM
Good question. In that case, which Opera Version do you have? For the 2011 TVs, the Opera useragent is "Opera/9.80 (Linux mips ; U; HbbTV/1.1.1 (; Philips; ; ; ; ) CE-HTML/1.0 NETTV/3.1.0; en) Presto/2.6.33 Version/10.70"

Though I'm not sure they use this (there's no bubbles on startup and no Sicherheitsinformationen in the Options Menu) when using "Play from PC".

But the Fritzbox FW changelog for 84.04.86 says:
- Mediaserver: verbesserte Interoperabilität mit verschiedenen Abspielgeräten (Mediarenderer, DLNA) sowie Dateiformaten

As I have .89 running, maybe AVM solved it in the meantime?
What Fritzbox FW are you using?

smart
02-04-2012, 11:06 PM
I don't think, that AVM did some improvements on this, I have also tried with firmware: 84.04.89 (I have pointed them to this thread and also a ticket open, but it seems moreless to be a bug on TV side).

Currently I'm using 84.05.09-21499. This is the newest beta firmware. In the changelog, there are also comments in improved compatibility to TVs. I always kept both devices on newest firmware and tried with every new configuration.

You are right, regarding the menu, there are no dots and the menu is different. I thought, this might be just changed in this context.

smart
02-04-2012, 11:09 PM
Browser Version should be:
Opera / 9.70 (Linux mips; U; CE-HTML/1.0 (<profilelist><ui_profile name=“PHILIPS_OLS_2010″/></profilelist>); en) Presto/2.2.1

I did not check it by myself, this is from toengels blog.

matthias
02-06-2012, 08:14 AM
Just tried another video (nzm_PureVideo_SDvsHD_AVI_small.avi) to play over Fritzbox on TV, and it also worked.
So it seems, this was either fixed on the 2011 TVs, or my Fritzbox FW version does not send the "Length-0" tag..

MediaInfo on Video:
Format : MPEG-4 Visual
Format profile : Simple@L1
Format settings, BVOP : No
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default
Codec ID : FMP4
Duration : 1mn 0s
Bit rate : 13.8 Mbps
Width : 1920 pixels
Height : 1080 pixels
Display aspect ratio : 16/9
Frame rate : 29.970 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.223
Stream size : 99.1 MiB (99%)
Writing library : Lavc52.55.03

smart
02-06-2012, 09:20 AM
Since I tried it with the same firmware, you are also using on your fritzbox, I think, this is a 2010 TV model issue.

I think, it should not be too hard to fix this. I assume others might experience the same also with other media servers, but do not know, there is an issue and it should work.

smart
02-06-2012, 09:23 AM
I shared the file: nzm_PureVideo_SDvsHD_AVI_small.avi with matthias as it is not working on 2010 TV set when using Fritzbox Media Server, but when using USB or Windows Media Server.