(2013-02-02, 17:20)Prof Yaffle Wrote: I suspect you'll find that everything records in the format in which the stream is received, typically MPEG2 for SD and H.264 for HD.
Actually, most HDTV content in the USA is MPEG2. h264 Is the format primarily used for encoding Blu-ray discs. In my case, I'm talking about HDTV via Comcast cable, which is going to be primarily MPEG2. From what I've heard, there are cable companies using h264 for some channels, and perhaps they're moving in the direction of all-h264, but for now, most of it is MPEG2. Perhaps it's encoded as h264 in the UK?
(2013-02-02, 17:20)Prof Yaffle Wrote: Transcoding while receiving would be problematic, in that you'd have to either hope that you're encoding more slowly than receiving (so you never reach the end of the recorded file prematurely) or else have to keep pausing while you got some more data.
I would think that it should be relatively easy for transcoding software to be designed such that it could slow down, if necessary, to a 1:1 speed. Basically, it just needs to be transcoding frame-by-frame, and if it completes the transcoding/writing of a frame and the next frame hasn't been "served up" yet, it would just wait till it gets it. It would also be checking to see when the source file is "complete". But perhaps I'm wrong and what I'm describing is a lot more difficult than that. FWIW, the upcoming SiliconDust HDHomeRun Prime will be doing this sort of thing via a hardware h264 encoder.
(2013-02-02, 17:20)Prof Yaffle Wrote: Are you transcoding for consumption on a different device, are you trying to save space, or something else?
Primarily the first reason, but the 2nd is a bonus. There is no shortage of devices that can handle h264 via their GPU, but hardware MPEG2 decoding is rarer, for whatever reason. My specific needs/desires are for iOS support. With an MP4 source format, I could play it easily on my iPhone and even push it over to the AppleTV via AirPlay. The smaller filesizes will be a bonus, too, as it will require less-than-optimal network bandwidth. Streaming MPEG2 HDTV over even 802.11n can work under ideal conditions, but multiple clients at the same time? Forget it. Then there's the added bonus of significantly smaller filesizes in regards to hard drive storage. And you can take some of your shows on-the-go on an iPhone with limited local space, if desired.
As I mentioned, the upcoming SiliconDust HDHomeRun Prime refresh is going to support this natively, but that may not come till much later this year, I've got a server that should be capable to handle it (desktop Intel i7-2600K), so I'd like to see what can be done. Now, perhaps I'm being overly ambitious, because if you're working with 3 simultaneous MPEG2 streams, you would need to be able to have the software handle on-the-fly transcoding/recording at 3x real-time, or else it would lag behind. I suspect that my i7 could handle that, but it might require sacrificing some PQ (lower bitrate). But I've also got a 2nd HDHomeRun Prime which I was planning to hook up, and that would open up the possibility of 6 simultaneous streams.
In any case, I don't doubt that software *could* accomplish what I'm asking, even if real-time performance for multiple streams was not feasible, and I'm curious if any of the existing back-ends might already support this to some extent. Hopefully some folks who have some in-depth knowledge of the various PVR back-ends can provide their insight.
