[mythtv] PATCH: TVFormat

[Brad Allen]

While doing a bit of the potential table unification of types I
considered in the above patch submission message, I noticed a
theoretical conflict, but I don't think it will affect anything:

Kernel with typical patch for pcHDTV HD-2000:
----- /usr/{|src/linux/}include/linux/videodev.h
#define VIDEO_MODE_ATSC		4       /* dtv */
----- mythtv-cvs/libs/libmythtv/channel.cpp
    else if (fmt == "ATSC") 
        mode = VIDEO_MODE_ATSC; 
// ...
    else if (fmt == "PAL-M") 
        mode = 4; 
-----


I found it while I was making a potential new frequencies.c.  Here's
the diff I made of that potential new frequencies.c:

================================
--- frequencies.c.~1~	2003-11-21 09:41:24.000000000 -0800
+++ frequencies.c	2004-01-15 18:41:30.000000000 -0800
@@ -1153,3 +1153,20 @@
     { "australia-optus",  pal_australia_optus, CHAN_COUNT(pal_australia_optus) },
     { NULL, NULL, 0 } /* EOF */
 };
+
+/* --------------------------------------------------------------------- */
+
+static struct tvformattypes_t {
+    char *fmt;
+    int v4l2_videomode, v4l_mode;
+} tvformattypes[]={ // V4L2's is bitmapped (great!), whereas V4L's is sequenced
+    { "NTSC",	V4L2_STD_NTSC_M	   /*0x1000*/,	VIDEO_MODE_NTSC /* 1 */ },
+    { "ATSC",	V4L2_STD_ATSC_8_VSB /*0x1000000*/, VIDEO_MODE_ATSC /* 4 */ },
+    { "PAL",	V4L2_STD_PAL	     /*0xFF*/,	VIDEO_MODE_PAL /* 0 */ },
+    { "SECAM",	V4L2_STD_SECAM	 /*0x7F0000*/,	VIDEO_MODE_SECAM /* 2 */ },
+    { "PAL-NC",	V4L2_STD_PAL_Nc	    /*0x400*/,	3 },
+    { "PAL-M",	V4L2_STD_PAL_M	    /*0x100*/,	4 },
+    { "PAL-N",	V4L2_STD_PAL_N	    /*0x200*/,	5 },
+    { "NTSC-JP",V4L2_STD_NTSC_M_JP /*0x2000*/,	6 },
+    { (char*)0,	-1, -1}
+};
================================

V4L2 bitmapped types, which is something I would have done for V4L,
but they weren't very visionary.  Anyway:

The above is just a part of an idea I have; the conflict is still
there and in the main code.  We could remove the conflict possibly.


This brings up bigger questions:  do we want to convert to V4L2's
bitmapped system internally, and then just convert to old V4L when
necessary?


That way, a card could be type "foo", where "foo" is
V4L2_STD_ATSC_8_VSB|V4L2_STD_NTSC_M, which means it has both ATSC &
NTSC on it, which is very much the case with at least one card on the
market, and would solve a coding question about how to handle it
currently in Myth.

Then, internally Myth would consider each item in the list a checkbox
with respect to screens which let you change it, and would convert
that into a bitmapped value which would be stored in mythconverg in
its appropriate location.


Externally, it would interact with V4L in such a way that V4L would
work.


I envision such a change would be done after the next release.  Before
the next release, the most I would consider is just putting up that
table and using it in the four locations that use that data.  A more
conservative approach would be to use a table like above that exactly
mimicks current behavoir wrt the assigned numbers, whether or not it's
buggy or badly conceived.

I also made another minor change to the table above:  I noticed there
is a seperate entry for NTSC & NTSC-JP, and V4L2 also has two entries:
V4L2_STD_NTSC_M & V4L2_STD_NTSC_M_JP respectively.  However, Myth was
using V4L2_STD_NTSC & V4L2_STD_NTSC_M_JP respectively; V4L2_STD_NTSC
is just V4L2_STD_NTSC_M|V4L2_STD_NTSC_M_JP in V4L2.  So, obviously I
changed V4L2_STD_NTSC to V4L2_STD_NTSC_M.

Does Myth actually care what these numbers are elsewhere in the code?
Where?  I'll need to know that if I install this table for actual use
and make the above two changes.  Like I said, a more conservative
approach would be to just use the current values in such a table, and
might be called for if a release is coming up and the above table idea
is implemented before then.

I see they may be used for driver APIs:

./libs/libmythtv/channel.cpp:    tuner.mode = mode;
./libs/libmythtv/channel.cpp:    vc.norm = mode;

that means that in V4L, there is a conflict for two drivers.  For
compatability, we'll have to just use the value that the current
(conflicting) drivers expect, but that's not an issue now because no
one will be using both drivers at the same time?  According to
frequencies.h, PAL & ATSC are not used in the same place (I just
sorted and fgreped the list, and no one uses both NTSC and any type of
PAL, and ATSC is only where NTSC is now AFAIK).

Hey --- MythTV is a big video program, so I bet a lot of you can
answer these questions with more knowledge than me (albeit apparently
with a bit of history of a few bits less of wisdom in assignment
coding principles).