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 > General > Audio encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th March 2019, 13:20   #14781  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,348
Quote:
Originally Posted by sneaker_ger View Post
How would we know when you don't provide any sample.

Also I'm not sure what you expect from running QTGMC "without 'InputType=0'" (which is the same as running it with that parameter as that's the default value) on progressive content.
For every progressive material, I normally use 'InputType=1'. Only interlaced gets InputType=0.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 5th March 2019, 13:24   #14782  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,266
Quote:
Originally Posted by asarian View Post
Hmm, eac3to marks a video at 1080i50.
Quote:
Originally Posted by asarian View Post
Well, here's a sample
That sample is 1080p60.
sneaker_ger is offline   Reply With Quote
Old 5th March 2019, 13:26   #14783  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,348
Quote:
Originally Posted by sneaker_ger View Post
That sample is 1080p60.
Yikes, I linked the wrong sample. Here is the real one: proper sample
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 5th March 2019, 13:37   #14784  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,266
Progressive 1080p25 encoded as interlaced.
sneaker_ger is offline   Reply With Quote
Old 5th March 2019, 13:41   #14785  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,348
Quote:
Originally Posted by sneaker_ger View Post
Progressive 1080p25 encoded as interlaced.
That's what I thought.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 5th March 2019, 17:28   #14786  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 161
Quote:
Originally Posted by sneaker_ger View Post
Progressive 1080p25 encoded as interlaced.
That's not the whole story. It's MBAFF with pic_struct SEIs declaring every coded frame to be progressive; furthermore, bottom_field_pic_order_in_frame_present_flag is set to zero (meaning that the top and bottom fields of the coded frames have the same pic order count and even in the absence of a pic_struct SEI the coded frames should be considered progressive*). But it also has ct_type equal to 1 which means that the original source material is interlaced; furthermore the specs contain the clause that "Two consecutive fields in output order shall have different values of clockTimestamp when the value of ct_type for either field is 1 (interlaced)." This means that this stream is simply out-of-spec!

The reason that this particular sample is treated as interlaced is that FFmpeg uses the ct-type to override the pic_struct (notice that ct_type isn't simply the value read from the bitstream). So changing the ct_type is one way of fixing this.

Notice that ffmpeg has a bug because it always flags MBAFF as interlaced in the absence of SEI (see here) regardless of the pic order count of the fields involved. This means that simply deleting the SEI would not change the behaviour of FFmpeg based players unless FFmpeg is fixed, too (and the player updated).

*: From the semantics of pic_struct:
"NOTE 6 When pic_struct_present_flag is equal to 0, then in many cases default values may be inferred. In the absence of other indications of the intended display type of a picture, the decoder should infer the value of pic_struct as follows:
If field_pic_flag is equal to 1, pic_struct should be inferred to be equal to (1 + bottom_field_flag).
Otherwise, if TopFieldOrderCnt is equal to BottomFieldOrderCnt, pic_struct should be inferred to be equal to 0 [progressive frame].
Otherwise, if TopFieldOrderCnt is less than BottomFieldOrderCnt, pic_struct should be inferred to be equal to 3 [TFF].
Otherwise (field_pic_flag is equal to 0 and TopFieldOrderCnt is greater than BottomFieldOrderCnt), pic_struct should be
inferred to be equal to 4 [BFF]."
mkver is offline   Reply With Quote
Old 5th March 2019, 17:46   #14787  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,266
I always wonder what the guys writing MPEG specs are smoking.
sneaker_ger is offline   Reply With Quote
Old 5th March 2019, 21:19   #14788  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,348
@mkver, wow, that's a complicated story!

Quote:
This means that this stream is simply out-of-spec!
That might explain why tsMuxer totally tripped on it (badly broken and jittery output). I was able to extract the main stream correctly with eac3to.

Quote:
But it also has ct_type equal to 1 which means that the original source material is interlaced;
There's some visual evidence for that too; darn if I can find one now, but earlier, I saw a few frames with your typical interlaced 'stripes' artifacts in them (as if badly deinterlaced). It's this way on the original .m2ts blu-ray too (so it's not an eac3to extract thing).
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Reply

Tags
eac3to

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 01:05.


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