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 December 2011, 14:20 | #6941 | Link |
CoreCodec Founder
Join Date: Oct 2001
Location: San Francisco
Posts: 1,421
|
madshi... can you explain this a little more. If "hard telecine" is used there are no flags in the source so we have no idea what to set, and for "soft telecine" streams coreavc ignores the flags so the original rate is used.
__________________
Dan "BetaBoy" Marlin Ubiquitous Multimedia Technologies and Developer Tools http://corecodec.com |
11th December 2011, 14:37 | #6942 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
You may wonder why this might be useful. After all if you simply ignore soft-telecine, we get perfect progressive output, right? Well, that's true for HD DVD and Blu-Ray. But some countries are now broadcasting in h264, and we can't expect the broadcast to always stick to soft-telecine. The broadcasts might switch between soft-telecine and hard-telecine in the middle of the stream. I don't have a sample for that, but it happens very often with MPEG2 broadcasts (plenty of samples for that) so I would expect this to eventually happen with h264 broadcasts, too. In order to properly IVTC such streams, it is very useful to know which frames are hard-telecined and which are soft-telecined and how they are soft-telecined. That's why it would be useful if CoreAVC could pass the soft-telecine flags downstream. I'm working on an IVTC algorithm for madVR, and it's working pretty well for MPEG2 broadcasts, even if there are mixed hard-telecined and soft-telecined sections, as long as the MPEG2 decoder outputs the proper soft-telecine flags. So this is why I'm now asking you for this, too, just to make sure that IVTC will work well for h264 broadcasts with mixed hard-telecined and soft-telecined frames, too. Last edited by madshi; 11th December 2011 at 14:40. |
|
11th December 2011, 15:04 | #6945 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
I don't have a sample here with me but it can be created. A lot of bd encoders have a built-in IVTC so they can encode both soft and hard pulldown (soft when they catch the pattern and hard when they're unable to detect it).
It can happens with 1080i contents but also with 480i (always referred to AVC encode) |
11th December 2011, 15:21 | #6946 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Would it be easy for you to create such a sample? It would be quite useful for testing purposes. If you can do this, maybe you can pick a sample with a lot of movement in it, so that it's easy to see whether IVTC succeeded or not?
|
11th December 2011, 19:00 | #6947 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
Here: http://www.mediafire.com/?s9wr6ljdrl3ew9a
Both 1080i60 and 480i60 (don't know if there are flag differences). There are 2 segments in each file, first segment is hard pulldown, second is soft. |
11th December 2011, 19:40 | #6948 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
I can confirm that with these test samples, my (work-in-progress) IVTC algorithm reliably detects a 3:2 cadence in the hard-telecine section with both CoreAVC and LAV Video Decoder. When the soft-telecine section begins, with CoreAVC my IVTC algorithm detects a cadence break and detects a new 2:2 cadence for the 2nd half of the samples. When using the LAV Video Decoder, the cadence stays unbroken at 3:2 for the full runtime of both samples, because LAV Video Decoder forwards the soft-telecine flags to madVR. The SD and HD samples behave identically. |
|
12th December 2011, 00:43 | #6950 | Link | |
Registered User
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
|
Quote:
|
|
12th December 2011, 07:32 | #6951 | Link | |
Registered User
Join Date: Jan 2003
Location: Silicon Valley
Posts: 455
|
Quote:
Ron
__________________
HD MPEG-2 Test Patterns http://www.w6rz.net |
|
13th December 2011, 19:48 | #6952 | Link |
CoreCodec Founder
Join Date: Oct 2001
Location: San Francisco
Posts: 1,421
|
madshi... we are on the fence here about your post. It's our general opinion that this is not a bug and that it's more of a feature request. So to that...
CoreAVC already removes soft pulldown by itself. If the stream switches between soft and hard then those sectors have no relevance to each other so the flags are then useless. Also, since we are already undoing the soft telecine it would be bad (in our opinion) to pass the progressive frames with those flags set. So for the end users if we did not handle soft telecine the way we do, we can only imagine the amount of people complaining about getting an interlaced picture when they used to get progressive. So the statement of "there should be no negative side effects at all" we feel only applies to your renderer. The only way to properly fix hard interlacing is to use a deinterlacer that is designed to do it.
__________________
Dan "BetaBoy" Marlin Ubiquitous Multimedia Technologies and Developer Tools http://corecodec.com Last edited by BetaBoy; 13th December 2011 at 20:10. |
13th December 2011, 20:18 | #6953 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
"On the fence" isn't too bad, it means you're still open for discussion...
Quote:
Quote:
I'm sorry to say but this is just not true. If you look at such mixed hard-/soft-telecined streams, if you honor the soft-telecine flags you always end up with exactly 60 fields per seconds, no matter how often the stream switches between soft- and hard-telecine. If you silently drop the telecine flags, the deinterlacer will neither get 48 fields per second, nor 60 fields per second, but something in between, every time the stream switches between soft <-> hard telecine. If you have ever tried writing an IVTC algorithm then you should know that this is not a good situation. Getting exactly 60 fields per second is a requirement of most IVTC algorithms. How else can you detect a 3:2 pattern in the stream? If you get e.g. 55 fields per second, the 3:2 cadence will be broken several times and applying IVTC will become extremely hard to do. Last edited by madshi; 13th December 2011 at 22:26. |
||
14th December 2011, 00:03 | #6954 | Link | |
soy sauce buyer
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
|
Quote:
Last edited by 06_taro; 14th December 2011 at 00:06. |
|
14th December 2011, 00:41 | #6955 | Link |
Registered User
Join Date: Jan 2005
Posts: 105
|
define remove?
lav and other decoders I used as well (mpeg-2 decoders mostly), leave the indicated output framerate alone at 29.97 so hard telecine parts of a mixed stream play back at 29.97 (or 59.94) but soft telecine parts of the stream play back at 23.976. In coreavc soft telecine plays back at 29.97, the same as hard telecine. at the very least, this should be an option to do it as in lav, so users can (when madshi's ivtc renderer is done) play back 29.97 hard and soft telecine streams as well as mixed hard/soft at 23.976 |
14th December 2011, 09:00 | #6956 | Link |
Registered User
Join Date: Feb 2004
Posts: 24
|
In version 3.01 I noticed a new output option '9/10 bit', but whenever I check the box then hit Apply and OK the box is unchecked when I go back into decoder properties. What does that mean? Is it a problem with CoreAVC or my hardware?
|
14th December 2011, 17:48 | #6957 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
It's neither a problem with CoreAVC or your hardware. The '9/10 bit' check-box is only a toggle for showing/hiding P010 & P016 in the output format box. The '9/10 bit' check-box does not affect anything but the GUI.
The real options to enable/disable high bitdepth output are the P010 & P016 check-boxes. As long as they are checked, they are enabled and available for use with 9/10 bit h264 video and a supporting video renderer. (Currently only madVR supports P010/P016 input). |
14th December 2011, 19:25 | #6959 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
There is a noticeable quality difference between 10-bit x264 and 8-bit x264.
Yet there is hardly any quality difference between CoreAVC outputting 10-bit x264 as dithered 8-bit YV12 vs 10-bit P010. Both ways are eventually output to your display as 8-bit. If you are using madVR there is a minor technical benefit of outputting P010, since madVR can then do other processing gamut/gamma/yuv->rgb using the full 10-bit data and dither to 8-bit for your display as the last step. Would you notice the difference of madVR processing 8-bit input vs 10-bit input, probably not. But depending how close you look, you may notice a difference in dithering quality & noise pattern. |
15th December 2011, 08:08 | #6960 | Link | |
契約者
Join Date: Jun 2008
Posts: 1,576
|
Quote:
^very simplified explanation The switch in the coreavc and other decoders tells what they should do, leave 10bit format as is so it will be dithered to 8bit later (by madvr for example) or dither it by itself. So nothing is wrong if you don't see the difference. Last edited by Keiyakusha; 15th December 2011 at 08:13. |
|
Tags |
codec, coreavc, corecodec, coremvc, cuda, decoder, dxva, h.264, mvc, scam |
Thread Tools | Search this Thread |
Display Modes | |
|
|