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
Member

CvH 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.

Show comment
Hide comment
@lrusak

lrusak Apr 7, 2016

Member

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.

Member

lrusak 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.

Show comment
Hide comment
@CvH

CvH Apr 7, 2016

Member

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

Member

CvH commented Apr 7, 2016

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

@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
@stefansaraev

This comment has been minimized.

Show comment
Hide comment
@stefansaraev

stefansaraev Apr 9, 2016

Contributor

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

Contributor

stefansaraev 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.

Show comment
Hide comment
@CvH

CvH Apr 9, 2016

Member

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.

Member

CvH 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.

Show comment
Hide comment
@stefansaraev

stefansaraev Apr 9, 2016

Contributor

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 :)

Contributor

stefansaraev 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.

Show comment
Hide comment
@CvH

CvH Apr 9, 2016

Member

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.

Member

CvH 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.

Show comment
Hide comment
@stefansaraev

stefansaraev Apr 9, 2016

Contributor

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 ?

Contributor

stefansaraev 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.

Show comment
Hide comment
@stefansaraev

stefansaraev Apr 9, 2016

Contributor

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.

Contributor

stefansaraev 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.

Show comment
Hide comment
@CvH

CvH Apr 10, 2016

Member

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.

Member

CvH 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

@lrusak

This comment has been minimized.

Show comment
Hide comment
@lrusak

lrusak Apr 14, 2016

Member

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

Member

lrusak 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.

Show comment
Hide comment
@CvH

CvH Apr 14, 2016

Member

@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.

Member

CvH 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.

@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.

Show comment
Hide comment
@piotrasd
Contributor

piotrasd commented Jul 8, 2016

@CvH

This comment has been minimized.

Show comment
Hide comment
@CvH

CvH Jul 8, 2016

Member

@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

Member

CvH 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.

Show comment
Hide comment
@piotrasd

piotrasd Jul 8, 2016

Contributor

@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 ??

Contributor

piotrasd 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.

Show comment
Hide comment
@CvH

CvH Jul 8, 2016

Member

@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)

Member

CvH 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.

Show comment
Hide comment
@piotrasd

piotrasd Jul 8, 2016

Contributor

@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

Contributor

piotrasd 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