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 > (HD) DVD, Blu-ray & (S)VCD > DVD & BD Rebuilder

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th June 2020, 17:01   #29521  |  Link
MrVideo
Registered User
 
MrVideo's Avatar
 
Join Date: May 2007
Location: Wisconsin
Posts: 1,685
Quote:
Originally Posted by Sharc View Post
Isn't this much the same as with x264 AVC: The coded size has always been 1920x1088 while the display size is 1920x1080?
Yep, that be the case.
MrVideo is offline   Reply With Quote
Old 28th June 2020, 22:07   #29522  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,530
Looking at the output from NVENCC, I'm guessing (but only guessing) that this may be the issue:

According to "White Paper Blu-ray Disc Read-Only Format Coding constraints on HEVC video streams for BD-ROM Version 3.0", page 6, each GOP (Group of Pictures) of the HEVC stream must start with an IDR (of course) -- and will contain one SPS (Sequence Parameter Set), one VPS (Video Parameter Set), and at least one PPS (Picture Parameter Set), and no more than 30 PPSs.

In dumping out the HEVC stream I'm finding that only the first GOP (the first IDR frame and following P/B frames in the file) meets this requirement. All the others IDR frames (start of GOP) I've looked at only have an AUD (Access Unit Delimeter) and a couple SEI's (Supplemental Enhancement Information) preceding the IDR slice.

I'll have to do some finagling with the stream to find out if this is truly the issue -- but it could make sense and explain why the stream can start playing from the beginning (the IDR that has the required information) but can't step into any of the others (FF/REW and CHAPTER SKIPS).

You never know, this may not be the problem at all... but I guess I'm going to have to find out somehow. In X265 you create a stream that contains the SPS/VPS/PPS in every GOP by using the --repeat-headers command line option. I'm hoping the same thing can be done in NVENCC.

I've added this information to my Issue Report at GITHUB. Hopefully someone with a little more HEVC/UHD-BD knowledge than me can confirm or deny this as the cause of the issue I'm seeing.

[Edit] In the meantime, I'm going to see how hard it would be for me to to scan and insert the headers via a software routine -- or if it is even possible. Unfortunately that would require me to read through the entire HEVC file and write a new one -- which requires significant processing time. In the end I may find out it isn't even the problem!
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net

Last edited by jdobbs; 28th June 2020 at 22:52.
jdobbs is offline   Reply With Quote
Old 29th June 2020, 01:54   #29523  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,530
Quote:
Originally Posted by jdobbs View Post
Looking at the output from NVENCC, I'm guessing (but only guessing) that this may be the issue:

According to "White Paper Blu-ray Disc Read-Only Format Coding constraints on HEVC video streams for BD-ROM Version 3.0", page 6, each GOP (Group of Pictures) of the HEVC stream must start with an IDR (of course) -- and will contain one SPS (Sequence Parameter Set), one VPS (Video Parameter Set), and at least one PPS (Picture Parameter Set), and no more than 30 PPSs.

In dumping out the HEVC stream I'm finding that only the first GOP (the first IDR frame and following P/B frames in the file) meets this requirement. All the others IDR frames (start of GOP) I've looked at only have an AUD (Access Unit Delimeter) and a couple SEI's (Supplemental Enhancement Information) preceding the IDR slice.

I'll have to do some finagling with the stream to find out if this is truly the issue -- but it could make sense and explain why the stream can start playing from the beginning (the IDR that has the required information) but can't step into any of the others (FF/REW and CHAPTER SKIPS).

You never know, this may not be the problem at all... but I guess I'm going to have to find out somehow. In X265 you create a stream that contains the SPS/VPS/PPS in every GOP by using the --repeat-headers command line option. I'm hoping the same thing can be done in NVENCC.

I've added this information to my Issue Report at GITHUB. Hopefully someone with a little more HEVC/UHD-BD knowledge than me can confirm or deny this as the cause of the issue I'm seeing.

[Edit] In the meantime, I'm going to see how hard it would be for me to to scan and insert the headers via a software routine -- or if it is even possible. Unfortunately that would require me to read through the entire HEVC file and write a new one -- which requires significant processing time. In the end I may find out it isn't even the problem!
Well... even a broken clock is right twice a day.

That was it. I wrote some code to insert the SPS/VPS/PPS headers into the IDR of each GOP and... it fixed the issue. Fast Forward, Rewind and Chapter jumps now work.

I'll add code into BD-RB to correct the HEVC stream after encoding. It looks like it will add about 15 minutes or so to a job. But that's not bad considering how much time is saved using the NVENCC encoder. I just ran a complete job on a 2 hour and 22 minute UHD/HDR movie and it finished the encoding portion in less than 30 minutes (using the fastest setting).

I have to add supporting code for several subroutines before BD-RB is ready for a testing release -- expect it in the next week or so.

I will also update my issue information on GITHUB and hopefully all the will have to do is add a "--repeat-headers" command line function and make my workaround unneeded.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 29th June 2020, 09:13   #29524  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,643
Quote:
Originally Posted by jdobbs View Post
I will also update my issue information on GITHUB and hopefully all the will have to do is add a "--repeat-headers" command line function and make my workaround unneeded.
Now let's hope that rigaya takes action
Sharc is offline   Reply With Quote
Old 29th June 2020, 09:30   #29525  |  Link
Ch3vr0n
Registered User
 
Join Date: Jan 2009
Posts: 1,337
2h22m compared to what for you @jdobbs? 16hrs? ^^
Ch3vr0n is offline   Reply With Quote
Old 29th June 2020, 12:06   #29526  |  Link
Mike-uk
Registered User
 
Join Date: Jun 2018
Location: Dorset
Posts: 118
i guess this blank issue is only present on a bluray player, was playing the file on a pc ok ??
Mike-uk is offline   Reply With Quote
Old 29th June 2020, 12:51   #29527  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,530
Quote:
Originally Posted by Mike-uk View Post
i guess this blank issue is only present on a bluray player, was playing the file on a pc ok ??
Yes. It was only an issue when authored into BD format and played on a Blu-Ray player. On a PC it had worked fine. I didn't test it, but I would assume an MKV or MP4 would probably have played even on the BD unit. The issue (needing the headers in each GOP) is related to the container type used in an authored BD.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 29th June 2020, 12:57   #29528  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,530
Quote:
Originally Posted by Ch3vr0n View Post
2h22m compared to what for you @jdobbs? 16hrs? ^^
2h22m was the length of the movie. The actual job only about 45 minutes start-to-finish (before correcting the HEVC stream). And, yes, using X265 it would have probably taken somewhere in the neighborhood of 16 hours.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 29th June 2020, 14:21   #29529  |  Link
cartman0208
Registered User
 
Join Date: Jun 2010
Posts: 48
Can't wait to do some alpha tesing
cartman0208 is offline   Reply With Quote
Old 29th June 2020, 14:59   #29530  |  Link
Ch3vr0n
Registered User
 
Join Date: Jan 2009
Posts: 1,337
I don't suppose this will be of benefit for 3D encoding would it. Last time i tried hw acc FRIM it resulted in severe artifacts for software based players.
Ch3vr0n is offline   Reply With Quote
Old 29th June 2020, 18:01   #29531  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,530
Quote:
Originally Posted by Ch3vr0n View Post
I don't suppose this will be of benefit for 3D encoding would it. Last time i tried hw acc FRIM it resulted in severe artifacts for software based players.
Sorry, no.

I haven't looked at FRIM or 3D in a while, but I seem to remember that problem as being related to drivers.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 29th June 2020, 18:02   #29532  |  Link
Ch3vr0n
Registered User
 
Join Date: Jan 2009
Posts: 1,337
I believe a while back someone said there was an updated FRIM build that supposedly fixed that problem. I just have no idea where to get it.

Sent from my Pixel 3 XL using Tapatalk
Ch3vr0n is offline   Reply With Quote
Old 29th June 2020, 19:24   #29533  |  Link
musiclover
Registered User
 
Join Date: Jul 2005
Posts: 116
Quote:
Originally Posted by Ch3vr0n View Post
I believe a while back someone said there was an updated FRIM build that supposedly fixed that problem. I just have no idea where to get it.

Sent from my Pixel 3 XL using Tapatalk
https://www.videohelp.com/software/FRIM and https://forum.doom9.org/showthread.php?t=169651
musiclover is offline   Reply With Quote
Old 29th June 2020, 21:27   #29534  |  Link
Ch3vr0n
Registered User
 
Join Date: Jan 2009
Posts: 1,337
Which one would i need for BDRB, the 32bit version? My cpu is a 9900K
Ch3vr0n is offline   Reply With Quote
Old 29th June 2020, 21:32   #29535  |  Link
gonca
Registered User
 
Join Date: Jul 2012
Location: Somewhere over the rainbow
Posts: 998
32 bit
gonca is offline   Reply With Quote
Old 29th June 2020, 22:56   #29536  |  Link
Mike-uk
Registered User
 
Join Date: Jun 2018
Location: Dorset
Posts: 118
bdrebuilder uses frim 1.25, there has been 5 updates and now 1.31
Mike-uk is offline   Reply With Quote
Old 30th June 2020, 01:46   #29537  |  Link
jdobbs
Moderator
 
Join Date: Oct 2001
Posts: 20,530
Anybody else experiencing this?

I can start NVENCC with a fixed command line.

When I start the job it seems to be slower than I'd expected -- about 125fps. So I stop the job and restart it. Suddenly I'm getting 420fps... with the exact same command line. Try it again... and it's random. I might get either of the two speeds. Weird.

Now THAT's confusing.
__________________
Help with development of new apps: Donations.
Website: www.jdobbs.net
jdobbs is offline   Reply With Quote
Old 30th June 2020, 03:44   #29538  |  Link
MrVideo
Registered User
 
MrVideo's Avatar
 
Join Date: May 2007
Location: Wisconsin
Posts: 1,685
Quote:
Originally Posted by jdobbs View Post
Well... even a broken clock is right twice a day.
Not if it is a digital clock and the display goes dark/blank.
MrVideo is offline   Reply With Quote
Old 30th June 2020, 07:45   #29539  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,643
Quote:
Originally Posted by jdobbs View Post
Anybody else experiencing this?

I can start NVENCC with a fixed command line.

When I start the job it seems to be slower than I'd expected -- about 125fps. So I stop the job and restart it. Suddenly I'm getting 420fps... with the exact same command line. Try it again... and it's random. I might get either of the two speeds. Weird.

Now THAT's confusing.
Strange. Did you check the GPU load and temperature (e.g. using GPU-Z)? Is the speed limited by the GPU or by the bus transfers/memory access? Are you using HDD or SSD? Virus scanner interference, or some other background process interfering?
What I noticed here (NVEncC x264 1050Ti) is an initial speed increase during the first few (say 10) seconds which then settles to a steady value.

Last edited by Sharc; 30th June 2020 at 09:10.
Sharc is offline   Reply With Quote
Old 30th June 2020, 10:17   #29540  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 820
Quote:
When I start the job it seems to be slower than I'd expected -- about 125fps. So I stop the job and restart it. Suddenly I'm getting 420fps... with the exact same command line. Try it again... and it's random. I might get either of the two speeds. Weird.

Now THAT's confusing.
An app being quicker on second run is no mystery, happens with sore more SW.
Its just that these date are still kept in RAM.
Like with tsMuxeR, muxing time went from 9..10 min first run
down to 1,5 minutes for the same 10GB test stream on second and third run.
(Magnetic platter HDDs used, with SSD maybe unnoticeable)
I just extensively tested for one particular stream losing packets at the end.
(solved since the 2020-06-27 build for me, BTW)

Would fit the available 32GB RAM. (Did not run RAMMap though to confirm)
Why it would be slower on third run, I cannot comment.
But if I close the app and allow the RAM to be flushed, then it may take the full first running time again.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're working on that issue. Synce invntoin uf lingöage..."

Last edited by Emulgator; 30th June 2020 at 10:23.
Emulgator is offline   Reply With Quote
Reply

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:26.


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