Tvheadend 3.4
#31
Regarding to Handbrake, I can't find equivalent for ffmpeg's '-acodec copy'. No matter what I do, it always wants to reencode my audio, even when I don't want it. It's really annoying for me. Passthru also affects audio, why can't just tell Handbrake to left audio completly untouched?

About conversion. I don't know how mpeg2 ota streams looks like, in my country there are mpeg4/avc channels only and they are good enough for me and I see no reason for reencode them. I'm only considering now if it's worth to encode to hevc my 1080i recordings to reduce bitrate and file size.

Perhaps you are right about mpeg2, I believe they are encoded with higher bitrate to get reasonable video quality and produces large files.
Reply
#32
I've never examined the audio passthru setting, so I'd assumed it ... well, passes through, but clearly it doesn't! I think your only option would be to demux, encode and then remux the audio (e.g. mkvmerge).

For MPEG-2 (SD only here, all HD is H.264/AVC), I've found it beneficial to re-encode to H.264 with decomb on... makes a better picture than deinterlacing IMO, plus is really quick.
Reply
#33
(2014-10-11, 22:35)Prof Yaffle Wrote: I've never examined the audio passthru setting, so I'd assumed it ... well, passes through, but clearly it doesn't! I think your only option would be to demux, encode and then remux the audio (e.g. mkvmerge).
I can always remux, but no reason for this, since I can use ffmpeg instead and get mkv that doesn't need to be remuxed.
Reply
#34
Thx again guys for all the infos!

I'm located in North America and unfortunately here all public TV stations broadcast in mpeg2 format for HD stream over the air. I heard that it is different in other part of the world. I hope that this will change to H.264 eventually to get smaller file by default from my recordings.
Reply
#35
I have finally play a little with avidemux and handbrake and so far my favorite is handbrake. It's really a well made app and it is doing one hell of a job to resize, encode and decomb my mpeg-2 recordings.

Those are the handbreak settings that have worked best for me (best value for quality and size):

Picture settings > dimension > 1280 x 720

Picture settings > filters > Decomb > Default

Format > MKV

Video > Encoder > x264

Framerate: 24 (Constant Framerate)

RF: 18

H.264 Level: 4

Audio > Encoder > AC3 Passthru (5.1 ch)

bitrate: 384

Now that I can make good quality h.264 with a reasonnable file size, I need to find a good way to remove commercials from my recordings. I have try removing them manually with avidemux and openshot but I had encounter some video anomaly or some app freezes during my tests. Anyway, my HTPC has only a Celeron Haswell Dual Core CPU and I'm wondering if the issues encountered with both video editor are related to my CPU. I will try on a i7 Quad Core tommorow to see if it's working fine on a more powerful box.

By the way, how are you dealing with commercials removal? Are you doing it manually each time or do you use a app to detect automatically all the ads?
Reply
#36
Removing ads is difficult to automate - it's highly dependent on having some unique flags that can be spotted when analysing the video stream (e.g. if the channel logo disappears, if there's a clear couple of black frames on entry/exit from the break, and so on). Comskip does as good a job as any, but needs tuning.

For avidemux, I've found 2.6.7 more stable than 2.6.8 (on Linux, anyway). If you're getting video anomalies, you're probably not cutting in the right places... you need to know a bit about how videos are compressed before you realise that you can only really cut when you have an entire frame (I-frames or key frames in H.264), and not when it's only a part frame (B- and P-frames). Cutting on a partial frame obviously causes problems because they use information from previous (P) or previous/next (B) frames, and you've just chopped those out. When re-encoding in Handbrake, you can create more frequent I-frames by adding keyint= and keyint-min= to the advanced options - these determine how often a key frame is generated (think about your frame rate to determine how often, e.g. keyint=12 on a 24 fps stream gives you one every half second - versus a default of perhaps one every 300 frames, depending on the content and how much it's changing). Obviously, more key frames increases file size slightly, but that's your choice. You could also cut the file *before* compressing, as MPEG2 is easier to slice due to its simpler encoding algorithm.

Other thoughts:

1. Handbrake's defaults are pretty good in most instances (e.g. H.264 profile).

2. RF18 is possibly overkill for OTA broadcasts - RF 20 or even 22 will give you smaller files without any perceivable loss in my experience.

3. I'd always leave the framerate as 'same as source' - you're less likely to get sync problems (although HB does a good job at avoiding those)

4. CFR vs VFR... personal choice. VFR will give you a slightly smaller file, but it'd be slightly less portable as not everything can play variable rates (so I've been told)

5. You can't set bit rate and RF as they're different approaches to the same thing. Personally, I use RF, although I used to use bitrate (and file size) when I started... it depends on what's important to you (e.g. if you need to control bit rate because of your link speed or want to make sure that files are no bigger than 1Gb/hour once compressed).

It's all up to you, though, and feel free to ignore me if you're happy with how it's working at the moment!

And your CPU should do it, it may just take a touch longer than your i7.

Heading a bit off topic for either XBMC or tvheadend now, though...
Reply

Logout Mark Read Team Forum Stats Members Help
Tvheadend 3.40