Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
11th September 2009, 17:34 | #5141 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
BUT... when I turned KEEP_INTERLACING off (the BD-RB default) -- I ended up with a beautiful 1080p picture that had nice smooth edges during horizontal movement... I didn't look inside the M2TS for flags, but I have to assume X264 is encoding it correctly. So the bottom line is -- I don't see anything to fix on the KEEP_INTERLACING=1 side. One think I could do (and probably will), is still do the deinterlacing within AVISYNTH to clean up the edges but keep the output as 1080i so it matches the original... I'm going to see if selecting movie-only makes a difference... Last edited by jdobbs; 11th September 2009 at 18:40. |
|
11th September 2009, 17:49 | #5142 | Link |
Registered User
Join Date: May 2009
Posts: 60
|
Sorry, I have not been able to follow the development of the program and wanted to know if any improvements have been made to 24f playability on Panasonic players (in BD25 Movie only mode) and also to more exact output size (undersized and sometimes oversized files were output before). Thank you in advance.
|
11th September 2009, 18:19 | #5143 | Link | |
Registered User
Join Date: Jul 2009
Posts: 61
|
Quote:
And isn't that the preferred method since the player would have MUCH more video "horsepower" than a screen would? On the Oppo, it does the deinterlace & then outputs 1080p or 108p/24 to the screen. In the setup menu, I can select the following deinterlace modes: Auto (that's where I leave it, 'cause 1080p & original "i" looks GREAT) Film Bias Mode Video Bias Mode 2:2 Odd 2:2 Even Couldn't tell you what each of those are supposed to do, but I tried all those with the bum 1080i RB's & didn't see any real diff. I'd suspect, it's because the source is FUBAR up & can't be "saved". |
|
11th September 2009, 18:32 | #5144 | Link | |
Registered User
Join Date: Jul 2009
Posts: 61
|
Quote:
Referring to my "poster child" 1080i RB done at "default", if I bring up the Oppo "on screen info", it says "AVC BDMV 29.97fps 16:9". I can't believe the Oppo would LIE to me! Or maybe, something in the RB is "confusing" it, telling it to deinterlace when it shouldn't??? |
|
11th September 2009, 19:21 | #5145 | Link | |
Registered User
Join Date: Aug 2006
Posts: 696
|
Quote:
If you could then go to a bit that is live action behind the scenes and tell me if you can see the film look you get as you would in a main movie Vs how it looks on the original. I guess there really is no way around it then, but I'm greatful for you having a good look at it as you have. Cheers, Rob |
|
11th September 2009, 19:22 | #5146 | Link | |
Registered User
Join Date: May 2006
Posts: 3,997
|
Quote:
1. demux the .m2ts with TSMUXER 2. re-size and re-encode the video 3. resize the original .sup from 1. using Sup2Sub.jar 4. remux 2. and 3. with TSMUXER Perhaps you may want to include Sup2Sub in the Tools. |
|
11th September 2009, 22:00 | #5147 | Link | |
Registered User
Join Date: Sep 2007
Posts: 21
|
Quote:
http://www.100fps.com/wrongfieldorder.avi (taken from http://www.climaxtek.com/Faq/Deinterlacing.htm) As I said, I encode interlaced material with the keep_interlacing=1 function (reason I mentioned earlier) and the output looks just like that on my standalone player as well as proper playback software like 'powerdvd 9' (deinterlacing is set to hardware). I remember using mpeg2 encoding it was even possible to change the field order interpretation 'after' the encoding with a bitstream modifier (like pulldown.exe, restream or whatever) but I doubt that's possible with mpeg4 derivates. Last edited by Aratar; 11th September 2009 at 22:04. |
|
11th September 2009, 22:34 | #5148 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
|
|
11th September 2009, 22:36 | #5149 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
Last edited by jdobbs; 11th September 2009 at 23:34. |
|
11th September 2009, 22:38 | #5150 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
|
|
11th September 2009, 22:41 | #5151 | Link | ||
Registered User
Join Date: Jul 2005
Posts: 1,995
|
Quote:
I commented on this to you back on 8-22-08, post #4725 (page 237) Quote:
I was only able to get the audio in sync by doing a manual backup of 00000.m2ts by command line with the meta file from BD-RB, inserting timeshift = 250 in that meta file, rebuilding that 00000.m2ts file individually, and substituting it in place of the BD-RB version upon rebuild. ( 83ms did not correctly fix the async) Tedious, yes, but the backup plays in sync now. ( I can be determined at times ) I reported this way back, and at that time seems like one of those rare discs that are troublesome. But timing is everything. I did not want to present jdobbs with an issue that is rare and not highly reported as a bug. ( not sure it is) I believe jdobbs reported that audio delays are corrected with BD-RB, but not sure when. It would not have mattered with this disc anyway, since the actual 83ms delay was not enough to correct the async anyway. Last edited by Capsbackup; 11th September 2009 at 22:44. |
||
11th September 2009, 22:53 | #5152 | Link |
Registered User
Join Date: Sep 2007
Posts: 21
|
Another thing:
you can find out about the field order by evaluating movement using the avisynth command: DirectshowSource("00xxx.m2ts", fps=29.97, framecount=10328, audio=false) AssumeBFF().SeparateFields() <-- BFF if movement is fluent #AssumeTFF().SeperateFields() <-- TFF if movement is fluent ConvertToYV12() as well as swap the field order for encoding with SwapFields() so I guess there'd be no need for a patched x264 version. |
11th September 2009, 23:32 | #5153 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
Also, doing what you are suggesting would make it playback correctly on an output device. But it gets frame-served to the encoder, and if an encoder will only do one type (e.g. TFF) or it has nothing telling it that the field order and it is getting fed frames for encoding, this won't do a thing. This first example doesn't change the position of the lines in the frame in any way. Swapfields actually will change the fields assuming you know when it is wrong -- but they are now out of position (line 2 is now above line 1, etc.) and what do you do when you have hybrid streams or changing field orders? [Edit] By the way -- I have no idea how X264 detects or outputs interlaced field order, so please don't quote me as saying it does it one way or the other. Last edited by jdobbs; 12th September 2009 at 00:01. |
|
11th September 2009, 23:40 | #5154 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
As I've said (several times now) the problem isn't in the changing of field order-- it is in the detection of field order. Just because a stream starts with one field order, there is no guarantee it stays that way. In fact you will find sources that also embed progressive content with pulldown in random places throughout the stream. I am trying to avoid having to do a 40GB scan of every source... I can do that very easily and simply by decombing the source. Which (surprise, surprise) is exactly what the default setting already does. You're suggesting manual interface solutions as a solution and are making the assumption that since you can look at a screen and say "that doesn't look right" it should be easy to program the same. That very definitely isn't the case. Last edited by jdobbs; 12th September 2009 at 00:13. |
|
11th September 2009, 23:49 | #5155 | Link |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
To all,
Enough on this interlacing subject. I appreciate the help, but I understand very well how all this all works. I'll work on it and do it the way I think is best. No more suggestions... let's please get back to bug reports. Last edited by jdobbs; 12th September 2009 at 00:10. |
11th September 2009, 23:52 | #5156 | Link | |
Registered User
Join Date: Oct 2003
Posts: 273
|
Quote:
I might be wrong tho. Either way, this is an issue that needs to be addressed, so I think it's best we'll let jdobbs have a look at it, as he has the disc himself. |
|
12th September 2009, 00:16 | #5157 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
|
|
12th September 2009, 00:35 | #5158 | Link |
Registered User
Join Date: Sep 2002
Posts: 31
|
Hey jdobbs,
Been a long time user of dvd rebuilder .. trying the br version I tried with The Shawshank Redemption movie only and i got this .. it seems it's the famous error. I am runing on Windows 7. Maybe it's the cause of the problem? Thanks [00:20:14] PHASE ONE, Encoding - [00:20:14] Extracting A/V streams [VID_00002] - [00:30:52] Reencoding: VID_00002 (1 of 1) - [00:30:52] Collecting video information - Video: 1920x1080, 23,976fps, 205.076 frames - Bitrate: 6.431 Kbs - [00:30:52] Reencoding: VID_00002, Pass 1 of 2 - [00:31:53] GUI issue, no hWnd returned. - Encode failed. Retrying. |
12th September 2009, 01:10 | #5159 | Link | |
Registered User
Join Date: Jul 2005
Posts: 1,995
|
Quote:
I exhausted myself on this disc, and 83ms did not correct the async for me. I agree that if jdobbs can address/confirm that any and all audio delays are corrected by BD-RB, this would be welcome. As a side note, my BD-RB backup, if viewing the .m2ts file or the .mpls file, shows 0ms delay. The original .m2ts and .mpls files show the 83ms delay. If BD-RB does correct this delay, I am curious when and where. For most of my backups, I select do not reencode audio files, and keep HD audio for BD-25 backups. Thus the original audio file is kept. So where is the audio delay being corrected if not the .mpls, maybe the clpi? |
|
12th September 2009, 01:23 | #5160 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|