[gupnp-dlna] Update TODOs.



commit f04023aea645f55b05d7b37a376f2d281b5ff315
Author: Krzesimir Nowak <krnowak openismus com>
Date:   Thu Nov 15 15:43:06 2012 +0100

    Update TODOs.

 TODO     |   87 ++++++++++++++++++--------------------------------------------
 TODO.old |   62 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 87 insertions(+), 62 deletions(-)
---
diff --git a/TODO b/TODO
index 4fe6f15..7d76a8a 100644
--- a/TODO
+++ b/TODO
@@ -1,62 +1,25 @@
-This is a list of things that need to be addressed yet.
-
-In gupnp-dlna:
-----
-
-* Encoding still needs quite a bit of testing.
-
-* Speaking of testing, some automated tests would be nice. Right now, there are
-  a bunch of corner cases in tests/xml which can be run through the parser with
-  tests/dlna-profile-parser, and we make sure it doesn't crash.
-
-* A set of (non-copyright-encombered) media for each profile would be aces. One
-  way of getting this would be to use encodebin once the issues above are
-  resolved, but these must go through some manual verification as well.
-
-* We don't have a way of checking the system bitratem.
-
-* We're not checking channel maps, or verifying that 6 channels is actually
-  5.1, etc.
-
-* It would be nice to have the bitrate check to be intelligent enough to work
-  with either bitrate or maximum-bitrate, whichever is available. For example,
-  if the restriction specifies that bitrate = 1-128000, and the stream has no
-  bitrate tag, but does have maximum-bitrate = 112000, it should be matched
-  anyway.
-
-* And, of course, MOAR PROFILES!!111!
-
-Outside gupnp-dlna (mostly GStreamer):
-----
-
-* Bitrate for AAC ADTS streams - there is no stream header, and guessing the
-  bitrate based on the first few frames (as is done in aacparse), can be wildly
-  inaccurate.
-
-* HE-AAC support. There isn't any code around for HE-AAC support at all. We
-  need to detect both implicitly and explicitly signaled HE-AAC before we can
-  support these streams. There's a detailed explanation of the problem at:
-  https://bugzilla.gnome.org/show_bug.cgi?id=612312#c7
-
-* Encoding needs a way for properties such as bitrate to be passed to the
-  encoder from encodebin. Edward has a plan for this.
-
-* Bitrate/profile/level are not exported by MPEG-TS streams.
-
-
-More on encoding
-----
-
-Jotting down discussion on the encoding API. This is not necessarily final.
-
-1. Rygel fetches list of DLNA profile names that it should offer to transcode
-   to from config
-2. Rygel asks gupnp-dlna for list of all supported profiles
-3. Rygel filters that list against the profiles that config has asked for
-4. Rygel sorts the filtered list by "distance" from the streams
-   GUPnPDLNAInformation
-
-Here distance is a metric of transcoding "difficulty" (shorter distance =>
-easier to transcode). Basically:
-
-transmuxing < audio transcode < video transcode < audio+video transcode
+* Prepare native sets API for exposing into public. This needs to have
+  a bit of thought as we probably will want to expose only read-only
+  API. Also we probably don't want to expose every gory detail of sets
+  implementation. For GObject introspection purposes the exposed
+  classes will need to be boxed into GTypes.
+
+* Merge native profile backend into GUPnPDLNAProfile and
+  GUPnPDLNAProfileGuesser. That way we can get rid of
+  GUPnPDLNAProfileGuesserImpl and some backend files, expose profile's
+  restrictions and rename GUPnPDLNANativeFoo into GUPnPDLNAFoo. Also
+  we could extend gupnp-dlna-info-2.0 and gupnp-dlna-ls-profiles-2.0
+  to show more information about DLNA profiles.
+
+* More about extending tools - gupnp-dlna-info-2.0 could show DLNA
+  profiles restrictions (likely) and discovered metadata attributes
+  (bit unlikely, but dunno). gupnp-dlna-ls-profiles-2.0 could show
+  restrictions of listed DLNA profiles.
+
+* Write a GStreamer-only utility for creating a GstEncodingProfile
+  from GUPnPDLNAProfile. That could be easily done when above points
+  are done.
+
+* Bring the tests back to life. And make them being run on make check.
+
+* Read TODO.old for some ideas.
diff --git a/TODO.old b/TODO.old
new file mode 100644
index 0000000..4fe6f15
--- /dev/null
+++ b/TODO.old
@@ -0,0 +1,62 @@
+This is a list of things that need to be addressed yet.
+
+In gupnp-dlna:
+----
+
+* Encoding still needs quite a bit of testing.
+
+* Speaking of testing, some automated tests would be nice. Right now, there are
+  a bunch of corner cases in tests/xml which can be run through the parser with
+  tests/dlna-profile-parser, and we make sure it doesn't crash.
+
+* A set of (non-copyright-encombered) media for each profile would be aces. One
+  way of getting this would be to use encodebin once the issues above are
+  resolved, but these must go through some manual verification as well.
+
+* We don't have a way of checking the system bitratem.
+
+* We're not checking channel maps, or verifying that 6 channels is actually
+  5.1, etc.
+
+* It would be nice to have the bitrate check to be intelligent enough to work
+  with either bitrate or maximum-bitrate, whichever is available. For example,
+  if the restriction specifies that bitrate = 1-128000, and the stream has no
+  bitrate tag, but does have maximum-bitrate = 112000, it should be matched
+  anyway.
+
+* And, of course, MOAR PROFILES!!111!
+
+Outside gupnp-dlna (mostly GStreamer):
+----
+
+* Bitrate for AAC ADTS streams - there is no stream header, and guessing the
+  bitrate based on the first few frames (as is done in aacparse), can be wildly
+  inaccurate.
+
+* HE-AAC support. There isn't any code around for HE-AAC support at all. We
+  need to detect both implicitly and explicitly signaled HE-AAC before we can
+  support these streams. There's a detailed explanation of the problem at:
+  https://bugzilla.gnome.org/show_bug.cgi?id=612312#c7
+
+* Encoding needs a way for properties such as bitrate to be passed to the
+  encoder from encodebin. Edward has a plan for this.
+
+* Bitrate/profile/level are not exported by MPEG-TS streams.
+
+
+More on encoding
+----
+
+Jotting down discussion on the encoding API. This is not necessarily final.
+
+1. Rygel fetches list of DLNA profile names that it should offer to transcode
+   to from config
+2. Rygel asks gupnp-dlna for list of all supported profiles
+3. Rygel filters that list against the profiles that config has asked for
+4. Rygel sorts the filtered list by "distance" from the streams
+   GUPnPDLNAInformation
+
+Here distance is a metric of transcoding "difficulty" (shorter distance =>
+easier to transcode). Basically:
+
+transmuxing < audio transcode < video transcode < audio+video transcode



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]