HD video additions to the guides - Ripping

[BasharOfTheAges]

How common is the last point, though? I've yet to see a BRD that isn't progressive scan (i.e. there's no reason to IVTC) and I can't say I know enough about various filters that play with ordered frames that aren't all about de-interlacing.

Blu-ray can only store interlaced video at 30fps. Hence, anything that's supposed to be 30fps can only be stored as interlaced. For 720 this is less of a concern because 720p60 is supported, but 1080 is restricted to just 1080p24 or 1080i30 (or 1080i60, if you go with the way the spec says it - still the same thing because they're talking fields, not frames).

Whether you see it in the wild is another matter, but the possibility exists (and what are the chances that the weirdness that occurs with DVD hybridism is rendered impotent on Blu-ray?).

Must be my sample size then. I'm 4/4 with 1080p24. Mayhaps I'll eventually find something that rips as 1080i30. I take it that's the old film/broadcast dichotomy showing up in this format again?

It's all rather far-reaching to discuss at this point. Until GPU rending becomes commonplace, people aren't going to have the patience to use such large formats - the filtering takes for fucking ever to do.

[Qyot27]

Or at least until AviSynth (and external filters) gets proper 64-bit integration. 2.6 at least will have native multithreading once it reaches final, but adding 64-bit support requires a lot of code gutting and revision from the way I've seen it discussed. The existing AviSynth64 doesn't do enough to fix the problem once and for all.

In the meantime, I'd settle for multi-pass filtering and then just natively use 64-bit interfaces (like outputting to .y4m and giving that file directly to 64-bit x264, or piping).

[mirkosp]

I worked with the Blu-ray release of Mushi-Shi, which is telecined. Other telecined BDs, for example, are Air and CANAAN, as far as I know. By the way DSS2 did great with mushi-shi, if that's any concern. But well, in my experience I haven't had any frame accuracy issue with DSS2, although I am now aware that there might be (thanks for the link, qyot). An issue I did have with it, though, was when I was trimming. If I had the trim start at 0, everything is fine, but if I had a trim that started at something different than 0, avisynth would shit brix on me. Now since DGAVCIndex isn't an option anymore (no longer supported etc., so I don't trust the use), and I prefer my cpu over my gpu (admittedly, my GPU has CUDA, but it's just a geforce 9600GS, so...), I decided to go with dss2, even more 'cause loading with ffmpegsource/2 would just crash avisynth. >_<
So basically what I do is use dss2 to convert the whole m2ts to lossless, with the quality filters in the chain (generally just antialiasing and/or debanding, if anything, really), and then I do the trimming from the lossless.
I think that in blu-ray cases the PTS timestamps are supposedly reliable, or at least experience so far makes me hope so, although the trimming issue (which I only had on the Macross Zero blu-ray, by the way) admittedly might have to do with it...

[Qyot27]

I decided to go with dss2, even more 'cause loading with ffmpegsource/2 would just crash avisynth. >_<

It would crash during the indexing phase or playback? I do find it's far easier (and more convenient) to use ffmsindex to render the index files for FFMS2, although the downside is that it's still just CLI* - albeit there are pushes for a Qt-based GUI for it down the line. That was mentioned on Doom10.

*ridiculously easy:
ffmsindex inputvideo.ext
is all that's required for using FFVideoSource by itself.
ffmsindex -t -1 inputvideo.ext
will act as FFmpegSource("video.ext",atrack=-1) does.
ffmsindex -t -1 inputvideo.ext index.ffindex
can be specified if you want to keep your index files in a specific place and use the cachefile parameter to load them.

The benefit, of course, is that using the indexing app is a lot faster and less hefty than trying to write the index by playing the script in WMP or MPC. And it gives you a progress meter. I added C:\Program Files\AviSynth 2.5\plugins to Windows' PATH, so I don't have to worry about updating it manually every time FFMS2 updates. Otherwise you could just throw it in C:\WINDOWS and be done with it, but have to copy new versions there on each update. The Open Command Prompt Here powertoy from Microsoft or the alternate shell extension from code.kliu.org can really make your life easier with that. Note: Vista, and I also assume Win7, users can just right-click while holding Shift to bring up the native Open Command Window Here option, but it is nice to not have to remember that every time you want to use it.

I think maybe I should write a more general primer on doing CLI work and writing batch scripts so I don't have to keep repeating myself on that.

[Willen]

Blu-ray can only store interlaced video at 30fps. Hence, anything that's supposed to be 30fps can only be stored as interlaced. For 720 this is less of a concern because 720p60 is supported, but 1080 is restricted to just 1080p24 or 1080i30 (or 1080i60, if you go with the way the spec says it - still the same thing because they're talking fields, not frames).

Whether you see it in the wild is another matter, but the possibility exists (and what are the chances that the weirdness that occurs with DVD hybridism is rendered impotent on Blu-ray?).

I think you meant to type 1080p30.

The reason the BD specs say 1080i60 and not 1080p30 is because if done properly, you can use that interlaced signal to store true 60i and 30p footage. If you are encoding native 1080i60 ATSC video you are golden. If you have 1080p footage shot at 30 frames per second, possibly from some AVCHD cameras or video-capable DSLRs, it would be stored as interlaced field pairs on the BDs (i.e. 1080p30 converted to 1080i60). It should be no different than how DVDs handle pure interlaced material derived from 30 (29.97) frames per second original footage. De-interlacing on playback should be pretty straightforward to reconstruct the original 30 frames.

As for if the footage is properly flagged as pure interlaced or field pairs for correct playback, I don't know...

BTW, most 1080i60 BDs I've encountered are of the National Geographic documentary type. Most of them are shot with HD video cameras which operate at 60i (NTSC/ATSC). I would imagine the expense of shooting in 35mm film (or even IMAX) would go above the budgets of most of the programs.

[Qyot27]

I think you meant to type 1080p30.

The reason the BD specs say 1080i60 and not 1080p30 is because if done properly, you can use that interlaced signal to store true 60i and 30p footage. If you are encoding native 1080i60 ATSC video you are golden. If you have 1080p footage shot at 30 frames per second, possibly from some AVCHD cameras or video-capable DSLRs, it would be stored as interlaced field pairs on the BDs (i.e. 1080p30 converted to 1080i60). It should be no different than how DVDs handle pure interlaced material derived from 30 (29.97) frames per second original footage. De-interlacing on playback should be pretty straightforward to reconstruct the original 30 frames.

As for if the footage is properly flagged as pure interlaced or field pairs for correct playback, I don't know...

BTW, most 1080i60 BDs I've encountered are of the National Geographic documentary type. Most of them are shot with HD video cameras which operate at 60i (NTSC/ATSC). I would imagine the expense of shooting in 35mm film (or even IMAX) would go above the budgets of most of the programs.

No, I meant 1080i30 - I default to referring to fps by the proper # of frames, no matter whether the method is interlaced or progressive. 30 frames per second, interlaced, rather than 60 fields per second, interlaced (in which case saying 'interlaced' is redundant). The European Broadcasting Union denotes it in a similar manner, 1080i/30 or 1080i/25 - I'm just too lazy to bother putting a slash in there like they do.

When you mention field pairs though, are you talking about [essentially] pulldown flagging (I assume not, considering you're talking about deinterlacing on playback)? Faking out a player by using the interlaced flag on progressive footage? I've seen talk of that on Doom9, but the general impression I got from there is that it's iffy whether all Blu-ray players support it, or whether it's simply an assumed trait.

The point being, that unlike DVD where you could have a progressive 29.97fps stream stored as Progressive, you're not allowed to do that on Blu-ray for whatever stupid reason (no matter what resolution you're talking about - 480, 720, 1080: all of them say i60, not p30). Sure, you can reconstruct 1080i into 1080p using TFM just like you can do with DVD footage, but 'reconstruct' and 'supports 30 fps progressive' are two different things. '30p' means it had better be stored progressive, no reconstruction necessary. Hence the flagging trick I mentioned earlier that doesn't seem to be spec-compliant even if the players accept it.

[Willen]

No, I meant 1080i30 - I default to referring to fps by the proper # of frames, no matter whether the method is interlaced or progressive. 30 frames per second, interlaced, rather than 60 fields per second, interlaced (in which case saying 'interlaced' is redundant). The European Broadcasting Union denotes it in a similar manner, 1080i/30 or 1080i/25 - I'm just too lazy to bother putting a slash in there like they do.

Ah, I see. The lack of a slash threw me off. I prefer using the U.S./Japan broadcasting terminology since when it comes down to it, 60 fields isn't always exactly 30 frames. Which is why some U.S. broadcasters use 720p60 capture/transmission to avoid de-interlacing artifacts when shown on progressive scan devices (pretty much all modern HDTVs). Logically, the EBU notation is more consistent since the final number is always frame rate (instead of scanning frequency), but after working with NTSC (and now ATSC) devices for over a decade, I'm kinda set in my ways.

When you mention field pairs though, are you talking about [essentially] pulldown flagging (I assume not, considering you're talking about deinterlacing on playback)? Faking out a player by using the interlaced flag on progressive footage? I've seen talk of that on Doom9, but the general impression I got from there is that it's iffy whether all Blu-ray players support it, or whether it's simply an assumed trait.

The point being, that unlike DVD where you could have a progressive 29.97fps stream stored as Progressive, you're not allowed to do that on Blu-ray for whatever stupid reason (no matter what resolution you're talking about - 480, 720, 1080: all of them say i60, not p30). Sure, you can reconstruct 1080i into 1080p using TFM just like you can do with DVD footage, but 'reconstruct' and 'supports 30 fps progressive' are two different things. '30p' means it had better be stored progressive, no reconstruction necessary. Hence the flagging trick I mentioned earlier that doesn't seem to be spec-compliant even if the players accept it.

I meant using interlace flags to store 30fps progressive footage (essentially tricking the players to do Progresssive segmented Frame playback). I'm in the camp of assuming that most BD players will handle 30PsF progressive footage flagged as interlaced properly. I actually have all the hardware I need to confirm whether my stand-alone players support it (PC burner, PS3, BD player), but it hasn't been a priority. It's only recently when 1080p30 (29.97) recording capable cameras (DSLRs such as the Canon EOS 7D) have become popular that the question has risen to importance.

I'm actually still a bit surprised that while the ATSC spec allows for a 1080p30 format, Blu-ray (which was finalized much later) ignored it. Although, again, until recently there was very little professional-level hardware that used that format.

And there may be a way to store 29.97fps footage on Blu-ray: record it as 720p60 (59.94) with duplicated frames. This is how 30p video is recorded on AVCHD Lite cameras. Although now you are dropping resolution down...