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 October 2008, 14:35 | #563 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
|
11th October 2008, 14:39 | #564 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
And here for h.264.
http://en.wikipedia.org/wiki/H.264 Under section levels. How accurate the wiki is though, is anyone's guess. BTW. I've only seen 1 blu-ray so far out of about 35 that has had a max bitrate under the 40mbps of the spec. And IIRC about 2 or 3 with max bitrates above 50mbps. The limit of level 4.1. Last edited by Audionut; 11th October 2008 at 14:40. Reason: I guess people would like to understand the post. |
11th October 2008, 14:57 | #565 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Version 1.0.4
* Fixed a problem that could cause large SPSs to not be processed, resulting in decode failures.
* Revised the NALU parser to allow for some missing profile_idc values. * Added lines CODED and PLAYBACK in the DGA file to provide the number of coded and playback frames. * Added a workaround for the Windows bug that (rarely) caused the DGAVCIndexNV window to open off the screen. http://neuron2.net/dgavcdecnv/dgavcdecnv.html |
11th October 2008, 18:04 | #566 | Link | |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
Quote:
|
|
11th October 2008, 23:31 | #567 | Link | |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
On the contrary, the wiki clearly states, Max video bitrate for given levels. Max frame size, Max macroblocks per second.
Quote:
http://akuvian.org/src/x264/ITU-T_H264.pdf.gz Last edited by Audionut; 11th October 2008 at 23:57. |
|
16th October 2008, 00:00 | #569 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
My local build working with MEGUI
Some good news...
My local build is working with MEGUI. This is not the server version but rather just based on the current code but implementing a single D3D instance shared by floating contexts, as recommended by Nvidia. I want to do a little more testing before releasing a beta for testing. MEGUI does some real goofy stuff internally. It opens the script 7 times for a simple 2-pass encode! |
16th October 2008, 21:09 | #572 | Link | |
Registered User
Join Date: Mar 2006
Posts: 1,538
|
Quote:
|
|
17th October 2008, 08:52 | #573 | Link |
Registered User
Join Date: Dec 2006
Posts: 69
|
Dare I say it - yes I will, bit sloppy, even though I use MeGUI myself and like it, but 7 times, fair enough I could understand - once for the preview, and a few for the encode (depending on no# of cores), but that exceeds even that amount (would be 5 in a quad core machine). There is no reason too even have the preview open while encoding anyway .. and sorry neuron2 I know you want too keep the thread clean.
|
17th October 2008, 09:51 | #574 | Link |
Registered User
Join Date: Aug 2002
Location: Latvia
Posts: 69
|
Some experience with DGAVCIndexNV on NVIDIA Quadro NVS140M (Lenovo T61 notebook).
Although there is no certain info about V2 existence on this chip on NVIDIA site, I did give a try, since my previous attempt with GeForce 8800GTS failed (I had to read all discussion thread more carefully). Well, back to Quadro NVS 140M - it works but not on full HD resolution. I could run DGAVCIndexNV on smaller sample videos: 720x400 ~ 200 FPS in preview mode, 1280x720 ~ 90 FPS. When I did try to open 1920x1080 clip, DGAVCIndexNV fails to initialize video decoder: "GPU decoder: Failed to create video decoder (100)" Possibly it is some limitation of chipset, although DXVAChecker does report ability to decode H.264 up to 1920x1080. Another issue - did try to encode to something else (Xvid, MPEG-2). Xvid went fine (I did use VirtualDub on .AVS script), but CCE SP2 Trial did fail with Exception 0xC0000005 in all attempts. Any ideas what might be the reason for this CCE crush? The same clip when used with DGAVCIndex (libavcodec) and DGAVCDecode works normally on CCE. Added later info 19.10.2008: I did try also encoding to MPEG-2 with HC_enc (0.23) and QuEnc (0.72). Both failed exactly the same way - Exception 0xC0000005. Can anyone report the success with MPEG-2 encoding if DGACVDecodeNV is used in .AVS script? Last edited by screw; 19th October 2008 at 10:21. |
17th October 2008, 11:29 | #575 | Link | |
Registered User
Join Date: Dec 2007
Posts: 639
|
Quote:
|
|
18th October 2008, 01:06 | #576 | Link | |
Registered User
Join Date: Dec 2006
Posts: 69
|
Quote:
---- I was under the belief that x264 can output too sout and serr (standard out and standard error streams) so therefore there isn't really a need for the extra as MeGUI could just monitor those streams and do whatever it wants with the info (it does already with the fps, time, etc), so it really doesn't justify extra avisynth processes running just for monitoring (actually it doesn't make much sense at all too me). Then again I haven't looked at the MeGUI code, so I may just be spouting crap. |
|
18th October 2008, 16:22 | #577 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
sorry for helping the hijack here...
x264 writes the log information (debug, info, warnings, etc. depending on the level of info you want: see --verbose and --quiet) to stderr by default, and the code is hardcoded for that, so it can't output video data to stderr. x264 can write to stdout though by specifying the out file as - the thing is iirc, A. megui already monitors the stderr stream for displaying the progress statistics and x264 error/info within megui B. I don't recall megui natively supporting x264 writing to stdout, it wants x264 to write to a file. C. megui handles more programs than just x264, so i believe point B is related to not all the programs it deals with having stdout support. i have only a vague idea why megui would open the avs script that many times as i don't use it regularly; that would be to check the video parameters (AR, FPS, etc.) and then from opening it, it would find errors. But of course this is just speculation within reason. would have to ask Sharktooth on why it actually opens that many times. so a bit back on topic... hows the progress on testing that floating context version build coming along? because honestly once that stabilizes the whole multiopening conflict within megui and any other encoding programs, the problem becomes moot. Last edited by kemuri-_9; 18th October 2008 at 16:25. |
22nd October 2008, 05:46 | #578 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
But there is good news. I went back to my server idea and just tonight completed the implementation of DGAVCDecodeNV based on the client-server model. It works just fine and MEGUI works without issues. Interestingly, a global mutex was not required because MEGUI is well behaved about closing the script each time before re-opening it again. I may add one later anyway, but it's not required to support MEGUI. I hope to roll this out tomorrow evening after doing a code review. I also plan to release the source code for the server as well as a primitive GUI client (though not the source code for DGAVCDecodeNV). That will enable other people to use the CUVID decoder in their own applications. Last edited by Guest; 22nd October 2008 at 05:50. |
|
22nd October 2008, 13:03 | #579 | Link |
Registered User
Join Date: Jan 2004
Posts: 849
|
Neuron, I was following the CUDA dialogue you keep track of on your site with interest, and I was wondering if the code provided by NVidia engineer (NV12->YUY2) is under any form of licence or if it's otherwise inadvisable to just take it from there and use it. Also if it is free-for-all kind of a deal, your last recorded message reads that you are using an updated version of that function. Is that the second one posted there, or have they sent you an even newer one?
Thanks.
__________________
Geforce GTX 260 Windows 7, 64bit, Core i7 MPC-HC, Foobar2000 |
22nd October 2008, 13:07 | #580 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|