Talk:Media Play and DLNA - Revision history

Ttmcmurry: formatting

2009-10-28T20:54:51Z

formatting

Ttmcmurry: update

2009-10-28T20:53:36Z

update

Ttmcmurry: formatting

2009-10-27T14:58:02Z

formatting

Ttmcmurry: comments.

2009-10-27T14:56:02Z

comments.

Cus1 at 13:46, 27 October 2009

2009-10-27T13:46:09Z

Ttmcmurry: forgot to mention the last point #5.

2009-10-26T19:44:01Z

forgot to mention the last point #5.

Ttmcmurry: formatting

2009-10-26T19:34:09Z

formatting

Ttmcmurry: initial ideas for improvement.

2009-10-26T19:33:06Z

initial ideas for improvement.

New page

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.

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.

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.

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.

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

@@ Line 44: / Line 44: @@
 :56, 27 October 2009 (UTC)<br>
 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... <br>
-Round(MIN(1024*(Level's Maximum Decoder Buffer)/((((WidthX)*(HeightY)/256)*384),16),0 --[[User:ttmcmurry|ttmcmurry]]
+Round(MIN(1024*(Level's Maximum Decoder Buffer)/((((WidthX)*(HeightY)/256)*384),16),0 --[[User:ttmcmurry|ttmcmurry]]<br>
 ''<font color="grey">I was able to update the h.264 article on wikipedia:  http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Reference_Frames'' [[User:Ttmcmurry|Ttmcmurry]] 20:53, 28 October 2009 (UTC)

← Older revision		Revision as of 20:53, 28 October 2009
Line 45:		Line 45:
	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... <br>		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... <br>
	Round(MIN(1024(Level's Maximum Decoder Buffer)/((((WidthX)(HeightY)/256)*384),16),0 --[[User:ttmcmurry\|ttmcmurry]]		Round(MIN(1024(Level's Maximum Decoder Buffer)/((((WidthX)(HeightY)/256)*384),16),0 --[[User:ttmcmurry\|ttmcmurry]]
		+	''<font color="grey">I was able to update the h.264 article on wikipedia: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Reference_Frames'' [[User:Ttmcmurry\|Ttmcmurry]] 20:53, 28 October 2009 (UTC)

@@ Line 13: / Line 13: @@
 ''<font color=grey>I don't really think that general encoding best practices belong here, sorry.</font>
---[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)''
+--[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)''<br>
 ''<font color="grey">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.</font>--[[User:ttmcmurry|ttmcmurry]] 14:56, 27 October 2009 (UTC)

@@ Line 12: / Line 12: @@
 ..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.
+''<font color=grey>I don't really think that general encoding best practices belong here, sorry.</font>
---[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)
+--[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)''
-)  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.
+)  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.<br>
-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.
+''<font color="grey">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.</font>
---[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)
+--[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)''<br>
 )  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.
+''<font color="grey">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.</font>
---[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)
+--[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)''<br>
 )  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.
+''<font color="grey">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.</font>
---[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)
+--[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)''
 )  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.
+''<font color="grey">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.</font>
---[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)
+--[[User:Cus1|Cus1]] 13:46, 27 October 2009 (UTC)''<br>
 I would appreciate any commentary anyone wants to offer on this subject.  The data needs to be more practical.

← Older revision		Revision as of 19:44, 26 October 2009
Line 17:		Line 17:

	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.		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.
		+
		+	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 would appreciate any commentary anyone wants to offer on this subject. The data needs to be more practical.		I would appreciate any commentary anyone wants to offer on this subject. The data needs to be more practical.

@@ Line 3: / Line 3: @@
 )  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:
-- .avi has very limited support for b-frames which doesn't include (in spec) a way to properly handle h.264 b-frames
+- .avi has very limited support for b-frames which doesn't include (in spec) a way to properly handle h.264 b-frames<br>
-- any .avi which contains h.264 is hacked and not spec-compliant
+- any .avi which contains h.264 is hacked and not spec-compliant<br>
-- 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
+- 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<br>
-- just because x264/ffdshow does it, doesn't mean you should too
+- just because x264/ffdshow does it, doesn't mean you should too<br>
-- there are several standard containers which were designed for h.264 and those can more easily be utilized
+- there are several standard containers which were designed for h.264 and those can more easily be utilized<br>
-- encouraging users to create non-compliant containers when appropriate standards exist doesn't make sense
+- encouraging users to create non-compliant containers when appropriate standards exist doesn't make sense<br>
 ..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.