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. |
14th June 2010, 15:22 | #321 | Link | |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
To say 'for certain' you must have the dvd-video specification from the DVDForum. What I can say is that I've made a lot of these dvd and no one complain about strange incompatibility with standalone players. Also, EclipseSuite (which is very reliable) validate the verification.
Quote:
- Encode as 25p with 4% speedup - Encode as 50i with 4% speedup (this is the 2:2 pulldown) - Encode as 24p with 2^12:3 euro-pulldown As for the third option, there's no progressive-scan players able to reconstruct the original 24p and display at 25p since the cadence is quite uncommon. You'll see it always as interlaced with 2 stutters every second. This is different with software dvd decoders that will output true 24p. I don't know if this happends even for dvd players with HDMI output. If the player can output 24p via HDMI it could be that the hdtv will display the original 24p... but I've never tried it. |
|
15th June 2010, 09:03 | #322 | Link |
Registered User
Join Date: May 2010
Posts: 24
|
Point One is quite settled in my opinion, and to draw it back to the topic of this thread, the Prog_frame=ON TFF=off Prog_sequence=ON was the default behaviour in HCEnc when doing progressive encodes.
I think it'd be good to have that default behaviour back? But anyway the choices are now clear. As to the second point of 2:2 pulldown again! Apparently this is a nullity. Are there any real world applications of 50i, where 2:2 pulldown happens, when encoding from progressive sources (film or not, it has been sped up to 25fps frame-wise)? Is this another possibility for HCEnc? 50i? |
15th June 2010, 16:30 | #323 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
So yes, there are plenty - anything that broadcasts or displays interlaced material uses it. |
|
15th June 2010, 17:07 | #324 | Link |
Registered User
Join Date: May 2010
Posts: 24
|
I was responding to mp3coder's observation that with a progressive source we could choose to "Encode as 50i with 4% speedup (this is the 2:2 pulldown)".
It may seem like splitting hairs, but what I was driving at is whether that would entail interlacing the progressive source and causing the MPEG stream to be hard-encoded at 50i (i.e. picture structure = field) If, when fed a truly progressive source, HCEnc or any other EN-coder splits the frame into two fields, it would be hard 50i encoding and then we'd probably have a case where "2:2 pulldown" is an apt description. Of course, interlacing a progressive source is at the EN-coder level is programmmatically simple. But should we do it? Is it done this way? Perhaps. I don't know. Right now it seems that HCenc (or any other encoder) does not do that to a truly progressive source. Instead the frames are encoded (25fps nominally) and it is the job of the DE-coder to interlace the output auto-magically. There is no "pulldown", in the strict sense of the term, by the EN-coder. And even if such an option were available, I still think it would be cleaner to encode as progressive stream. Any thoughts? |
15th June 2010, 17:36 | #325 | Link | |
Registered User
Join Date: May 2010
Posts: 24
|
Quote:
You know, I was pretty convinced. But just a few minutes ago I came across this statement: "Although Eclipse Image Analysis is crucial, it does not check the VIDEO_TS folder for DVD Spec compliance (IFO files, VOB data structure, navigation commands, etc)." http://www.dvdverification.com/public/119.cfm I honestly wish that this basic information became public instead of staying subject to some hefty licence fee and NDA. Last edited by Koutsoubos; 15th June 2010 at 17:43. |
|
15th June 2010, 18:17 | #326 | Link | ||||
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
Quote:
Returning in topic, if you encode your progressive source as interlaced (top field, frame or field structure, alternate scanning order etc etc), you're making a '2:2 pulldown encode'. Quote:
Quote:
Quote:
|
||||
15th June 2010, 19:33 | #327 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
That might be a lawyer-worded way of saying that while they'll check for their idea of conformance, they do not guarantee that their idea is a perfect complete test of the spec. Otherwise, lawsuits and yada yada.
|
15th June 2010, 19:56 | #328 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
First of all a small bug report for HC 0.24 beta 04-04-2010:
In 1-pass VBR mode the HC log file always reports an average quantizer which is too small by a factor of 10 (0.400 instead of 4.00). Haven't tested it in 2-pass VBR. Peanuts... @Koutsoubos Interesting discussion, but I still think you should follow neuron's advice and post a sample. If your source is purely progressive, but your display chain still shows combing artifacts, a phase shift in your source is pretty much the only explanation. Just assume for a moment that I (and neuron) are right and your source is phase shifted by 1 field: Play it through a standard DVD player (no progressive scan) on an interlaced display (CRT), no combing would be visible as long as the field order is right. Play it on a progressive scan player fed to a progressive display device, and say that either the player or the display has turned on their built-in deinterlacer: No combing artifacts, but certainly a loss of quality. And according to your first post not setting the TFF flag must have triggered the deinterlacer which is not good... Play it in a progressive chain where neither the player nor the display have turned on their deinterlacer (which would be correct) then you would see combing artifacts. So please provide a sample... Cheers manolito |
16th June 2010, 02:05 | #329 | Link |
Registered User
Join Date: May 2010
Posts: 24
|
Hey, it's not that I do not want to heed the advice of the likes of neuron2 or you. I see that both of you have a very rich bank of experience behind you.
Just that the source is very big (even a 4 second Lagarith-compressed snippet is 80 MB) and copyrighted. I am not authorized to release the material. And it cannot be a field shift. For starters, there are no fields. The source is progressive. In my "case 1 encoding" (HCEnc's new behaviour), in two progressive test setups (progressive player and display), when I actually force the DVD standalones to output progressive, things are fine. When I leave them in "standard" interlaced mode, perceptible combing appears, shall we say they do not seem smart enough to produce a kosher 50fps interlaced image from the 25p encoding. Commercial interlaced DVDs play fine. In a plain-vanilla non-progressive scan DVD player and interlaced CRT, the decoder-interlaced image appears just fine. So... that led to the long discussion about flags and all and whether "case 3" is the way to go ... I would like to pose a question to all. Given a nominally 25 fps (i.e. forget about speed-up or not, it's now 25fps) progressive source bound for PAL, would you encode it as 25p or go ahead and encode it as 50i? Why or why not? How would you do it? Last edited by Koutsoubos; 16th June 2010 at 04:45. |
16th June 2010, 02:12 | #330 | Link | |
Registered User
Join Date: May 2010
Posts: 24
|
Quote:
This from an individual known as Trai, expressed in the Creative Cow forums (http://forums.creativecow.net/thread/155/869917): The EclipseSuite of tools is crucial, no doubt; I've been licensed with them since September 2002, and use them everyday. But these tools make sure that what's presented to you as a replicator, i.e., the DVD Image, and that it can be mastered. Only a very few checks of the contents of the build folder (DVD-Video file structure in the VIDEO-TS folder) are included that pertain to mastering the Image; things like proper placement and flagging of layer break cell (which I and my partner working on DVDAfterEdit got Eclipse to implement during 2003/2004), making sure the DSI (data search information) has the correct number of sectors listed as are actually on the disc (more to it than that), and just a very few others... And yes, it's true I'm afraid, Eclipse, as good as it is, doesn't check for DVD for spec compliance. The MEI DVD-Video Verifier does that. Eclipse (worth it's weight for the crucial tasks it performs) verifies if the Image presented is configured properly for your mastering equipment, and that the Image follows certain file system specifications - but again (and again) does not check the DVD for DVD-Video spec compliance. Last edited by Koutsoubos; 16th June 2010 at 04:44. |
|
16th June 2010, 09:17 | #331 | Link | ||
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
Quote:
Quote:
Regarding your problem about 'combing' artifacts on progressive image, it could be that some flags are switching over time. Even the scanning order (from Alternate to Zig-Zag and viceversa) could led to some strange artefacts on some standalone players. |
||
16th June 2010, 17:57 | #332 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Maybe to avoid all possible issues with different hardware player setups you could do what virtually all commercial authoring houses do:
Flag progressive PAL DVDs as interlaced TFF Out of curiosity I just pulled 20 commercial progressive PAL DVDs from my collection and checked their flagging with ReStream. Result: None of them had progressive flags whatsoever, all were flagged as interlaced TFF. Nine of them showed zig-zag scan order, eleven had alternate scan order. This leads to a feature request for the next HC version: I would like to have an additional setting called *NO_PROGRESSIVE_FLAGS (or similar) This way I could correctly encode progressive content with zig-zag scan order, but there would still be no progressive flag in the stream. This is currently not possible with HC (CCE SP can do this...) In AutoInterlaced mode this would also avoid the constantly alternating progressive flags which has been reported to cause trouble in some hardware configurations. Cheers manolito Last edited by manolito; 16th June 2010 at 18:00. |
17th June 2010, 07:36 | #333 | Link | ||
Registered User
Join Date: May 2010
Posts: 24
|
Quote:
Quote:
I don't know about switching flags. Would HCEnc do that sort of thing? What could I use to check this? Restream? |
||
17th June 2010, 07:37 | #334 | Link | ||
Registered User
Join Date: May 2010
Posts: 24
|
Quote:
Quote:
How is this achieved in CCE SP? |
||
17th June 2010, 09:17 | #335 | Link | |||
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
It could be a good thing to test other encoder if you can.
Quote:
Quote:
Quote:
|
|||
17th June 2010, 12:48 | #336 | Link | |||
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Quote:
The probable reason why most commercial progressive PAL DVDs are encoded (or just flagged) as interlaced is that the authoring folks are too lazy or just too ignorant to flip a couple of switches on their hardware encoders. Quote:
mp3dom already answered this. Quote:
Cheers manolito |
|||
18th June 2010, 03:52 | #337 | Link | ||
Registered User
Join Date: May 2010
Posts: 24
|
Quote:
Quote:
I really want to thank you all, guys. You were a revelation. I'm off to do more tests. I hope this discussion has been fruitful for the HCEnc developers too. It's a great program. |
||
18th June 2010, 06:48 | #338 | Link | |
Registered User
Join Date: Sep 2007
Location: Europe
Posts: 602
|
Quote:
The Cinema Craft line of encoders (at the very least the high-end versions) are designed for DVD compressionists, and the manual tells you to set PAL Progressive as Progressive if the source is such. So I would be surprised if Cinema Craft a) even allowed you to produce non-compliant output when its "DVD" mode is enabled and b) would recommend you to do so in their user manual! FWIW, this is the UK PAL version of "Howl's Moving Castle" which is one of the only PAL discs I've seen that's flagged Progressive. I believe the same version is on sale in Australia: I've only done one PAL DVD (sold in the UK) and encoded it Progressive where applicable. I would hate to encode it Interlaced due to the decline in compression efficiency/quality. Has anyone ever seen any issues with doing this? Last edited by Lyris; 18th June 2010 at 07:16. |
|
18th June 2010, 15:15 | #339 | Link | |
Big Bit Savings Now !
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
|
Some posts back:
http://forum.doom9.org/showthread.ph...63#post1367663 I encode all my PAL-Speedup25p-from-film-24p DVDs as 25p with HC since then and am happy with the outcome on different setups. To flag Progressive Sequence as: no seems to be the vital part to be DVD compliant. Quote:
Given the fact that PAL and NTSC are field-based and the main video connection 1995 was the yellow Cinch connector carrying the composite video signal in interlaced sequence there was no need to allow an encoding parameter to be set to an untransmittable value. Otherwise, DVD players should simply skip this value if set to Progressive sequence. But it made a visible difference on my setup... All pulldowns, 3:2 (23.976p Film on 29.97i NTSC), Euro (2:2:2:2:2:2:2:2:2:2:2:2:3 24p Film on 25i PAL) come out a bit borked on this particular combination. To encode and flag the progressive frame as progressive frame came out beautiful, player will have to perform 2:2 pulldown to output as fields via Composite anyway. A progressive-capable player may probably output such encodes as progressive if this is allowed via HDMI. I can't tell exactly, but reflagging tests showed an advantage in certain player/TFT-combinations. To encode and flag progressive material as interlaced (no matter if tff=1 or 0) came out less optimal encodingwise. On playback player will follow tff/rff flags anyway.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain) "Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..." Last edited by Emulgator; 18th June 2010 at 15:39. |
|
18th June 2010, 15:55 | #340 | Link |
HCenc author
Join Date: Nov 2003
Location: Netherlands
Posts: 570
|
Encoding settings suggestion:
- progressive sequence: off - progressive frame: off - TFF: set - alternate scan: off - MacroBlock dct_type: always frame This way the encode is pure progressive and the player will see it as TFF interlaced (2:2 pulldown). But AFAIK there's no encoder that can do this.
__________________
HCenc at: http://hank315.nl |
Thread Tools | Search this Thread |
Display Modes | |
|
|