Talk:Media Play and DLNA

I wanted to start a discussion on this page to clarify some of the information on it.

1) Support for h.264 inside an .avi container is a BadThing™ and falls in to the "yeah, it's possible to do this, but why would you?" category of things. My rationale is to recommend users not do this as it's generally a bad idea to advise the average user to hack standards for the following reasons:

1 - .avi has very limited support for b-frames which doesn't include (in spec) a way to properly handle h.264 b-frames
2 - any .avi which contains h.264 is hacked and not spec-compliant
3 - CE devices will not play h.264-in-avi without using non-compliant hacks. most vendors will not release software to intentionally play hacked formats due to compatibility/security/stability/legal reasons
4 - just because x264/ffdshow does it, doesn't mean you should too
5 - there are several standard containers which were designed for h.264 and those can more easily be utilized
6 - encouraging users to create non-compliant containers when appropriate standards exist doesn't make sense

..in summary, even though Samsung says they support this, we should mention this is a "not recommended" practice. I don't want to offend anyone (someone in particular, :-D ) - it's wiser to think-forward and err on the side of compatibility instead of using a hack. After the last 10 years in the IT industry, my experience says hack=bad. Make things do what they are designed & intended to do.

I don't really think that general encoding best practices belong here, sorry. --Cus1 13:46, 27 October 2009 (UTC)
To me, it's relevant reason enough to remove anything that is non-standard. I'm not saying 'this is how to encode,' rather, this reason enough it shouldn't even be mentioned there is h.264 support in avi containers.--ttmcmurry 14:56, 27 October 2009 (UTC)

2) It would probably be wise to have both the main "supported formats" list as a reference (i.e. at the end of the page), whilst having a more practical chart higher up on the page. The first chart would list the video codec first, maximum resolutions, codec-specific information, audio codec info, followed by applicable industry-accepted container formats.

I see what you mean, however the inserted chart is more or less official (the formats are definitely are, I am not sure about the bit rates and the resolutions), and follows the structure of the chart of supported formats in the Samsung TV manuals / homepage. Yes, it may be better to group the supported formats by the video codecs, and not by the containers. --Cus1 13:46, 27 October 2009 (UTC)
Agreed. --ttmcmurry 14:56, 27 October 2009 (UTC)

3) There should probably be a separate encoding chart which addresses each codec at necessary increments. For example, using h.264 with a CE target such as a high-definition TV, XBox360, or PS3, one should use High Profile (HP) level 4 or 4.1 for encoding at 720p or 1080i/p. The chart on the page doesn't address what CE targets are. Should the information on the chart is taken literally, someone might get the (wrong) impression that Baseline Profile (BP) or Main Profile (MP) is appropriate for hi-def content. Sure, you can do it, but the quality will be worse and will achieve a much larger encode than what HP can product.

Encoding best practices for other CE is not relevant here, only encoding best practices for Samsung TV-s are. So I suggest you create a page where you describe encoding best practices for Samsung TV-s keeping in mind the standards (what is not a hack to do :)), what the TV supports and for what resolutions which profiles should be used. --Cus1 13:46, 27 October 2009 (UTC)
I sort-of agree here, the Samsung TV *is* a CE device. In terms of h.264 encoding all devices adhere to a maximum level, so with that in mind, it wouldn't make any sense to advertise using HP 5 to encode and expect it to work; simultaneously no other home entertainment devices support that level anyway. However, PS3 and XBox360 support HP Level 4.1; should Samsung TVs also support HP 4.1, then I'd use 4.1 as the most compatible target and give a notable mention about compatibility with other CE targets. --ttmcmurry 14:56, 27 October 2009 (UTC)

4) It would be very useful if someone had a document describing the characteristics of the codecs the Samsung HDTVs support. For example, when using h.263 (DivX/XviD), does it support all DivX profiles or only a subset? Does it support h.264 up to HP 4.1 or higher/lower? What are the valid options for .wmv encoding (v9/v10? - vc1 compliance)? Most of the questions I have concerning audio support is defined by the container being used and doesn't require any research.

Absolutely. Unfortunately this kind of information is not known, one should contact Samsung to get it, or do thorough tests with the TV-s to figure it out. --Cus1 13:46, 27 October 2009 (UTC)

5) There is duplicate information in the chart as it is now. Referencing "MPEG-4 SP/ASP" is duplicitive of DivX/XviD; they're all h.263. Much of this information needs to be disambiguated.

I didn't know that, and probably more people heard about DivX than MPEG-4 SP/ASP. So even if you merge these codecs, you should also keep the more famous names (DivX, XviD) of them. --Cus1 13:46, 27 October 2009 (UTC)
Agreed. --ttmcmurry 14:56, 27 October 2009 (UTC)

I would appreciate any commentary anyone wants to offer on this subject. The data needs to be more practical.

---

14:56, 27 October 2009 (UTC)
I'm going to *attempt* to update the wikipedia entry for h.264, section about maximum reference frame examples. we'll see how that goes. The information on the included chart is a little misleading if interpreted literally; the actual formula should be provided so people can work out the answer on their own. The forumla in english is...
Round(MIN(1024*(Level's Maximum Decoder Buffer)/((((WidthX)*(HeightY)/256)*384),16),0 --ttmcmurry
I was able to update the h.264 article on wikipedia: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Reference_Frames Ttmcmurry 20:53, 28 October 2009 (UTC)