Mailing List Archive: MythTV: Dev

vps once again...

Index | Next | Previous | View Threaded

waggawagga at gmx

Jul 22, 2004, 12:17 PM

Post #1 of 16 (2688 views)
Permalink

vps once again...

hi all,

i just subscribed to the mythtv-dev mailing list and wanted to append to
the former vps thread but since i dont have an email to simply reply to
i have to start a new one. (can anyone tell me how to appand to an
existing thread without having an email of it)

ok now to the reason i'm writing:
i posess a hauppauge winpvr 250 setup allright with mythtv up and
running (took me some time). i live in austria, one of the countries
using the vps signal (besides germany, switzerland and the netherlands,
and 2 chanels in france afaik). i'd like to know if anyone has made any
attempts to include vps support into mythtv, if not i'd like to start to
work on that, anyone who's interested to help is welcome just drop a
line. i found some code like denoted in the earlier vps thread on
http://sourceforge.net/projects/vpsdecode/
it's gpl, but does not yet compile with gcc3.3 (debian/sarge)

btw. does the hauppauge pvr 250 support vbi, as this is mandatory for
receiving vps signals i hope it does.

so long
maestro

mtdean at thirdcontact

Jul 22, 2004, 1:02 PM

Post #2 of 16 (2647 views)
Permalink

Re: vps once again... [In reply to]

maestro wrote:

>i'd like to know if anyone has made any
>attempts to include vps support into mythtv,
>
I don't think so.

>btw. does the hauppauge pvr 250 support vbi, as this is mandatory for
>receiving vps signals i hope it does.
>
>
Hans Verkuil has been doing a significant amount of work on VBI/VPS
support for the PVR-x50 cards using Chris Kennedy's patch series for
ivtv-0.1.10pre2. I recommend checking out ck100b (
http://kmos.org/~ckennedy/ivtv/ivtv-0.1.10-pre2-ck100b.diff ) and
subscribing to the IvyTV ML's (
http://sourceforge.net/mail/?group_id=73219 ) before getting too
involved. You'll probably still have to do some work on Myth, but might
find that the PVR-x50 drivers are ready to go.

IIRC, Myth doesn't currently provide support for VBI/CC with the
PVR-x50's, yet, since the stable version of ivtv (0.1.9) doesn't support
VBI. Therefore, to get the patch accepted into Myth, you'll have to at
least consider drivers that don't support VBI and have a plan for
ensuring that the new code doesn't interfere with users of the stable
driver (or cause a flurry of "why doesn't it work for me" questions on
the list).

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

lucas at mach8

Jul 22, 2004, 1:56 PM

Post #3 of 16 (2654 views)
Permalink

Re: vps once again... [In reply to]

Hey,

> btw. does the hauppauge pvr 250 support vbi, as this is mandatory for
> receiving vps signals i hope it does.

It does. there is some preliminary support already for it in some of the
more recent ck versions of the ivtv driver. If I have the util output
all vps messages I got about 1 every 20 minutes orso, thats all testing
I've done.

Now to get back on topic, how this would properly intergrate into myth
is harder.

Making a recording stop when receiving the next vps is pretty
straightforward. But when do you start? In order to receive vps's you
need to be tuned into the channel. So you should already have a card
listening for vps before the show starts. How much before? an hour? 3
hours? a day?

I'm not that fermilier yet with the mythtv code, so I don't know how
flexible it would be to a completely different way of timing when to
start and stop recording. It would also be a pain to deal with
conflicts. what if the show goes on longer than expected, moving into
the timespace of another show that was supposed to be recorded.

what if you start listening for vps an hour early, but you were too
late? you'll keep on waiting for the vps while you could be recording,
only to find out at the next vps that the show is over..

So technically yes, the pvrx50's can receive vps's, but how to deal with
them from a usability point of view is a whole other can o worms.

Looking forward to bright ideas people might have on this topic.

Bye, Lucas

waggawagga at gmx

Jul 22, 2004, 2:10 PM

Post #4 of 16 (2653 views)
Permalink

Re: vps once again... [In reply to]

thanks mike,

i guess i'll subscirbe to the ivtv dev -mailinglist as i think thats the
right place to get involved with the vbi/vps stuff in the driver, right?

hm im not quite sure if i understand your last paragraph correctly (as
i'm not a native english speaker) i'll try to repeat what you said in my
own words.
please correct me if i misunderstand something.

mythtv doesnot support vbi with x50's since it uses the latest stable
version of the ivtv driver and vbi isnt supported there. so far so good.
and the newer (unstable) version of ivtv is not used (yet). and new code
(in myth) must not interfere with old drivers (e.g. render them
unusable).

if so what about the feature in the appearance setup page that allows to
specify different resolutions for gui and video? this is only available
if xrandr support is available in the x-window system. wouldnt that be a
similar case? vps only available with ivtv driver-version > 0.1.9

if vbi/vps support is in the newer version ivtv drivers as you said,
won't theses drivers new capabilities (most important for me vps
support) be added to mythtv in a near future release?

so long & thanks
maestro

p.s. mythtv missed the last 3 minutes of C.S.I. yesterday, because of
the unpreceise timings given by orf (austrian broadcast company) and
that would be no problem with vps support, so i said to myself
"something has to happen". i hope i'm able to do it, if its not allready
done.

Am Don, den 22.07.2004 schrieb Michael T. Dean um 22:02:
> maestro wrote:
>
> >i'd like to know if anyone has made any
> >attempts to include vps support into mythtv,
> >
> I don't think so.
>
> >btw. does the hauppauge pvr 250 support vbi, as this is mandatory for
> >receiving vps signals i hope it does.
> >
> >
> Hans Verkuil has been doing a significant amount of work on VBI/VPS
> support for the PVR-x50 cards using Chris Kennedy's patch series for
> ivtv-0.1.10pre2. I recommend checking out ck100b (
> http://kmos.org/~ckennedy/ivtv/ivtv-0.1.10-pre2-ck100b.diff ) and
> subscribing to the IvyTV ML's (
> http://sourceforge.net/mail/?group_id=73219 ) before getting too
> involved. You'll probably still have to do some work on Myth, but might
> find that the PVR-x50 drivers are ready to go.
>
> IIRC, Myth doesn't currently provide support for VBI/CC with the
> PVR-x50's, yet, since the stable version of ivtv (0.1.9) doesn't support
> VBI. Therefore, to get the patch accepted into Myth, you'll have to at
> least consider drivers that don't support VBI and have a plan for
> ensuring that the new code doesn't interfere with users of the stable
> driver (or cause a flurry of "why doesn't it work for me" questions on
> the list).
>
> Mike
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

waggawagga at gmx

Jul 22, 2004, 3:20 PM

Post #5 of 16 (2646 views)
Permalink

Re: vps once again... [In reply to]

hi lucas,

here is what jumped to my mind when i read your reply.

Am Don, den 22.07.2004 schrieb Lucas Meijer um 22:56:
> Hey,
>
> > btw. does the hauppauge pvr 250 support vbi, as this is mandatory for
> > receiving vps signals i hope it does.
>
> It does. there is some preliminary support already for it in some of the
> more recent ck versions of the ivtv driver. If I have the util output
> all vps messages I got about 1 every 20 minutes orso, thats all testing
> I've done.
>
> Now to get back on topic, how this would properly intergrate into myth
> is harder.
>
> Making a recording stop when receiving the next vps is pretty
> straightforward.
ACK

> But when do you start? In order to receive vps's you
> need to be tuned into the channel. So you should already have a card
> listening for vps before the show starts. How much before? an hour? 3
> hours? a day?
a trivial solution would be to tune into the channel when recording
should take place according to epg, and listen for the vps, as the
recording would take place from then on without vps that sounds ok for
me. this would miss events when a show starts early, for these cases i
don't know a propper solution, do you know if this is common practice by
the broadcasters?

>
> I'm not that fermilier yet with the mythtv code, so I don't know how
> flexible it would be to a completely different way of timing when to
> start and stop recording.
neither do i.

> It would also be a pain to deal with
> conflicts. what if the show goes on longer than expected, moving into
> the timespace of another show that was supposed to be recorded.
i cant see the problem there, this could be solved by a "simple"
priority scheme like it's allready present right?
>
> what if you start listening for vps an hour early, but you were too
> late? you'll keep on waiting for the vps while you could be recording,
> only to find out at the next vps that the show is over..
hm thats a tough one.
<wild guessing mode>
why not start recording accodring to epg, and chop of the beginning
when receiving a correct vps? as you mentioned before stop recording
because of a vps event would be straitforward problem solved?!
</wgm>
>
> So technically yes, the pvrx50's can receive vps's, but how to deal with
> them from a usability point of view is a whole other can o worms.
>
> Looking forward to bright ideas people might have on this topic.
>
> Bye, Lucas
>
> ______________________________________________________________________
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

martin at martinm-76

Jul 22, 2004, 3:49 PM

Post #6 of 16 (2660 views)
Permalink

Re: vps once again... [In reply to]

I am not sure exactly how VPS/PDC works, but I believe it goes something
like this:

Your point of reference is the time the show *should* start according to
the listings, say 21:00. Along(?) with that they send a value for when
they think it *will* start (maybe this is only PDC, but I think VPS and
PDC are the same..?). If this is true, then theoretically, MythTV could
cycle the channels set to record that day in 'off' periods and update
its VPS info once in a while (possibly user definable. Something like 15
minutes should be fine I think).
There must then be a signal of some kind when the show really does start
but if you have recent VPS/PDC data and no conflicts then start
listening for this signal shortly before it is expected (or if
back-to-back, maybe just start recording? I guess that depends on what
you can see from the VBI datastream).

I hope this is fairly close to reality. I only have TextTV to base it on
where some shows alternate listing time and PDC time... :)

fre, 2004-07-23 kl. 00:20 skrev maestro:
> hi lucas,
>
> here is what jumped to my mind when i read your reply.
>
> Am Don, den 22.07.2004 schrieb Lucas Meijer um 22:56:
> > Hey,
> >
> > > btw. does the hauppauge pvr 250 support vbi, as this is mandatory for
> > > receiving vps signals i hope it does.
> >
> > It does. there is some preliminary support already for it in some of the
> > more recent ck versions of the ivtv driver. If I have the util output
> > all vps messages I got about 1 every 20 minutes orso, thats all testing
> > I've done.
> >
> > Now to get back on topic, how this would properly intergrate into myth
> > is harder.
> >
> > Making a recording stop when receiving the next vps is pretty
> > straightforward.
> ACK
>
> > But when do you start? In order to receive vps's you
> > need to be tuned into the channel. So you should already have a card
> > listening for vps before the show starts. How much before? an hour? 3
> > hours? a day?
> a trivial solution would be to tune into the channel when recording
> should take place according to epg, and listen for the vps, as the
> recording would take place from then on without vps that sounds ok for
> me. this would miss events when a show starts early, for these cases i
> don't know a propper solution, do you know if this is common practice by
> the broadcasters?
>
> >
> > I'm not that fermilier yet with the mythtv code, so I don't know how
> > flexible it would be to a completely different way of timing when to
> > start and stop recording.
> neither do i.
>
> > It would also be a pain to deal with
> > conflicts. what if the show goes on longer than expected, moving into
> > the timespace of another show that was supposed to be recorded.
> i cant see the problem there, this could be solved by a "simple"
> priority scheme like it's allready present right?
> >
> > what if you start listening for vps an hour early, but you were too
> > late? you'll keep on waiting for the vps while you could be recording,
> > only to find out at the next vps that the show is over..
> hm thats a tough one.
> <wild guessing mode>
> why not start recording accodring to epg, and chop of the beginning
> when receiving a correct vps? as you mentioned before stop recording
> because of a vps event would be straitforward problem solved?!
> </wgm>
> >
> > So technically yes, the pvrx50's can receive vps's, but how to deal with
> > them from a usability point of view is a whole other can o worms.
> >
> > Looking forward to bright ideas people might have on this topic.
> >
> > Bye, Lucas
> >
> > ______________________________________________________________________
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev [at] mythtv
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
> ______________________________________________________________________
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Jul 22, 2004, 4:23 PM

Post #7 of 16 (2649 views)
Permalink

Re: vps once again... [In reply to]

maestro wrote:

>i guess i'll subscirbe to the ivtv dev -mailinglist as i think thats the
>right place to get involved with the vbi/vps stuff in the driver, right?
>
>
Yes, but I would recommend signing up for the others, too. The ivtv-cvs
list never gets used (has had 2 messages so far), and the ivtv-users is
relatively low-volume (264 messages compared to ivtv-devel's 12078
messages). That means that signing up for all three messages will
result in only a negligible increase in messages, but prevent you from
missing that one all-important message that's invariably on the list you
don't receive.

>hm im not quite sure if i understand your last paragraph correctly (as
>i'm not a native english speaker)
>
I am a native english speaker, but that doesn't mean that my words
always mean what I want them to mean. (In other words, it's probably
more my fault for not explaining things properly than your fault. ;)

>i'll try to repeat what you said in my own words.
>please correct me if i misunderstand something.
>
>mythtv doesnot support vbi with x50's since it uses the latest stable
>version of the ivtv driver and vbi isnt supported there.
>
Basically. Although a user can choose to use any version of the ivtv
drivers (I'm using ivtv-0.1.10pre2-ck100b, for example), MythTV was
written to support users of the stable version of the ivtv drivers.

>so far so good.
>and the newer (unstable) version of ivtv is not used (yet). and new code
>(in myth) must not interfere with old drivers (e.g. render them
>unusable).
>
>if so what about the feature in the appearance setup page that allows to
>specify different resolutions for gui and video? this is only available
>if xrandr support is available in the x-window system. wouldnt that be a
>similar case? vps only available with ivtv driver-version > 0.1.9
>
>if vbi/vps support is in the newer version ivtv drivers as you said,
>won't theses drivers new capabilities (most important for me vps
>support) be added to mythtv in a near future release?
>
>
Yes. This is true. However, (and this purely conjecture based on
interactions I've observed on the ivtv and Myth ML's), until ivtv
releases a "stable" 0.1.10 version (i.e. a version that is intended for
general use by all end users, for distribution by packagers, and for use
as a basis of development in other projects), MythTV is being developed
for use with ivtv 0.1.9. That doesn't mean that the primary Myth
developers don't know about the other features available in newer
versions of ivtv--many of them are subscribed to the IvyTV ML's. As a
matter of fact, many--including Isaac--have been known to contribute to
the IvyTV ML's--in many cases to ensure that ivtv driver development
proceeds in such a way that a 0.1.10 release will be compatible with
current versions of MythTV while allowing future versions of MythTV to
include new features.

In other words, Chris Kennedy has released hundreds of patches. For
example, the version I'm using is ck100b; Chris has released versions
ck1 through ck10--without skipping any numbers--each of which has had
several (up to 26) letter releases. Throughout these releases there
have been changes which make the drivers better, and changes which make
the drivers worse. For example, Chris actually has versions ck100c and
ck100d available, but these are less stable and less functional with
Myth than ck100b. Knowing which version to use requires a lot of
homework on the end-user's part, so Isaac, et. al., want to ensure that
MythTV users can just install ivtv 0.1.9 if they're more interested in a
working PVR than in actively following development of the ivtv drivers.

Also, among these driver releases, there have been many changes to the
API (the calls other programs make to the drivers to interact with the
cards), the tools (i.e. test_ioctl has become ivtvctl), the module
options (i.e. the newest versions auto-detect everything--and
surprisingly accurately, believe it or not), and more. Because of all
these changes, the MythTV developers want to ensure that before a
feature is added to Myth, that feature will still be available in future
versions of the ivtv driver and the means by which that feature is
accessed will remain (relatively) constant (so we don't have
MythTV-0.15.1-ck100b releases :).

So, for all practical purposes, ivtv-0.1.9 is the most current driver
version available because all other versions are development versions
not intended for general use. So, if you can create VPS support that
has no effect on users of the 0.1.9 drivers (not to mention users of
non-ivtv-based cards) but that just works if the VPS data is available
(possibly with a switch to enable/disable VPS support), you might be
able to convince the main developers to include that patch in the main
branch. Otherwise, you might have to wait for ivtv-0.1.10 (or ivtv
0.2.0). Also, I think the BTTV cards support VBI, so in theory, if you
write the VPS code generically enough, it can be used for BTTV cards and
for PVR-x50's.

>p.s. mythtv missed the last 3 minutes of C.S.I. yesterday, because of
>the unpreceise timings given by orf (austrian broadcast company) and
>that would be no problem with vps support, so i said to myself
>"something has to happen". i hope i'm able to do it, if its not allready
>done.
>
>
I'm sure many others will be indebted to you for the work you plan to
do. After all, CSI just isn't CSI if you don't hear Grissom's final
one-liner and see him shaking his head in bewilderment as the
perpetrator gets dragged away by the cops.

Mike

BTW, you'll make many more friends on this list if you reply to a post
by adding to the bottom (bottom-posting) or by responding to parts of a
post "inline" as I did. And, it's always a good idea to trim the
extraneous material from previous messages.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

hpoley at dds

Jul 23, 2004, 2:04 AM

Post #8 of 16 (2638 views)
Permalink

Re: vps once again... [In reply to]

Op donderdag 22 juli 2004 22:56, schreef Lucas Meijer:
> > btw. does the hauppauge pvr 250 support vbi, as this is mandatory for
> > receiving vps signals i hope it does.
<snip>
> Making a recording stop when receiving the next vps is pretty
> straightforward. But when do you start? In order to receive vps's you
> need to be tuned into the channel. So you should already have a card
> listening for vps before the show starts. How much before? an hour? 3
> hours? a day?

By the standard, a day (if i'm informed correctly). And from your other
remarks I suspect you already knew that ;)

Henk Poley <><
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

lucas at mach8

Jul 23, 2004, 2:22 AM

Post #9 of 16 (2644 views)
Permalink

Re: vps once again... [In reply to]

>>Making a recording stop when receiving the next vps is pretty
>>straightforward. But when do you start? In order to receive vps's you
>>need to be tuned into the channel. So you should already have a card
>>listening for vps before the show starts. How much before? an hour? 3
>>hours? a day?
>
> By the standard, a day (if i'm informed correctly). And from your other
> remarks I suspect you already knew that ;)

Actually I didn't. The problem I see is just how to code this into myth.
What if we have a card listening for the vps, but then a user starts
watching livetv on another channel? or when I have 3 recordings
scheduled on one day, each on a different channel. One at 16:00, one at
18:00 and one at 20:00.. I would need 3 cards in order to detect the
vps's..

All those worries aside, I think the suggestion mentioned previously
isn't a bad one at all: Since programs usually get scheduled later
instead of earlier, just start recording say 10 minutes before the
program is supposed to start, and when you receive the vps, set a marker
there (or cut it already right there, not sure if thats possible).

I think I can easily live with not supporting vps when a program moves
to an earlier time.

Another concern would be on what to do if the program gets moved an hour
back, and because of that now conflicts with another (possible also
vps'd) recording.

Ugh.. brain hurts :p

Bye, Lucas

hpoley at dds

Jul 23, 2004, 2:51 AM

Post #10 of 16 (2637 views)
Permalink

Re: vps once again... [In reply to]

Op vrijdag 23 juli 2004 11:22, schreef Lucas Meijer:
> >>Making a recording stop when receiving the next vps is pretty
> >>straightforward. But when do you start? In order to receive vps's you
> >>need to be tuned into the channel. So you should already have a card
> >>listening for vps before the show starts. How much before? an hour? 3
> >>hours? a day?
> >
> > By the standard, a day (if i'm informed correctly). And from your other
> > remarks I suspect you already knew that ;)
>
> Actually I didn't.

Google for 'VBI (PDS OR VPC)' and you can find out more than you would ever
want :>

> The problem I see is just how to code this into myth.
> What if we have a card listening for the vps, but then a user starts
> watching livetv on another channel? or when I have 3 recordings
> scheduled on one day, each on a different channel. One at 16:00, one at
> 18:00 and one at 20:00.. I would need 3 cards in order to detect the
> vps's..

Yups, though VPS/PDC is retransmitted every .. , dependant on channel, 5
minutes seems to be normal if I remember correctly, which might well not be
the case.

> Another concern would be on what to do if the program gets moved an hour
> back, and because of that now conflicts with another (possible also
> vps'd) recording.

Well that's something for the scheduler, just 're-run' it when some data
changes. btw, off topic, but I'm away for 10 days in a minute or so. Have a
nice discussion.

Henk Poley <><
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

waggawagga at gmx

Jul 23, 2004, 10:31 AM

Post #11 of 16 (2634 views)
Permalink

Re: vps once again... [In reply to]

Am Fre, den 23.07.2004 schrieb Michael T. Dean um 01:23:

> Yes, but I would recommend signing up for the others, too.
hm guess you're right. done that.

> Basically. Although a user can choose to use any version of the ivtv
> drivers (I'm using ivtv-0.1.10pre2-ck100b, for example), MythTV was
> written to support users of the stable version of the ivtv drivers.
ok got that.

> ... until ivtv
> releases a "stable" 0.1.10 version (i.e. a version that is intended for
> general use by all end users, for distribution by packagers, and for use
> as a basis of development in other projects), MythTV is being developed
> for use with ivtv 0.1.9.
i know it belongs to the ivtv mailing list but you seem to have (a
little) insight there: do you have any infos when such a stable release
will happen,
and won't it be 0.2 since in the readme states 0.1 isn't developed
actively anymore. (i think that interferes with ck's efforts doesnt it?)

> Knowing which version to use requires a lot of
> homework on the end-user's part, so Isaac, et. al., want to ensure that
> MythTV users can just install ivtv 0.1.9 if they're more interested in a
> working PVR than in actively following development of the ivtv drivers.
seems reasonable to me.

> Also, among these driver releases, there have been many changes to the
> API (the calls other programs make to the drivers to interact with the
> cards),
stable api is always good, means less work if the api doesnt change.

>
> So, for all practical purposes, ivtv-0.1.9 is the most current driver
> version available because all other versions are development versions
> not intended for general use. So, if you can create VPS support that
> has no effect on users of the 0.1.9 drivers (not to mention users of
> non-ivtv-based cards) but that just works if the VPS data is available
> (possibly with a switch to enable/disable VPS support), you might be
> able to convince the main developers to include that patch in the main
> branch. Otherwise, you might have to wait for ivtv-0.1.10 (or ivtv
> 0.2.0). Also, I think the BTTV cards support VBI, so in theory, if you
> write the VPS code generically enough, it can be used for BTTV cards and
> for PVR-x50's.
hm it seems as if the vbi support in the newer ivtv drivers is already implemented.
i posted a msg on the ivtv list on this topic and awaiting answers.
so if it would be (re) implemented to work with 0.1.9 and mythtv it
would probably only live until ivtv > 0.1.9 is released, (because it
will then be supported by the driver) the mythtv - changes may persist
if they work with the new drivers or will need to be reimplemented. that
sounds like doing work twice doesn't it?

> BTW, you'll make many more friends on this list if you reply to a post
> by adding to the bottom (bottom-posting) or by responding to parts of a
> post "inline" as I did. And, it's always a good idea to trim the
> extraneous material from previous messages.
thanks for the hint. i'll try to bear this in mind for my future
postings (guess this one's ok?!)

so long
manuel

lists at kenneth

Jul 24, 2004, 4:20 PM

Post #12 of 16 (2616 views)
Permalink

Re: vps once again... [In reply to]

On Friday 23 July 2004 11:04, Henk Poley wrote:
> Op donderdag 22 juli 2004 22:56, schreef Lucas Meijer:
> > > btw. does the hauppauge pvr 250 support vbi, as this is mandatory for
> > > receiving vps signals i hope it does.
>
> <snip>
>
> > Making a recording stop when receiving the next vps is pretty
> > straightforward. But when do you start? In order to receive vps's you
> > need to be tuned into the channel. So you should already have a card
> > listening for vps before the show starts. How much before? an hour? 3
> > hours? a day?
>
> By the standard, a day (if i'm informed correctly). And from your other
> remarks I suspect you already knew that ;)

Don't know if you noticed, but the vbidec.cpp of my new experimental dvb patch
has a stub for vps decoding, have a look at line 578, and give me a word if
you want info or help decoding it.

Kenneth
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

waggawagga at gmx

Jul 25, 2004, 12:17 PM

Post #13 of 16 (2611 views)
Permalink

Re: vps once again... [In reply to]

> Don't know if you noticed, but the vbidec.cpp of my new experimental dvb patch
> has a stub for vps decoding, have a look at line 578, and give me a word if
> you want info or help decoding it.

sorry for not answering quicker, i just installed a new ivtv driver
where vps is supported (using ck100b like michael does) and inspected
the vbi sample program.
any additional info to your code is greatly appreciated as i think it
enhances the likelyhood of the stuff i'm trying to do getting applied to
mythtv one day, when it's done in a similar way as someone else did.

i'll try to take a look at your code this evening, so i have a base of
discussion.

so long & thanks
manuel

waggawagga at gmx

Jul 27, 2004, 12:06 PM

Post #14 of 16 (2595 views)
Permalink

Re: vps once again... [In reply to]

Am Son, den 25.07.2004 schrieb Kenneth Aafl�y um 01:20:
> Don't know if you noticed, but the vbidec.cpp of my new experimental dvb patch
> has a stub for vps decoding, have a look at line 578, and give me a word if
> you want info or help decoding it.
>
> Kenneth

ok so i downloaded your patch and applied it to current cvs. then i
started to inspect the vbidec.cpp file as you mentioned.
i'd really like to get the vps feature going and vps decoding is done
allready in the vbi.c example programm that comes with newer
ivtv-drivers. (i'm using ck100b) but i cannot see the correlation
between these two pieces of code.

as far as i can reconstruct <please correct me if i'm wrong>
some piece of code calls the processPesPkt method of a vbidecoder object
where the uint8_t *buf parameter contains the actual vbi data provided
by the/any driver (that has vbi support ivtv > 0.1.9, bttv...)
uppon that the buffer is sanity-checked and processPesPktData is called
that constructs a teletext-page out of the buf.
am i getting this right?

to implement vps support, would it be the best/correct way to create a
new class (maybe VpsInfo, like TeletextPage) that holds current vps data
for the current channel, and add a method (like in vbi.c from ivtv
driver) that extracts readable/usable data from the buf that is provided
by the calling piece of code.

once again, i really want to do this, and if you would help me getting a
start with it, it would for sure be much easier for me to do.
i run this email-exchange to enlarge my knowledge about mythtv (which i
think is a great project btw) so please feel free and do correct me if i
got anything/everything wrong.

so long
manuel

p.s. please excuse my bad english, i'm a not a native english speaker,
but trying my best.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

lists at kenneth

Jul 28, 2004, 9:31 AM

Post #15 of 16 (2578 views)
Permalink

Re: vps once again... [In reply to]

On Tuesday 27 July 2004 21:06, maestro wrote:
> ok so i downloaded your patch and applied it to current cvs. then i
> started to inspect the vbidec.cpp file as you mentioned.
> i'd really like to get the vps feature going and vps decoding is done
> allready in the vbi.c example programm that comes with newer
> ivtv-drivers. (i'm using ck100b) but i cannot see the correlation
> between these two pieces of code.

I had a quick look at this code, but I could not see any decoding of the VPS.
But it does show how to aquire various VBI data.

> as far as i can reconstruct <please correct me if i'm wrong>
> some piece of code calls the processPesPkt method of a vbidecoder object
> where the uint8_t *buf parameter contains the actual vbi data provided
> by the/any driver (that has vbi support ivtv > 0.1.9, bttv...)

This buffer is coming from the AvFormatDecoder, which handles the MPEG2
decoding. This buffer is defined in EN 301 775 (Vbi data in dvb) and contains
many vbi data lines. What this function does is to demux it, and feed the
teletext line data to the teletext decoding function. There are also stubs to
mux vps/wss/cc and so on to other decoder functions, but I have not seen
these data types yet, hence no point for me to decode them.

> uppon that the buffer is sanity-checked and processPesPktData is called
> that constructs a teletext-page out of the buf.
> am i getting this right?

What I would do, is to add a function similar to the processPesPktData to
demux the data from the ivtv vbi device. It would look something like the
process function of the example vbi.c. Then you would make a VPS
decoding/parser function similar to the ::line function that would be general
enough to suit data from both ivtv and dvb.

Right now, this VbiDecoder is only suited to be placed on the frontend. Since
the VPS really is backend related, I would like to see this beeing
implemented outside it, or better, that the decoder would be told if it lives
on the backend or frontend. I also want to make an extension to it so that
teletext data can be muxed out of a recording and be transmitted as an extra
stream, and that only recording related stuff such as subtitles/wss/cc is
ever stored in a recording.

> to implement vps support, would it be the best/correct way to create a
> new class (maybe VpsInfo, like TeletextPage) that holds current vps data
> for the current channel, and add a method (like in vbi.c from ivtv
> driver) that extracts readable/usable data from the buf that is provided
> by the calling piece of code.
[snip]

I would say that VPS info should be sent to the Scheduler, so that it can try
to match it's own recording list to the info that VPS sends. With a general
interface to feed data to the Scheduler and decoding of the line data in
VbiDecoder, this should be very easy to expand to other data types.

I find these documents valuable (all can be downloaded www.etsi.org):
EN 300 472 - Teletext in DVB
EN 301 775 - VBI Data in DVB
EN 300 231 - Video Programming System
EN 300 294 - Wide Screen Signalling

Hope this helps.

Kenneth
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

waggawagga at gmx

Jul 28, 2004, 1:17 PM

Post #16 of 16 (2580 views)
Permalink

Re: vps once again... [In reply to]

> I had a quick look at this code, but I could not see any decoding of the VPS.
> But it does show how to aquire various VBI data.

well i used the word decode as it appears in the function name
"decode_vps" and since binary vbi information is displayed as human
readable datetime information. (as i allready said im not an english
native speaker)

> This buffer is coming from the AvFormatDecoder, which handles the MPEG2
> decoding. This buffer is defined in EN 301 775 (Vbi data in dvb) and contains
> many vbi data lines. What this function does is to demux it, and feed the
> teletext line data to the teletext decoding function. There are also stubs to
> mux vps/wss/cc and so on to other decoder functions, but I have not seen
> these data types yet, hence no point for me to decode them.
does this mean, that your teletext function only works for vbi data that
comes with dvb signals and thus does not work for cards like pvr's and
bttv based cards? i assume its working with them aswell, but to know for
sure is always better.

>
> What I would do, is to add a function similar to the processPesPktData to
> demux the data from the ivtv vbi device. It would look something like the
> process function of the example vbi.c. Then you would make a VPS
> decoding/parser function similar to the ::line function that would be general
> enough to suit data from both ivtv and dvb.

so do you suggest that i insert my code into your codebase and create my
own patchset (based on mythtv cvs, and your patchset)?
>
> Right now, this VbiDecoder is only suited to be placed on the frontend. Since
> the VPS really is backend related, I would like to see this beeing
> implemented outside it, or better, that the decoder would be told if it lives
> on the backend or frontend. I also want to make an extension to it so that
> teletext data can be muxed out of a recording and be transmitted as an extra
> stream, and that only recording related stuff such as subtitles/wss/cc is
> ever stored in a recording.
>
> I would say that VPS info should be sent to the Scheduler, so that it can try
> to match it's own recording list to the info that VPS sends. With a general
> interface to feed data to the Scheduler and decoding of the line data in
> VbiDecoder, this should be very easy to expand to other data types.
if i get this right, it would make me append some function to the
scheduler that accepts (retreives) vps-data that matches a current show.
(e.g. the scheduler collects vps information when it is supposed to
start a new recording)
>
> I find these documents valuable (all can be downloaded www.etsi.org):
> EN 300 472 - Teletext in DVB
> EN 301 775 - VBI Data in DVB
> EN 300 231 - Video Programming System
> EN 300 294 - Wide Screen Signalling
thanks i'll take a look at them.
>
> Hope this helps.
>
me aswell
manuel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads