Best Recording Format?

[EnterNoEscape]

Originally Posted by Fuzzy

If I knew anything about .c, I'd probably look at adding the stv: (media server) format to ccextractor, as that sounds like it'd be the most versatile thing in the end. I mean, there is MythTV specific code in there, don't see why there shouldn't be SageTV specific code in there as well.

The MythTV code is for reading files written by MythTV and nothing more which is a lot easier to implement than this proposal. The only problem is that from what I have seen in the code, all of the encoders are using the write(int,const void*,size_t) function to write out the file as you might expect. It only currently supports streaming in a specific format which would suggest maybe this is not trivial. I have never created a custom file descriptor and that would be the only way to fix this without needing to apply a patch that would affect a large number of files.

As an alternative, we could use the code already in there to stream to a TCP port and modify it slightly to recognize a SageTV media server (stv://) which would have it use the SageTV media server protocols. The only downside there is the same one I mentioned before. The stream will be a proprietary binary stream that faithfully represents the the original caption data, but needs to be further processed within SageTV to actually be displayable. At this rate, there would actually be very little gained by streaming directly through the executable over streaming stdout through OpenDCT.

[graywolf]

Originally Posted by Fuzzy

Alternatively, using OpenDCT to actually transcode the file to h.264 would provide a very portable file, but does take a decent chunk of cpu on the server to do, especially with multiple streams.

Because I'm curious and also would be helpful info when I get to V7.

I know that V7 embeds metadata into the file. so if you lose your wiz.bin, you could rebuild from the metadata in the media files.

I believe I remember that if you manipulate the media file, you lose the metadata. So would that be true for transcoding also?

[Monedeath]

Originally Posted by graywolf

I believe I remember that if you manipulate the media file, you lose the metadata. So would that be true for transcoding also?

I think that depends on what you use to do the Transcode. If it's SageTV, you probably have a decent chance. If it is something else, odds are the file metadata is toast.

[Tiki]

Originally Posted by Monedeath

I think that depends on what you use to do the Transcode. If it's SageTV, you probably have a decent chance. If it is something else, odds are the file metadata is toast.

And if OpenDCT (or some other tuner/encoder) is doing the transcoding as part of the original recording process, the metadata should be intact.

[Fuzzy]

Originally Posted by Tiki

And if OpenDCT (or some other tuner/encoder) is doing the transcoding as part of the original recording process, the metadata should be intact.

That's not entirely true. If OpenDCT is transcoding, and writing to disk itself, it doesn't know the metadata to put into the file (since all it is told is what channel to record, and what file to record it to). It is possible that if writing from opendct to the sagetv mediaserver, and through sage's builtin remuxer, it is POSSIBLE that it is writing the metadata, but I honestly do not KNOW that to be the case. I honestly don't even know how the metadata is stored in the recordings to check.

[EnterNoEscape]

Originally Posted by Fuzzy

That's not entirely true. If OpenDCT is transcoding, and writing to disk itself, it doesn't know the metadata to put into the file (since all it is told is what channel to record, and what file to record it to). It is possible that if writing from opendct to the sagetv mediaserver, and through sage's builtin remuxer, it is POSSIBLE that it is writing the metadata, but I honestly do not KNOW that to be the case. I honestly don't even know how the metadata is stored in the recordings to check.

I thought I noticed that SageTV would append it's own data post recording when I was updating the way all files are written last year. Take a look at this: https://github.com/google/sagetv/blo...gMetadata.java

In Seeker.java, addMediaFileMetadata(MediaFile) is called whenever a recording is ended or switch is called.

[Fuzzy]

Originally Posted by EnterNoEscape

I thought I noticed that SageTV would append it's own data post recording when I was updating the way all files are written last year. Take a look at this: https://github.com/google/sagetv/blo...gMetadata.java

In Seeker.java, addMediaFileMetadata(MediaFile) is called whenever a recording is ended or switch is called.

Huh.. I had seen that addMediaFileMetadata stuff, but for some reason never found where it was called. Makes sense.

[KarylFStein]

How do I have OpenDCT transcode to H.264 on the fly? I've tried all other things suggested (except post-recording transcoding) to try and get something that will work across what I use (Placeshifter local and remote, Android mini-client local and remote, and HD300 local). The only thing that works all the time is the HD300. Although I guess this won't help with the recordings from the 2250 . Nothing will skip reliably or in some cases even play.

[phelme]

Originally Posted by graywolf

I believe I remember that if you manipulate the media file, you lose the metadata. So would that be true for transcoding also?

Originally Posted by Monedeath

I think that depends on what you use to do the Transcode. If it's SageTV, you probably have a decent chance. If it is something else, odds are the file metadata is toast.

I use SJQ and Mediashrink to compress the files overnight as opposed to doing it in realtime; I like the flexibility they give me. The only metadata of consequence I've found to be lost is the original encoder/tuner info, for some reason there is nothing in the API I can locate to be available to retain that.

If you use SageTV's built-in transcoding though it's kept intact.

Edit: Hmm, I might be wrong about that last point. Just did a quick "Convert" in SageTV v9 and the "Encoded by:" line disappears in the info in the resultant transcoded MP4. Could have sworn this was kept in the past. I could be mistaken.

[bialio]

I've got almost all of my favorites that record in MPEG2 set to use SageTV's built in transcoding - I use the MPEG4 HDTV-High Quality H.264 MKV preset.

It cuts the size about in half. I haven't noticed any issues with playback on HD300, AndroidTV (Shield and MiBox) - both Wired and Wireless even. I don't have a place shifter that I use so I can't test that really. I also haven't noticed any issues with the server being over taxed. It converts one at a time and by the time I get around to watching anything it's already converted...

btl.

[KarylFStein]

Originally Posted by bialio

I've got almost all of my favorites that record in MPEG2 set to use SageTV's built in transcoding - I use the MPEG4 HDTV-High Quality H.264 MKV preset.

It cuts the size about in half. I haven't noticed any issues with playback on HD300, AndroidTV (Shield and MiBox) - both Wired and Wireless even. I don't have a place shifter that I use so I can't test that really. I also haven't noticed any issues with the server being over taxed. It converts one at a time and by the time I get around to watching anything it's already converted...

btl.

I've been using the same profile and with limited testing it makes playback much more usable across Placeshifter and Android. The only issue I've seen is that when the transcoding is running it seems to screw around with the Android mini-client, (UI freezes, playback jumping to end, etc.) I haven't had time to investigate further.

[Fuzzy]

Originally Posted by KarylFStein

I've been using the same profile and with limited testing it makes playback much more usable across Placeshifter and Android. The only issue I've seen is that when the transcoding is running it seems to screw around with the Android mini-client, (UI freezes, playback jumping to end, etc.) I haven't had time to investigate further.

While transcoding is running, or simply playing back a recording before it's completely transcoded and replaced with the h.264 mkv? Because that behavior sounds like iffy timecodes, which the transcoding will eliminate.

[KarylFStein]

Originally Posted by Fuzzy

While transcoding is running, or simply playing back a recording before it's completely transcoded and replaced with the h.264 mkv? Because that behavior sounds like iffy timecodes, which the transcoding will eliminate.

Sorry, this is just using the mini-client while a transcoding process is running. If I can navigate to a file (*one already transcoded*), and get it to play before the UI freezes, then I can get weird playback. But more often than not the UI freezes before I can play something. I tinkered with it for maybe 45mins one night before giving up and reading some of a book .

(By a freeze I mean it will just sit there and not respond to inputs. If I let it sit for a couple minutes, it will move a little then freeze again.)

I haven't had time to collect better information. When I first decided to transcode everything it took a few days to get through. I just tried a couple times to watch things on my tablet during that then decided to wait until all transcoding jobs were done before trying again. Now that it's done, (well, I skipped transcoding the 2 million or so Simpsons episodes we seem to have now--I don't know which one of my kids set that as a favorite and to record reruns, but since we've never recorded the Simpsons before there are a LOT of reruns being grabbed), tablet viewing works fine. That's just based on watching a couple shows on the tablet last night.

I watched some things via Placeshifter while the transcoding was going on and that worked fine.

Anyway, I should do some more tests, but not sure when I'll get around to it. I will say that after transcoding, I have not had a single issue with Placeshifter or tablet playback where before I had pretty much given up on them as basically nothing skipped properly. I blame Comcast .