BD Rebuilder Beta - Bug Reports Only

[mparade]

Originally Posted by Sharc

Does your x265 interlaced encode look much different compared to an x264 interlaced encode of the same interlaced (or telecined?) source?
In any case, your player should deinterlace (or inverse-telecine) the encoded interlaced (telecined) stream, otherwise you will see combing especially in action scenes.
I am not familiar with PowerDVD or Kodi, but usually SW players have the option to force deinterlacing. (I am not even sure if any affordable HW players for HEVC/h.265 already exist)

It looks much different compared to the original true interlaced source which was mpeg2 encoded while using the same deinterlacing parameters in PDVD. PDVD has quite advanced deitnerlacing options. While watching the original true interlaced m2ts container, one even couldn't recognize any combing that is why I assumed there could be
some eventual problem with the settings of the x265 commandline I used.

Anyway, I haven't made x264 reencoding on the same source to check if there would be any combing with that.

Anyway, thank you for your answer.

[mparade]

Originally Posted by MrVideo

Interlaced video, by definition, will have "combing" when there is motion. It is a fact of life with interlaced video. We've lived with it since TV broadcasting became a standard. Since moving to digital video, it seems that many expect the combing to go away. It won't.

The only way to remove combing is to deinterlace pure video sources, or IVTC 23.976 sources that were converted to 29.97 interlaced. I personally do not like deinterlacing as it removes spatial info and can reduce vertical resolution. Deinterlacing has gotten really good over the years, but nothing is a good as the original.

If the video came from a 23.976 source, I certainly recommend IVTCing from 29.97 to 23.976. I do it for ALL of my 1080i material, as I prefer the original 1080p23.976 video.

Having said all that, here is the sticky wicket in all of this. No digital playback viewing device displays images by interlacing. That has vanished. It is all progressive now. So, the display device will handle the deinterlacing. And those sets that are 120Hz (really 29.97 x 4) can deal with the interlaced video, keeping the spatial info intact.

But, if the interlaced video is stored as progressive, where the two fields are combined into a single frame, then deinterlacing can't take place. Maybe the interlacing flag needs to be added. I know that if I forget it with x264 encodes, I see that x264 is doing 1080p instead of 1080i encodes.

Thank you for the explanation! My source was true interlaced.

[Lathe]

Originally Posted by MrVideo

I know this isn't an AVISynth class, but IIRC, anything in the plugins directory is automatically loaded. LoadPlugin is used when the DLL isn't in that directory.

BTW, I have the WotW DVDs and never noticed anything wrong with them. I think I still have my sat feed recordings of the series as it was fed from Paramount to the affiliates. All on Umatic tape. Yep, that goes back a ways.

Heh, well, like I say, I am definitely NO expert. Just trying to help. It SORT OF sounded like the kind of files I had.

FWIW, I did indeed buy the Season 1 set on DVD, used. I can't remember if it was from the UK or from here in the U.S. It was the Season 2 files that I was having trouble with, and I remember it took me quite a while to find a thread somewhere where someone HAPPENED to mention these Avisynth commands, and they happened to work

IIRC (since it's been over a bloody YEAR since I dealt with this) I think what the deal was that the actual video looked interlaced, but it was encoded progressively. Even when I tried to play the native files on my OPPO, the deinterlacing apparently was not 'triggered' and you could see all the combing, etc... So, whatever this fellow was talking about reminded me of this uniquely odd situation that I had.

Oh, and to tie it in to the overall discussion here (well, sort of... ) The thing that got me started with these files is that BDRB's built in deinterlacers didn't have any affect on the files - I'm GUESSING because they were encoded progressively and therefore didn't flag the fact that the video itself actually was (or looked) very interlaced. And I was puzzled thinking, wouldn't BDRB simply just re-encode the files and make them right? So, that is what got me started on the long quest to figure out what to do...

[AmigaFuture]

Originally Posted by Sharc

Yes, agree.
Without more info/tests or without analyzing a sample it remains speculative as to where the OP's problem comes from:
- problematic source (can normally be excluded with Blu-ray discs)
- wrong interpretation of the source format
- incorrect decoding and/or frame serving
- encoder issue (settings or bug)
- or simply a problem with the playback/player.
A sample of the source and encode would be helpful. (I never tried interlaced encoding with x265 though).

TiVo file edited to remove commercials with VideoReDo TVSuite to produce MPEG-2 .TS that isn't rerendered or transcoded.

[Sharc]

Originally Posted by mparade

It looks much different compared to the original true interlaced source which was mpeg2 encoded while using the same deinterlacing parameters in PDVD. PDVD has quite advanced deitnerlacing options. While watching the original true interlaced m2ts container, one even couldn't recognize any combing that is why I assumed there could be
some eventual problem with the settings of the x265 commandline I used.

Anyway, I haven't made x264 reencoding on the same source to check if there would be any combing with that.

Anyway, thank you for your answer.

I made a quick test with x265: Encoding a TFF interlaced source to a TFF interlaced target. Although x265 reported "x265 [warning]: Support for interlaced video is experimental" the interlaced output was fine after muxing the .265 to .m2ts with tsMuxeR.

script interlaced_.avs

LoadPlugin("c:\.....\DGDecodeNV.dll")
DGSource("c:\....\i_source.dgi",fieldop=0)

x265 commandline:

"C:\.....\avs4x265.exe" --x265-binary "c:\....\x265.exe" --crf 27 --preset faster --interlace tff --output "c:\....\interlaced.265" "c:\....\interlaced_.avs"
pause

[mparade]

Originally Posted by Sharc

I made a quick test with x265: Encoding a TFF interlaced source to a TFF interlaced target. Although x265 reported "x265 [warning]: Support for interlaced video is experimental" the interlaced output was fine after muxing the .265 to .m2ts with tsMuxeR.

script interlaced_.avs

LoadPlugin("c:\.....\DGDecodeNV.dll")
DGSource("c:\....\i_source.dgi",fieldop=0)

x265 commandline:

"C:\.....\avs4x265.exe" --x265-binary "c:\....\x265.exe" --crf 27 --preset faster --interlace tff --output "c:\....\interlaced.265" "c:\....\interlaced_.avs"
pause

I think here the problem is that --interlace false is used by default by x265 (assuming progressive input). I am only making my assumptions.

[Sharc]

Originally Posted by mparade

I think here the problem is that --interlace false is used by default by x265 (assuming progressive input). I am only making my assumptions.

You could inspect your .265 or .m2ts with MediaInfo. It should report under Encoding Settings "interlaced=1".

[jdobbs]

I'll look at adding that for the next release. I looked at the code and had that parameter commented out -- which scares me, because I can't remember why.

[Sharc]

Originally Posted by jdobbs

I'll look at adding that for the next release. I looked at the code and had that parameter commented out -- which scares me, because I can't remember why.

Has perhaps this been the reason?
http://forum.doom9.org/showpost.php?...31&postcount=2

[mparade]

Originally Posted by Sharc

You could inspect your .265 or .m2ts with MediaInfo. It should report under Encoding Settings "interlaced=1".

I will give you a feed back on this issue after checking the x265 encoded interlaced stream in mediainfo. Anyway, as far as I know, it is not enough to let x265 know that the source is interlaced by using a parameter such as --interlace tff in the command line but the avs file itself should have a SeparateFields() also at the end for the --interlace tff parameter to work properly.

[jdobbs]

Originally Posted by mparade

I will give you a feed back on this issue after checking the x265 encoded interlaced stream in mediainfo. Anyway, as far as I know, it is not enough to let x265 know that the source is interlaced by using a parameter such as --interlace tff in the command line but the avs file itself should have a SeparateFields() also at the end for the --interlace tff parameter to work properly.

That really doesn't make any sense. You don't have to do that in X264.

[sneaker_ger]

x264 is a different software so that point is irrelevant. The x265 docs say:

HEVC encodes interlaced content as fields. Fields must be provided to the encoder in the correct temporal order. The source dimensions must be field dimensions and the FPS must be in units of fields per second. The decoder must re-combine the fields in their correct orientation for display.

http://x265.readthedocs.org/en/default/cli.html
Do not assume because you can play it back in e.g. MPC-HC that it is encoded correctly.

[jdobbs]

Originally Posted by sneaker_ger

x264 is a different software so that point is irrelevant.

It is certainly based (from an interface standpoint) on X264, though. For the most part the command line parameters (that are supported) are the same. I'm guessing this was the reason I'd not used the --interlace parameter in the past (although I really can't remember).

Separating the fields and adjusting to fields-per-second is easy enough... but it would sure make a lot more sense for the encoder to separate them.

Is it my imagination, or does it seem like people are getting more "snippety" on DOOM9 lately?

[Sharc]

Originally Posted by sneaker_ger

x264 is a different software so that point is irrelevant. The x265 docs say:

http://x265.readthedocs.org/en/default/cli.html
Do not assume because you can play it back in e.g. MPC-HC that it is encoded correctly.

Is this info up-to-date? I didn't have to separate the fields.
When I separated the fields x265 produces just encoded fields ("bobbing" half-height).
Interlaced encoding with x265 seems still not to be stable, according to the warning of the encoder.

[sneaker_ger]

Originally Posted by Sharc

When I separated the fields x265 produces just encoded fields ("bobbing" half-height).

What do you mean by "produced"? You in mean in your player? How do you know your player isn't the one handling HEVC interlaced incorrectly? Or your muxer?

[CV91913]

Originally Posted by jdobbs

Is it my imagination, or does it seem like people are getting more "snippety" on DOOM9 lately?

No, it is not your imagination. Not just Doom, but every forum I follow. It is a sign of the impersonal times. The passive aggressive tone that would not be tolerated in a person to person interaction, has become the norm.

[Sharc]

Originally Posted by sneaker_ger

What do you mean by "produced"? You in mean in your player? How do you know your player isn't the one handling HEVC interlaced incorrectly? Or your muxer?

I am using MPC-HC with madVR and LAV 0.68 for playback......

[sneaker_ger]

That seems to be one of the combinations that doesn't play it correctly. I don't think it would be a good idea to create non-spec-compliant encodings to account for broken player. If the players get fixed eventually the encodes would break again. (and rightfully so)

[Sharc]

Which player / combination should I be using then in order to play HEVC (x265) interlaced material correctly? Any recommendation? Thanks.

[sneaker_ger]

No idea. Nobody seems to care about it, in part because of missing tools like MBAFF.