• 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 16
Solved Update FFMPEG To Support ATSC Closed Captions
#46
(2014-11-26, 19:47)FernetMenta Wrote:
(2014-11-26, 12:59)xbmclinuxuser Wrote: I don't know if that matters in the slightest to you guys, but law or no law I just wish that if the ffmpeg developers don't deliver real soon now, that at some point in the near future you'd do the right thing and stop waiting for them, if that's what is happening.

Are you visually impaired or why do you ignore my post above? Instead you pull out some statement not even related to the topic of this thread.

I ended that quote with "if that's what is happening" because I honestly don't know what the holdup is. In reading this thread I get the sense that one of three things is happening here:

  1. The developers are waiting for the ffmpeg people to do SOMETHING, although I don't know what, exactly.
  2. The developers just don't want to add closed caption support, for whatever reason. Or they want to do it "someday", which is sort of the same thing. Either way, there is no sense that this is something that should be added relatively soon because it's the right thing to do.
  3. No one on the current development team can figure out how to add this.

Now perhaps I misread or misunderstood the part about ffmpeg, or entirely missed the real reason for the delay. I'm not at all sure what the issue really is. I could speculate further, but I'm sure the more I speculated on why I think this might be happening and why there is such hostility toward this request, the angrier you and some others would probably get, so I think it would probably be best if I just shut up now.

EDIT: Memphiz posted his response while I was writing this, and after reading that I added point #3 in the above list, which I think may be closest to the truth.
#47
(2014-11-07, 18:06)FernetMenta Wrote: ffmpeg supports extraction of CC. now we would need some libass like lib which creates a bitmap from the low level cc instructions which are like this: print character T at pos x,y.

One last pointer to you (as you really seem to not have read this or understand this).

This basically means - we are not waiting on ffmpeg anymore - thats as much as we will get from ffmpeg. So what we have now is the possiblity to get the CC data (which is something like "which text, at start time, and how long to display at position x,y" - a guess - i didn't check the API).

As pointed out we normally rely on third party libraries (for ass subtitles libass for example) to make something out of this data so we can render it on the screen. This peace of code is now still missing. I know this is all like "why is this so hard - sounds pretty easy" - but we can't describe it in any better way to non-developers. And no - we most likely can't use the same approach that vlc or mythtv uses.

And nobody wanting to work on this is similar to nobody is able to do this Wink - at least the result from users few is identical (you don't have your feature at the end).

Also it might just be a couple of lines of code which are missing now - i don't know and it doesn't help it.
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
#48
(2014-11-27, 11:46)Memphiz Wrote: The Dev who might know exactly what needs to be done is MIA.

Memphiz, I appreciate your response, it seems very reasonable to me. I only quoted the part above because that is the thing I really wasn't picking up on, which is that apparently right now there is no one on your development team that knows how to do this (at least not without an extraordinary amount of effort).

As for attracting someone to the project that could add this, I can only say I wish I knew someone like that. I would probably not struggle so much with Linux in general if I knew anyone with that level of skills. But I am an older person that just doesn't have anyone like that in my immediate circle of friends. I know a lot of computer users, but I probably know more about Linux than any of them, and that's really sad, and only true because most of them use Windows exclusively. I even know a couple of ham radio operators that only use Windows, and they're supposed to be technical guys!

However I do think that one issue for someone like that would be that they would first have to learn how Kodi works before they could add something like closed captions. But maybe I am wrong; I don't really understand programming so I can't comment on that.
#49
(2014-11-27, 11:46)ironic_monkey Wrote: but you ARE expecting others to do work for you

I suppose that is one way to view a feature request, but whenever you download a piece of free software, doesn't that mean that someone else has already done work for you? And if so, why would it be unreasonable to think that maybe they might be willing to do a bit more, in order to make their software better or more accessible? Particularly when we are talking about software like Kodi, which seems to regularly have new versions released that are presumably improvements over the previous releases.

That said, I am very thankful for the work that has already been done on Kodi and on other software that I use regularly (just one of many things to be thankful for today (Thanksgiving Day in the USA)).
#50
(2014-11-07, 18:06)FernetMenta Wrote: ffmpeg supports extraction of CC. now we would need some libass like lib which creates a bitmap from the low level cc instructions which are like this: print character T at pos x,y.

Can libzvbi be of any use? http://zapping.sourceforge.net/ZVBI/ Claims to be able to render captions to e.g. PNG.

/D
#51
guys. this actually doesn't look too bad from a what-needs-to-be-done pov as such. vlc et al relies on libzvbi. there is also libzvbi support in ffmpeg. compile with that, set the codec parameter to text and out comes ass markup for rendering (default), or set it to bitmap and out comes a bitmap to be rendered as an overlay. should fit right in with what we already have i think.

@xbmclinuxuser sure, there is nothing wrong with posting a feature request. nothing at all. it's all about the how you go about it.

do not try to shame peeps into doing things. do not imply that the devs are bad human beings who don't care about nobody but themself. would you want to help yourself were you in their shoes ?

try some humility. the later posts are much better. most devs are very strong-headed individuals who frown at being told what to do.
#52
I hope this is taken as a constructive suggestion: I wonder if a business that is/will be using and benefitting from Kodi (Cubox comes to mind) could be encouraged to put some resources into making CCs work? It would be a significant feature.

BTW, devs who contribute to Kodi have nothing to apologize for. Most of them are contributing their time freely and, understandably, work on issues that engage them. What's wrong with that? The collection of all that free work is pretty impressive and has benefitted everyone who uses Kodi. Further, Kodi is way less 'hubcaps before tires' than lots of other open source projects I have seen.

Also, xbmclinuxuser, you may want to revisit your sig. I had not noticed it until ironic monkey pointed it out, but its tone and content was relevant to your message and I think it contributed to the harsh response you got.
#53
(2014-11-27, 17:12)allan87 Wrote: Also, xbmclinuxuser, you may want to revisit your sig. I had not noticed it until ironic monkey pointed it out, but its tone and content was relevant to your message and I think it contributed to the harsh response you got.
allan87, my sig exists for a reason. As a user, nothing infuriates me more than to make some (hopefully) constructive suggestion and receive a response that amounts to, "if you want it, go code it yourself, or go to hell." No, that's not exactly how it's said, but that's how it comes across. The developers know, or should know, that 1) Not everyone is a coder, and 2) Not every one who is a coder can take the time from whatever project they are working on to learn enough about the internals of Kodi to make a meaningful contribution, and therefore such a response amounts to "let them eat cake". I fall into the first category. I try to help people when I can and however I can, for example, if I happen to see a forum post where someone has asked a question, and I happen to know the answer, I will post it (and I never answer anyone with a dismissive response like "read the man page" or "----ing Google it"), but when it comes to Kodi/XBMC it's very seldom that I read a forum post and know any more than the person asking the question, so unfortunately I really can't be very helpful here.

If someone doesn't want to code something, doesn't have time to code it, doesn't know how to code it, or there is some other reason they can't or won't do it that's fine, I just wish they would always be honest about it and not try to turn it back on the person asking. If I had previously demonstrated skills as a coder, or had previously contributed some code to the project, or in some other way had given people reason to think I had the ability to write the code I'm requesting, then such a response would be entirely appropriate. But Kodi is the type of project where the vast majority of users are not coders, therefore there is no reason to assume that just because someone makes a feature request, they should be able to go out and code it.

So my sig exists in the hope that anyone seeing it will understand that I am not a coder, and that I don't take kindly to that sort of flippant response. If someone looks upon my sig as a reason to give a harsh response, then chances are they are not the sort of person that would have ever been helpful anyway.
#54
If you can say that in your signature without literally calling someone an ass, that would be better. Till then, I've edited your signature for you :P

I'm glad this discussion has turned fairly positive. I hope xbmclinuxuser has a better understanding of the situation and how to better word things without offending others. Maybe this will even lead to faster ATSC CC support. It's a positive improvement we all welcome. I, too, wish I was a coder so that I could help with such things, but I must work within my limits.

I would like to comment on one last thing. I wasn't going to say anything, because I've already said it in this thread and I don't think repeating the same thing over and over helps much. When it comes to someone selling hardware with XBMC/Kodi on it, they do not have to support ATSC CC even if they're 100% based in the USA. The FCC's regulations on this matter do not work like that:

The FCC requires certain hardware manufacturers to comply when accessing TV content from certain sources. It does not require that any and all software that is able to access TV tuners must also support closed captioning. These laws simply make it so that people have reasonable access to closed captions. I believe companies who make computer-controlled TV tuners are likely required to provide software that does comply with the requirements, but they don't have to require it for every possible player.

This is like a building that has to provide wheelchair access at their entrance, but they are not required to make every single door wheelchair accessible.

Or, you can also think of it like Kodi is providing a 32-inch wide door, which many wheelchairs will have issues getting through. The building (think of the building as the tuner hardware and/or software) will work with whatever door the customer chooses to get, and several people provide wider doors. Kodi wants to eventually provide wider doors as well, but can't at the moment, but the burden is not on them to make the wider door. The burden is on the building owners to install at least one wide door.

...as far as I can tell. I'm not a lawyer and only have a limited understanding of the crazy US legal system. YMMV and your house might catch on fire by reading what I've written, etc.
#55
For what it's worth, I believe that devices (including set top boxes) that receive or play back Live TV programming must support closed captioning, if manufactured or imported for use in the United States. If Cubox were to sell such a device, they may have to address this issue, but it doesn't look like the "CuboxTV" is designed for that purpose - no tuner.

If anyone cares to go straight to the horse's mouth, the relevant authority is US Code of Federal Regulations, Title 47, Chapter I, Subchapter C,Part 79. Enjoy: http://www.law.cornell.edu/cfr/text/47/part-79

...and anyone who thinks that this can be used to strong-arm Kodi devs into coding the enhancement is an, is an, is an, is a donkey!
#56
(2014-11-28, 01:38)allan87 Wrote: For what it's worth, I believe that devices (including set top boxes) that receive or play back Live TV programming must support closed captioning, if manufactured or imported for use in the United States. If Cubox were to sell such a device, they may have to address this issue, but it doesn't look like the "CuboxTV" is designed for that purpose - no tuner.

If anyone cares to go straight to the horse's mouth, the relevant authority is US Code of Federal Regulations, Title 47, Chapter I, Subchapter C,Part 79. Enjoy: http://www.law.cornell.edu/cfr/text/47/part-79

...and anyone who thinks that this can be used to strong-arm Kodi devs into coding the enhancement is an, is an, is an, is a donkey!

So this last sentence is okay but my .sig was not?

I didn't know that attempting to get someone to do the right thing for the right reason was considered strong-arming them, but whatever. I mentioned the law only as a part of the bigger picture - I never said nor thought that the US law could force the Kodi developers to do anything. What I did think was that since the new CuBoxTV ships with Kodi, and since it could be considered a device capable of receiving or playing back Live TV (assuming a PVR addon is in use), that law could potentially cause problems for the sellers of the CuBoxTV. I don't know that it could, and I am not a lawyer.

But now that I know that they are including Kodi without permission or endorsement of the Kodi developers, I understand that this wouldn't matter to them in the slightest.

I'm through with this. Hee-Haw.
#57
(2014-11-28, 22:34)xbmclinuxuser Wrote: So this last sentence is okay but my .sig was not?
Yup. Your sig was rude and cranky. I was being wry.
(2014-11-28, 22:34)xbmclinuxuser Wrote: I didn't know that attempting to get someone to do the right thing for the right reason was considered strong-arming them, but whatever. I mentioned the law only as a part of the bigger picture - I never said nor thought that the US law could force the Kodi developers to do anything. What I did think was that since the new CuBoxTV ships with Kodi, and since it could be considered a device capable of receiving or playing back Live TV (assuming a PVR addon is in use), that law could potentially cause problems for the sellers of the CuBoxTV.
The right reason is the importance of CCs for the hearing impaired. Explaining that it is a significant quality of life thing, generous, honourable and righteous to make this enhancement is one thing. Saying 'It's the law' sounds coercive, and is unseemly if, in fact, it is not the law. Implying that it might be the law is not persuasive or productive.

As for CuBoxTV, while it may ship with Kodi, it does not ship with a tuner. It can not receive live TV. Again, it would be decent, generous, honourable and righteous to add the feature, and I agree that it is important, but it does not look like a legal obligation.

Consider rebooting the discussion. Since you appear to be sensitive to the needs of the hearing impaired, you might be able to explain the importance of this feature in a way that would motivate someone to work on it because you have inspired and engaged him - not because you want it and not because any dev has a duty to work on it.
#58
I may have a look into this but still looking for some motivation. I live in Europe where we have a some more advanced DVB standard and luckily don't have to bother with this outdated A53 CC thing.
#59
I am interested user too.
Recently I changed my TV tuner card, which has problems with CC to a better one,
hoping I can have proper support of CC on live TV and found this issue.


(2014-11-29, 09:44)FernetMenta Wrote: I may have a look into this but still looking for some motivation. I live in Europe where we have a some more advanced DVB standard and luckily don't have to bother with this outdated A53 CC thing.

FernetMenta: What kind of motivation are you looking for ? Can I help ? Is it financial motivation ?
#60
@FernetMenta

https://github.com/Memphiz/xbmc/commit/e...85f2b475ba

compiles on osx32/osx64/ios - needs work on android (it depends on iconv which is not available on android) - also someone needs to make it available on windows somehow (i guess so that ffmpeg can find it?) - needs at least this patch for windows - maybe more:

https://github.com/videolan/vlc/blob/d36...in32.patch

Was not able to upload the tarball to the mirrors yet (seems the rebrand borked my access...)
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 16

Logout Mark Read Team Forum Stats Members Help
Update FFMPEG To Support ATSC Closed Captions2