View Profile
View Forum Posts
Private Message
What you have there appears to be the x264 slow speed preset with the animation tuning and High Profile, Level 4.0, or something very close to it:Originally Posted by supercain
The above was using quality based encoding (CRF18) so there's a difference there (your video was encoded while specifying a bitrate for 2 pass encoding), and mine was a low resolution encode, which means the number of ref frames are higher than if it'd been 1080p, but loading the defaults, then configuring the x264 encoder like this gave me the above settings. I didn't touch any of the advanced options.Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 10 frames
Codec ID : V_MPEG4/ISO/AVC
Width : 496 pixels
Height : 272 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 142 r2409 d6b4e63
Encoding settings : cabac=1 / ref=10 / deblock=1:1:1 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=31250 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:0.60
Language : English
Keep in mind when re-encoding, the video is decompressed and the encoder re-compresses it. It's oblivious to how the source video was encoded originally so there's no need to match the settings used when encoding the source unless there's a specific need to do so.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 31 to 57 of 57
Thread
-
Last edited by hello_hello; 2nd May 2014 at 13:59.
-
I have tried megui before, i remember the very first times i was able to see that window with the video preview but not any more after that. I installed and reinstalled many times but i never got it back so i quit the program and uninstalled it forever. I also tried with a program called format factory which can open avisynth files so i created the script with vertualdub and then frameserved but couldnt get it right either.
What im confused about is, if i use avisynth then it doesnt matter i have 2 videos in different formats/encodings? I still can join them? -
I uninstalled Comodo firewall and now all my encoder sets work again.Originally Posted by DarrellS
After uninstalling Comodo firewall I'm still getting "AdTrustMedia is trying to make changes to your computer" messages.
It's a sorry state when free security software starts becoming Adware/Malware. -
Originally Posted by supercain
Yes, that's the whole point
It's all joined in the script, and you can hardsub at the same time
They only have to be the same dimensions, and framerate for the video. (The audio has to match for the audio as well e.g, # channels, sample rate) -
It is pretty interesting (but way over my head) how you can use scripts as encoders in Virtualdub. There is a guy on the Virtualdub forums (Raffriff) who uses bat files as encoders and muxers. Here are a couple of links...
http://forums.virtualdub.org/index.php?act=ST&f=3&t=21780
https://encodingtalk.com/threads/raffriffs-awesome-virtualdub-tutorial.739/page-4#post-15145 -
You'll have to re-encode them to join them. You can encode them individually and join the encodes together when they're done. As long as they have the same resolution and aspect ratio and you used the same encoder settings each time, and included --stitchable in the x264 commandline, you shouldn't have a problem. If the resolutions are different you'd resize where applicable to make them the same when you re-encode. The format/settings of the original files are irrelevant because you're re-encoding it all.Originally Posted by supercain
As poisondeathraysaid, it's possible to create a script which would encode the sections of video you want to keep while adding the subtitles where needed etc and then it could all be encoded as a single encoding job. It's not overly hard to do but it does require a little Avisynth knowledge.
I tend to encode video in sections and just append the encodes together when they're done. -
But wait, poisondeathray suggests and with avisynth i dont need to previously encode the parts to join them, right? But i cant do this with virtualdub because at the very moment i select append avi segment i get the error that says i cant put them together since they have different encoding settings so i cant even start the project. In fact i cant even select "append avi" because my part 2 is a mkv file. So my question now is what program to use to start off?
By the way, i just checked and i still have megui. However, i still have the same issue. I dont have any preview window. Why is it that? Is there any place where i must activate it or something?
Thank you. -
You could direct stream copy the files into an avi container. Sometimes, if you remove the audio from problematic avi files, Virtualdub will join them.
-
Hmm no, on virtualdub you cant direct stream copy videos such as mp4 or mkv, only avi.
-
Yes.Originally Posted by supercain
It's basically doing all your uncompressed steps, without all the steps or HDD space of uncompressed videos.
And even if the dimensions, frame rate don't match you can make them match in avisynth
Like I said earlier, rarely is there a single "best" way, but there are so many "pros" vs. cons to using this method, it really is the best way
These days it's more likely to succeed encoding and hardsubbing AVC if you do it correctly using --stitchable, or joining with elementary streams instead of using container (e.g. dos copy). And there is always a small risk it wont work doing it that way. But joining isn't as fast or good quality wise than doing it one step with avisynth. The more cuts you have, the fewer references that could have been used, potentially lowering encoding efficiency and quality.
If you're were NOT going to hardsub, then you can make a case for not using avisynth - because avisynth frameserves uncompressed video (it decodes frames "on the fly" , so you don't need huge HDD storage requirements with actual uncompressed videos) , so you usually need to re-encode to the final format
Don't get confused about all the other command line stuff. And it's not as difficult as all conditional filter stuff you asked about in the other thread - that wasn't an ideal 1st project to get you feet wet with avisynth. What you want to do here is very easy. You're going to kick yourself for not trying it earlier.
It might be as simple as something like this for the joining part: (You need an actual source filter, but it's just to demonstrate the point)
Code:A=Video1 B=Video2 C=Video3 A++B++C
If the softsubs are timed to each section you just add that
Code:A=Video1.Textsub("Video1.ass") B=Video2.Textsub("Video2.ass") C=Video3.Textsub("Video3.ass") A++B++C
You can edit the .avs in vdub. The .avs "looks" like an uncompressed video to vdub, so it's just like editing a video directly in vdub that you're familiar with.
Or you can use avspmod to edit the script directly - it has a trim editor, crop editor - those are part of avspmod and GUI's that allow you to interactively edit. And if you plan on doing more complex things with avisynth you will want to start using avspmod -
I don't think poisondeathray was saying you don't need to re-encode...... there's really no way around it..... just that with a bit of Avisynth knowledge you could probably combine all the encoding jobs into a single script and encode the output as a single encoding job.Originally Posted by supercain
I'd probably just encode each part individually and join the encodes together later.
I can't say I've come across anyone else with that problem. How old is the version you're using? Is it giving you an error? It might be an Avisynth issue, but I'd just delete/uninstall it and download the latest version. I don't think there's no installer anymore. You just unzip it, put it somewhere, run MeGUI and then the updater under the Options menu. Let it do it's thing and you should be good to go. The only third party application you need installed for some decoding is the Haali Media Splitter.... and I think MeGUI requires a minimum of dot net framework 2 to work (maybe that's the problem?) but unless you're running XP you'll definitely have that. It comes with a portable version of Avisynth so you don't need to install it separately. The only other thing required is the NeroAAC encoder which is easy to download if you want AAC audio encoding, then NeroAAC can be enabled in MeGUI's options. All you need to do is copy NeroAAC.exe to the following MeGUI folder: "MeGUI\tools\eac3to"Originally Posted by supercain
When you first run MeGUI you can switch to the Log tab and look under "Versions". If there's any important bits missing/not installed, it'll tell you there.
-
You sure that last bit isn't a little overstated? Sure, if you're combining encodes with durations measured in seconds, but when the individual encodes are longer than that it wouldn't have much effect on quality/file size. If any. At least not when using CRF encoding.Originally Posted by poisondeathray
If the audio in the original files is all the same format, I'd encode each section individually, replace the original video with the encoded version using MKVMergeGUI, save that as a new MKV, repeat the same process for the next section of video etc etc.... then append all the encodes together later..... but as you said, there's lots of ways to do it. -
That generic statement is a fact. I didn't say how much quality you would lose - maybe you interpreted as "overstated ? "Originally Posted by hello_hello
You sure that last bit isn't a little overstated? Sure, if you're combining encodes with durations measured in seconds, but when the individual encodes are longer than that it wouldn't have much effect on quality/file size. If any. At least not when using CRF encoding.Originally Posted by poisondeathray
Most of the time with a few cuts, it won't be noticably worse. You can only measure the quality loss with metrics
The quality loss is proportionally worse with the number of sections and the lower the bitrates relative to content complexity scenarios (lower parts of the compression curve). So with a few cuts and adequate bitrate it should be negligible
In situations where you need VBV control, it will potentially fail when joining as you violate VBV restrictions with buffer underflows, overflows (e.g. blu-ray compliance, some devices)
Sure you can append segments after encoding . Certainly an option - but it doesn't always work, and quality/compression is always worse , never better or the same than if you encoded it in 1 segment (although you might not see the loss depending on the situation), and it's slower to encode unless you use distributed encoding (multiple nodes encoding seperate segments), slower to join (you have to manually join or automate using scripts to join) -
I think I see where pdr is going. And to take it further, every time you make a cut/append of different angles/images, etc., you are creating an immediate, TOTAL motion dis-continuity. When done in a standard editor, this OUGHT to entail the subsequent use of that new image stream/sequence to begin with an I-frame (or more accurately an IDR/sequence header). Taking this to the absurd extreme, the more cuts you make, the more discontinuities to the stream, the more I-frame/IDRs there ought to be (and the shorter the GOPs will be), to the point where every frame is a new sequence and you have all I-frame video. Clearly at this point, you MUST either have been (greatly?) increasing your bitrate, or you would have conversely been lowering your quality.
Scott -
As an experiment I created three scripts to encode 3000 frames of a DVD I had sitting on my hard drive.Originally Posted by poisondeathray
I put this at the end of the first script:
Trim(5000,7999)
For the second one:
Trim(5000,6543)
And for the third:
Trim(6544,7999)
I made sure the first frame of "encode 3" was the first frame in a new scene.
When they were done (CRF18 and default x264 settings with --stitchable each time) I appended the second and third encodes together and compared the appended version to the first encode. According to Bitrate Viewer the difference in average bitrate was 1kbps (the appended version was lower). I repeated the process a second time (different split point) with the same result.
I'll admit a found it interesting because the first frame of "encode 3" had a lower bitrate than the same frame in "encode 1" (it was a keyframe each time). 12905kbps, v 9226kbps according to Bitrate Viewer. When I compared them I could see a quality difference (well I could see they were encoded slightly differently, at least). There was a similar difference between frames until the next keyframe, and from there the two versions seemed pretty much the same again (well it might have taken 2 keyframes before they were once again exactly identical, but the quality differences between frames in the second gop were next to nothing).
Mind you even though I'll confess the first "gop" in encode 3 was technically lower quality than the same "gop" in encode 1, it was definitely a difference it'd take pausing on identical frames and comparing them individually to see. And even then, if I didn't know which was which, I'd probably have to compare both to the original too see which version was more "accurate". At least when using a low CRF value.
For me, it's nothing which would stop me from encoding sections of video individually and appending them together. Especially as doing it that way can offer an advantage at times. Quite often I'll encode a few sections of video using a lower CRF value than the rest, then append the sections together. Or sometimes I'll encode a video and then wish I'd used noise filtering for five minutes in the middle somewhere, so I'll split it, encode the appropriate part again, then join the bits together..... that sort of thing.
I've never had a problem appending encodes if the same encoder settings are used each time and --stitchable is used, and I've done it quite a lot.Originally Posted by poisondeathray
I guess there's situations where one method would be more appropriate than another..... whatever works.
Last edited by hello_hello; 4th May 2014 at 13:05.
-
Don't you see there is more benefit, less downsides to doing it once instead of appending pieces ? There is no reason to append pieces after the fact if you're using avisynth and hardcoding anyways. The only reason I can think you might do that is for speed, if you do distributed encoding
What advantage over the 1 script method if you're re-encoding anyways? It's only disadvantages . Slower (unless you distribute) , lower quality always (in most cases minimal, in some cases relevant), VBV violations , more clunky requires you to join - even if you batch automate the joining the file has to be re-written (stream copied), so more HDD space, more time wasted again . Imagine if you had 20-30 sections. Or more.Especially as doing it that way can offer an advantage at times.
Sure, if you don't want to re-encode a section. But in his case, he's hardsubbing . Earlier I mentioned if there were large sections without subs, then you can make a case for smart rendering.
Quite often I'll encode a few sections of video using a lower CRF value than the rest, then append the sections together. Or sometimes I'll encode a video and then wish I'd used noise filtering for five minutes in the middle somewhere, so I'll split it, encode the appropriate part again, then join the bits together..... that sort of thing.
Use Zones if you want to apply different encoding settings for section
If you're filtering different filters, using different settings for segments, you can do it in the script and just encode once.
Large scene differences are a big risk for VBV violations (e.g. a noisy scene appended to a still, calm scene) , and the local buffer level isn't taken into account -
That is strange since I just direct stream copied a AVC.mkv into a AVC.avi.Originally Posted by supercain
-
Originally Posted by supercain
double post -
Definitely not true. Direct stream copy works even for ASF (WMV) files.Originally Posted by supercain
You cannot rewrap MPEG-1 or MPEG-2 in AVI through the MPEG-2 input plugin, though. -
Originally Posted by DarrellS
That is strange since I just direct stream copied a AVC.mkv into a AVC.avi.Originally Posted by supercain
Yes you can with the mkv import plugin. You can't with the DirectShow plugin and FFInputDriver because they are decoded to uncompressed
But it's not very useful - because editing natively with direct stream copy of AVC in vdub isn't reliable - you will often get glitches, green frames, or the wrong frame/ frames out of order - even if you attempt to cut on keyframes
Theoretically , if you used AVC without b-frames, or even I-frame only, you shouldn't get those issues. But I-frame AVC even has those issues in vdub for some reason -
I run a single threaded version of Avisynth because it's rock solid, and I use QTGMC quite a bit, so often when I add QTGMC to a script I split the encode in half and encode them both at the same time. That keeps the CPU pretty busy. When it's done, I append the two encodes. One very marginally lower quality gop in the middle of an encode is a small price to pay for nearly double the encoding speed. And judging from the test encodes I just ran, that's all the difference there'd be at the CRF value I use.Originally Posted by poisondeathray
A walk in the park. My record..... and admittedly it's a fairly extreme example, was to divide a movie into over 100 sections. I'll never to it again, and it started out as a single script, but should I adjust the filtering/cropping/colour/contrast for one section and then spend 10 hours re-encoding the whole thing, or should I re-encode just that section? Now let me see....Originally Posted by poisondeathray
I didn't end up with over 100 hundred individual scripts, but I definitely re-encoded quite a few of those sections more than once before I was happy.
It doesn't take too long to add individual encodes to a muxing job. And MKVMergeGUI has that "additional parts" button for bulk appending.
There's one MP4 which requires hardsubbing, and another which requires splitting and a third clip inserted into it, then the whole lot needs to be joined together.... the way I understand it.Originally Posted by poisondeathray
Smart rendering might be possible for some of it, but the chances of successfully appending it all probably wouldn't be too high.
That'd be fine if hindsight could be applied retrospectively..... but then I guess it'd be foresight..... the problem is, I don't always know a lower CRF value with a little more dithering will be required to stop banding in a particular scene until after I've encoded the whole thing.Originally Posted by poisondeathray
Sometimes I do, sometimes it requires the benefit of hindsight.Originally Posted by poisondeathray
Sometimes I've even encoded whole videos twice with different filtering or a different CRF value, then split each encode up the same way and combined the sections I want to keep to make it whole again. Sometimes I don't know what's going to work best until it's encoded. But then admittedly that's encoding the whole video as a single encode. Except for the times I re-encode one of those sections with different filtering again before combining all the bits.....
I've tested the VBV settings required in order for my Bluray player and TV's media player to play a high bitrate encode without stuttering. I re-encoded a complex 1080p video with a CRF value which pushed the bitrate up to 100,000kbps in places (sustained for a few seconds). The Bluray player didn't care. The TV required --vbv-bufsize 58000 and --vbv-maxrate 58000 in order to play the video smoothly. Any higher and it'd stutter a little. As it turned out, the same settings were required for my video card to do the decoding stutter-free. Consequently VBV restrictions don't really don't factor into the equation for me. It's very unlikely to be an issue.Originally Posted by poisondeathray
In a perfect world...... yes, I definitely agree. Patching everything together with a single script and running a single encode is the best way to do it, but for lots of practical reasons, often it isn't.
The discussion so far really only takes video re-encoding into account. Keeping the audio in sync can be a whole other issue when joining "unrelated" videos together, especially if you don't want to re-encode it. If you're re-encoding the audio it shouldn't be hard, but if you're not, sometimes encoding each section of video individually, adding the appropriate audio to each, then appending each section together is the easiest way to avoid sync issues, at least when using MKVMergeGUI for appending.Last edited by hello_hello; 4th May 2014 at 15:52.
-
I thought about that after I posted. It also goes for avisynth which is why it is better to always use the correct codecs when you can instead of taking the lazy route and installing one plugin hoping it will work for all your files. Even with the input plugins you still need to depend on ffdshow to help open certain files.Originally Posted by poisondeathray
Originally Posted by DarrellS
That is strange since I just direct stream copied a AVC.mkv into a AVC.avi.Originally Posted by supercain
Yes you can with the mkv import plugin. You can't with the DirectShow plugin and FFInputDriver because they are decoded to uncompressed
But it's not very useful - because editing natively with direct stream copy of AVC in vdub isn't reliable - you will often get glitches, green frames, or the wrong frame/ frames out of order - even if you attempt to cut on keyframes
Theoretically , if you used AVC without b-frames, or even I-frame only, you shouldn't get those issues. But I-frame AVC even has those issues in vdub for some reason
I know it's not wise to put avc in avi container but for trying to append multiple files together for editing, it is a work around. Using mkvmerge to append is probably a better option though. I hardly ever get mymp4box or Yamb to work correctly. AVC is a finished product though and not meant to be edited. Even the best editors will choke on avc at times. -
i did not see the suggestion for using ffmpeg, since you can direct-stream-copy the source. if you're just splitting pieces then i don't see why not give it a try also.
-
Thats weird, i have the plugin that opens mkvs but even with that, i cant save them as direct stream copy. Why? Do i need another plugin?
Aslo, i kinda found a solution for my problem. In fact i just recalled what i had already done before in these situations. Since i have to encode anyway, i encode part 1 and 2 separately, and since they are going to be encoded with exactly the same settings then i can join them with direct stream copy. I just would like to be able to use the external encoders feature so i can save to mp4 instead. -
I tried opening an MP4 using the Quicktime plugin and VirtualDub resaved the output as an AVI using direct stream copy without any problem. The Matroksa plugin did the same for an MKV.
Try the Quicktime and Matroska plugins on this page (the fccHandler versions). When you open a file, make sure you specifically choose the correct plugin. VirutlaDub may be opening the video using the wrong plugin by default.
Last edited by hello_hello; 5th May 2014 at 13:08.
-
I've never had to use the "open with "Matroaska files"". You do need to have the mkv input plugin and ffdshow vfw set to open h264/avc with libavcodec.
You cannot use direct stream copy under Video with the external encoder feature. You can use ffmpeg to pass through mp3 and ac3 with the external encoder feature but not aac. -
First:Originally Posted by supercain
use %(outputname).264 instead of %(outputname).mp4
I use special encoder sets to mux files with no audio.
For MP4:
Create an Encoder called MP4-NA-Mux
Type: Multiplexor
Program: C:\Tools\GPAC\mp4box.exe
Command Arguments: -add "%(tempvideofile)" "%(outputname)" -fps %(fps)
Check Mark for first three boxes
Create an Encoder Set called MP4-M-NA
Video encoder: 264_M
Audio encoder: (None)
Multiplexer: MP4-NA-Mux
Check mark for Process partial output when render is aborted
File description: mp4
File extension: mp4
For MKV:
Create an encoder called MKV-NA-Mux
Type:Multiplexer
Program: C:\Tools\mkvtoolnix\mkvmerge.exe
-o "%(outputname)" --compression 0:none --default-duration 0:%(fpsnum)/%(fpsden)fps "%(tempvideofile)"
Check Mark for all boxes
MKV-M-NA
Video encoder: 264_M
Audio encoder: (None)
Multiplexer: MKV-NA-Mux
Check mark for Process partial output when render is aborted
File description: mkv
File extension: mkv
Quote
