Log in

View Full Version : Old AutoRV10 discussion (closed)


Pages : 1 2 3 4 5 6 7 8 9 10 [11] 12 13

Dark-Cracker
10th December 2004, 17:42
edit : i think i have found the bug.

Doom9
18th December 2004, 12:10
I guess I just don't know how AutoRV10 checks that but it is throwing a major fit on my machine:

When I install AutoRV with AviSynth, upon startup I get a "You need to install AviSynth 2.5.x" error message. And.. in fact I can no longer play may AviSynth files. So then I installed AviSynth 2.5.5 after AutoRV10 and now I get a "You need to install a YV12 decompressor". Needless to say that this is complete BS, my PC is perfectly capable of handling YV12 content and just in case I've installed the latest XviD build (and I know with certainty that XviD can handle YV12 decoding, and not only for XviD playback).

Valky
18th December 2004, 12:27
For the first time ever, I had this error too "You need to install a YV12 decompressor" when I was trying to start the app.
I know I dont need to install anything and I have not had any problems with earlier builds.

Razorblade2000
18th December 2004, 12:52
there is some helix community yv12 decompressor thingy bundeled with realanime... maybe that's what you need :D

Doom9
18th December 2004, 13:08
instead of having to install yet another real rip package, is there any chance you could post that decompressor for us to try? I'd much appreciate it and I'm sure valky would, too.

Razorblade2000
18th December 2004, 13:47
Kein Problem :D
I attached it, hope it's ok :D

edit: hmm... he DOES display something when I edit the post (Keep current attachment ( yuvcodecs.zip ))...
but it isn't visible for others 0_o
Does it have to be accepted by an admin/mod first?

Doom9
18th December 2004, 13:54
Does it have to be accepted by an admin/mod first?Yes it does. Thanks for posting. Too bad I can't try it right now as I'm encoding and I'm a bit afraid installing filters might have an adverse effect on that.

hellfred
18th December 2004, 14:01
I can help great mr doom9 himslef?
Great!
The Helix codec is available <drums rolling> in your very own forum (http://forum.doom9.org/showthread.php?s=&threadid=56972). It is a vfw codec, so maybe that is the problem with letting xvid do the colour scace transformation from th YV12 to the I420 colourspace.
I think I once tried to enable ffdshows raw decoding support in the vfw configuration, but i have forgotten weather that worked, too, or not. So you can check that one before installing any Helix binaries.

By the way, do you know some basic german?
Here (http://www.heise.de/newsticker/meldung/54377) is a link anouncing that Cyberlink (http://gocyberlink.com/english/index.jsp) has a
MPEG4 AVC encoder application (http://www.gocyberlink.com/english/cyberstore/product_order.jsp?ProdId=89) for sale.

Hellfred

hellfred
18th December 2004, 14:02
Damit, i was too slow :(
EDIT: No fame for me for helping doom9 himself :( :(
EDIT: Not even recieving any sign of attention by his Higness
*hellfred wanders off sobbing*
:D

karl_lillevold
18th December 2004, 17:29
I think D-C used to include the YV12 codec in his installer. Now it is simply listed as one of the three downloads on the first page in this thread. This probably indicates it would be a good idea to again include it in his installer. :)

Dark-Cracker
18th December 2004, 18:56
hi,

in fact the yv12 error msg is just a check on the registry key :

HKEY_LOCAL_MACHINE, "Software\Microsoft\Windows NT\CurrentVersion\Drivers32", "VIDC.YV12

i don't know exactely how avisynth react if it doesn't found an yv12 decompressor (i think i will try with YUV and if it fail it will try with RGB).
so to avoid problem of multiple colorspace conversion i have add a check on this registry key (installed when you install xvid or helixyv12 codec who will be included in the final installer). if someone know a better check to know if the yv12 colorspace will be correctely decompressed, let me know the tip.

for the avisynth error it's because my nsis script is bugged this will be solved with the next install script.

PS : a new build will be released soon, i will try to made it quickly if you need a binary soon.

++

Doom9
18th December 2004, 19:10
installed when you install xvid or helixyv12 codec who will be included in the final installerActually, I tried installing XviD. I already had Koepi's 1.1 build installed, then I tried Nic's and finally Koepi's 1.0.2 and I kept getting the same error. It'll be another 1.5 hours then I can try installing the real codec and see where that gets me.

Dark-Cracker
18th December 2004, 21:33
hi,

a quick build to fix the bugs reported from the beta 7.

link :
------
http://dark.pluridis.org/AutoRV10_v1.0_b7.1_update.zip

changelog :
-----------
- fix one little bug if the .pass is really huge
- fix bug with the maxbitrate when you use endcredits
- disbable the yv12 error msg (be sure you have an yv12 decompressor)
- add the new erv4.dll (latest RV10 codec dll)
- i have finaly add some code in my "exit buttons" :) :) :)

@doom9
plz use this build , i have also disable the yv12 error msg. else if you install the helixyv12 codec you will not have this error msg.

Bye.

Bye.

Valky
19th December 2004, 01:18
Things are working again, so thanks for this quick-fix.
I didn't have to intall any additional codecs (I know I had them anyway).




Hmm.. managed to get an error. Error number '13' 'type incompatible' or something like that.

edit: I found the problem. I was testing with very short video and I used the same script first with file limit 1mb (0.151bits) and next testing I didn't want to use 2mb cause this would have gave me too big 0.302 bits. Program accepted filelimit setting 1.5mb and it would have gave me 0.227 bits, but it always gave me that error when it should have started encoding.

This isn't a big issue cause people don't usually use that kind of filelimits but cause it accepted that value I thought it should work.

Dark-Cracker
19th December 2004, 02:45
hi,

i think you have got this error because you have try to enter a float number file size but with the wrong separator.

perhaps you have used the character "," instead of "." ?

i will add some check error in the textbox later :)

EDIT : in fact if you use the separator "." for the float it will not work you should use the comma "," so i think "1,5" should work.
i will try to fix this when i found a few minute :)

++

Doom9
19th December 2004, 12:40
@Dark-Cracker: thanks for the new build, though I'm already well into encoding.. I installed the codec to be done with it.

Valky
19th December 2004, 13:03
Originally posted by Dark-Cracker




EDIT : in fact if you use the separator "." for the float it will not work you should use the comma "," so i think "1,5" should work.
i will try to fix this when i found a few minute :)

++

Actually I tried with both separators, but when trying to use comma the value in bit-box didn't change like it did when using dot. That's why I thought I chose the right separator.

Doom9
19th December 2004, 14:24
I do have a feature suggestion: check the available space.. I just wasted the last 14 hours because I didn't check if there was enough HD space (serves me to use a notebook as encoding machine).. and not even realproducer aborted.. it simply wrote a 500mb file instead of a 1400mb one.

Dark-Cracker
19th December 2004, 15:15
@valky
it's perhaps because it search in the local setting the separator ( dot for english country and coma for european country), i will solve this bug for the next build :)

@doom9
yes you are right i think this option could be usefull , i have add it to my todolist.

EDIT : by curiosity do you use the Standard Curve compression or the AltCC option ?

Bye.

Doom9
19th December 2004, 15:34
EDIT : by curiosity do you use the Standard Curve compression or the AltCC option ?standard as suggested by karl

Valky
20th December 2004, 09:41
I was little bit surprised to see my final result was 6 mb oversized when target was 350 mb (dvd, ac3 audio). I have never had any problems before with this tool, but it was the first time I used this setting '100 insane'.

Dark-Cracker
20th December 2004, 15:06
hi,

yes it's strange, it's perhaps because you source is hard to compress, if you want you can try to re-do only the second pass (when you click on add job you can select the first .pass file and when it will ask if you want to keep the scaled value you answer NO) keep the same params but with a size lower else you can also disable the AltCC and use the Linear Scaling it will perhaps work more accurate.

Bye.

ookzDVD
23rd December 2004, 03:28
@DC

To be honest, the AutoRV10 is the most complete & easy solution for DVD into RV at least for me. Two thumbs up for your program!

I wonder someday your program will be more similar like AutoGK which
does automatic field detection, automatic resize, etc.

No more manual work to do except ripping the DVD use the DVD Decrypter in IFO mode.

Thank you.

Dark-Cracker
23rd December 2004, 04:08
hi,

@ookzDVD

thank u for you nice words :) i am always glad when i see my work is apreciated and usefull for other peoples :)

about the *auto* feature there is still a lot of room to improve them, for the moment i have add a "basic" frame analyser who detect the percent of FILM, Interlaced or telecined frame i think however hybrid material are not really well detected, for the resolution there is an auto-crop (who select the black bars / it analyse 5 frame to detect the correct values instead of using the autocrop avisynth filter), i have also work on a way to suggest the best resize resolution (once you have made a compressibility test it analyse the avg quatizer).
of course these functions are not perfect because it requiere a lot of time to made some tests and to find the correct threshold to use for an accurate result. i think len0x have spend a lot of time to made some tests, and in my case i don't have really much time to develop my softwares so for the moment i will try to improve other features (like a better subtitle support, DTS support, or improve ripping functions) and after i will try to improve this :)


Bye.

#2
23rd December 2004, 21:19
Hi DC. Thanks also from me for this tool it has made my encoding life so much easyer. : )

Right now, with the latest beta, I'm getting my Favourite error again.

Settings: For LOTR-ROTK extended edition (2 DVDs).

-AMD optimisations
-PAL 16:9
-Anamorphic resise with keep croped resolution
-No Field filter (progressive source)
-removegrain
-Normal motion
-First pass higher complexity
-E.H.Q. 100
-Idle Process Priority

Heeps of space every where, NTFS, win XP SP1 and SP2. This has happened on 2 machines one with an output file size of 4680MB useing a single .d2v
and the other with 2 .d2v/jobs (finalsizes of around 2250MB)

Blade Runner went ok with very simmilar settings;

-Decomb Field filter
-finnalsize=1850MB

I'm going to try it now with the b7 /softs;/avs and the b6 exe;ini;cfg;dll

Dark-Cracker
23rd December 2004, 22:01
hi,

i suggest you to test with the following :

- install the full version
http://dark.pluridis.org/downloads/Autorv10_v1.0.zip
- install the update beta 7.1
http://dark.pluridis.org/AutoRV10_v1.0_b7.1_update.zip
- install the fix (overwrite the old .exe with this new one)
http://dark.pluridis.org/AutoRV10_tmp.zip

the beta 7.1 have fix the overflow error msg when you have a big .pass file (=> when you have a long movie).

the third fixed .exe is to avoid overflow error when you use and ouput desired size bigger than 3072 mb.

some people who encode some hdtv movie for an output size of dvd (4489 mb) have report me this error and i think the third .exe have fixed this matter.

remember you can re-use the first stat .pass file this will avoid you to re-do the first pass.

in any case thank you for the bug report :)

PS : just in case : when you encode with an output size bigger than 2GB don't use endcredits else rmeditor will failed to open such bigger file.

PS2 : let me know if this solve you problem :)

PS3 : it's perhaps time for me to made a full working installer :)

Bye.

ookzDVD
24th December 2004, 02:15
@DC,

Thank you for your reply.

Glad to know you still have "energy" to improve your program :)

I know the "auto" feature is need more time to try and test
than time to program itself. :) But I believe someday you have
some time to make that happen! :)

I'm agree with you (like a better subtitle support, DTS support, or improve ripping functions) is in your priority.

Thank You.

#2
25th December 2004, 11:46
Wow. I really appreciate the speed of your work.

I thought you might like an up date.
The b6 attempts failed with the same error while your latest build worked flawlessly for the 2x 2250MB encode.The 'all in 1' 4680MB encode just finnished now and is split at 3.9G even though it was in a NTFS partition, a fail safe for fat32 I guess? Now all I have to do is figure out how to join a 3.9G file to a 690MB one. : )

BTW I'm really likeing the high quality encodes that you can get with 'Anamorphic resize' and 'keep cropped resolution'

Are there any other tweeks to my settings that I could be doing for these type of back ups? Any thing to the advanced codec settings? And correct me if I'm wrong but with 'keep cropped resolution' there is no resizeing done so Lancoz vs Bicubic would make no difference?

And thanks once again for your great tool.

Dark-Cracker
25th December 2004, 20:01
hi,

yes i think the 3.9 Gb problem come from the producer (limited at 4gb it's perhaps a safe limitation for fat32, it seems to me i have speak about this problem with karl and it seems to me it was a limitation for linux ??? but i will ask him again later).

I don't know how to made a such join (even if you move the file on a ntfs disk , rmeditor can't open file bigger than 2gb :( ) i think the best solution is to re-do the second pass with an output size of 3990 mb .

in anamorphic keep cropped res mode the filter resize is ignored.

i think some good time for such high encode could be :

AltCC with auto calc at light, and agressivity at Slow.
and i think a litte Xsharpen could improve slighthy the details.

i think there is no other *general* tweak to improve such HD encode :)

thank you for the bug report these fixes will be added in the next releases :)

Bye.

#2
26th December 2004, 10:31
Cheers DC I'll try those settings.

Another couple of Qs;

-With Xsharpen. If I'm useing 'removegrain' might I also use 'Reduce Noise Amplification' with a light Xsharpen? Or would that be more for lower bit rates?

-If I change my 'Curve Agression' from Medium to Slow can I still reuse my first pass file?

Thank you.

calinb
26th December 2004, 12:40
Originally posted by Dark-Cracker
it seems to me i have speak about this problem with karl and it seems to me it was a limitation for linux ??? but i will ask him again later). I don't know why there would be this limitation for Linux running any of the popular and modern filesystems.

I too am having much better results with your latest test build. One job, that previously had the error 6, completed. My 4489MB jobs are not yet finished, though. Great work, darkcracker :)

@ #2 - you might try to re-mux to matroska, or even ogm. Then try to read/append the files into vdubmod 1.5.10. I've had some luck using directstream copy to join mp4 ASP files this way. I'll let you know if a figure out a method.

Dark-Cracker
26th December 2004, 16:36
hi,

@#2
it's not needed to use "reduce noise amplification" with xsharpen for such hight bitrate :)

yes even if you change some tweak in the altCC you can still reuse you first pass (autorv10 write the *new* scaled frame size value in the .pass file without overwritting the original frame size, and when you re-use a first stat .pass file if autorv10 detect such a file was already scaled it will ask you if you want to keep these value or not, if you select not it will overwrite the .pass file without the scaled value and when it will start the second pass it will scaled the file with the AltCC settings, hum i hope it's enough clear even with my poor english :) ).

and i think the better solution to join the two file is to use mkvmerge and get an output matroska file (attention it will strip some rmvb information like chapters or tag, so if you have use them think to add them again in mkvmerge GUI).

PS : apparently realproducer have split you file in two part can you plz post the name of the 2 file ? (i think it have generate a name like xxx_20041220 by adding the date and perhaps time in the filename).

@calinb
happy to heard it work also for you :)
i am not sure if the previous realproducer were running under linux so perhaps if it's a start they have add a limitation and wait to fix it later. i will let you know if i found more information on this :)

PS : i think you have made some bigger backup so i am interested to know if you have encountered some filesize limitation/problems ?

Bye.

#2
26th December 2004, 19:59
Thanks Cal. I remuxed to .mkv with mkvmerge then used avimux to join and then mkvmerge to mux the audio. (Could possibly use AVIMux for the whole lot if your not useing an AAC audio stream)

During the encode I trimed the 2 black frames of the end of the first disc and the audio is in sync for the whole film. I must say I am pritty happy with the results. : )

For DC. My file names.
LOTR-ROTKallin1_Movie.rmvb
LOTR-ROTKallin1_Movie1.rmvb
Sorry no dates in them.

Re. the first pass file. I guess I should have asked which settings I should NOT change if I want the first pass file to still be worth useing to save time.

I'm guessing I can change any filters on the filters page but not resolution/cropping or frame count?

If I change the final file size then the first pass file will still save time? Just the output size will be over writen?

I'm not sure about changing the codec settings either; EHQ complexity, first pass complexity, advanced codec settings, dupe filter, black filter etc.

Cheers
#2

Dark-Cracker
26th December 2004, 21:37
>which settings I should NOT change if I want the first pass file to still be worth useing to save time.

when you open the first stat .pass file autorv10 check if the following params are correct :

- detect if the realvideo stat version file is correct.
- check if the number of frames is equal.
- check if the FPS is equal.
- check if the resolution is equal.

as soon as the following values stored in the .pass are equal at the input video you can re-use the .pass file. there is no check on the crop or the filter used, so you can change them (slightly) from the first pass to the second pass without *problem* (attention : filters change the compressibility so this can *potentially* disturb the bits redistribution for the second pass).

you can change final size, EHQ level, and AltCC params without problems.

"first pass EHQ" will be ignored because the first pass will be skipped because you re-use the .pass file :)

for the realvideo filters (like DropDupe and black filter) i think there is no problem too.

but in any case if you re-use a .pass file it's always better to reuse the same filters, and only change EHQ, final size and AltCC params.

Bye.

IgorC
27th December 2004, 02:33
i have a version 1.0.6 (downloading update right now) Does it use a last updated codec RV10?
i put in properties ¨Delete temporal files¨ but it didn´t delete them.

can anybody suggest me how enchased RV10 for high bitrate? 3-3.5 Mbits

Source: NTSC 29.9 fps 740x480 no noisy, most scences are high-motion.

Dark-Cracker
27th December 2004, 05:28
hi,

yes latest beta come with the new erv4.dll file (latest rv10 codec).
"delete tempory file" is not actually completely finished so it will work better in the futur releases :)

my personnal (i can't take responsability :) ) settings for HD encoding :

RV10 HD => use anamorphic resize (keep cropped resolution) be sure you crop values are not ODD.

perhaps a ligh xsharpen filter to improve sharpness.

removegrain filter genraly doesn't harm.

use kerneldeint for IVTC if needed.

EHQ = 100 / highter EHQ for first pass.

if you encode a short movie ( around 1H30 or below) use AltCC with autocalc at full and agressivity at slow.
if the movie is >1H30 i suggest AltCC with autocalc medium and agressivity at fast.

hope these few suggestions can help you :)

++

calinb
27th December 2004, 10:06
Originally posted by #2
Thanks Cal. I remuxed to .mkv with mkvmerge then used avimux to join and then mkvmerge to mux the audio. (Could possibly use AVIMux for the whole lot if your not useing an AAC audio stream)

Hey, thank you #2. I hadn't found time to try it myself but, after your success, I did. :) I even used the GUIs for mkvmerge and avimux and they worked great. I thought maybe avimux would have trouble with the AAC, but it seems to mux it okay, after doing the initial mux of the files with mkvmerge. I now have my first 4489MB file created with AutoRV10--actually, it's about 4MB oversize in both mkv and rvmb files but now we know how to do it :)...and thanks to dark-cracker for supporting large files. Now, if we can just get RN to do something about the silly 3.9G limiation we can reduce the steps.

#2
27th December 2004, 12:10
This is great. So many Questions that I've wanted to know are now being answered.

Just to clarify this DC;

Originally posted by Dark-Cracker
if you encode a short movie ( around 1H30 or below) use AltCC with autocalc at full and agressivity at slow.
if the movie is >1H30 i suggest AltCC with autocalc medium and agressivity at fast.


Do you mean;

if you encode at a 'high quality (bits/frm*pxl)' use AltCC with autocalc at strong (full?) and agressivity at slow.
if the movie is encoded at lower quality (bits/frm*pxl) i suggest AltCC with autocalc medium and agressivity at fast?

By "if you encode a short movie" I'm asuming you mean that for a given file size, say 2 CDs, a short movie would then have a higher bits/frm*pxl. And you then adjust the 'Auto. Calc.' and 'Curve Agression' settings based on the encodes 'Quality' (bits/frm*pxl)

Or were you saying that the running time of a film has an influence on the 'Auto. Calc.' and 'Curve Agression' settings.

I assume that you mean the first. And if so the sugestion you gave me for high my high 'quality' (0.235 bits/frm*pxl) encodes was;
Auto. Calc.=Light
Curve Agression=Slow

But above you sugest
Auto. Calc=full (I guess you mean Strong?)
Curve Agression=Slow


So I guess I'm a bit confused.

-Did you mean Strong not full
-Did you mean bits/frm*pxl or actual running time.
-Would you still sugest;
Auto. Calc.=Light
Curve Agression=Slow
For my 0.235 bits/frm*pxl encode of a 4hr+ film.

Thanks again this has been very informative

P.S. I'm glad to hear it worked for you Cal esp. with AAC. Ditto on the 3.9 GB Real splitting.

Dark-Cracker
27th December 2004, 18:14
hi,

in fact i have speak about lenght of movie just to separate the 2 cases :
- an easy compressibility.
- a movie hard to compress.

i think you can speak about Quality (bits/frm*pxl) even if in this case the resolution doesn't matter.

i will explain a bit better the AltCC params :)

Auto Calculation => calculate the high and low % from average frame size.
the params (Light / Medium / Strong) are some threshold to compute these %
- Light => count all the frames.
- Medium => exclude some frames (ignore some "unnaturally high" framesizes)
- Strong => exclude more frames.

for example with a short sample you have these values :
- Light => 600% / 250%
- Medium => 300% / 200%
- Strong => 250% / 190%

these high/low distance % are used in the bitrate redistribution, Lowering the low distance will move the preference towards low bitrate frames. Raising the high distance will move the preference towards high bitrate frames.

Curve aggression defines how quickly the codec adapts bitrate to frames.
the params (Slow / Medium / Fast) are the speed of bitrate redistribution.

A fast aggression will help the codec aid low bitrate frames while hurting high bitrate frames and is better for very dynamic scenes (i.e. a slow motion scene, then up to a lot of motion very quickly). Slow aggression adapts slower and won't improve low bitrate frames as much, but will not harm high bitrate frames much either.
Medium aggression is a compromise of the two.
-----------

1)
in you case i think >=0.23 bits/frm*pxl
Auto. Calc.=Light
Curve Agression=Slow

it will result in a no agressive redistribution.

2)
and below :
Auto. Calc.=Strong
Curve Agression=Fast

this will result in a redistribution of hight bitrate toward the low bitrate frame size.

the case 1) is what i call a short movie , case 2) is what i call a long movie. :)

PS : feel free to post another question , i am actually working on a FAQ :)

Bye.

tiki4
28th December 2004, 09:58
Hi D-C,

I just saw your FAQ. Very nice work!

Best wishes,

tiki4

Dark-Cracker
28th December 2004, 18:08
thank you :)

the faq is here : http://forum.doom9.org/showthread.php?s=&threadid=87270

and it's still under construction but if you find some usefull question/answer to add feel free.

++

calinb
29th December 2004, 06:28
Originally posted by #2
During the encode I trimed the 2 black frames of the end of the first disc and the audio is in sync for the whole film. I must say I am pritty happy with the results. : )#2: How did you trim the 2 frames? I'm happy with the results and our file joining method usually works for me, but I have one encode where the 2nd part has audio 1000ms ahead of the video. Other encodes are perfect. Weird! I'm unfamilar with RV10 tools and directstream copy in Vdubmod leaves me with a corrupted file. Thanks!

#2
29th December 2004, 09:30
For Cal.

Originally posted by calinb
I have one encode where the 2nd part has audio 1000ms ahead of the video.

This sounds like there's 1 second of video missing at the change over (or 1 sec of audio padded). So it doesn't sound to me like trimming more video will help you. : ]

3 ways to trim; (especially for 2+DVD encodes)

1- Untick the last chapter while useing DVD Decrypter on all but the last DVD. (Not the most reliable method)

2- Use rmeditor.exe to trim post compression. (Reliable but not frame accurate and only for sub 2GB files : (

3- Add a trim line below the source line of your AVS ('Edit Script AVS' button in AutoRV10 'Add Job' dialoge)

Video=Trim(Video,Start Frame,End Frame)
For Example;

# VIDEO SOURCE
Video=Mpeg2Source("F:\RIPS\LOTR-ROTK\D2\LOTR-ROTKallin1.d2v", idct=2 )
Video=Trim(Video,0,183534)

Or you can cheat and set your end credits to your desired 'end frame' and then use the Film_Movie.rmvb
(Frame accurate but obviously slow)

Originally posted by calinb
I'm unfamilar with RV10 tools

Methods for useing rmeditor

- Add the attached file (Open Cmd Prompt Here for NT/2000/XP/2003) to you registry. Unless you already have this.

-Copy the file you want to split/trim to your ...\Autorv10\Softs\Rp9_Light directory.

-OR Add ;"Drive:\Path\To\Autorv10\Softs\Rp9_Light" to your PATH. Right click My Computor -> Properties -> Advanced tab -> Enviorment variables -> Select Path -> Edit -> scroll to end -> add your path to rmeditors folder including the ";" separator(Useing this method you can use rmeditor from any directory with out haveing to copy a potentialy large file to your System partition)

-Right click on the directory with your file in it and select cmdhere.

-Type "rmeditor" in the cmd prompt for useage help. It's easy really.

For example.
rmeditor -i LOTR.rmvb -o LOTRTrimmed.rmvb -s 00:00:00:000 -e 02:12:14.855

(You can get the start and end time from Ctrl+G in MPC when paused at the right frame)


Don't worry it took me 3 months to get my encode of the Starship Troopers flipper right. ;)
Hope that helps.

P.S Fantastic start to your FAQ DC that really helps a lot.

calinb
29th December 2004, 19:51
#2, Thanks for the tutorial. Your post gave me some ideas. I'm encoding HD transport streams so there's no DVDDecrypter step. I'm trying to avoid re-encoding so I'll try trimming about 1 sec of video with rmediator or adding 1 sec of sound with BeSweet. Re-encdoding the AC3 sound won't take long. Luckily, the break is in a place in the movie where it won't be noticed :) Even though it's not frame accurate, I might get lucky with rmediator.

Update:

The sync problem was associated with using avi-muxGUI to join and mux the producer split files containing real audio sound. Actually, I was surprised when avimuxGUI almost worked.

So I encoded the original AC3 to AAC with Nero to try it again. I remuxed the fully joined video file using mkvmerge and no sync problems :). I didn't need to edit the video stream at all. If dark-cracker can convince Real to remove this 3.9G limitation we'd have a pretty sweet point and shoot ap for making full DVD-R/+R HD videos.

To summarize what works for me for an output filesize > 3.9GB:

1. Use AutoRV10 to encode video only (no audio).

2. Use an audio encoding ap of choice to encode audio (or just keep AC3/DTS or whatever.

3. Use mkvmerge mmg/GUI to remux the 2 rmvb files to 2 mkv files.

4. Use avimuxGUI to join the 2 mkv files and remux with audio, if the audio is compatible with avimuxGUI.

5. Use mkvmerge mmg/GUI to mux audio to the mkv file produced by avimuxGUI (joined file), if not done in step 4 (AAC, for instance).

karl_lillevold
31st December 2004, 19:36
calinb: Thanks for doing all these experiments!

In Step 1) above, did you encode the video in two parts to end up with two files, both < 3.9 GB in size?

I have to refresh my memory (by talking to the right person) how hard it is to fix the 4GB file size limit, but I worry that it is quite problematic. It might be field in the RM file format that is 32 bit, and RMFF itself must be changed. The 2GB limit in Rmeditor is a programming problem, but the Producer team is extremely limited in resources and will not update the old rmeditor code.

I wonder if it is possible for AutoRV10 to use the mkvwriter output plugin to output directly to Matroska, thus having no filesize problems at all, and significantly simplifying the process outlined above..

I think using Matroska is the best solution for now. The 4GB filesize limit will not be fixed soon.

calinb
2nd January 2005, 09:58
Originally posted by karl_lillevold
calinb: Thanks for doing all these experiments!

In Step 1) above, did you encode the video in two parts to end up with two files, both < 3.9 GB in size? Yes. My target filesize is 4.38 GB (single DVD-R) and I always end up with one file of 3.9 GB and the "overflow" in a 2nd file.

Another method for ease of use and close to full DVD-R bit utilization would be to not encode the audio and keep the AC3 as a separate file on the DVD-R. Encode the video right up to the 3.9 GB limit. MPC can load external audio files automatically. No remux hassle :) A matroska plugin solution would be much better though, obviously.

Dark-Cracker
3rd January 2005, 08:35
hi,

hum if i right remember the matroska plugin have still some problems :(
i will try to see later if there is a better way but i think for the moment huge encode will still need the previous trick.

++

#2
5th January 2005, 04:01
To further the High Definition encode discussion.

What I have been doing to date is setting the bits/frm*pxl to 0.235 for all sources. However due to the continuium of sources' compressibility based on the ammount of detail and motion in it. This will generate a different visual 'quality' for each encode??

I gather from what I've read on your compressibility test in earlyer posts if you get a 'compressibility' result of 100% from a test useing 100% of 'movie percent used' then you can be sure that the source will be encoded to 'max' quality with producer in quality=75 mode (used to be quality=83). Is this correct?

If this is correct then for the sources I've tested. I end up with large file sizes at 'max' Quality (100% Comp. test result) :

Blade Runner;
2843MB
0.362 bits/frm*pxl

A Time For Dancing;
2701MB
0.285 bits/frm*pxl

ROTK (Ext. ed.);
8697MB
0.336

Dead Man;
2981MB
0.443 bits/frm*pxl

Also I've noticed that the greater the percentage of a source I use the higher the 'Compressibility' results tend to be.

eg. Dead Man: 5%=57.9 15%=57.9 50%=60.1 80%=61.8 100%=63.9
I got similar results (4% - 8% increase in 'Compressibility' from 5% 'movie percent used' to 100% 'movie percent used') for other sources as well.

So I'm guessing I could be better to set my finnal file size for a 60% - 70% 'Comp. test' result than to just religiously sick to a 0.235 bits/frm*pxl setting.

Also what might be a min. 'Comp.test' result that would still be compatable with the type of HD encodes we've been talking about here. ('light' / 'slow', Anamorphic, Keep Cropped, kerneldeint, EHQ = 100 / higher EHQ for first pass, Xsharpen)

P.S. Is 'Use chroma mode decision' good for HD?

P.P.S Are there any more strings that I can use in the Settings.cfg file to change the defaults to say 'removegrain', AltCC settings, Anamorphic, Keep Cropped, EHQ = 100 / higher EHQ for first pass, etc.

Thanks : )

#2

karl_lillevold
5th January 2005, 20:29
#2: Sorry I can not be of much help.. I generally do not use the comp. test. I have found that for SD anamorphic encodes when viewed on my Samsung DLP via DVI, 0.235 bits/pixel looks very nice. Lower motion content, even 0.2 or a little lower is OK. I always use HFE2 for playback, no sharpening for anamorphic.

I have not yet played around with encoding HD for viewing on that TV though.

The reason compressibility increases when you use more of the source for the the comp test, is that the scene changes then become less frequent. This makes the source easier to compress.

I would also suggest you use EHQ 85 and 50 for 1st pass for HD. This will save you a bunch of time, without any noticable loss in quality. Chroma mode decision should improve the quality for strong chroma videos, both SD and HD, and never hurt for any videos.

I would be curious which bits/pixel number you end up with, if you target 60-70% comp test final file size ....

#2
5th January 2005, 22:57
Thanks Karl.

You've just inspired me to use HFE2 for the first time. (I take it is not included in RealPlayer 10-5?)

Nice explanaton on the Comp. test discrepency. I'm thinking with a bit of experience one might be able to fairly well guess the result of a "Select movie percent used=100%" test from the results of a "Select movie percent used=10%" test. (eg. +3-6% for high motion source +6-9% for a low motion source)

So you think EHQ=85 and the default 50 for the first pass? I'll run some speed tests and see if I can spot the difference visually.

While on the subject... please excuse a potentially silly question but if we are not too worried about exact final file size, just a Quality setting of around 70%. Could we not run a "One Pass VBR" or "One Pass Quality" encode? Or will it just not be as clever with its bit-rate redistribution and also end up with larger than nesessary files?


The bits/pxl figures for a 70% Quailty target are.... Just 70% of the 100% Quality figure.. : ) All those Comp. tests were useing 100% of the source and calculated for 100% Quality.

Blade Runner
0.253 bits/pxl

A Time for Dancing
0.2 bits/pxl

ROTK (Ext. ed.)
0.235 bits/pxl

Dead Man
0.31 bits/pxl

Dead Man is a bit of a suprise as it is B/W and very low motion. (although high grain)

Is "Max" quality still calculated with producer in quality=75 mode?