Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tvheadend 4.2 with transcoding #123

Merged
merged 2 commits into from Apr 15, 2016

Conversation

Projects
None yet
5 participants
@CvH
Copy link
Member

commented Apr 7, 2016

Transcoding is only integrated for Generic

  • Vorbis, aac, VP8/9 and x264/5
  • needs more runtime testing - test addons for Generic / RPi2-3 / WeTek_Play click here
  • reworked the whole default settings to hopefully useful settings and without errors
  • renamed that we are able to ship 2 Tvh versions (4.0 and 4.1/2)
  • I couldn't test the xmltv and power scripts - maybe borked
  • splitted in 2 commits that it is easier to see what is needed for transcoding/reverting/porting
  • QSV for Intel gpu acceleration is NOT included because it is not working for unknown reason (it compiles fine but didn't work)

tx to @vpeter4 and @lrusak

@lrusak

This comment has been minimized.

Copy link
Member

commented Apr 7, 2016

looks pretty good, my only concern is when/if we move back to one tvheadend that the addon id's will be borked, but nothing we can really do about this.

@CvH

This comment has been minimized.

Copy link
Member Author

commented Apr 7, 2016

you never know what is happen in the future :-/

@CvH CvH force-pushed the CvH:tvh_4.2-with branch from 4a740a4 to e513d31 Apr 9, 2016

@CvH CvH removed the Keep Open label Apr 9, 2016

addons: add Tvheadend 4.2
- reworked settings
- this is a pre version of Tvheadend 4.2 because it is not branched yet

@CvH CvH force-pushed the CvH:tvh_4.2-with branch from e513d31 to 105b133 Apr 9, 2016

@stefansaraev

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2016

addonid should not be changed. and if there is high demand for transcoding. it should be enabled for all platforms.. and you will hit a wall with this. too

@CvH

This comment has been minimized.

Copy link
Member Author

commented Apr 9, 2016

Addonid isn't nice - we know - but no better idea to allow 2 versions of Tvh (it is prerequisite to support 4.0 - at least at 7.0).

Software transcoding at arm is atm more or less useless - something hw accelerated isn't implemented somewhere.

@stefansaraev

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2016

why 2nd? what if there is demand for yet one more tvh feature tomorrow, you will add 3rd addon ?

EDIT: I know, it is easy to forget what OE/LE is (was) supposed to be, a good base for kodi :) I see docker stuff is going in, virtual re-added, soon or later this is going to be completely out of control :)

@CvH

This comment has been minimized.

Copy link
Member Author

commented Apr 9, 2016

Not supporting 4.0 would result in "failed" upgrading for OE users (if 4.2 would replace it).
Not supporting Tvh 4.2 would be a major mistake - feature and stableness wise.
There is no plan to support 4.0 till forever. The situation isn't ideal - but we won't sacrifice user-friendliness over KISS.

@stefansaraev

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2016

so, same sh** like OE's 3.2 -> 4.0 migration. and even worse, as tvh can't handle it's own (old) config files now (it fails because of old dvr-config right?). what about 4.4, 4.6 and 4.8 btw ? new addons because upgrade will fail in LE 9/10/11 ?

@stefansaraev

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2016

I am sure @perexg can help fixing the remaining issues if you run (EDIT: compiled with debug syms) tvheadend under gdb and report to him, adding new addon just because upgrading from old version fails is a no go.

@CvH

This comment has been minimized.

Copy link
Member Author

commented Apr 10, 2016

The upgrade fails for numerous reasons even at debian as reported by different users.
We need an 1click solution that actually work. I would also like just an update but at the moment this fails. We could provide a clean upgrade path that works through this. At the moment every change is dictated if the upgrade will work (even Kodi fails there). If 4.4 is also not upgrade friendly, I guess, we would add an "new" package again (4.0 is dropped ofc). Nobody likes to setup his Tv at every major upgrade - so we could at least stretch the time till this is necessary.

CvH referenced this pull request in nkvoronov/OpenELEC.tv Apr 10, 2016

@CvH CvH force-pushed the CvH:tvh_4.2-with branch 3 times, most recently from aa3f8fa to 5f67c9d Apr 10, 2016

@lrusak

This comment has been minimized.

Copy link
Member

commented Apr 14, 2016

I think we should just keep it the same for all platforms. No reason to single out the Generic project.

If people want to try and transcode on their RPi1 then that's their choice

@CvH

This comment has been minimized.

Copy link
Member Author

commented Apr 14, 2016

@lrusak then you have to do the upstream work and implement it in Tvheadend it self, even the normal packages doesn't support it. Even if implemented you have to write an gpu encode integration because the cheap ass ARMs doesn't have enough cpu power to get something done. I don't think that we need to support more as the upstream creators. The benefit (I guess nobody wants to write an gpu integration) is 0 because it is far away from usable.

@CvH CvH force-pushed the CvH:tvh_4.2-with branch from 834da41 to 14f61df Apr 14, 2016

@chewitt chewitt merged commit dcfc567 into LibreELEC:master Apr 15, 2016

@CvH CvH deleted the CvH:tvh_4.2-with branch Apr 15, 2016

LongChair added a commit to plexinc/LibreELEC.tv that referenced this pull request Apr 16, 2016

LongChair added a commit to plexinc/LibreELEC.tv that referenced this pull request Apr 16, 2016

@piotrasd

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2016

@CvH

This comment has been minimized.

Copy link
Member Author

commented Jul 8, 2016

@piotrasd
sadly not, also it is deprecated and the vaapi implementation (ffmpeg 3.1) should be used but they is still not completely supported by Tvh

@piotrasd

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2016

@CvH this is not becuase

Requriments on Linux: you need either to rely on the Intel Media Server Studio for Linux, or use a recent enough supported system, with the libva and libdrm libraries, the libva Intel drivers, and the libmfx library packaged by lu_zero

libmfx library ??

@CvH

This comment has been minimized.

Copy link
Member Author

commented Jul 8, 2016

@piotrasd the problem is the libmfx lib - they have some problem (forgot why) and sadly there is zero help (from the creators) if you only mention ffmpeg (libav vs ffmpeg situation) :/
If someone gets this fixed I`m the last one who is against to include it ;) (the vaapi way would be the much better path)

@piotrasd

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2016

@CvH ok thanks for answer :) i will also look about some news in topic.
i have please, because i know you tried get working x11grab in ffmpeg
could you look at #523 after --enable-x11grab im still get Unknown input format: 'x11grab', im suppose that problem libxcb

droidbox pushed a commit to droidbox/LibreELEC.tv that referenced this pull request Jan 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.