Recorded TV - In Progress Processing

[Spaceboy 2500]

Since the on the fly transcoding was removed (still to find any of these people that apparently had an issue with that) we have had the ability to issue post-processing commands. These are not that helpful in the context of live tv though because I would imagine that most people are like me and watch their tv from in progress recordings or very shortly after they have completed. this doesn't give long enough for any post-processing to be completed.

 

Please, can we have an In Progress Processing option as well? This would be identical to the current post-processing feature except that it should have a user-defined delay that kicks off the task X minutes after the recording starts. This would allow a buffer to be built. As the recorded tv file keeps growing my understanding is that FFmpeg will continue to work on the file until it is complete. this should eliminate the delays that post-processing incurs.

 

With this solution, there is the potential for a fuller replacement of the on the fly transcoding that was previously removed

[Carlo 4331]

Still won't help you with in-progress recordings.  You would essentially be recording/saving in TS format while simultaneously building a 2nd files.

The files wouldn't get "traded out" until the recording is finished.  Then what happens if a person has the original file open and watching it?  Can't delete an open file.

 

However, with a bit of queue work and handling this would/could certainly speed up things.  You could for example be running Comskip against the recording (like NextPVR can do).  You could be converting to H.264 or H.265 while the recording is in progress.  This cuts down the overall timeline of having access to the finished transcode (without commercials).  A 3.5 hour NFL game could be ready 15 to 20 minutes after the game finishes vs 2.5 hours later which makes a big difference in user perception.

[Spaceboy 2500]

Still won't help you with in-progress recordings.  You would essentially be recording/saving in TS format while simultaneously building a 2nd files.

The files wouldn't get "traded out" until the recording is finished.  Then what happens if a person has the original file open and watching it?  Can't delete an open file.

 

However, with a bit of queue work and handling this would/could certainly speed up things.  You could for example be running Comskip against the recording (like NextPVR can do).  You could be converting to H.264 or H.265 while the recording is in progress.  This cuts down the overall timeline of having access to the finished transcode (without commercials).  A 3.5 hour NFL game could be ready 15 to 20 minutes after the game finishes vs 2.5 hours later which makes a big difference in user perception.

just leave us to worry about that thanks.

 

ok that was a bit short in conjunction with @@PenkethBoy 's powershell scripts, this can pretty much be done already. we just need a method of initiating the processing, which at the moment can only be done on the completion of recording

Edited September 20, 2018 by Spaceboy

[maegibbons 1267]

Plus 10. We need to get back to somewhere near "on the fly" conversion. Post processing takes too long.

 

Krs

 

Mark

 

Sent from my SM-N950F using Tapatalk

[jfgilliam 26]

My 2 cents, add ability to extract thumbnails for Roku and eventually all other clients it possible. Need to be able to see those thumbnails when scrubbing on the timeline while watching live-tv delayed.

[Carlo 4331]

just leave us to worry about that thanks.

 

ok that was a bit short in conjunction with @@PenkethBoy 's powershell scripts, this can pretty much be done already. we just need a method of initiating the processing, which at the moment can only be done on the completion of recording

Maybe you didn't understand what I'm saying.  YES I'm in favor of this for post processing features but it won't help in-progress recordings is all I'm saying.

 

Expanded.  You could be recording the TS file of say a 3.5 hour football and be running a background task of converting this to H.264 or H.265, cutting commercials, etc but this won't allow you to use those while viewing the in-progress recordings.  You will still only have access to the TS file.

 

What it will do is allow you to access the comskiped/converted file quicker after the recording is complete.

 

Do you disagree with that?

 

Again, I'm all for this and would make use of it and build some fancy scripts for Emby conversions like I have available for Plex for post processing (actually they work now for Emby) but would add this "pre-processing" to those scripts to get a leg up on time savings.

 

I've actually just recently requested that we have the ability to get the station ID embedded in the file name so that the scripts can tune themselves to the station.  For example you can modify comskip.ini files to use specific settings on a station.  Logo detection, screen blacks, use of closed captioning or setup certain channels to not cut the ending, etc

[PenkethBoy 2063]

You can access (play in Emby) a PP file while its being worked on

 

and an In-Progress file (if we had the option) would be the same

[CBers 6780]

Subscribed.

[Carlo 4331]

You can access (play in Emby) a PP file while its being worked on

 

and an In-Progress file (if we had the option) would be the same

Not sure I follow your second point.

If you are creating an MP4 file you couldn't be playing it while writing it or you could cause yourself all kinds of grief.  MP4 files use MOOV atoms that are written AFTER processing the streams.  Essentially you re-write the file on completion moving the MOOV atoms to the front of the file so they are streamable.  You can't really play these files as they are being written either as there is no indexes/moov atoms until the first pass is done.

 

MKV has quirks as well that don't like a file open/locked while writing to them.

Edited September 20, 2018 by cayars

[PenkethBoy 2063]

work fine as a MKV file - you need to test more

 

how do you think transcoding on the fly in emby works then

[Spaceboy 2500]

Not sure I follow your second point.

If you are creating an MP4 file you couldn't be playing it while writing it or you could cause yourself all kinds of grief.  MP4 files use MOOV atoms that are written AFTER processing the streams.  Essentially you re-write the file on completion moving the MOOV atoms to the front of the file so they are streamable.  You can't really play these files as they are being written either as there is no indexes/moov atoms until the first pass is done.

 

MKV has quirks as well that don't like a file open/locked while writing to them.

it does work. it is working for me right now. not perfect but i am sure perfectable

[Carlo 4331]

work fine as a MKV file - you need to test more

 

how do you think transcoding on the fly in emby works then

You do realize Luke had to pull MKV transcoding support during recording right?

I'm not saying this couldn't be done, but it's not nearly as easy as you think it is.

 

Converting files and replacing them when they aren't open or used is cake. Converting files and writing files with indexes when you don't have the full file to be able to build indexes and moov atoms is another thing.  You don't get optimized files and would want to still reprocess them yet again to fully optimize them.

[Carlo 4331]

it does work. it is working for me right now. not perfect but i am sure perfectable

Please explain how you are building MP4 files while playing them when you haven't written the moov atoms yet?

 

Some software can deduce things from the stream but this is less then desirable and sort of mutes the use of using an MP4 files.

You won't have an optimized streaming files (not possible) since you haven't written the important parts of the file yet, which you can't do until you finish processing the file and optimizing it.

 

Try playing those files in progress back on different devices like an Apple, Roku, PS3/4, Xbox, etc and see how well you make out on a variety of devices that want a file written to "spec".

 

These are the heart of the matter why Luke uses a Transport Stream format for recording.  It's not by choice but by function.  TS is meant for incomplete files/streams where you don't have all the information written into the file to tell you about the streams, index, etc.  You either need to do that or work in segments and use HLS/DASH so you can process/store parts of the file as it's being broadcast.

 

This latter approach is exactly how Plex does it using segments and why it can get away with compression on the fly.  It then takes all the segments generated during the recording and combines them back again after the recording is completed.  Down side is that the compression is poor compared to doing it after the fact when you have proper look ahead and can manage the bit rates properly.

Edited September 20, 2018 by cayars

[Luke 37181]

Exactly, as i mentioned elsewhere, on the fly conversion to mkv resulted in a couple deal-breaking problems:

• You could not seek the in-progress recordings
• Even after completion, the resulting mkv files could not be trusted to be playable on all platforms, even if the platform technically supports the container and codecs.

I'm not against bringing back the on the fly conversion feature with a reduced feature set, meaning the container would have to stay .ts.

[Spaceboy 2500]

Exactly, as i mentioned elsewhere, on the fly conversion to mkv resulted in a couple deal-breaking problems:

• You could not seek the in-progress recordings
• Even after completion, the resulting mkv files could not be trusted to be playable on all platforms, even if the platform technically supports the container and codecs.

I'm not against bringing back the on the fly conversion feature with a reduced feature set, meaning the container would have to stay .ts.

thats not what is being requested here. We would just like more functionality on the processing feature. there are many reasons for this, transcoding in progress is one. commercial scanning is another. i am sure there are others. Post processing should be set to run on the start or end of a recording, plus with the ability to delay it by x seconds. this is a relatively simple change to make and gives the user the freedom to implement their own solutions

Edited September 20, 2018 by Spaceboy

[Luke 37181]

Right i get it. The conversation started leading in that direction so that's the only reason i mentioned it. Thanks.

[Spaceboy 2500]

Please explain how you are building MP4 files while playing them when you haven't written the moov atoms yet?

 

Some software can deduce things from the stream but this is less then desirable and sort of mutes the use of using an MP4 files.

You won't have an optimized streaming files (not possible) since you haven't written the important parts of the file yet, which you can't do until you finish processing the file and optimizing it.

 

Try playing those files in progress back on different devices like an Apple, Roku, PS3/4, Xbox, etc and see how well you make out on a variety of devices that want a file written to "spec".

 

These are the heart of the matter why Luke uses a Transport Stream format for recording.  It's not by choice but by function.  TS is meant for incomplete files/streams where you don't have all the information written into the file to tell you about the streams, index, etc.  You either need to do that or work in segments and use HLS/DASH so you can process/store parts of the file as it's being broadcast.

 

This latter approach is exactly how Plex does it using segments and why it can get away with compression on the fly.  It then takes all the segments generated during the recording and combines them back again after the recording is completed.  Down side is that the compression is poor compared to doing it after the fact when you have proper look ahead and can manage the bit rates properly.

we're not writing to mp4 files

[Carlo 4331]

Just to make sure we're on the same page.

What I think we all agree on is that having a Pre-Optimize feature would allow SOME types of processing to be kicked off at the start of the recordings.  we could get a notification that Emby is about to start recordings X file name.

 

Once we receive the notification OUR external program/script could:

Be a notification engine and send a text, email, or any other type of notification we program that X program is now recordings.  Someone else had just requested notification of when NFL games were being recorded so we could use this hook and send a message.

 

We could use this for starting to process the files behind the scenes such as running comskip against the ongoing file which can be done and IS done in NextPVR via an adding. Running it this way we could have a finished comskip cut file produced a about a minute or so after the recording is done.  If this was recorded from cable where the provider is using H.264 already instead of mpeg2 then we simply cut the file using ffmpeg and remux it back together which could be done in 1 or 2 minutes.  Thus we could have a commercial file in less than 5 minutes after the recording is done vs what could normally take 45 minutes to an hour using post-processing.

 

I'm sure we could find many other uses for this PRE recording notification.  Hmm, just thinking about this, we could probably do many of these things even without any formal Emby notification by watching the file system for new TS files but it wouldn't be as clean.

[Spaceboy 2500]

Just to make sure we're on the same page.

What I think we all agree on is that having a Pre-Optimize feature would allow SOME types of processing to be kicked off at the start of the recordings. we could get a notification that Emby is about to start recordings X file name.

 

Once we receive the notification OUR external program/script could:

Be a notification engine and send a text, email, or any other type of notification we program that X program is now recordings. Someone else had just requested notification of when NFL games were being recorded so we could use this hook and send a message.

 

We could use this for starting to process the files behind the scenes such as running comskip against the ongoing file which can be done and IS done in NextPVR via an adding. Running it this way we could have a finished comskip cut file produced a about a minute or so after the recording is done. If this was recorded from cable where the provider is using H.264 already instead of mpeg2 then we simply cut the file using ffmpeg and remux it back together which could be done in 1 or 2 minutes. Thus we could have a commercial file in less than 5 minutes after the recording is done vs what could normally take 45 minutes to an hour using post-processing.

 

I'm sure we could find many other uses for this PRE recording notification. Hmm, just thinking about this, we could probably do many of these things even without any formal Emby notification by watching the file system for new TS files but it wouldn't be as clean.

your ability to state what has already been very efficiently stated in up to 10 times the verbosity is very impressive. I’m bored of you however. You’ve been essentially just repeated the whole thread and even taken my suggestion from the nfl thread to make yourself sound more important. And please the cayars thread? The best on plex? If you were a lollipop you would lick yourself

[CBers 6780]

If you were a lollipop you would lick yourself

 

[PenkethBoy 2063]

You do realize Luke had to pull MKV transcoding support during recording right?

I'm not saying this couldn't be done, but it's not nearly as easy as you think it is.

 

Converting files and replacing them when they aren't open or used is cake. Converting files and writing files with indexes when you don't have the full file to be able to build indexes and moov atoms is another thing.  You don't get optimized files and would want to still reprocess them yet again to fully optimize them.

Wow - i must be very stupid then - I wonder why i created a Post-Processing script - hmmm let me think - oh yes it was because Luke took away the MKV transcode on the fly!!

 

Funny though it works with MKV's and its not hard to do.

 

Optimised files are not the goal - stop thinking from you limited perspective - others have issues you dont have and vice versa

 

this is LiveTv which by its nature is poor quality/prone to errors in the streams and has audio sync errors as well recently - so requires a re encode to re sync the audio so plays in sync in Emby.

 

As for my earlier comment re how does emby do transcoding on the fly - well you play a ts while its still recording and Emby will transcode on the fly (to a MkV) if your client does not support the ts stream - no different to running an InProgress PP script

[Carlo 4331]

your ability to state what has already been very efficiently stated in up to 10 times the verbosity is very impressive. I’m bored of you however. You’ve been essentially just repeated the whole thread and even taken my suggestion from the nfl thread to make yourself sound more important. And please the cayars thread? The best on plex? If you were a lollipop you would lick yourself

If that's you're take.  A lot of what was said can't be done as is and I was trying to clarify for those that don't understand. I then tried to sum up what could be done and gave a few examples. Sorry if that bored you.  Concerning said other thread, I didn't say "best" I said "popular" and would be at the top of the list because of that to make it easy to find (was asked).  Different things my friend. I apologized in that thread for hijacking it and also sent a PM to the mod and OP with an apology as well as to ask the mod to remove all my posts from it. Then I butted out as that thread was clearly about someone's else script/work not a general conversation. I tried to write my wrong (I was).

 

Wow - i must be very stupid then - I wonder why i created a Post-Processing script - hmmm let me think - oh yes it was because Luke took away the MKV transcode on the fly!!

 

Funny though it works with MKV's and its not hard to do.

KEY WORD: "Post-Processing". You started with a file that was complete. You ran a script that converted a file and wrote it out completely then used that file.  Neither file was open or being written to it when being used. All parts of the file including the indexing was written and usable.  That's a lot different then many things mentioned in this thread so you can't assume the same thing works with open files without proper indexing or stream headers. See below:

Optimised files are not the goal - stop thinking from you limited perspective - others have issues you dont have and vice versa

Read the OP Post.  What is being asked for as I read it is best done by Luke during recording (conversion aspect).  He can compress or change the codec but would still need to save the file as a TS file package.  I Never said it was the ONLY goal and stated multiple things that could be done. You could comskip, remux, use filters,convert CC to subtitles, convert, etc  But these would all essentially be "post processing" type features that are started during the recording to make the overall process faster timeline wise.  You couldn't reliably use them however until the file is finished recording and you write/replace the file and Emby has scanned them.

 

this is LiveTv which by its nature is poor quality/prone to errors in the streams and has audio sync errors as well recently - so requires a re encode to re sync the audio so plays in sync in Emby.

 

As for my earlier comment re how does emby do transcoding on the fly - well you play a ts while its still recording and Emby will transcode on the fly (to a MkV) if your client does not support the ts stream - no different to running an InProgress PP script

For LIVE-TV WE can't change the package or codecs on the fly like you mentioned as Emby has no knowledge of it (alternate file being written).  Emby is still going to be playing back from the TS file.  You can do it AFTER recording as you do in your present script or start the process while it's being recorded and then replace the original file shortly after it's done recording but this doesn't help with actual LIVE-TV while it's being recorded as presently implemented in the apps. Only Luke & ebr, etc can do that.

 

SOMETHING CONSTRUCTIVE and POSSIBLE WORK-AROUND

If you think you know how to fix or resolve LIVE-TV with a pre-processing script, have at it.  For testing you don't need any notification from Emby.  Start a recording, go look at the file system and grab the TS file name being recorded and use that for any test script/program you want to work on.  We can all do this today for testing. Even without an Emby notification we can watch the file system recording directory for new files.

 

That will allow you to test anything you want like this.  I don't see how this could help the LIVE-TV situation because you could be building an MKV (or any other type) file but Emby will still be using the TS file as that is all it knows about and what the server/apps are going to use by default.

 

I'll do that right now

1 created new lib "InProgress"

2 started recording of show on OTA using mpeg2 "CBS News Sunday Morning"

3 ran the following ffmpeg command line from the path where InProgress was setup

 

C:\Convert\ffmpeg -i "X:\EmbyDVR\Series\CBS News Sunday Morning\CBS News Sunday Morning 2018_09_23_09_00_00.ts" -c copy -c:v libx264 -preset medium -vf yadif=0:-1:1 -crf 23 "CBS News Sunday Morning 2018_09_23_09_00_00.ts"

 

4 tried this as TS & MKV and also simplified the ffmpeg commands as well to:

 

C:\Convert\ffmpeg -i "X:\EmbyDVR\Series\CBS News Sunday Morning\CBS News Sunday Morning 2018_09_23_09_00_00.ts" -c copy -c:v libx264 "CBS News Sunday Morning 2018_09_23_09_00_00.ts"

 

5. Refeshed "InProgress" library so system found file (impatient).

 

Both would play.  MKV would throw an error in Shield TV that it can't seek (no index).  TS can seek as expected.

 

HOWEVER, both would end when it got to the length as found by the library scan. By this I mean if there was 1 minute of file when I scanned the library that is the duration Emby thinks the file is and would stop playing when it got to that point on the Shield TV.

 

If I rescanned the library and waited until it processed the file I would then get 10+ minutes of video and can seek (TS) and use 10 minutes of file but then hit the same problem again until I rescan the library again and repeat.  Since Emby thought it played the file to the end it doesn't create a resume point so each new playback starts at the beginning.

 

Using Stats for Nerds, Emby showed the transcoder changing the package to HLS for delivery to the client.

 

These are some of the obstacles we're going to hit trying to "fix" Live-TV or creating a work-around for in-progress recordings (while trying to watch them). As far as I can tell we can't work around this without core Emby changes.

 

I did not try to segment the video and create manifests which can be done via ffmpeg. Might be worth a try if Emby can use them (not sure) as a source format.

 

Don't take my word for it.  Try this yourself or whatever else you were thinking about. I just don't see how we can "fix" Live-TV or inprogress recordings.