BD Rebuilder Beta - Bug Reports Only

[MrVideo]

I really just want to extract the Theatrical version, primarily because it has all these great commentaries on it (including one by the MST3K group!)

It shouldn't matter which version you extract, since the commentary soundtrack will be on both. As you well know, it is embedded in the M2TS file(s).

[mparade]

@jdobbs

First of all, thank you very much for your software.

I have just checked 1 pc from my HEVC encoded interlaced m2ts files (from one of my HEVC archives) and saw a lot of combing artifacts in PowerDVD and Kodi's DVD player. MPC even couldn't play it at all. Couldn't be the cause that we are not using --interlace tff/bff (default is false) in the HEVC command line as suggested by the x265 documentation and feeding the encoder with frames instead of fields?

Sorry for disturbing you with such questions...I have just started to make my big archivum using your program and HEVC and noticed these artifacts with interlaced content that was HEVC encoded with the latest version of BD-RB. Maybe, I am completely overlooked something in BD-RB...

I would really appreciate your answer.

[MrVideo]

I have just checked 1 pc from my HEVC encoded interlaced m2ts files (from one of my HEVC archives) and saw a lot of combing artifacts in PowerDVD and Kodi's DVD player.
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.

[Sharc]

@jdobbs

I have just checked 1 pc from my HEVC encoded interlaced m2ts files (from one of my HEVC archives) and saw a lot of combing artifacts in PowerDVD and Kodi's DVD player.
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)

[MrVideo]

In any case, your player should deinterlace (or inverse-telecine) the encoded interlaced (telecined) stream, otherwise you will see combing especially in action scenes.

As I mentioned in my posting, Deinterlacing, or IVTC, cannot be done if the interlaced video is turned into progressive video by combining the two fields into a single frame. By not having any fields to work with, it can't deinterlace, or IVTC.

That said, there are a few AVISynth scripts out there to deal with screwed up video like that. But display devices, or video players, are not made to handle screwed up video.

[Lathe]

As I mentioned in my posting, Deinterlacing, or IVTC, cannot be done if the interlaced video is turned into progressive video by combining the two fields into a single frame. By not having any fields to work with, it can't deinterlace, or IVTC.

That said, there are a few AVISynth scripts out there to deal with screwed up video like that. But display devices, or video players, are not made to handle screwed up video.

Yeah, I think you are right. I 'got ahold' of DVD prints of the series 'War of the Worlds' At first I couldn't figure out why they were tagged as 'progressive' when they looked as interlaced as hell (extreme combing and such) Well, I don't remember HOW I found it, but finally I stumbled on an Avisynth script that made it look perfect (well, 'perfect' as far as DVD goes, but it honestly came out looking pretty dang good!) I saved the script, so I'll paste it here if it is any help. I honestly am NO expert at this at all, so this may not be in any way helpful. But, it sure did the trick with this DVD series, and I had tried every stock deinterlacer that I could find. If I remember correctly, what threw me was that I tried to process them through BDRB, but even after processing, they still looked the same. I don't remember the details, but I think I may have posted some things here when that happened. And, of course, there is a GOOD chance that I just didn't have the BDRB settings right :)

Again, I don't know if this is really relevant at all, but here is what I used:

DirectShowSource("G:\War.Of.The.Worlds.S2E03.Doomsday.mkv",fps=29.970)
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\decomb.dll")
FieldDeinterlace()

[Sharc]

As I mentioned in my posting, Deinterlacing, or IVTC, cannot be done if the interlaced video is turned into progressive video by combining the two fields into a single frame. By not having any fields to work with, it can't deinterlace, or IVTC.
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).

[Sharc]

...
......Again, I don't know if this is really relevant at all, but here is what I used:

DirectShowSource("G:\War.Of.The.Worlds.S2E03.Doomsday.mkv",fps=29.970)
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\decomb.dll")
FieldDeinterlace()
This really does not look like an original source, eh?

[Lathe]

This really does not look like an original source, eh?

Not the point of the post my friend...

I was just trying to help with a 'screwed up source' that sounded like something similar that I had to deal with... CLEARLY, the person is dealing with some kind of encode that was not done correctly and is obviously far from the 'original source' With this kind of issue, I think that is a given..

[MrVideo]

DirectShowSource("G:\War.Of.The.Worlds.S2E03.Doomsday.mkv",fps=29.970)
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\decomb.dll")
FieldDeinterlace()

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. :eek:

[mparade]

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]

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]

:rolleyes: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. :eek:

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... :rolleyes: ) 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]

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]

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]

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]

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]

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?p=1759631&postcount=2

[mparade]

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]

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]

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]

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. :confused:

[sneaker_ger]

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]

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]

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.

[Sharc]

Hmmm..., in this case it seems to be currently better to deinterlace the source and encode it progressive only with x265, until further notice.

[gonca]

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?

Not your imagination

Like CV91913 said...

[jdobbs]

Hmmm..., in this case it seems to be currently better to deinterlace the source and encode it progressive only with x265, until further notice.You're right. I personally have my reservations in accepting that every player on the planet is wrong and a link to an X265 "readthedocs" post is the authoritative source. But, since I choose not to personally scour the specs and prove or disprove it, I will change BD-RB so it deinterlaces before encoding interlaced sources using X265.

It makes absolutely no sense to create a stream that nothing will play.

[sneaker_ger]

From spec:
field_seq_flag equal to 1 indicates that the CVS conveys pictures that represent fields, and specifies that a picture timing
SEI message shall be present in every access unit of the current CVS. field_seq_flag equal to 0 indicates that the CVS
conveys pictures that represent frames and that a picture timing SEI message may or may not be present in any access
unit of the current CVS. When field_seq_flag is not present, it is inferred to be equal to 0. When
general_frame_only_constraint_flag is equal to 1, the value of field_seq_flag shall be equal to 0.

NOTE 11 – The specified decoding process does not treat access units conveying pictures that represent fields or frames differently.
A sequence of pictures that represent fields would therefore be coded with the picture dimensions of an individual field. For
example, access units containing pictures that represent 1080i fields would commonly have cropped output dimensions of
1920x540, while the sequence picture rate would commonly express the rate of the source fields (typically between 50 and 60 Hz),
instead of the source frame rate (typically between 25 and 30 Hz).
I can confirm x265 outputs using field_seq_flag=1 with each field as a distinct picture so I'm inclined to say the x265 documentation is correct.

[jdobbs]

I repeat, however -- it makes absolutely no sense to create a stream that nothing will play.

[Sharc]

A sort of workaround is to force the player to 16:9 DAR. It then resizes the 1920x540 pictures (fields) vertically and plays at double rate. Like a bobber with the vertical interpolation (or resizing) delegated to the player......:eek:

[Lathe]

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

Uh..., (cough...) eh, no boss...

No snippetiness here... :rolleyes:

[AmigaFuture]

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

Social Networking... Facebook. I'm not a fan of Facebook...but friends tell me things and I'm hearing more complaints about comments and drama. I tell them to stop using it. I like fora like this...very little of it. At least the few threads I follow. Personally, I'd like to see Facebook and sites like it end...go back to more person to person. Though, I also like being able to chat across States, so...there's the catch.

[laserfan]

I'm assuming since the "snippety" comment followed sneaker_ger's post that it was in response to that, which I did not find "snippety" at all.

There are several things at work in fora such as people making quick responses in the interest of time, other people using poor choice of wording that comes-across wrong when you read it, and here too there are plenty of posters for whom English is a second or third language (not to mention of course that young people nowadays who are "educated" in the good 'ol US of A sorta suck at it themselves IMNSHO).

I for one have many dozens of boards that I try to check every day and it's not easy sometimes to pick/choose what to respond to (vs. what to let slide). Amazing that I care to post here since I don't know a single one of you, though I do sorta love jdobbs for the cool stuff he's built over the years. That's in a manly way, of course.

Carry on.

:)

[jdobbs]

That's in a manly way, of course.Me too. A very manly masculine man-among-men way. :)

[Groucho2004]

Me too. A very manly masculine man-among-men way. :)
You two get a room already. :D

[jdobbs]

You two get a room already. :DEr..ehh... how about those Bears, eh? Great football team. Yep.

[Sharc]

I repeat, however -- it makes absolutely no sense to create a stream that nothing will play.
Just for info, this seems to work for my interlaced source and .mkv output:

Script (interlaced_.avs):
LoadPlugin("c:\....\DGDecodeNV.dll")
DGSource("c:\......\Sample.dgi",fieldop=0)
AssumeTFF()
separatefields()
AssumeFieldBased() #may be skipped
AssumeFPS(50) #source is 25fps interlaced

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


For muxing to .mkv one has to specify the DAR 16:9 in mkvmerge for the container.
The .mkv plays at 50fps with correct duration, full temporal resolution and correct AR in MPC-HC and VLC, without special player settings.

I didn't succeed with tsMuxeR. Playback was always too slow and size was half-height only unless I force the player to 16:9 DAR; setting the ar=16:9 parameter in tsMuxeR had no effect. I am giving up .....

[sneaker_ger]

Just for info, this seems to work for my interlaced source and .mkv output:
That still leaves the bobbing like you mentioned in post #24087.

[Sharc]

That still leaves the bobbing like you mentioned in post #24087.
Absolutely. But at least something playable ... :D

[MrVideo]

:rolleyes:

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 :)
If from the U.K., the MPEG-2 video would have been coded from a 23.976p master to 25p. A U.S. release should not have been 29.97p.

Oh, and to tie it in to the overall discussion here (well, sort of... :rolleyes: ) 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...

There would be no need for BDRB to have code in it to look for screwed up video and attempt to deal with it. It should only have to deal with correctly encoded sources.

[ggtop]

Hi all,

is it the normal behavior that multi channel input gets stereo downmixed? I have a Bluray with DTS XLL track. My alternate file has option audio AC3 and bitrate 640 (I also tested bitrate 448). Reading the instruction in alternate.txt I assumed only bitrates 384 and lower end in stereo downmix.

ggtop

[jdobbs]

No it's not normal. But you may want to check your settings in FFDSHOW or LAV Filters (whichever you use) and make sure that "mixing" isn't enabled. BD-RB tries to turn mixing off in the registry each time it does an audio encode, and then set it back to it's original state at completion -- but if your rights don't allow the changes (or your A/V software intercepts it), it could fail to change.

[ggtop]

Thank you for the hint. I'm using LAV filters and Mixing is not enabled. I did 2 quick tests using "Intact Video" and the AC3 came out 6ch as expected. The first test was with Microsoft Security Essentials disabled. The second test had it enabled. Both were fine. I will do another test tomorrow with the same Profile that a had the issue with. Interessting was that the 2ch AC3 file (created by BD-RB) had the same size than the file I created myself with eac3to with the demuxed DTS file from BD-RB. But this one showed up as 6ch AC3... If I find something I will let you know.

ggtop

[jdobbs]

What are you using to tell you whether it is/isn't 6 channel? MediaInfo? Could you post the profile you used to encode? Could you also post the "AUD_00000_4352.AVS" file (the name will change depending upon the M2TS number and stream ID, but will always start with "AUD" and end with ".AVS")?