Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

HLS Without Transcoding?

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


list-mythtv-users at jack

May 16, 2012, 2:54 AM

Post #1 of 10 (1575 views)
Permalink
HLS Without Transcoding?

Hi all,

Is there any way of using the HLS functionality of the API without
transcoding the media? I have a 'smart' TV and Blu-ray player in
separate rooms and these devices are capable of playing any of the
videos or recordings natively via UPnP. There are only two drawbacks to
this :-

1. I don't get all the artwork and metadata that I do with a real Myth
client
2. Watching recordings 'in progress' doesn't work.

The thought occurred that I could use the new APIs to create a web-based
front-end for these devices, however it looks as though the HLS API
wants to transcode all video files to a specified or default resolution
and bit-rate. As the network and receivers are already capable of
handling the data natively, this seems to be a waste of CPU time and a
needless downgrading of the source material.

I have not done much in the way of experimentation as yet, but am I
right in that belief and is there a way around it?

TIA,

Jack

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mtdean at thirdcontact

May 16, 2012, 7:35 AM

Post #2 of 10 (1533 views)
Permalink
Re: HLS Without Transcoding? [In reply to]

On 05/16/2012 05:54 AM, Jack wrote:
> Hi all,
>
> Is there any way of using the HLS functionality of the API without
> transcoding the media? I have a 'smart' TV and Blu-ray player in
> separate rooms and these devices are capable of playing any of the
> videos or recordings natively via UPnP. There are only two drawbacks to
> this :-
>
> 1. I don't get all the artwork and metadata that I do with a real Myth
> client
> 2. Watching recordings 'in progress' doesn't work.
>
> The thought occurred that I could use the new APIs to create a web-based
> front-end for these devices, however it looks as though the HLS API
> wants to transcode all video files to a specified or default resolution
> and bit-rate. As the network and receivers are already capable of
> handling the data natively, this seems to be a waste of CPU time and a
> needless downgrading of the source material.
>
> I have not done much in the way of experimentation as yet, but am I
> right in that belief and is there a way around it?
>

Don't you just want to use UPnP to stream the videos to the TV?

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jyavenard at gmail

May 16, 2012, 8:08 AM

Post #3 of 10 (1531 views)
Permalink
Re: HLS Without Transcoding? [In reply to]

On 16 May 2012 19:54, Jack <list-mythtv-users [at] jack> wrote:
> Hi all,
>
> Is there any way of using the HLS functionality of the API without
> transcoding the media? I have a 'smart' TV and Blu-ray player in
> separate rooms and these devices are capable of playing any of the
> videos or recordings natively via UPnP. There are only two drawbacks to
> this :-

HLS requires to transcode as HLS only supports mpeg-ts container with
a H264 streams for video, and either a MP3 or a AAC stream for audio.

For what you want to do, you can't use HLS, use another medium (Airplay or UPnP)
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


list-mythtv-users at jack

May 16, 2012, 8:16 AM

Post #4 of 10 (1528 views)
Permalink
Re: HLS Without Transcoding? [In reply to]

On Wed, 2012-05-16 at 10:35 -0400, Michael T. Dean wrote:
> On 05/16/2012 05:54 AM, Jack wrote:
> > Hi all,
> >
> > Is there any way of using the HLS functionality of the API without
> > transcoding the media? I have a 'smart' TV and Blu-ray player in
> > separate rooms and these devices are capable of playing any of the
> > videos or recordings natively via UPnP. There are only two drawbacks to
> > this :-
> >
> > 1. I don't get all the artwork and metadata that I do with a real Myth
> > client
> > 2. Watching recordings 'in progress' doesn't work.
> >
> > The thought occurred that I could use the new APIs to create a web-based
> > front-end for these devices, however it looks as though the HLS API
> > wants to transcode all video files to a specified or default resolution
> > and bit-rate. As the network and receivers are already capable of
> > handling the data natively, this seems to be a waste of CPU time and a
> > needless downgrading of the source material.
> >
> > I have not done much in the way of experimentation as yet, but am I
> > right in that belief and is there a way around it?
> >
>
> Don't you just want to use UPnP to stream the videos to the TV?

That's what I already do, but that limits me to browsing through a tree
and file titles. I have a vision of a seamless, information-rich
interface (displaying cover-art and plot synopsys etc.) that is
searchable by title, genre, actors etc.

Jack


_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


list-mythtv-users at jack

May 16, 2012, 8:29 AM

Post #5 of 10 (1525 views)
Permalink
Re: HLS Without Transcoding? [In reply to]

On Thu, 2012-05-17 at 01:08 +1000, Jean-Yves Avenard wrote:
> HLS requires to transcode as HLS only supports mpeg-ts container with
> a H264 streams for video, and either a MP3 or a AAC stream for audio.

That's fine, most (if not all) of my media is h264. OK, they would have
to be re-packed from mkv to mpeg-ts. Not sure why the restriction on
audio (or video, for that matter) codec - surely that choice should
depend on what the receiving system can handle?
My main question is about the enforcement of an expensive scale and
re-encode of the video stream. Why isn't there a 'leave it alone and let
the client deal with it' option?

jack



_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jyavenard at gmail

May 16, 2012, 8:47 AM

Post #6 of 10 (1529 views)
Permalink
Re: HLS Without Transcoding? [In reply to]

On 17 May 2012 01:29, Jack <list-mythtv-users [at] jack> wrote:
> That's fine, most (if not all) of my media is h264. OK, they would have
> to be re-packed from mkv to mpeg-ts. Not sure why the restriction on
> audio (or video, for that matter) codec - surely that choice should
> depend on what the receiving system can handle?
> My main question is about the enforcement of an expensive scale and
> re-encode of the video stream. Why isn't there a 'leave it alone and let
> the client deal with it' option?

I guess if the original file is h264 and AAC/MP3 audio, it could be
kept as is.. Not sure if the API contains such possibility...
There are restrictions to the bitrate used with iOS devices..
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


gnassas at mac

May 16, 2012, 4:23 PM

Post #7 of 10 (1515 views)
Permalink
Re: HLS Without Transcoding? [In reply to]

On 2012-05-16, at 11:29 AM, Jack wrote:

> That's fine, most (if not all) of my media is h264.
> ...
> Why isn't there a 'leave it alone and let the client deal with it' option?

The HLS code is very new and pretty embryonic. The author (Chris Pinkham) has mentioned how he debated including it in .25 at all in case people should pop up asking how come it doesn't include feature X, Y, or Z. The answer is the HLS code is incomplete and there are plenty of more important features to be implemented first.

That said I think what you're asking for is a great idea. It doesn't seem too difficult to scan through an h.264 video and create offsets which could be used to synthesize HLS segments on the fly. It's all I/O and no compute so it would run super fast. On the other hand the audience for such a feature is probably pretty small so as usual in open source we await your patch ;)

- George
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


list-mythtv-users at jack

May 17, 2012, 1:04 AM

Post #8 of 10 (1505 views)
Permalink
Re: HLS Without Transcoding? [In reply to]

On Wed, 2012-05-16 at 19:23 -0400, George Nassas wrote:
> The HLS code is very new and pretty embryonic.
<snip>
> That said I think what you're asking for is a great idea. It doesn't seem too difficult to scan through an h.264 video and create offsets which could be used to synthesize HLS segments on the fly. It's all I/O and no compute so it would run super fast.
Ahh, OK as this appeared to be the simplest way of implementing it and
the use-case (to me) was obvious, I had wrongly assumed that it would
have more or less been the first thing implemented. Chris is clearly
targeting a different class of device to me and I have an aversion to
fruit ;)


> On the other hand the audience for such a feature is probably pretty small so as usual in open source we await your patch ;)
Compared to the tablet market, currently yes. Though as more and more
TVs become 'smart' and people upgrade, I would suggest the potential
audience is much larger. I may just go and get my hands dirty - been a
long time since I did anything non-trivial in C :)

Cheers,

jack


_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


cpinkham at bc2va

May 23, 2012, 1:54 PM

Post #9 of 10 (1454 views)
Permalink
Re: HLS Without Transcoding? [In reply to]

* On Thu May 17, 2012 at 09:04:06AM +0100, Jack wrote:
> Ahh, OK as this appeared to be the simplest way of implementing it and
> the use-case (to me) was obvious, I had wrongly assumed that it would
> have more or less been the first thing implemented. Chris is clearly
> targeting a different class of device to me and I have an aversion to
> fruit ;)

The fruit is just the easiest thing to test with. I've been testing
the HLS code with several non-fruit clients. A couple nights ago,
I was playing back a video from MythTV on my Roku over HLS. I started
with a modified copy of MythRokuPlayer and a set of hand-crafted .qsp
files served up by mythbackend's internal webserver, but have now
partially completed a set of .qsp files that serve up the XML necessary
to watch MythTV recordings and videos on the Roku via HLS.

The Roku can play .mp4 directly as well as HLS spec .ts files with h264
video and AAC audio. I'd have to look into it, but there could be
a benefit in converting a .mp4 or other file to a segmented .ts to
serve it up via the HLS code. That functionality would be a bit more
complex than most of the other thigns on my HLS TODO list though due
to having to handle getting the uncompressed video and audio and dealing
with writing them out. Currently the 'player' code used in mythtranscode
is the same code used by the normal player in MythTV, so it is designed
to hand out uncompressed video and audio (well, compressed audio is
supported for the ancient lossless nuv -> nuv mode).

> > On the other hand the audience for such a feature is probably pretty small so as usual in open source we await your patch ;)
> Compared to the tablet market, currently yes. Though as more and more
> TVs become 'smart' and people upgrade, I would suggest the potential
> audience is much larger. I may just go and get my hands dirty - been a
> long time since I did anything non-trivial in C :)

As TV's become smarter, shouldn't they be able to handle the input file
directly rather than having to convert into HLS segmented .ts? :)

--
Chris
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


list-mythtv-users at jack

May 24, 2012, 5:32 AM

Post #10 of 10 (1423 views)
Permalink
Re: HLS Without Transcoding? [In reply to]

On 2012-05-23 21:54, Chris Pinkham wrote:>
> As TV's become smarter, shouldn't they be able to handle the input
> file
> directly rather than having to convert into HLS segmented .ts? :)

They certainly can. I have not had much involvement with video over
HTTP other than as a user and had assumed that the HLS approach was the
common and generic way of doing it. The splitting into segments seemed
to be a logical way to deal with seeking within the file and bookmarks.
It seems I had the wrong idea of what HLS is trying to solve - am I
right in now thinking that it is more of a restrictive protocol with
the
aim of off-loading some work from the client device?

If so, my project may end up being a lot simpler than I had thought :)

Cheers,

Jack


_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.