BD Rebuilder Beta - Bug Reports Only

[Sharc]

I noticed that interlaced HFUY sources 720x576i25 get AVC converted as progressive (profile: baseline Level 3.0, scantype: progressive) during import.

MediaInfo reports the HFYU (.avi) source as interlaced. Stream inspection confirms that it is interlaced video, TFF, as expected.
But after importing, MediaInfo and DGIndexNV report the converted .m2ts as progressive. Field separation however indicates that the video is in fact still true interlaced (50 temporal fields per second).

Is this interlaced/progressive ambiguity ok, or should the import process include --tff for the conversion of interlaced (HFUY) sources?

[jdobbs]

Originally Posted by Sharc

I noticed that interlaced HFUY sources 720x576i25 get AVC converted as progressive (profile: baseline Level 3.0, scantype: progressive) during import.

MediaInfo reports the HFYU (.avi) source as interlaced. Stream inspection confirms that it is interlaced video, TFF, as expected.
But after importing, MediaInfo and DGIndexNV report the converted .m2ts as progressive. Field separation however indicates that the video is in fact still true interlaced (50 temporal fields per second).

Is this interlaced/progressive ambiguity ok, or should the import process include --tff for the conversion of interlaced (HFUY) sources?

I simply use DirectshowSource() in an AVS and pass the video to X264. I would have thought that the frame format would be recognized correctly. I should have known better than to assume anything. I'll add some code to check for interlacing (bff/tff) and pass the parameter to X264..

[jdobbs]

Originally Posted by Sharc

I noticed that interlaced HFUY sources 720x576i25 get AVC converted as progressive (profile: baseline Level 3.0, scantype: progressive) during import.

MediaInfo reports the HFYU (.avi) source as interlaced. Stream inspection confirms that it is interlaced video, TFF, as expected.
But after importing, MediaInfo and DGIndexNV report the converted .m2ts as progressive. Field separation however indicates that the video is in fact still true interlaced (50 temporal fields per second).

Is this interlaced/progressive ambiguity ok, or should the import process include --tff for the conversion of interlaced (HFUY) sources?

Interesting. During import all non-MKV files are remuxed into an MKV for consistency (MediaInfo reports different information, even for the same CODECs, depending upon the container). If I run MediaInfo against the AVI, it tells me the scan type is interlaced -- but if I run it against the MKV it doesn't. I guess I'm going to have to manually set the field order in MKVMERGE. That's kinda' disappointing -- you'd think something as obvious as progressive/interlaced formatting would be detected automatically.

[Edit] It gets even worse. The version of MediaInfo included with BD-RB doesn't even report the scan type as interlaced on the HFYU.avi file you sent me. And I've avoided updating it because the newer one seems to be worse at recognizing variable frame rates. And, even if I used the new one -- it doesn't tell you the field order. A wrong field order would look much worse than combining the fields and playing it as progressive.

[Sharc]

Originally Posted by jdobbs

Interesting. During import all non-MKV files are remuxed into an MKV for consistency (MediaInfo reports different information, even for the same CODECs, depending upon the container). If I run MediaInfo against the AVI, it tells me the scan type is interlaced -- but if I run it against the MKV it doesn't. I guess I'm going to have to manually set the field order in MKVMERGE. That's kinda' disappointing -- you'd think something as obvious as progressive/interlaced formatting would be detected automatically.

[Edit] It gets even worse. The version of MediaInfo included with BD-RB doesn't even report the scan type as interlaced on the HFYU.avi file you sent me. And I've avoided updating it because the newer one seems to be worse at recognizing variable frame rates. And, even if I used the new one -- it doesn't tell you the field order. A wrong field order would look much worse than combining the fields and playing it as progressive.

Ufff....I didn't imagine that adding these codecs for importing the .avi would cause such headaches. Sorry for the trouble. You are right MediaInfo does not tell the field order even when it detects interlaced, and maybe the info is not even available from the .avi (or is codec/mux dependent). Pretty inconsistent and confusing, I think.
It seems now that manual analysis of the source is required and x264 must then be manually forced to encode --tff or --bff. That's what I have been doing until now, using BD-RB at the end for quick-authoring a number of pre-encoded compliant .m2ts. So BD-RB still holds its strong place in this scenario

[jdobbs]

Originally Posted by Sharc

Ufff....I didn't imagine that adding these codecs for importing the .avi would cause such headaches. Sorry for the trouble. You are right MediaInfo does not tell the field order even when it detects interlaced, and maybe the info is not even available from the .avi (or is codec/mux dependent). Pretty inconsistent and confusing, I think.
It seems now that manual analysis of the source is required and x264 must then be manually forced to encode --tff or --bff. That's what I have been doing until now, using BD-RB at the end for quick-authoring a number of pre-encoded compliant .m2ts. So BD-RB still holds its strong place in this scenario

There's always a way. I'll probably have to analyze the stream myself. Look for something in the next release.

[Sharc]

Originally Posted by jdobbs

There's always a way. I'll probably have to analyze the stream myself. Look for something in the next release.

Btw., capturing the tapes with x264 in lossless mode with field order specification seems to keep the interlace and field order information correctly and consistently during import. So I could capture the tapes again, but unfortunately the tapes have aged (like me) and deteriorated (like me) since the original capture in HFYU format about 8 years ago.

Now I am curious and patiently waiting for the next release of BD-RB

[MrVideo]

You have issues with tapes that are only 8 years old? I have VHS/S-VHS/Umatic/DVCAM tapes that are many years (decades even) older than that and I do not have issues with them.

[Lathe]

Originally Posted by MrVideo

You have issues with tapes that are only 8 years old? I have VHS/S-VHS/Umatic/DVCAM tapes that are many years (decades even) older than that and I do not have issues with them.

Hmmmm... Can anyone say, 'BETA'...!

[Lathe]

Originally Posted by Sharc

...but unfortunately the tapes have aged (like me) and deteriorated (like me)...

Geez JD, do you think you could throw a little something into the next build to help ol' Sharc...?

He's decomposing before our eyes, poor fellow...

[MrVideo]

Originally Posted by Lathe

Hmmmm... Can anyone say, 'BETA'...!

Beta, VHS, whatever. It should not be giving you issues.

[Sharc]

Originally Posted by Lathe

Geez JD, do you think you could throw a little something into the next build to help ol' Sharc...?

He's decomposing before our eyes, poor fellow...

Nothing to really worry about, Lathe. It's in no respect as dramatic as what we see from your selfie here

[Sharc]

Originally Posted by MrVideo

You have issues with tapes that are only 8 years old? I have VHS/S-VHS/Umatic/DVCAM tapes that are many years (decades even) older than that and I do not have issues with them.

The tapes are actually much older, about 25....30 years old, but I captured (digitized) these lossless only about 8 years ago. For few of the tapes I noticed visible deterioration recently.
I posted a sample here of a VHS tape which was still reasonably clean some years ago.

[jdobbs]

Originally Posted by Sharc

Ufff....I didn't imagine that adding these codecs for importing the .avi would cause such headaches. Sorry for the trouble. You are right MediaInfo does not tell the field order even when it detects interlaced, and maybe the info is not even available from the .avi (or is codec/mux dependent). Pretty inconsistent and confusing, I think.
It seems now that manual analysis of the source is required and x264 must then be manually forced to encode --tff or --bff. That's what I have been doing until now, using BD-RB at the end for quick-authoring a number of pre-encoded compliant .m2ts. So BD-RB still holds its strong place in this scenario

Here's how I'm doing it. If the source is 25fps or 29.97fps, and mediainfo doesn't specifically find it to be progressive -- I will assume it is interlaced. In my testing it seems to detect and specify "Progressive" 100% correctly. Since TFF is much more common than BFF (except maybe in DV) I will make that the default. But I'll add a hidden option that can override that. It's pretty obvious when the field order is backwards -- so that will be easy to detect and correct manually.

[jdobbs]

Originally Posted by Sharc

The tapes are actually much older, about 25....30 years old, but I captured (digitized) these lossless only about 8 years ago. For few of the tapes I noticed visible deterioration recently.
I posted a sample here of a VHS tape which was still reasonably clean some years ago.

I think all my very old tapes show degradation. But since it happens gradually, you don't really notice it and you just assume it always looked that way. But when I look at an old digital capture from the same tape I can easily see it.

[Sharc]

Originally Posted by jdobbs

Here's how I'm doing it. If the source is 25fps or 29.97fps, and mediainfo doesn't specifically find it to be progressive -- I will assume it is interlaced. In my testing it seems to detect and specify "Progressive" 100% correctly. Since TFF is much more common than BFF (except maybe in DV) I will make that the default. But I'll add a hidden option that can override that. It's pretty obvious when the field order is backwards -- so that will be easy to detect and correct manually.

I think this is a good strategy.

[datman]

I'm guessing this is a bug but its such an obscure use for BDRB it might be unfixable.

I posted awhile back how I was capturing video either from the DVR or the computer. The OEM software quality was lost if I processed and burned down to a BD-5 disc. I figured out that I could process it to a BD-25 size within the software then use BDRB to encode down to a BD-5 disc. Worked well but a lot of processing time from both programs.

So I tried to side step it by importing the capture TS file and it appeared to work. When I tried this prior I got nothing but coasters and it appeared that the AAC audio from the capture, which was unchanged would cause the discs not to play.

This time I unchecked both the "do not convert DTS to AC3 and do not encode AC3" This time the audio was converted to multi-ch AC3 and it plays in my BD player. The two different captures I did both sound like it's playing at 5X speed.

I tried tsMuxerGUI and it seems the AAC audio is my biggest issue. If I process it in Power Director I can convert it to DD.

[Blurayhd]

Hi guys, hi jdobbs, I have a question, lets say I want to pass to bd25 in Only movie mode but I wish to keep the Splash menu (that is calling?), You know, when you play the movie and you want to change some language or subtitles there´s some way to push the control so the Spalsh java menu appears? I know you can set all this with changing subtitles and audios but I so wish to know
Thank you for your time!!

[MrVideo]

Originally Posted by Sharc

The tapes are actually much older, about 25....30 years old

I've got a bunch of 1/4" reel-to-reel tapes that are 40-46 years old. Not one of which had issues when I played them back for capturing. And yes, the Sony reel-to-reel deck is also functioning after all these years. Storage conditions were not ideal either.

[Lathe]

Originally Posted by Sharc

Nothing to really worry about, Lathe. It's in no respect as dramatic as what we see from your selfie here

I swear... you try to show a little concern and this is what you get...

[Lathe]

Originally Posted by MrVideo

I've got a bunch of 1/4" reel-to-reel tapes that are 40-46 years old. Not one of which had issues when I played them back for capturing. And yes, the Sony reel-to-reel deck is also functioning after all these years. Storage conditions were not ideal either.

Reel-to-Reel...???! Holy Smokes! What's next, you gonna break out your Edison wire spools...?

How frigg'n OLD are you, for God's sake!?

(this almost reminds me of the old Monty Python sketch, 'Well, when I was young, we had to etch our own recordings in granite...')