Jump to content

Live Tv = Direct Play; Recorded Tv = Transcoding


bungee91

Recommended Posts

bungee91

This is likely obvious to most, and I can provide logs, etc...

 

However my HDHR's will direct play to my Nexus Player and my Shield just fine, however anything I record from the exact same channel and playback forces a full transcode.

On the server page it lists the stream as not supported for container, video codec and audio codec.

This seems to be the same for both MPEG2 HDHR streams, and MPEG4.

 

Screens attached of what I see when playing.

 

Would it be helpful to set the "Automatically convert recordings to a streaming friendly format" to enabled? I'd prefer not to if I don't have to.

Thanks.

 

Edit: Added a trancode log since it will likely be asked for...

post-131141-0-33022500-1503884826_thumb.png

post-131141-0-27979400-1503884832_thumb.png

ffmpeg-transcode-a895fa50-c86d-42be-a829-eef8af36f322.txt

Edited by bungee91
Link to comment
Share on other sites

But just to clear this example up, it is transcoding in order to deinterlace, which I believe is an issue you brought up in another topic.

For the live stream, because live playback comes with more complexities, we have made the decision to direct play whenever possible, even if it means without deinterlacing.

Link to comment
Share on other sites

bungee91

I'll grab a log specific to this with a direct play followed by a transcode, as the log now would have all kinds of stuff in it.

 

As for the interlaced or not, that wasn't me, I've never even talked about it, or get to worked up about it actually. However it shouldn't be the case, as the one channel I mainly notice this on (not the one on my attached transcode log) is an OTA MPEG2 720P stream that definitely exhibits this behavior.

 

I'll work up a log tomorrow to attach.

Link to comment
Share on other sites

Well the point being, ffmpeg has detected the recording as interlaced, so if we were to direct play it then you may not get any deinterlacing.

Link to comment
Share on other sites

bungee91

Makes sense.. It's lying!.. =P

If I set my user profile to not allow transcoding will it just fail to playback, or will it pass it as is and I can see what it looks like?

Link to comment
Share on other sites

It looks like you allowed remuxing but took away transcoding support. We have never really promised that all possible combinations of those three settings will work in all apps,and the help text will need to make that more clear. Try just taking all three of them away so that it actually direct plays.

Link to comment
Share on other sites

bungee91

That did it, thanks for noticing that I left one of the three on.

Yep, playing perfectly! So somehow ffmpeg is analyzing this incorrectly. It's been like this for quite a while now, just thought I'd finally mention it.

For now I'll leave the transcoding options off, unless that starts to cause troubles with other videos that I playback. I almost never use Emby away from home.

 

Thanks for the support!

Link to comment
Share on other sites

bungee91

@@Luke nope can't leave the options off as it caused an odd issue with some local files of mine (shows as direct playing, but if I remove the three transcode options it still says direct playing but there's no sound).

 

I'll run the recording through media info and other players to verify it's 720P, I'll let you know those results. That channel supposedly transmits in 720p, always has been since HD OTA came around. I tried the cable version of the same channel, recorded a show, and it as well showed up as 720i. More to come.

Link to comment
Share on other sites

maegibbons

Umm.

 

If you are recording without transcoding then you are recording to .ts files.

 

Because of seek issues in a .ts container @@ebr forces them to transcode.

 

If you enable record transcoding then they will direct play when recorded EXCEPT when they are an Active Recording.

 

HD is a pecularir example for some areas (uk especially) where you have to NOT preserve audio and video in record transcode for it all to work nicely.

 

Krs

 

Mark

  • Like 1
Link to comment
Share on other sites

afullmark

Umm.

 

If you are recording without transcoding then you are recording to .ts files.

 

Because of seek issues in a .ts container @@ebr forces them to transcode.

 

If you enable record transcoding then they will direct play when recorded EXCEPT when they are an Active Recording.

 

HD is a pecularir example for some areas (uk especially) where you have to NOT preserve audio and video in record transcode for it all to work nicely.

 

Krs

 

Mark

 

But then you lose subtitles, right?

Link to comment
Share on other sites

bungee91

Umm.

 

If you are recording without transcoding then you are recording to .ts files.

 

Because of seek issues in a .ts container @@ebr forces them to transcode.

 

If you enable record transcoding then they will direct play when recorded EXCEPT when they are an Active Recording.

 

HD is a pecularir example for some areas (uk especially) where you have to NOT preserve audio and video in record transcode for it all to work nicely.

 

Krs

 

Mark

 

Interesting, thanks for the information.

As I stated in the beginning, this is likely obvious to most.  :D

 

In my limited testing last night forcing direct play the file (.ts) seeked quicker/better than a transcoded one.

My main issue with this being forced other than the obvious lifting by my server (not a big issue for me) is that when starting an in progress recording and seeking past the first 2 minutes (my default padding) it can take almost 30 seconds to start playing from the initial skip (I think actual time is between 15 - 20 seconds). I assume this is because it is transcoding the file, and it just started working on it and I'm already seeking.

 

Either way, this is not exactly ideal. Are seek issues in a .ts container an issue for a limited set of equipment, just Android, or any other specific setup?

I have no testing from an in-progress recording with transoding forced off, but like I said the completed recording played better with it disabled (again, limited testing).

Forcing a full transcode certainly sounds like a work-around that hopefully can be resolved.

Link to comment
Share on other sites

The .ts container format is not seekable.  It does not contain the information that other containers do that allow players to accurately seek within the stream.

 

Some video players try to allow seeking by employing some guessing techniques and these work with varying degrees of success but the Google developers (responsible for Android) have stated they do not wish to do this because you cannot guarantee it will work properly.

Link to comment
Share on other sites

bungee91

Informative, thanks.

 

So I assume the HDHR is sending out a ts container, right? If so, how does WMC, SiliconDust's DVR, and SWMC provide seeking without needing to transcode the entire file (or so it seems; also I'm just asking, not trying to be a dick)?

Edited by bungee91
Link to comment
Share on other sites

maegibbons

But then you lose subtitles, right?

 

Correct.  Currently transcoding to MKV does not copy the dvdsubs stream over.

 

I have reported this in the Live TV forum and @@Luke is currently looking at it.  I know its at the top of his priority list and I am sure there will be a solution soon. :)

 

Krs

 

Mark

Link to comment
Share on other sites

bungee91

I've now read up about the decision to force the transcode for these, but still have some questions.

 

Is the transcode just a re-mux (it seems to be, but the info from the Dashboard just tells me nothing is right for container/codecs)?

 

Is there anyway since this decision has been made to somehow pre-buffer a recording so that the initial start and skip two minutes doesn't take a long time to initially work? I ask primarily because that is the use case here, watching an active recording, load it up, skip to the good stuff, sit back and enjoy?

 

Is there any difference from tuning into liveTv and pausing, skipping, as opposed to watching a recording? I ask because a livetv stream shows up as direct streaming, and not transcoding, but seems to be doing the same thing (buffering an active stream).

 

Also (and not that it seems to be the reason the transcode is taking place at this point), my recordings for this channel are incorrectly being probed as 720i when they're actually 720p. 

I've compared this with both Mediainfo and in MPC-HC, and both read this as 720p, which should be correct given the channel this is recording from. Screenshot attached (no I don't watch So You Think I Can Dance  :huh: )

post-131141-0-98301200-1503967006_thumb.png

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...