Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
dlna [2014/03/03 15:21] beandog [DLNA] |
dlna [2014/07/19 00:29] beandog |
||
|---|---|---|---|
| Line 42: | Line 42: | ||
| * Store more details in SQLite database -- number of times played, which media device is requesting, etc. | * Store more details in SQLite database -- number of times played, which media device is requesting, etc. | ||
| * Figure out how resume-playback works -- I'm guessing that the DLNA server makes a request for a starting point | * Figure out how resume-playback works -- I'm guessing that the DLNA server makes a request for a starting point | ||
| + | |||
| + | ==== Best Practices: DLNA ==== | ||
| + | |||
| + | When it comes to encoding video with x264 for embedded devices that do playback (Blu-ray players, Roku, etc.), your **safest bet** is to use little to no advanced H.264 features. The reason being is that you have to assume that the playback software could be dumb as rocks, and throwing some advanced stuff its way may only make playback poor. | ||
| + | |||
| + | General testing with various encoding settings is a reasonable approach, but if you want to keep it safe, focus on changing the CRF or constant bitrate, or the preset, and that's it. That'll give you good quality without taking risks for playback. | ||
