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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 11th December 2011, 14:20   #6941  |  Link
BetaBoy
CoreCodec Founder
 
BetaBoy's Avatar
 
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
BetaBoy is offline   Reply With Quote
Old 11th December 2011, 14:37   #6942  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by BetaBoy View Post
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.
There's nothing you can do about hard telecine. But for soft telecine you should pass the flags downstream. You don't need to do anything with the flags yourself, just set them in the properties of the IMediaSample2 you output. That's really all you need to do, should be very easy to do, and there should be no negative side effects at all.

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.
madshi is offline   Reply With Quote
Old 11th December 2011, 14:48   #6943  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 1,135
Quote:
Originally Posted by madshi View Post
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.
It happens with Bluray too... especially on trailers that are edited at 60i for 'broadcast' purpose but gets a mixture of hard and soft pulldown encode while on disk.
mp3dom is offline   Reply With Quote
Old 11th December 2011, 14:56   #6944  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by mp3dom View Post
It happens with Bluray too... especially on trailers that are edited at 60i for 'broadcast' purpose but gets a mixture of hard and soft pulldown encode while on disk.
Didn't know that. Do you happen to have a sample?
madshi is offline   Reply With Quote
Old 11th December 2011, 15:04   #6945  |  Link
mp3dom
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)
mp3dom is offline   Reply With Quote
Old 11th December 2011, 15:21   #6946  |  Link
madshi
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?
madshi is offline   Reply With Quote
Old 11th December 2011, 19:00   #6947  |  Link
mp3dom
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.
mp3dom is offline   Reply With Quote
Old 11th December 2011, 19:40   #6948  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by mp3dom View Post
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.
Thank you!!

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.
madshi is offline   Reply With Quote
Old 11th December 2011, 21:13   #6949  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 1,135
Glad it helps The samples are bd-compliant, so it's the way an hypothetical bluray could look.
mp3dom is offline   Reply With Quote
Old 12th December 2011, 00:43   #6950  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 707
Quote:
Originally Posted by madshi View Post
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.
Generally speaking, you don't set your encoders to do pulldown detection if you're sending captions because it has bad hardware support. This applies to AVC broadcasts as well so I think this issue will be quite rare.
kieranrk is offline   Reply With Quote
Old 12th December 2011, 07:32   #6951  |  Link
drmpeg
Registered User
 
Join Date: Jan 2003
Location: Silicon Valley
Posts: 455
Quote:
Originally Posted by kieranrk View Post
Generally speaking, you don't set your encoders to do pulldown detection if you're sending captions because it has bad hardware support. This applies to AVC broadcasts as well so I think this issue will be quite rare.
Almost every 1080i pay TV channel in the US has IVTC enabled on their encoders.

Ron
__________________
HD MPEG-2 Test Patterns http://www.w6rz.net
drmpeg is offline   Reply With Quote
Old 13th December 2011, 19:48   #6952  |  Link
BetaBoy
CoreCodec Founder
 
BetaBoy's Avatar
 
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.
BetaBoy is offline   Reply With Quote
Old 13th December 2011, 20:18   #6953  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by BetaBoy View Post
we are on the fence here about your post.
"On the fence" isn't too bad, it means you're still open for discussion...

Quote:
Originally Posted by BetaBoy View Post
CoreAVC already removes soft pulldown by itself. If the stream switches between soft and hard then those sectors have no relevance to each other then the flags are 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.
You're saying that users would get an interlaced picture if you set the telecine flags. But I don't think that's true. Anyway, can you describe a setup for me where setting the telecine flags would result in a loss of quality? The LAV Video Decoder does (always) set the telecine flags, so it should be easy to test. If you're right then LAV Video Decoder should show soft-telecined content at a lower quality compared to CoreAVC with some renderers.

Quote:
Originally Posted by BetaBoy View Post
The only way to properly fix hard interlacing is to use a deinterlacer that is designed to do it.
And that is exactly what I'm working on. But CoreAVC is making things harder than necessary. CoreAVC sets the media type information to 30fps, but for soft-telecined sections only sends 24fps, without telecine flags. So basically CoreAVC is lying. If you remove the telecine flags then you should set the media type information to 24fps. Of course that will make problems with content that has hard-telecine sections, so that brings me back to my argument that there's no reason not to set the telecine flags.

Quote:
Originally Posted by BetaBoy View Post
If the stream switches between soft and hard then those sectors have no relevance to each other then the flags are useless.
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.
madshi is offline   Reply With Quote
Old 14th December 2011, 00:03   #6954  |  Link
06_taro
soy sauce buyer
 
Join Date: Mar 2010
Location: United Kingdom
Posts: 164
Quote:
Originally Posted by BetaBoy View Post
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.
Then you can provide an option for end users to decide whether to maintain pulldown flags and handle them after decoding, or to drop the flags with 24fps film content output directly as in the present version. Those who never meet mixed soft/hard telecined films and don't use any IVTC/deinterlacing postprocessing can still choose the second one to avoid getting interlaced content, but for those who prefer a more reliable IVTC algorithm which can handle mixed soft/hard telecined contents, the first one is much better for most ( if not all ) IVTC algorithms.

Last edited by 06_taro; 14th December 2011 at 00:06.
06_taro is offline   Reply With Quote
Old 14th December 2011, 00:41   #6955  |  Link
dead_screem
Registered User
 
Join Date: Jan 2005
Posts: 105
Quote:
Originally Posted by BetaBoy View Post
CoreAVC already removes soft pulldown by itself.
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
dead_screem is offline   Reply With Quote
Old 14th December 2011, 09:00   #6956  |  Link
v_spec
Registered User
 
v_spec's Avatar
 
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?
v_spec is offline   Reply With Quote
Old 14th December 2011, 17:48   #6957  |  Link
cyberbeing
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).
cyberbeing is offline   Reply With Quote
Old 14th December 2011, 18:17   #6958  |  Link
v_spec
Registered User
 
v_spec's Avatar
 
Join Date: Feb 2004
Posts: 24
Thanks for clearing that up. I've been reading up on madVR for the past couple of hours and was thinking if there is a noticeable difference in quality between the non-9/10 bit h264 video and 9/10 bit video?
v_spec is offline   Reply With Quote
Old 14th December 2011, 19:25   #6959  |  Link
cyberbeing
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.
cyberbeing is offline   Reply With Quote
Old 15th December 2011, 08:08   #6960  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
Quote:
Originally Posted by v_spec View Post
and was thinking if there is a noticeable difference in quality between the non-9/10 bit h264 video and 9/10 bit video?
You should think of 10bit as "yet another switch in x264 that improves quality during encoding" And resulting 10bit file is "yet another video format"
^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.
Keiyakusha is offline   Reply With Quote
Reply

Tags
codec, coreavc, corecodec, coremvc, cuda, decoder, dxva, h.264, mvc, scam

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 05:56.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.