Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#4891 closed defect (invalid)

Enabling VBI for a broader array of drivers and hardware

Reported by: starz909@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: 0.21-fixes
Severity: low Keywords: cc vbi teletext caption subtitle
Cc: Ticket locked: no

Description

Hello everyone,

Currently, the ability to view closed captioning in channels or recordings is highly dependent on the drivers for the recording hardware. With software encoders, this isn't a problem because mythtv offers a dialog box to specify the location of the vbi device node. With hardware encoders, even the common Hauppauge encoders, mythtv relies on the drivers being able to insert vbi data into the mpeg stream, where mythtv will find the data and display it, if the user requests it.

Unfortunately though, few hardware drivers do this well, and some developers choose not to add this feature to their driver code. The popular ivtv driver only does this well for some hardware, and, for example, a developer of v4l's blackbird driver, Michael Krufky, has decided not to implement this feature in the blackbird drivers.

Why? Because the driver, and other similar drivers like ivtv, create a dedicated vbi device node as well, which gives the computer access to the vbi data streaming from the hardware. In Krufky's and my own opinion, this would be a more convenient and stable means of acquiring vbi data for broadcasts.

http://lists.zerezo.com/video4linux/msg20539.html

If mythtv claims it supports decoding CC, which it must since there are menus that allow it to be enabled and configured, then I think it would be more efficient for mythtv to give the user the option of specifying where the vbi data is to be captured -- the mpeg stream, or a dedicated device node.

I was considering an option that is placed in the mythtv-setup menu, under configuring a new hardware encoder card, and when enabled, lets the user specify a location for a vbi device node, and perhaps a slider or box to input a delay or buffer number if the vbi device node is not synched properly with the mpeg node.

I'm not sure how this external vbi data will be recorded with the video nuv file; whether the vbi data should be a separate file linked somehow to the video file, either with the same name or through the database, or if the vbi data should be inside the nuv file, in which case, I'm not sure if a lossless transcoding process will be necessary.

I consider this a workaround or bug fix, and not a feature request, because mythtv is supposed to already decode cc; this is just a means of letting it work for a wider range of devices whose drivers do not, and perhaps will not support slicing vbi data into their mpeg stream - but do provide a functional vbi device node.

Thank you for your patience and for considering this request, Sam

PS. Unfortunately, I do not have programming skills sufficient for this kind of modification, so I cannot propose a patch, but I am willing to help with testing on my free time.

Change History (4)

comment:1 Changed 13 years ago by Isaac Richards

Milestone: 0.21unknown
Resolution: invalid
Status: newclosed

Feature request without patch, and unlikely to be implemented anyway. Capturing the full stream is the drivers job, not myth's.

comment:2 Changed 13 years ago by starz909@…

The driver is doing it's job; it is providing the device nodes for mythtv to use. Mythtv is not doing it's job letting a user specify the proper nodes, if necessary.

Out of respect, I will not remark this as open without consent, but I do wish you would reconsider.

As for a patch - Those are high expectations for someone without sufficient programming knowledge.

Respectfully, Sam

comment:3 Changed 13 years ago by dekarl@…

Sam, I hope I understand that conversation on the list and your request right.

You are asking the mythtv devs to work around bugs in the firmware that the driver writers don't want to handle? It might be easier to just ask the hardware vendor for a working firmware, cause that's what you paid for.

If the vendor won't fix their firmware then it's still more economic to work around the bugs in one place, the driver, instead of every place the vbi data might be consumed (each and every recorder application)

Regards, Karl

comment:4 Changed 13 years ago by starz909@…

I would like to continue this discussion on the mythtv-dev mailing list.

Thank you for your attention, Sam

Note: See TracTickets for help on using tickets.