View Profile
View Forum Posts
Private Message
You need to do the test with info(). Because you're not using MPCHC to decode or encode, they might be using different decoding pathways. The short explanation is there are slightly different decoding pathways. Since you're using AVISource(), not Directshow, not something else, that's what you should be testing if you want to be precise
When you're talking about GUI's that's what they are, just window dressing. They are supposed to make it easier to use. They have tickboxes, switches, sliders etc.. Avisynth works with almost all of them (for example, you can load .avs scripts into vdub, you can load .avs scripts into megui, or ripbot or almost any of them. They all have access to x264 settings, and most of them have an extra commandline option box, which means you have access to all the x264 settings , maybe not through a tick box, but through the commandline box)
Of course higher would be better, but 3.5Mbps is definitely watchable for this type of content - it's not difficult to compress content like lots of movement, actions scenes etc...
The "deadline" was just referring to the timeframe you said you wanted to encode it. Some filters will slow it down considerably, but light filtering won't slow it down 4x .
Increased max # consecutive b-frames will improve compression efficiency . That's probably one of the most important settings for improving compression efficiency for x264. Unfortunately for you, the safe value for devices is 3 . Some will happily play strings of 16, but that's device specific . Again you need to do some tests, or if you don't have time, just go with 3 to be safe
For the multipass encodes and lossless intermediate - for example, if you run a 2 pass encode, but have a slow filter in the script. That slow filter is encountered twice - once in the first pass, a second time in the 2nd pass. If you use a lossless intermediate you might think it's slower because you're encoding 3 times, once for the lossless, 1st pass, 2nd pass. But that' s the nature of slow bottlenecking filters. They are so fricken slow that applying it once to a lossless intermediate is actually faster even with "3" encodes.
+ Reply to Thread
Results 31 to 60 of 61
-
-
Does it matter to convert the colorspace? Yes, as standard profiles of h264 expect YV12 as a source (at least, using x264).Originally Posted by abolibibelot
OK, noted. Is the compression ratio comparable with those ?Originally Posted by Cornucopia
Thanks for the improved script. Does it matter to convert the color space before encoding ? Does the "Aud" line automatically extract a full-length WAV file as you wrote earlier ? Does the "Audiodub" work flawlessly in your experience, with no sync issues ? What do "Ready", "Return", "Mix" mean exactly ?@abolibibelot, the AVS script...should get you a proper YV12 combined source with which to encode with MeGUI. I would use a standard hardware-based profile using MP4 container, AVC video & AAC audio. Start with ~CRF 18-22.Code:A = AVISource("video1.avi") B = AVISource("video2.avi") C = AVISource("video3.avi") Aud = WAVSource ("audio.wav") Vid = A ++ B ++ C Mix = Audiodub (Vid, Aud) Ready = ConvertToYV12(Mix) Return(Ready)
Should I choose "Blu-Ray" as hardware-based profile ?
CRF mode won't produce a predictable file size, or I would have to make many tests to get the correct value, which defeats the purpose of saving time with a single pass encode.
Very good idea indeed, I can send my brother a sample and ask him to test it on his external hard drive connected to the LG player. I can't do the same with my mother and that Thomson TV, though (she barely knows what a USB port looks like, as for my grandmother she was fascinated by my compact camera which films "in colors" !).Suggestion: cut a clip of ~20 sec from your AVISynth script (using an extra line of TRIM() at the end, and save as a 2nd AVS) and do the encode (saving your MeGUI settings to a custom preset) and send those to the interested parties to have them test the file. If it doesn't work, you haven't wasted a long time. If it does work, you just do the full length encode.
I've seen far worse regarding the bitrate (actually one of the extra files I plan on adding on the DVD is the movie “Rain Man”, YIFY encode, which is a meager 621MB for 2h13 in 1280x720, that is 613kbps average bitrate ! and, well, it's definitely watchable... at least way better looking than another version I had “found” earlier in 720x404 RV9 for 701MB...).3hours at avg ~2Mbps would be 2.7GB (not uncommon for 720p highly compressed encodes). Too big to email, but you could put it up on dropbox etc., or you could mail a SL data DVD, or a small, standard FAT-formatted USB.
Again, sending it through the internet would work with my brother (I regularly have TeamViewer sessions with him, so I can do the technical stuff myself), but I have a slow uploading capacity and he has a relatively slow download capacity (even more so within a TeamViewer session), it would take me about 10 hours to upload, and 2 hours to download it from his computer. Couldn't do the same with the other intended recipients. So physical means of transfer seem preferable in this case. USB sticks would be way more expensive (5 euros at best for a 4GB one when a SL DVD is 0.25 € and a DL DVD about 1€). I might use DL DVDs after all, but there would still be a 4GB limit, hence my settling on a 2-pass encode in any case (not sure this is grammatically correct).
AUD does not extract a wav, you have to render the wav out from your NLE ahead of time (as I suggested earlier). AUD just references it, just like the video lines are referenced to their respective video pre-renders.
Mix and Ready are like the other variable names, just to help you with understanding the program flow. Return() is what gets you the frameserved output when you lead up to it with named variables (it just makes it explicit).
Blu-ray is a profile you could try out. I don't think it will end up being the best profile, but it's a start.
You could do 2pass VBR, but assuming your encodes are less than 4GB for your total, the filesize isn't that important, so CRF encoding makes more sense, as long as you are in the ballpark with the proper value.
Again, you can (and usually SHOULD) do test encodes on snippets to get yourself near where you want to be. Yes, it adds a small amount to your total time.
I agree about the price differential with the various media.
Doesn't have to be a 4GB limit on DL media if you rendered to HDD that was NTFS, etc. and then transferred to & burned a data DVD that used UDF 2.0 or >. Only mUDF 1.02 (specific to "DVD-Video" compatibility) requires 1GB max filesize. And one shouldn't use ISO9660 for DVDs anymore really.
Remember, in this type of situation, you can do partial renders->join->encode or you can do partial renders->encodes->join. Whichever works best for you (though I usually prefer the former, as that allows for bitrate efficiency across the join). -
I copied the script into an AVS file, just like you wrote (AVISource("name_of_file_1.avi") + Info()), then opened that script with MPC, and wrote down the info it displayed. Isn't that what you requested ? The exact same info is displayed if opened with VirtualDub or MeGUI. Not sure what I did wrong here (and getting tired, need to sleep !).Originally Posted by poisondeathray
All right, then RipBot is in the same class, but for instance, speaking of similar tools I do know, Handbrake, though very easy to use, doesn't propose some of these refinements (no Avisynth support, limited set of codecs and settings). (Maybe I should upgrade it though, I have a 2011 version, but I read that it hadn't changed in that regard -- which isn't a bad thing, its specific appeal is to be simple and straigthforward.)When you're talking about GUI's that's what they are, just window dressing. They are supposed to make it easier to use. They have tickboxes, switches, sliders etc.. Avisynth works with almost all of them (for example, you can load .avs scripts into vdub, you can load .avs scripts into megui, or ripbot or almost any of them. They all have access to x264 settings, and most of them have an extra commandline option box, which means you have access to all the x264 settings , maybe not through a tick box, but through the commandline box)
In this case it better be watchable as it was encoded with CRF18, which is supposed to deliver excellent quality, almost indistinguishable from the source. But the other file encoded with target file size is 1.6Mbps and to my eyes is still very good.Of course higher would be better, but 3.5Mbps is definitely watchable for this type of content
What do you mean ? I thought it was one of the trickiest aspects of a video influencing its compressibility.- it's not difficult to compress content like lots of movement, actions scenes etc...
OK, I had missed the "On multipass encodes" (so many informations at once). Indeed, even the first pass has to analyze the already filtered frames to provide reliable statistics.For the multipass encodes and lossless intermediate - for example, if you run a 2 pass encode, but have a slow filter in the script. That slow filter is encountered twice - once in the first pass, a second time in the 2nd pass. If you use a lossless intermediate you might think it's slower because you're encoding 3 times, once for the lossless, 1st pass, 2nd pass. But that' s the nature of slow bottlenecking filters. They are so fricken slow that applying it once to a lossless intermediate is actually faster even with "3" encodes. -
Okay......Originally Posted by abolibibelot
-
Ok, if it says RGB then, does it look ok in terms of colors in megui preview, if you erase ConvertToYV12(). Or do the colors look shifted? If they look OK, then you should be using ConvertToYV12(matrix="Rec709") for it to look the same on a BD playerOriginally Posted by abolibibelot
You can double check that, by previewing with RGB using the Rec709 matrix . Temporarily add ConvertToRGB(matrix="Rec709"), and if the colors look right, you will be ok . Don't forget to erase or comment it out before encoding for real
It depends on how your editor converted the original footage to RGB. If it did it correctly, it should have used Rec709. When you export RGB, everything is still ok up to that point, then you must specify 709 when converting back to YV12
Handbrake is the notable one that doesn't support avisynth, at least not directlyAll right, then RipBot is in the same class, but for instance, speaking of similar tools I do know, Handbrake, though very easy to use, doesn't propose some of these refinements (no Avisynth support, limited set of codecs and settings). (Maybe I should upgrade it though, I have a 2011 version, but I read that it hadn't changed in that regard -- which isn't a bad thing, its specific appeal is to be simple and straigthforward.)
Typo - it was supposed to say not difficult to compression content like yours, compared to content with lots of movement....What do you mean ? I thought it was one of the trickiest aspects of a video influencing its compressibility.- it's not difficult to compress content like lots of movement, actions scenes etc... -
What happens if it's not ? Avidemux didn't complain when I made those first tests, did it convert it automatically ? And as I wrote earlier, x264vfw configuration within VirtualDub has an option to "Keep input colorspace" or "Keep/Accept only YUV 4:4:4", etc.Originally Posted by Cornucopia
OK, sorry, I got that soon after (it became obvious when I had an error warning at line 4 in the script). So I did render the whole audio as WAV from Magix Video Deluxe, the program didn't crash (at least the first time), but for some reason it ended up as two chunks, one being 1 942 898 KB, the other 115 853 KB ; I tried 4 times, with the same result (same chunk sizes). I tried to correct a possible source of error at the junction point (a cross-fade overlapping with a curve attenuation of some brief noise if that's clear enough), to no avail. (I also tried to export a small portion around that point and it produced only one file, so it's only when exporting the whole movie's audio.) Another strange thing is that the contents of those files (for instance the first chunks from the two first attempts, before I changed anything on the timeline) appear very different in an hex editor (although they seem to sound just the same) -- shouldn't they be identical ? (I wanted to compare them with ExactAudioCopy's WAV comparison tool but it only accepts 44.1kHz WAVs, I don't know another program with such a function.)AUD does not extract a wav, you have to render the wav out from your NLE ahead of time (as I suggested earlier). AUD just references it, just like the video lines are referenced to their respective video pre-renders.
Now what can I do, try to append those two chunks with yet another tool, or attempt to run the encode without the "WAVSource" part and hope the joining will be flawless ?
OK ! Being french it wasn't readily obvious... So it could be anything instead, or it would work the same if not using variables and typing the whole corresponding command each time ?Mix and Ready are like the other variable names, just to help you with understanding the program flow.
I read here that "DXVA" was generally optimized for maximum compatibility :Blu-ray is a profile you could try out. I don't think it will end up being the best profile, but it's a start.
http://www.sevenforums.com/tutorials/104382-video-encoding-x264-megui.html
If I use SL-DVD file size is important (3 hours movie to fit in 3GB). With DL-DVD indeed, from what you said about DVD file systems, it should be fine with a CRF of 20-22.You could do 2pass VBR, but assuming your encodes are less than 4GB for your total, the filesize isn't that important, so CRF encoding makes more sense, as long as you are in the ballpark with the proper value.
The thing is, there are several distinct parts with very different video content, even if the bulk is similar to the sample I posted ; so doing test encodes would only give a very rough estimate of the final size.Again, you can (and usually SHOULD) do test encodes on snippets to get yourself near where you want to be. Yes, it adds a small amount to your total time.
I tried once to burn a >4GB MKV file with ImgBurn, the file system selection was probably ISO9660 + Joliet + UDF 2.01 as I generally do for data DVD, and it said I had to choose between two tricks for it to work, if I remember correctly, either fake an exactly 4GB size, or split it in two chunks, and it posed compatibility issues -- so that was only because ISO9660 was selected ? I thought it was a case of "Who can do more, can do less", i.e. that selecting all the available file systems would result in maximum compatibility... And so there's no justification anymore to use ISO9660, even to guarantee compatibility with older devices ?Doesn't have to be a 4GB limit on DL media if you rendered to HDD that was NTFS, etc. and then transferred to & burned a data DVD that used UDF 2.0 or >. Only mUDF 1.02 (specific to "DVD-Video" compatibility) requires 1GB max filesize. And one shouldn't use ISO9660 for DVDs anymore really.
Indeed the first way seems "cleaner", but apparently it doesn't go without "glitches" (that word sounds so ominous once you've heard it in Robocop !). By the way, is this issue specific to Avisynth ? Would joining those three files with VirtualDub or FFMPEG (as others advised) have produced a perfect file with glitch-free audio ?Remember, in this type of situation, you can do partial renders->join->encode or you can do partial renders->encodes->join. Whichever works best for you (though I usually prefer the former, as that allows for bitrate efficiency across the join). -
If it isn't YV12, depends on the app that's being frameserved. Some might compensate for it, some won't. MeGUI (which I've used many times) offers to append the line to the script if it isn't already there and needs it (and I usually recommend you heed its warning and let it do that).
WAV format has either a 2GB max or a 4GB max, depending upon which set of standards it is trying to conform to (much older vs. somewhat less old), and the corresponding libraries that assist in the export. Sounds like Magix uses older, stupider libraries. In that case, is there another lossless format (CAF? R64? FLAC?...) that it can export to that doesn't have the 2GB/4GB limitation (AIFF is 2GB)? (I would have looked myself, but Magix requires a customer login to access manuals - another bad move, IMO). As I've already mentioned, audio joins (either from intended segments or unintended) are RARELY flawless.
"Mix" and "Ready": yes you can use whatever variable name you'd like. You could also have not used variables for part of it and used the implicit "Last()" variable.
Can't comment on the "DXVA" as I haven't had need to use/try it.
SL DVD is 4.37GB, no less. You can nearly max out the space with the one file if you want, or not.
Rough estimate's roughness depends on how different places are, and how long of a segment you trial encode. You could do a 5min. segment if it assuages your worries. Yes, it takes a while. If you think you won't be fully satisfied unless you do 2passVBR, then do a 2passVBR. For, say, <4GB, you'd want to make AVG=2.96Mbps, Max=?. (Not usually necessary to do more than 2x or 3x the avg. for the max)
Your >4GB file problem was exactly because of the inclusion of the ISO9660 FS. All OSes from Win2000 onward (and MacOS ~10.3 onward) have full support for UDF of one form or another, so the only need for inclusion of ISO9660 anymore would be a VERY old OS or a VERY dumb device, and modern dumb devices usually don't even have that trouble. Remember, you aren't making a "DVD-Video" spec disc, just a data disc, so your constraints are relaxed.
Scott
<edit>Wait a minute...3 hours = 10800 sec. A standard WAV would be 16bit/48kHz/stereo LPCM. That = 192000Bytes/second. Times 10800 = 1.93GB. That's still less than 2GB. You must be doing something different/wrong for it to go over 2GB!Last edited by Cornucopia; 12th Jun 2015 at 01:42.
-
Sorry for the delay, I had to take a break from this...
Regarding color spaces, I added a small edit on the last comment of page 1 :If it isn't YV12, depends on the app that's being frameserved. Some might compensate for it, some won't. MeGUI (which I've used many times) offers to append the line to the script if it isn't already there and needs it (and I usually recommend you heed its warning and let it do that).
At first I tested an export of a small sample in uncompressed RGB, and I definitely noticed a shift in colors, then tested in HuffYUV and compared to the original source files, there was no shift at all. So that's the explanation, the uncompressed RGB was in the wrong color mode ? (Plus it appeared vertically flipped in Avidemux.)
I really didn't know about this size limit... No, Magix only proposes WAV and MP3 for audio only export (another reason to try another NLE software ? does Vegas have more comprehensive export options ?). Would it work if I simply joined those chunks with CMD's "copy" command ? Well, I tried : it gives me a 13KB file... oh, wait, with the /B switch [= "binary"] it works, exact same size as the sum of the chunks, but the duration is that of the first chunk only, it's not readable beyond, and MediaInfo says in contains 2 audio streams. Maybe with Audacity ?WAV format has either a 2GB max or a 4GB max, depending upon which set of standards it is trying to conform to (much older vs. somewhat less old), and the corresponding libraries that assist in the export. Sounds like Magix uses older, stupider libraries. In that case, is there another lossless format (CAF? R64? FLAC?...) that it can export to that doesn't have the 2GB/4GB limitation (AIFF is 2GB)? (I would have looked myself, but Magix requires a customer login to access manuals - another bad move, IMO). As I've already mentioned, audio joins (either from intended segments or unintended) are RARELY flawless.
The whole movie is 3h03min00s (10980 sec). And the total size of those two chunks is still less than 2GB, or more accurately 2GiB (1.96GiB, 2058751KB : 1024², or 2108160088 bytes : 1024³) ; the first chunk is only 1.85GB (but 1989527084 bytes, so the limit you talk about might be 2000000000 bytes). And 192000 x 10980 is 2108160000, just 88 bytes less. Those units are so confusing...Wait a minute...3 hours = 10800 sec. A standard WAV would be 16bit/48kHz/stereo LPCM. That = 192000Bytes/second. Times 10800 = 1.93GB. That's still less than 2GB. You must be doing something different/wrong for it to go over 2GB!
It could have been another confusion with those damn multiple-of-1024 units, but indeed you're right, theoretically it's 4700000000 : 1024³ = 4.377GB (or GiB as it should be noted). I've had less than that though, depending on the -R / +R format, I'm pretty sure ImgBurn showed a recordable space of 4.34GB (GiB) for Verbatim DVD+R (but it's been quite some time I haven't burned DVDs on a regular basis).SL DVD is 4.37GB, no less. You can nearly max out the space with the one file if you want, or not.
On the other hand, it's not recommanded to max out the space and burn every last byte available, especially for the long term, I read it and learned it the hard way : when a DVD (or CD) starts to have unreadable sectors due to ageing or exposure to light/moisture, it almost always starts from the edge of the disc, which is burned last, so it's safer to keep a safety margin of at least 100MB (some advise never to go beyond 4GB). I've lost files that way, and never trust DVD-R anymore as long term storage medium. (Choosing a good brand barely helps in my experience : I've had Verbatim discs highly damaged when others of supposedly less reliable brands and bought around the same time were still perfectly readable.)
Which ones did you use with the most success on that sort of devices ? Anyway, the test files made with "DVXA" worked on the LG Blu Ray player. I made one with profile "Main 3.1" and CRF 22 and one with profile "Main 4.1" and CRF 20, my brother told me that both played fine on the BR player, but the first one played better (more fluid) on his computer (a 2004 laptop, I already knew it could struggle with 1280x720 H264 videos, apparently some more than others depending on the bitrate I suppose). What are the differences between profiles 3.1 and 4.1 ?Can't comment on the "DXVA" as I haven't had need to use/try it.
As I say in the test below there is for example a short segment showing heavy rain and water running down a street with kinda jerky camera pans (which is obviously tough to compress), also a very noisy sequence shot at night with the gamma boosted almost to the max, another longer one filmed in exterior with a very mobile camera (but resized from 640x480), some brief excerpts from movies or TV shows... But about 2/3 or 3/4 of it is quite quiet.Rough estimate's roughness depends on how different places are, and how long of a segment you trial encode. You could do a 5min. segment if it assuages your worries. Yes, it takes a while. If you think you won't be fully satisfied unless you do 2passVBR, then do a 2passVBR. For, say, <4GB, you'd want to make AVG=2.96Mbps, Max=?. (Not usually necessary to do more than 2x or 3x the avg. for the max)
Also, is CRF based encode considered just as efficient in the way it distributes the bytes according to the complexity of each scene ? (I read somewhere that it could be a concern with older codecs, with which 2-pass was always preferable, but not with H264, that for a given file encoded in both mode at the same average bitrate the distribution and thus the overall quality would be so close as to be indistinguishable.) And how long is generally the first pass in H264 compared to the second ? (I read somewhere about half, unless the “slow first pass” option is selected in which case it's roughly the same duration.)
____________________________________
Test with MeGUI "One clic encode", 13s sample, x264 CRF=20 preset "Slower", Nero AAC default settings (QAAC requires a DLL I haven't yet installed – actually it seems like I have to install Apple QuickTime to use it, in which case I'm wondering like someone in this thread “Is the quality-level worth the bloat?”).
Script :
AVISource("1.AVI") ++ AVISource("2.AVI") ++ AVISource("3.AVI")
ConvertToYV12()
[denoising filter]
Trim(99700, 100000)
There was a problem with the script you provided, the "Trim" command placed at the end wouldn't be applied (maybe because of the "Return" ?) ; I kept only what I thought was necessary and it worked. As I still haven't solved the issue regarding the WAV export in two chunks, I also removed the "WAVSource / Audiodub" part and selected the sample around the first join, so as to also test if there would be any audio glitch – I didn't hear anything abnormal. I made the same test around the second join, it seems also flawless. What do these glitches sound like, when there are any ? If those test samples are glitch-free, can I be confident it'll be the same for the whole encode ? (At worst if there's a problem I could reencode the audio only and remux it with the video stream, if it means not having to start all over again...)
Result :
- MCTemporalDenoise(low) : 1.2FPS max (+ quite long "Preprocessing" step), 7874KB, 5165kbps
- SMDegrain() : 2.7FPS max, 5979KB, 3876kbps
(I wasn't sure of the exact command “poisondeathray” meant by “SMDegrain with a setting of 1” so I used default.)
- no denoiser : 2.9FPS max, 8716KB, 5738kbps
So in this case and with those settings, SMDegrain seems to produce a better result than MCTemporalDenoise at a much less reduced encoding speed. Visually the fluctuations in noisy areas are indeed more stabilized with SMDegrain, while details seem well preserved. But the overall level of details seems better preserved with MCTemporalDenoise – actually on screenshots I took of the exact same frame it appears more detailed than the non-denoised encode, and even the original HuffYUV ! (Maybe it does apply a sharpening filter after denoising ?) The first few seconds of this sample show heavy rain, with no apparent noise, it goes up to 10000kbps according to Bitrate Viewer, the rest is more like the previous sample, steady camera, a few persons talking, and some visible noise in dark areas ; if I look at this part only, the average bitrates are about : 5000kbps without denoiser, 4000kbps with MCTemporalDenoiser, 2700kbps with SMDegrain, which shows an even more impressive compressibility improvement (almost by half). Is there a particular setting I could try to improve a bit over this, in terms of speed or quality (preferably speed as the denoising is already very good, and removing more noise would result in a loss of details I'm assuming), or to globally improve the ratio of speed vs. noise removal vs. detail preservation, if I can have a cake and eat it too ? There are some examples on the dedicated page, but I don't know which one(s) would work best in my case.
On this page someone says that “in general combining a 'light' denoiser and a grain handler like removegrain(2) or x264s own -nr normally is a good way for denoising without too much detail loss”. Any thought ?
Here I read that as a general rule, temporal denoising is “safer” (less blurring, doesn't affect non-noisy areas) and should be applied in priority, while spacial denoising should be done lightly (causes blurring / loss of detail, affects the whole frame). It also says (second comment) that denoising filters “tend to speed up the encode a bit”, which I found to be not true (but the guy tested with the “very slow” x264 preset, which may be a bottleneck of its own).
- How do I tell Avisynth to apply the denoiser (or any filter for that matter) only to selections of frame intervals ?
- Are the processing speeds within the expected range ? It's damn slow... If I calculate correctly it's going to take about 274500 / 2.5 ~ 109800s ~ 30.5 hours with these settings (or since it's 25fps, 1/10th real time). It's significantly faster with the "Slow" preset (about 4.4FPS with SMDegrain).
- Apparently MeGUI does indeed first encode the audio stream, then the video stream, then mux audio and video as MP4 or MKV. Is it the best/safest way to do it ? Intuitively it feels “cleaner” to me when an encoding application (like Avidemux, Handbrake, FFMPEG...) does it all in one operation (plus it probably takes less time), less susceptible to synchronization issues for instance, but I may be mistaken on this.Last edited by abolibibelot; 14th Jun 2015 at 17:06.
-
Tough to say without more information and testing. If whatever process you are using results in the correct results now, just stick with itOriginally Posted by abolibibelot
The vertical flip bug in avidemux suggests it's RGB. Some decoders have problems with RGB input
A workaround that works for many programs is uncompressed audio in AVI (2.0) container to get around the WAV filesize limitation. Even the program doesn't allow "audio only" AVI, you can use a blank video and discard the blank video laterIn that case, is there another lossless format (CAF? R64? FLAC?...) that it can export to that doesn't have the 2GB/4GB limitation
Yes, any audio editor should be able to append WAV segments with the proper header... Maybe with Audacity ?
The difference is upper limits on resolutions, framerates, reference frames and bitrates. But the profile and level in x264 aren't actually enforced. If you violate them it will only give you a warning
Anyway, the test files made with "DVXA" worked on the LG Blu Ray player. I made one with profile "Main 3.1" and CRF 22 and one with profile "Main 4.1" and CRF 20, my brother told me that both played fine on the BR player, but the first one played better (more fluid) on his computer (a 2004 laptop, I already knew it could struggle with 1280x720 H264 videos, apparently some more than others depending on the bitrate I suppose). What are the differences between profiles 3.1 and 4.1 ?
https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
Likely your brother's laptop played one smoother because the CRF was higher (lower bitrate)
It's almost identical to 2pass if the bitrate is the same. That's the problem - there is no way to know exactly what the final bitrate is. If you need a specific filesize(bitrate) you use 2 pass. If you don't care, use CRFAlso, is CRF based encode considered just as efficient in the way it distributes the bytes according to the complexity of each scene ? (I read somewhere that it could be a concern with older codecs, with which 2-pass was always preferable, but not with H264.)
Yes, just remove the ReturnThere was a problem with the script you provided, the "Trim" command placed at the end wouldn't be applied (maybe because of the "Return" ?)
Glitches in that scenario usually sound like clicks - it's obvious you should be able to tell, and their location is right at the seamsWhat do these glitches sound like, when there are any ? If those test samples are glitch-free, can I be confident it'll be the same for the whole encode ? (At worst if there's a problem I could reencode the audio only and remux it with the video stream, if it means not having to start all over again...)
Yes MCTD contra sharpens. You can module the strength, the default is strength=100 .(Maybe it does apply a sharpening filter after denoising ?)
Some versions of SMDegrain have contra sharpen enabled too IIRC - you should check the debug mode
The "1" I was referring to was the temporal radius (tr=1). The default is 3. A lower value will reduce the NR strength, but also should be faster to process. You can also modulate the strength with thSAD. The defaults are 400, at least for some of the versions I think (higher is stronger)
]I can have a cake and eat it too ?
Nope . SMDegrain is a good general purpose NR filter, decent speed. x264's internal -nr is terrible IMO. It is fast, but not very good.
This gets asked frequently and is discussed exhaustively in other threads. Short summary: The simplest is Trim() to divide up into segments and append them with aligned splice as you've been doing (++) . Other methods include ApplyRange, or RemapFrames variations- How do I tell Avisynth to apply the denoiser (or any filter for that matter) only to selections of frame intervals ?
- Are the processing speeds within the expected range ? It's damn slow... If I calculate correctly it's going to take about 274500 / 2.5 ~ 109800s ~ 30.5 hours with these settings. It's significantly faster with the "Slow" preset (about 4.4FPS with SMDegrain).
- Apparently MeGUI does indeed first encode the audio stream, then the video stream, then mux audio and video as MP4 or MKV. Is it the best/safest way to do it ? Intuitively it feels “cleaner” to me when an encoding application (like Avidemux, Handbrake, FFMPEG...) does it all in one operation (plus it probably takes less time), less susceptible to synchronization issues for instance, but I may be mistaken on this.
It seems about right for an older dual core. Don't worry about separate audio & video processing. That is the way it has been done for many years. But nothing is stopping you from using one of the other methods. (Except avidemux and the free versions of ffmpeg don't have a high quality AAC encoder, only garbage ones. And it's difficult to use avisynth with handbrake) -
I'm wondering if I'll ever see the end of this...
# Export in AVI (I don't see “2.0” anywhere) with track 1 disabled (enough to get a ~90% blank video -- I have some audio in all other tracks and didn't want to bother removing video elements one by one, don't know a better way to do that) still produces two chunks (the second one with "_001" added to the name), just like WAV only export, with the exact same durations (and in the meantime I completely changed the audio at the cut point, after some cleaning in Audacity it's now a continuous WAV object with no tricky effect applied within Magix V.D., so it can't be an editing-related issue ; I should try in 44100Hz to see if the cut point is at a later time or if there is none in case it brings the file size below the threshold).
Strangely, the "Audio mix" function (in Magix's Edit menu, meant to assemble all the audio elements into one single audio track) produces a single 1.96GB WAV file with the correct full length, but it also “optimizes” the volume as explained in the relevant chapter of the integrated Help (and there's no option to disable this, while the volume limiter apparently isn't working with this function), which results in a crazy amount of vertical red lines (= saturations) when opened in Audacity (lucky I checked). And they still say this function does not reduce the audio quality even when used several times, go figure.
Well, the best I can do is extract the audio from the three AVI segments and append them with Audacity (probably cleaner than with those two chunks which break at a random point).
# Color spaces -- I still have a hard time wrapping my mind around this. As I went into yet another cycle of last minute corrections, and have to re-export at least one of the three parts of my project, I figured I should try the other supposedly better lossless codecs recommanded above. First, there seems to be a tremendous advantage in terms of compression efficiency, to the point that it's hard to believe it's still lossless (among audio lossless codecs, for instance APE is more efficient than FLAC by maybe ~5% ; here MagicYUV reduced the file size on a test sample by almost 50% with no color space conversion (test sample 86 frames, HuffYUV RGB : 135613KB, MagicYUV “Compress as is” [i.e. RGB too I guess] : 74299KB, HuffYUV with “Convert RGB to YUY2” checked : 64925KB, MagicYUV mode YUV 4:2:0 : 44469KB, UT Video YUV420 BT.709 : 49891KB).
Then, I notice a definite color shift in YUV (when viewed in VLC Media Player, and on VLC's screenshots), affecting mainly the reds, greens and skin tones, just like you wrote earlier, and the picture looks generally slightly duller. Is it normal and expected or did I do it wrong ? From what I read here, NLE softwares automatically convert video sources to RGB internally, so is that the necessary cost of the double conversion that takes place here ?
BUT I just tried exporting with MagicYUV and “Rec.601” color matrix (instead of “Rec.709” initially), and now the colors seem accurate. So, should I use this setting instead, even though (most of) the source files are “HD” ? By the way, what happens when different sources with different color spaces / color matrix(es) are mixed ? And will I get the exact same result if I 1) export as RGB then convert to YUV with Avisynth then encode with x264 or 2) export as YUV (likely in Rec.601 / BT.601 mode) and encode with no further color space conversion ?
Screenshots :
http://share.pho.to/9V6Vp
# In case someone needs this, I managed to make QAAC work in MeGUI without installing QuickTime or other Apple bloatware by copying the DLLs provided here :
http://audiophilesoft.ru/load/coders_utils/qaac/7-1-0-50
The average bitrate with the default settings (quality : 91) is higher than I expected (184kbps on a test sample, which seems huge for AAC, especially considering the type of audio content).
# So, in case the export to MagicYUV in Rec.601 mode (or UT Video in BT.601 mode) is the right thing to do at this point, and assuming I manage to get a correct full-length WAV file by stitching three extracted audio streams from those new AVIs, then is the following script correct ? Is there an easier or more “elegant” way to do the same ? I used this thread as reference. As I indicated in comments (not sure of the syntax), I'd like to apply a light and fast denoising filter to most of the frames, a medium-strong denoise filter to a few sequences, and no filter to the rest.
For Vid09, I wanted to use the template on the Avisynth Wiki dedicated page designed for “Tackling a grainy source”, but it's written on two lines, I don't know how to add the first one to my script as it is :Code:Vid = AVISource("20140821 - 1c.AVI") ++ AVISource("20140821 - 2b.AVI") ++ AVISource("20140821 - 3b.AVI") Aud = WAVSource("20140821.wav") Vid00 = Trim(Vid,0,3539) # no filter Vid01 = Trim(Vid,3540,30305).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid02 = Trim(Vid,30306,32969) # no filter Vid03 = Trim(Vid,32970,48295).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid04 = Trim(Vid,48296,49599) # no filter Vid05 = Trim(Vid,49600,52420).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid06 = Trim(Vid,52421,54429) # no filter Vid07 = Trim(Vid,54430,75840).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid08 = Trim(Vid,75841,76889) # no filter Vid09 = Trim(Vid,76890,79255).SMDegrain(tr=6,thSAD=500,contrasharp=30,prefilter=pre,str=1.2,refinemotion=true,lsb=true) # strong denoise Vid10 = Trim(Vid,79256,79460).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid11 = Trim(Vid,79461,81149) # no filter Vid12 = Trim(Vid,81150,83295).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid13 = Trim(Vid,83296,85199) # no filter Vid14 = Trim(Vid,85200,97785).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid15 = Trim(Vid,97786,99754) # no filter Vid16 = Trim(Vid,99755,105195).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid17 = Trim(Vid,105196,105209) # no filter Vid18 = Trim(Vid,105210,110670).SMDegrain(tr=2,thSAD=300,contrasharp=true,refinemotion=true,lsb=true) # medium denoise Vid19 = Trim(Vid,110671,110684) # no filter Vid20 = Trim(Vid,110685,114420).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid21 = Trim(Vid,114421,118509) # no filter Vid22 = Trim(Vid,118510,126430).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid23 = Trim(Vid,126431,138784) # no filter Vid24 = Trim(Vid,138785,145980).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid25 = Trim(Vid,145981,147504) # no filter Vid26 = Trim(Vid,147505,152805).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid27 = Trim(Vid,152806,153899) # no filter Vid28 = Trim(Vid,153900,183775).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid29 = Trim(Vid,183776,185114) # no filter Vid30 = Trim(Vid,185115,231854).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid31 = Trim(Vid,231855,231897) # no filter Vid32 = Trim(Vid,231898,232004).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid33 = Trim(Vid,232005,232182) # no filter Vid34 = Trim(Vid,232183,249460).SMDegrain(tr=1, thSAD=300, contrasharp=true) # light denoise Vid35 = Trim(Vid,249461,0) # no filter to the end (274500 frames total) VidDenoised = Vid00 ++ Vid01 ++ Vid02 ++ Vid03 ++ Vid04 ++ Vid05 ++ Vid06 ++ Vid07 ++ Vid08 ++ Vid09 ++ Vid10 ++ Vid11 ++ Vid12 ++ Vid13 ++ Vid14 ++ Vid15 ++ Vid16 ++ Vid17 ++ Vid18 ++ Vid19 ++ Vid20 ++ Vid21 ++ Vid22 ++ Vid23 ++ Vid24 ++ Vid25 ++ Vid26 ++ Vid27 ++ Vid28 ++ Vid29 ++ Vid30 ++ Vid31 ++ Vid32 ++ Vid33 ++ Vid34 ++ Vid35 Mix = AudioDub(VidDenoised, Aud) Return(Mix)
This is a sequence shot at night, with strong grainy noise, I tested an encode with CRF=20 (with no denoising filter) : the average bitrate is 10401kbps, with a max at 13333kbps. Ouch ! (This was filmed in March 2012, when the killer responsible for multiple shootings in south France was under siege, in the building right next to where I was, hence the street swarming with blue caps and big zooms.)Code:pre=fluxsmootht(3).removegrain(11) SMDegrain(tr=6,thSAD=500,contrasharp=30,prefilter=pre,str=1.2,refinemotion=true,lsb=true)
http://we.tl/n2yZPeAqwF (119MB, 1min34)
Vid18 was filmed in interior in low light in 640x480 MJPEG. Noise level higher than the other interior sequences, but as it's lower quality to begin with and has some “moire” effect (most notably on a CRT TV which occupies the whole frame at some points) which may produce an ugly result after heavy-handed noise filtering, I think I need to be especially careful with the settings.
See above.Originally Posted by poisondeathray
See above. How do I use the debug mode ?Yes MCTD contra sharpens. You can module the strength, the default is strength=100 .
Some versions of SMDegrain have contra sharpen enabled too IIRC - you should check the debug mode
The "1" I was referring to was the temporal radius (tr=1). The default is 3. A lower value will reduce the NR strength, but also should be faster to process. You can also modulate the strength with thSAD. The defaults are 400, at least for some of the versions I think (higher is stronger)
See above.This gets asked frequently and is discussed exhaustively in other threads. Short summary: The simplest is Trim() to divide up into segments and append them with aligned splice as you've been doing (++) . Other methods include ApplyRange, or RemapFrames variations
Is the hard drive or the CPU the bottleneck in this case ? MPEG2 files which often have a much higher bitrate play fine on that computer. I know H264 is more demanding in processing power than MPEG2, but how is it influenced by the bitrate ?Likely your brother's laptop played one smoother because the CRF was higher (lower bitrate)
Thanks again,
GabrielLast edited by abolibibelot; 19th Jun 2015 at 17:58. Reason: Added link to screenshots
-
It's not necessarily true that NLE's work in RGB - some editors work in YUV, at least for some types of inputs . But what you see in the preview display has been converted to RGB, even though the timeline might be working in YUV. How your software treats the files when importing, when handing off to the export codec, what the codec does are all points where something can go wrong . So when you have mixed inputs, mixed colorspaces, it depends on how the software handles it. For exapmle, some will use the proper 709 for conversion of HD and 601 for SD on a pure RGB timeline. Some will use the wrong coversion, which you should correct later. Other editors have mixed timelines concurrently - Sections can be in YUV while others can be RGB at the same time, until export.
Converting between YUV <=> RGB is a lossy conversion. You don't want to do it unless you have to . I can't answer your questions specifically because I don't use that editor . If it is using RGB internally , you would want to stay in RGB as long as possible until the end. Then you can control which way to convert it, with what matrix with the least number of coversions. Rec601 and 709 are equations that govern YUV <=> RGB. If you use the same matrix to convert one way and then back, the colors should look the same, or very similar . If you export an RGB intermediate, and it looks ok, then ConvertToYV12(matrix="rec709") should be the appropriate one to use for HD content . If you export a YUV intermediate, then it depends on many things including how you are viewing it and if you are viewing it properly. You can change it with color matrix() in YUV to as if it had used 709 or 601 when converting RGB to YUV as if it was done like that in the first place. If it doesn't make sense to you, don't worry about it, just look at the final result - if magic yuv works for you in this workflow then use it.
The debug mode for smdegrain is debug=true, it will show an overlay with the settings
Yes, h264 is a heavier load on CPU fo decoding. Bitrate plays a factor (higher bitrates require more CPU), but its less important than resolution, or certain settings like inloop deblocking, cabac -
Wow, that's tricky to say the least... One thing I know for sure though is that when I export from this software "as is", i.e. with no color space conversion (using HuffYUV or MagicYUV), I get RGB. Another thing I know now is that if I choose "Rec709" (as an export option or an Avisynth command, same result), I get wrong colors, whereas "Rec601" gives the appropriate colors (see the screenshots -- I added a picture straight from camera used for the montage below the video grabs taken where that picture appears, it shows a red car and the red is definitely different with "Rec709"). I guess I should trust my eyes rather than what should be appropriate (as you say, there are many ways it can go wrong).It's not necessarily true that NLE's work in RGB - some editors work in YUV, at least for some types of inputs . But what you see in the preview display has been converted to RGB, even though the timeline might be working in YUV. How your software treats the files when importing, when handing off to the export codec, what the codec does are all points where something can go wrong . So when you have mixed inputs, mixed colorspaces, it depends on how the software handles it. For exapmle, some will use the proper 709 for conversion of HD and 601 for SD on a pure RGB timeline. Some will use the wrong coversion, which you should correct later. Other editors have mixed timelines concurrently - Sections can be in YUV while others can be RGB at the same time, until export.
By the way, how is "HD content" defined in this context ? Is it automatically assumed from the resolution of the project ?
I don't get why you say that "if it looks OK in RGB, then "Rec709" is the correct option" : apparently this is not always the case. To avoid any mistake I re-exported the videos as MagicYUV in RGB ("Compress as is"), then made some test scripts with either "ConvertToYV12(matrix="rec709")" or "ConvertToYV12(matrix="rec601")", and again I'm pretty sure the correct colors are obtained with "rec601". (It's also correct if I don't add the "matrix" option.)Converting between YUV <=> RGB is a lossy conversion. You don't want to do it unless you have to . I can't answer your questions specifically because I don't use that editor . If it is using RGB internally , you would want to stay in RGB as long as possible until the end. Then you can control which way to convert it, with what matrix with the least number of coversions. Rec601 and 709 are equations that govern YUV <=> RGB. If you use the same matrix to convert one way and then back, the colors should look the same, or very similar . If you export an RGB intermediate, and it looks ok, then ConvertToYV12(matrix="rec709") should be the appropriate one to use for HD content . If you export a YUV intermediate, then it depends on many things including how you are viewing it and if you are viewing it properly. You can change it with color matrix() in YUV to as if it had used 709 or 601 when converting RGB to YUV as if it was done like that in the first place. If it doesn't make sense to you, don't worry about it, just look at the final result - if magic yuv works for you in this workflow then use it.
The "debug=true" option doesn't seem to work, I get "Error parsing avs file Script error: SMDegrain does not have a named argument "debug"".
And I struggled to make SMDegrain work with some advanced options. First I got "there is no function named 'Dither_lut8", which was solved by adding the Dither plugin. Then "lsb=true" got me "Avisynth open failure: Script error: MDegrain3 does not have a named argument "lsb" (SMDegrain v.3.0d.avsi, line 464)", and I couldn't find anything related to that issue. I updated some associated plugins (mvtools2, masktools, RgTools) and it seemed to have solved that particular issue, but then I got "Avisynth open failure: Script error: there is no function named "Quantile" (SMDegrain v.3.0d.avsi, line 532) (SMDegrain v.3.0d.avsi, line 498) (SMDegrain v.3.0d.avsi, line 464)", and again, I found nothing relevant on the dedicated page or other formal documentation, until I stumbled upon an obscure thread where it was implied that RemoveGrainHD is required for the "quantile" function, so I searched for RemoveGrainHD and found it on another obscure thread, and, well, it seems to work now -- but is this how it is supposed to be with Avisynth ? It's an awesome set of tools, but the accessibility to the layperson is far from optimal, to say the least.
So I made some more testing with that problematic dark and noisy sequence, and the results seem reversed compared to the previous tests with relatively well lit and slightly noisy samples :
frames 78500-79000 x264 CRF=23
MCTemporalDenoise "high" 0.40FPS (1245s) 9496KB 3685kbps (4583 max)
MCTemporalDenoise "medium" 1.00FPS (496s) 14768KB 5840kbps (6783 max)
SMDegrain tr=4,thSAD=400,contrasharp=true,str=2.0,refinemoti on=true,lsb=true 0.98FPS (510s) 17608KB 7001kbps (7978 max)
no filter (control) 2.43FPS (205s) 19785KB 7891kbps (8981 max)
MCTemporalDenoise "high" is very slow but reduces the size/bitrate by ~50%, yet it loses too much detail for it to be worth it. MCTemporalDenoise "medium" is reasonably slow and seems to be the best compromise between speed / file size / quality. SMDegrain is about as slow as MCTD "medium" but the bitrate reduction is hardly significant, while the level of detail is about the same (and to my eyes very close the control encode with no filter). There are still some "dancing" patches of pixels (even with MCTD "high"), but I guess it would be difficult to get a significantly better result with that kind of source (and then again it's just 1min30 of this whole 3h30min movie, it won't impact the final size immensely).
https://www.mediafire.com/?41rj985g8ad2ll0
https://www.mediafire.com/?5d6bto2a4547uy7
https://www.mediafire.com/?7cb4g2246mnph2l
https://www.mediafire.com/?4y8jyepp59umg8n
If anybody with trained eyes and experience in video denoising and Avisynth filtering could look at those files and advise me one way or another... Otherwise I'll try and run the full encode tonight with this script :
Code:Vid = AVISource("20140821-1C (MagicYUV RGB).AVI") ++ AVISource("20140821-2C (MagicYUV RGB).AVI") ++ AVISource("20140821-3B (MagicYUV RGB).AVI") Aud = WAVSource("20140821 collage Audacity 1+2+3.wav") Vid00 = Trim(Vid,0,3539) Vid01 = Trim(Vid,3540,30305).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid02 = Trim(Vid,30306,32969) Vid03 = Trim(Vid,32970,48295).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid04 = Trim(Vid,48296,49599) Vid05 = Trim(Vid,49600,52420).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid06 = Trim(Vid,52421,54429) Vid07 = Trim(Vid,54430,75840).SMDegrain(tr=1,thSAD=300, contrasharp=true) # light denoise Vid08 = Trim(Vid,75841,76889) Vid09 = Trim(Vid,76890,79255).MCTemporalDenoise(settings="medium") # strong denoise Vid10 = Trim(Vid,79256,79460).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid11 = Trim(Vid,79461,81149) Vid12 = Trim(Vid,81150,83295).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid13 = Trim(Vid,83296,85199) Vid14 = Trim(Vid,85200,97785).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid15 = Trim(Vid,97786,99754) Vid16 = Trim(Vid,99755,105195).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid17 = Trim(Vid,105196,105209) Vid18 = Trim(Vid,105210,110670).SMDegrain(tr=2,thSAD=300,contrasharp=true,refinemotion=true,lsb=true) # medium denoise Vid19 = Trim(Vid,110671,110684) Vid20 = Trim(Vid,110685,114420).SMDegrain(tr=1,hSAD=300,contrasharp=true) # light denoise Vid21 = Trim(Vid,114421,118509) Vid22 = Trim(Vid,118510,126430).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid23 = Trim(Vid,126431,138784) Vid24 = Trim(Vid,138785,145980).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid25 = Trim(Vid,145981,147504) Vid26 = Trim(Vid,147505,152805).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid27 = Trim(Vid,152806,153899) Vid28 = Trim(Vid,153900,183775).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid29 = Trim(Vid,183776,185114) Vid30 = Trim(Vid,185115,231854).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid31 = Trim(Vid,231855,231897) Vid32 = Trim(Vid,231898,232004).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid33 = Trim(Vid,232005,232182) Vid34 = Trim(Vid,232183,249460).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid35 = Trim(Vid,249461,0) VidDenoised = Vid00 ++ Vid01 ++ Vid02 ++ Vid03 ++ Vid04 ++ Vid05 ++ Vid06 ++ Vid07 ++ Vid08 ++ Vid09 ++ Vid10 ++ Vid11 ++ Vid12 ++ Vid13 ++ Vid14 ++ Vid15 ++ Vid16 ++ Vid17 ++ Vid18 ++ Vid19 ++ Vid20 ++ Vid21 ++ Vid22 ++ Vid23 ++ Vid24 ++ Vid25 ++ Vid26 ++ Vid27 ++ Vid28 ++ Vid29 ++ Vid30 ++ Vid31 ++ Vid32 ++ Vid33 ++ Vid34 ++ Vid35 Mix = AudioDub(VidDenoised,Aud) Final = ConvertToYV12(Mix) Return(Final) -
It's a bit more complicated than that - you have be sure that your preview or software for viewing is using correct matrix as well (your method of screenshot taking, by controlling the conversion to RGB for the preview ) . Theoretically, if your exported format is RGB and it looks correct, then you can use ConvertToYV12(matrix="rec709") (and preview with ConvertToRGB(matrix="rec709") , but don't encode with it, just use it temporarily to preview) . If your screenshot/viewing method uses 601 (for example vdub does this) , then you will see the wrong colors (and the preview will be wrong) - compared to when you see it on BD . When you view something, it's the RGB representation of it . So if the video is in YUV (for example the final video will be), you're not viewing it as is - you're viewing it as RGB. How that gets converted for display affects how the colors "look" . By default , HD uses Rec709 . It might be that your editor screwed up somewhere and you have to fix it along the way
Apologies, its show=true for the debugmode, it was just off the top of my head . Just look at the .avs or .avsi script for the parameters, they are listed. You probably don't want to use the stacked16 format, it will be much slower than it already is with very little benefit -
Sorry, I've been procrastinating again... And I had yet another unexpected issue : some cross-fade transitions appear differently on the exported files compared to the preview window, on a random basis ; I made some tests on two problematic sequences, sometimes it works as intended, sometimes there's a sudden dark frame where there should be a smooth transition, it's driving me crazy. I don't know if it's a memory-related issue or a bug, so far, since I noticed it, I couln't export the first part with no glitch. I noticed that FFDShow Video Decoder gets activated during the export or sometimes when previewing, I wonder if it could be related.It's a bit more complicated than that - you have be sure that your preview or software for viewing is using correct matrix as well (your method of screenshot taking, by controlling the conversion to RGB for the preview ) . Theoretically, if your exported format is RGB and it looks correct, then you can use ConvertToYV12(matrix="rec709") (and preview with ConvertToRGB(matrix="rec709") , but don't encode with it, just use it temporarily to preview) . If your screenshot/viewing method uses 601 (for example vdub does this) , then you will see the wrong colors (and the preview will be wrong) - compared to when you see it on BD . When you view something, it's the RGB representation of it . So if the video is in YUV (for example the final video will be), you're not viewing it as is - you're viewing it as RGB. How that gets converted for display affects how the colors "look" . By default , HD uses Rec709 . It might be that your editor screwed up somewhere and you have to fix it along the way
Apologies, its show=true for the debugmode, it was just off the top of my head . Just look at the .avs or .avsi script for the parameters, they are listed. You probably don't want to use the stacked16 format, it will be much slower than it already is with very little benefit
So you're saying that even a PNG screenshot made with VLC Media Player isn't a reliable indication of what the colors will look like on a standalone device ? (I already noticed that a VLC screenshot from an uncompressed RGB video gave "psychedelic" colors, like blue-purple tones.) And neither is VirtualDub ? What software can I use to accurately visualize videos when doing that sort of conversions ? (As I don't have a MP4-compatible standalone player myself.) Or is the line "ConvertToRGB(matrix="rec709")" enough to bypass the usual method of viewing in VirtualDub or MPC ? (Again, VLC doesn't seem able to recognize AVS scripts.) If I have an AVI file in RGB, should I use *both* lines, i.e. "ConvertToYV12(matrix="rec709")" then "ConvertToRGB(matrix="rec709")" ? (It seems absurd to convert RGB to RGB.) I just did just that and :
ConvertToYV12(matrix="rec709")
alone gives the wrong colors (the red car is dark red), while
ConvertToYV12(matrix="rec709")
ConvertToRGB(matrix="rec709")
gives the correct colors (in MPC or VirtualDubMod). Is that enough to ensure that I must definitely use "(matrix="rec709")" ?
(By the way, since I fiddled with Avisynth plugins to make SMDegrain work, I get this message when I open VirtualDubMod, which worked flawlessly before :
"Cette application n'a pas pu démarrer car MSVCP110.dll est introuvable. La réinstallation de cette application peut corriger ce problème."
It's french for "You're halfway screwed". But it still works after two such messages, go figure.)
What is "stacked16" ? Well, let's see :
I have virtually no idea what it means -- but I guess it has to do with the "lsb=true" option which appears on one segment of my Avisynth script. Well, I'm really new to this, and just copied one of the example settings from the dedicated page, barely understanding the technical explanations given for each command. This is the sequence already mentioned which is 3min40s long and composed of 640x480 MJPEG footage (resized to 960x720), with some "moiré" effect which (I think) may affect the quality of the denoising process, so I figured that an option promising extra accuracy wouldn't hurt. I haven't (yet) made any test for that sequence. (A little bit tired of it all, with all those unexpected issues, and eager to finish...) Do you think it will slow down the whole encode significantly (and for little benefit in that particular case), even if only applied to that one 3min40s sequence ?http://avisynth.nl/index.php/Stack16
"Stack16 is a workaround format commonly used to process 16-bit content in AviSynth's native 8-bit environment.
As explained in the Dither documentation:
As Avisynth doesn't support natively high bit depth, a specific format named 'stack16' is introduced. The picture is made of two parts: one containing the highest 8 bits (MSB) for each pixel, stacked on top of another containing the lowest 8 bits (LSB). When previewing the video stored in stack16 format, the top part looks quite like the original picture and the bottom one generally looks like psychedelic garbage."
Since you didn't make any other comment I'm assuming the script is otherwise alright. Too bad nobody else is contributing anymore. I tried subscribing to Doom9, which seems more specialized when it comes to Avisynth issues, but so far no luck (there's a 5 days waiting period, I received the activation e-mail 2 days after subscribing, and the link doesn't work). Thank you for still helping me ! -
If this is out of your editor, and it's using directshow for decoding (ffdshow, red icon), then yes it can be related . Directshow can have a problme with frame accuracy, especially when you need to scrub back/forth temporally, or when temporal filters are applied (when frames are not handed off in linear fashion)Originally Posted by abolibibelot
Not necessarily, because older versions of VLC used Rec601, newer ones use Rec709 . Some media players do it by height (e.g. if >540px, then use 709 etc...) Others always use one or the other. Sometimes its the renderer used e.g. madvR reads flags in the video and adjust accordinglySo you're saying that even a PNG screenshot made with VLC Media Player isn't a reliable indication of what the colors will look like on a standalone device ?
If you start in RGB, then that doesn't make sense - if you go back and forth with the same matrix, anything 709, 601, xyz etc.... you will get the same thing as you started with generally in terms of colors (there will be some quality loss) . But yes, if you are certain that you start with RGB, and it looks correct, then you should be using ConvertToYV12(matrix="rec709") before encodingWhat software can I use to accurately visualize videos when doing that sort of conversions ? (As I don't have a MP4-compatible standalone player myself.) Or is the line "ConvertToRGB(matrix="rec709")" enough to bypass the usual method of viewing in VirtualDub or MPC ? (Again, VLC doesn't seem able to recognize AVS scripts.) If I have an AVI file in RGB, should I use *both* lines, i.e. "ConvertToYV12(matrix="rec709")" then "ConvertToRGB(matrix="rec709")" ? (It seems absurd to convert RGB to RGB.) I just did just that and :
ConvertToYV12(matrix="rec709")
alone gives the wrong colors (the red car is dark red), while
ConvertToYV12(matrix="rec709")
ConvertToRGB(matrix="rec709")
gives the correct colors (in MPC or VirtualDubMod). Is that enough to ensure that I must definitely use "(matrix="rec709")" ?
All the problems occur when you go back and forth between RGB<=>YUV and you don't know what matrix is being used either for the conversion or the previewing method. For example if you started with a YUV lossless export then that raises more questions (do you know how the editor imported the video ? Do you know how the editor converted when exporting? What matrix is your preview method using converting to RGB ?) . There are some GUI's that allow you to toggle the preview between 709/601 . Avspmod, I think staxrip has a utility now, or you can do it with avisynth.
Yes it will slow it down, but only in that section (it won't slow down other sections). Is it worth it? Only you can decide that. Personally I would say probably not from what I've seen of your source footage
What is "stacked16" ?...
Do you think it will slow down the whole encode significantly (and for little benefit in that particular case), even if only applied to that one 3min40s sequence ? -
Regarding that black frame issue, I checked more closely, and it's even weirder. For one of the two problematic sequences I identified, the source is a scene from a (cartoon) movie in Xvid format (cut using Avidemux). At the (two) points where a black frame appears it transitions from 100% opacity to about 50% and then back to 100%, but apparently that's not the cause of the issue, it happens at the same points without the crossfades. When I place the cursor on each frame around those points (within the NLE software) in the normal reading direction (left to right), the preview appears normal, but if I process backwards (from right to left), or access those particular frames without first accessing the one before, they appear black. When I test exporting that 30s sequence, the result seems random (sometimes flawless, sometimes glitchy), but when exporting the whole 1 hour part the glitch is there seemingly every time (I tried with MagicYUV and UT Video, but not HuffYUV and I deleted the first export made in that format ; I also tried setting MagicYUV in single thread, to no avail). If I open the source video file in VirtualDubMod, the frames are displayed normally when read one by one from left to right, but there's a sort of stutter if I process backwards (the displayed frame is the one normally two frames later, then it's back to normal, i.e. if I count from that problem-frame it goes : F+5, F+4, F+3, F+2, F+1, F+2, F-1, F-2... where the second F+2 should be F+0), at the same points where a black frame appears in Magix editor. I upgraded ffdshow, same result ; I deactivated ffdshow video decoder for Videodeluxe.exe, same result ; I deactivated one by one some import modules apparently related to AVI files within the Magix software (AVI import module, Internal AVI import, Internal DirectShow AVI import, Internal DirectShow import), same result. I read here that : “Xvid uses temporal compression, which is not suitable for editing. Using Xvid files as source clips will cause you a lot of grief.” But doesn't H.264 use temporal compression as well ? (I had no such problems with MP4 sources.) I converted the source file to MPEG4-AVC with Avidemux, and x264 CRF=18 (resulting file size roughly the same as the source, 888kbps / 464x352), but I could still notice a slight loss in quality (weird as it's usually considered a high quality setting), then I tried with CRF=0, and -- yet another unpleasant surprise -- the resulting file with a bitrate of 8051kbps (still for a 464x352 resolution) had a horrendous quality ! (Full of blocks and artifacts, as if compressed with a very low bitrate. Isn't CRF=0 supposed to be virtually lossless ? I really wonder how it could go so wrong. There must be some kind of demon trying to prevent me from finishing this job.) It seems to work well with an AVI lossless conversion (no more stutter in VD, no more black frame in MVD), but then the file size is 30x that of the original Xvid.If this is out of your editor, and it's using directshow for decoding (ffdshow, red icon), then yes it can be related . Directshow can have a problme with frame accuracy, especially when you need to scrub back/forth temporally, or when temporal filters are applied (when frames are not handed off in linear fashion)
Screenshots :
http://share.pho.to/9X1zc
(The movie in question is "He-Man and She-Ra : Secret of the sword" -- my brother is telling our grandma that if there had been a “dimensional portal” like in that cartoon in the real world, he would have come visit her once in a while...)
The other instance is a transition from a JPG picture with 100% opacity to the same picture with ~50% opacity (plus an overlayed PNG export from the same picture edited in GIMP to delete everything but one person -- so as to emphasize one particular member from a music band). It seems a bit less problematic (some of the whole 1-hour exports don't have that issue, but it's still unpredictable).
At this point I could always export in smaller parts until I get all of them right and then append those with Avisynth...
By the way I found this in ffdshow video decoder settings :
http://pho.to/9WzzC
The default setting seems to be “ITU-R BT.601”, which could explain the color issue, at least for Media Player Classic (as I know VLC Media Player uses its own decoders, and I found no equivalent setting in its tremendously intricated list of parameters).
Speaking of which :
OK, so that was dumb to do this double conversion... But you said before : “Theoretically, if your exported format is RGB and it looks correct, then you can use ConvertToYV12(matrix="rec709") (and preview with ConvertToRGB(matrix="rec709") [...])”, if I read it correctly you suggested to preview with ConvertToRGB in that case where the exported file is in RGB.If you start in RGB, then that doesn't make sense - if you go back and forth with the same matrix, anything 709, 601, xyz etc.... you will get the same thing as you started with generally in terms of colors (there will be some quality loss) . But yes, if you are certain that you start with RGB, and it looks correct, then you should be using ConvertToYV12(matrix="rec709") before encoding.
All the problems occur when you go back and forth between RGB<=>YUV and you don't know what matrix is being used either for the conversion or the previewing method. For example if you started with a YUV lossless export then that raises more questions (do you know how the editor imported the video ? Do you know how the editor converted when exporting? What matrix is your preview method using converting to RGB ?) . There are some GUI's that allow you to toggle the preview between 709/601 . Avspmod, I think staxrip has a utility now, or you can do it with avisynth.
"...or you can do it with avisynth" => but Avisynth doesn't work alone, it sends frames to another software which (if I get it correctly) can interpret things in a bad way.
I meant it more like : if the whole thing takes 20 hours or so, would a slower setting for that small part significantly increase the total time.Yes it will slow it down, but only in that section (it won't slow down other sections). Is it worth it? Only you can decide that. Personally I would say probably not from what I've seen of your source footage
I finally made some tests for that sequence (there goes the sunday afternoon !).
Here's the sample encoded with CRF=18 and no filter :
https://www.mediafire.com/?5oduk4la7st45br
(If you're interested in the story behind this : on the night before Christmas 2007, my mother was doing crosswords while her former “companion” -- or whatever they call it these days -- was watching a “soft” erotic movie on TV, and complaining that he could no longer be “like this” anymore, while I was behind filming them, feeling both WTF?! and LMAO. He committed suicide three years later, and this is probably the only footage left of him.)
It's definitely noisier than the other footage you saw (which was native 1280x720 from AVCHD-Lite files, this was shot in 640x480 MJPEG with a ca. 2006 Fuji S6500 bridge camera, supposed to have great low-light capabilities at the time but here it struggles -- and video was more of an afterthought back then on digital photo cameras).
Test results (all with CRF=18) :
- no filter (the above sample) : 27417KB 9276kbps (peak 11694) 4,38FPS (601F / 137s)
- SMDegrain tr=2,thSAD=300,contrasharp=true,refinemotion=true, lsb=true : 20098KB 6782kbps (peak 9531) 1,50FPS (601F / 399s)
- SMDegrain tr=2,thSAD=300,contrasharp=true,refinemotion=true (no lsb) : 20082KB 6776kbps (peak 9589) 2,13FPS (601F / 281s)
- MCTemporalDenoise "medium" : 16311KB 5491kbps (peak 8248) 0,52FPS (601F / 1149s) (not counting ~60s preprocessing)
- MCTemporalDenoise "medium" : 23253KB 7857kbps (peak 11004) 1,51FPS (601F / 397s) (not counting ~30s preprocessing)
Screenshots : http://share.pho.to/9X0uv
It's indeed significantly slower with "lsb=true" for no benefit bitrate-wise, but still way faster than MCTemporalDegrain at "medium" settings and on par with MCTD at "low" settings.
Visually it's very hard to tell the differences. (And there's a glitch with Windows integrated picture viewing tool which makes it even harder to compare : when two files are viewed back and forth the second one or two width pixels “eaten” in the middle ; while XnView gets unstable and crashes when viewing several pictures in short succession. FastStone Image Viewer works fine though.) MCTD "low" seems sharper than without filter, MCTD "medium" loses too much detail (the reflection in the window for instance -- very important to preserve as the guy's face is never seen directly in this footage, kinda eery retrospectively), SMDegrain with those settings seems both slightly less sharp and slightly more accurate than MCTD "low" (with a significantly lower bitrate). Very little difference indeed between the encodes with and without "lsb=true", but there are small differences (again, it's most obvious on the window reflection, seems a tad more accurate with "lsb=true", but it may not be significant from only one screenshot comparison).
It's a damn lotta work for something so subtle... And all in all, from the tests I made, I can't see a clear pattern when it comes to the relative effects of those two denoisers at various settings.Last edited by abolibibelot; 28th Jun 2015 at 12:42.
-
Yes, the temporal compression can cause mixed up frames in some programs when scrubbing the timeline (non linear seeking). It's a decoding issue, not encoding issue so testing various export formats is a waste of time. x264 CRF=0 is lossless, but most NLE's don't understand it on import (can't decode it) . The safest option is to replace those with I-frame intermediates - most editors have a "replace" function (yes you need more HDD space) .
I can't explain the jpg /jpg overlay issue (do you have a 3rd layer , a video as well?) . That must be a bug with your program
Sorry for confusing you with the RGB business. I'm sure it makes sense to you now, but the reason for the last ConvertToRGB(matrix="rec709"), is to temporarily emulate what you would see on the BD player. If you just used ConvertToYV12(matix="rec709") and "thought" the colors were wrong, it might be because whatever software you were using to view used the wrong matrix to convert to RGB for display. The bottom line is if you have RGB in the avs script, all previewing software should look the same (unless you have it misconfigured, different renderer) . ie. You're using avisynth to control the RGB conversion to view with either 601 or 709 matrix. You want to control and dictate the conversion - so you know exactly what is going on. If it's already RGB , it's a no-op (nothing is done) .
I use avspmod for the avisynth "GUI" . You can compare various scripts, or images in different tabs (use number keys to swap) -
Regarding x264 CRF=0 : I didn't even try to import it on the NLE's timeline, the visual quality being so abysmal when viewed with VLC (just tried with MPC : even worse, almost looks like a scrambled video -- but strangely it looks flawless in Avidemux...). That file is obviously far from lossless (48s source file is 5.88MB, CRF=18 re-encode is 6.65MB, CRF=0 re-encode -- of the source file of course -- is 53.3MB, MagicYUV lossless re-encode is 187MB).Yes, the temporal compression can cause mixed up frames in some programs when scrubbing the timeline (non linear seeking). It's a decoding issue, not encoding issue so testing various export formats is a waste of time. x264 CRF=0 is lossless, but most NLE's don't understand it on import (can't decode it) . The safest option is to replace those with I-frame intermediates - most editors have a "replace" function (yes you need more HDD space) .
I couldn't find a "replace" function within MVD. There's a "Mix audio and video" function, but it replaces the *whole* timeline with one video track and one audio track, kinda overkill in that case (and it probably wouldn't finish this operation without crashing as I already experienced). It does propose to re-encode AVCHD files when importing as they're supposed to be so demanding in processing power, but I found it not to be necessary, even with my not-so-recent computer.
I'll use the lossless transcode then (a lossless AVI is only I-frames, right ?). It's strange 'cause other AVI/Xvid source files used in this project don't cause any problem. And how come it varies from one export to the next ?
Yes, there's a video as background, and a kinda tricky transition between three pictures over that video. Small samples showing the issue (6MB each, x264 CRF=18 re-encodes from two MagicYUV exports), first one correct, second one with the glitch, nothing changed in between (only it's when I tried single-threaded encode, from which the second file below was re-encoded, but as you say it's unlikely relevant) :I can't explain the jpg /jpg overlay issue (do you have a 3rd layer , a video as well?) . That must be a bug with your program
https://www.mediafire.com/?ilssykv0ff90dzi
https://www.mediafire.com/?cmgc79qekwy02ao
Screenshot of the timeline : http://share.pho.to/9X5Eh
It could also be a memory-related problem, I'm working on a Windows session started weeks ago, I know sometimes it can screw things up (MVD still seems to work well currently, but on other occasions on such a long session the preview would begin to stutter and restarting the program wouldn't fix it, only a proper reboot would bring it back to normal).
I think I get it now ! Just so we're clear :Sorry for confusing you with the RGB business. I'm sure it makes sense to you now, but the reason for the last ConvertToRGB(matrix="rec709"), is to temporarily emulate what you would see on the BD player. If you just used ConvertToYV12(matix="rec709") and "thought" the colors were wrong, it might be because whatever software you were using to view used the wrong matrix to convert to RGB for display. The bottom line is if you have RGB in the avs script, all previewing software should look the same (unless you have it misconfigured, different renderer) . ie. You're using avisynth to control the RGB conversion to view with either 601 or 709 matrix. You want to control and dictate the conversion - so you know exactly what is going on. If it's already RGB , it's a no-op (nothing is done) .
1) that's was indeed what you suggested, to add both lines one after the other, to test the expected display on standalone devices ?
2) and indeed if Avisynth sends the "matrix="rec709"" command, any decent software will display it that way no matter what is its usual way of converting YV12>RGB ?
Thanks, I'll try that. I read several 2011 comments complaining about it not working on Windows Vista / 7, has this issue been solved since then ? (I'm currently on an XP session but once I finish this very job I'll probably use Win7 exclusively.)I use avspmod for the avisynth "GUI" . You can compare various scripts, or images in different tabs (use number keys to swap) -
Maybe it didn't encode correctly, or you're using old versions of players ? Almost all current freeware can handle x264 losslessOriginally Posted by abolibibelot
You'd have to look at the manual. Most NLE's have a "replace" function where each instance of that clip is replaced with the one you specify. It might be called a "proxy" in some editors, or labelled something different where you replace the proxy with the real or alternative clipI couldn't find a "replace" function within MVD. There's a "Mix audio and video" function, but it replaces the *whole* timeline with one video track and one audio track, kinda overkill in that case (and it probably wouldn't finish this operation without crashing as I already experienced).
Not necessarily , for example you can use long GOP compression for x264 lossless in AVI, FFV1 etc...I'll use the lossless transcode then (a lossless AVI is only I-frames, right ?).
It might be that one has different characteristics. Or some other bug, or hardware issueIt's strange 'cause other AVI/Xvid source files used in this project don't cause any problem. And how come it varies from one export to the next ?
sad, but rebooting seems to "cure" a lot of windows software related issuesIt could also be a memory-related problem, I'm working on a Windows session started weeks ago, I know sometimes it can screw things up (MVD still seems to work well currently, but on other occasions on such a long session the preview would begin to stutter and restarting the program wouldn't fix it, only a proper reboot would bring it back to normal).
. It's not just a Windows 95/98 issue
Some editors have a flush memory cache function (or something worded like that). Have a look in the manual
Yes; For example if you did ConvertToYV12 with Rec601 (or something else) then RGB with 709 , and it looked "wrong" then you know to go back and double check
I think I get it now ! Just so we're clear :
1) that's was indeed what you suggested, to add both lines one after the other, to test the expected display on standalone devices ?
2) and indeed if Avisynth sends the "matrix="rec709"" command, any decent software will display it that way no matter what is its usual way of converting YV12>RGB ?
BD player setups use 709 for HD, that's one thing that is very consistent. But software players and varous software can be very variable, there are many steps where something can go wrong or "gotchas" .
It works on 7/8 not sure about Vista or 10, but probably does tooThanks, I'll try that. I read several 2011 comments complaining about it not working on Windows Vista / 7, has this issue been solved since then ? (I'm currently on an XP session but once I finish this very job I'll probably use Win7 exclusively.)I use avspmod for the avisynth "GUI" . You can compare various scripts, or images in different tabs (use number keys to swap) -
MPC may be old indeed (well, just checked : 2008... maybe I took the "if it's not broken don't fix it" motto a bit too literally in this case !), but VLC was recently updated.Maybe it didn't encode correctly, or you're using old versions of players ? Almost all current freeware can handle x264 lossless
I meant for the codecs I used in this case : MagicYUV, UT Video, HuffYUV (tried that one too, size is 50% bigger). Otherwise there's MJPEG which I know it only reference frames (each frame is a JPEG picture), but it's lossy. Anyway, it seems to be working reliably with MagicYUV or UT, I'll go with that.Not necessarily , for example you can use long GOP compression for x264 lossless in AVI, FFV1 etc...
Another weird thing... I converted that Xvid file to ffdshow MJPEG, MagicYUV and UT Video (using VirtualDub), and made PNG (lossless) screenshots of the exact same frame with VLC Media Player : MagicYUV and UT Video appear identical (visually and same CRC) but different from the original, while the file size of the (lossy) MJPEG encode screenshot is very close to that of the original Xvid (167KB), both inferior to the lossless conversions (180KB). Is it again related to the way files are decoded by each software, which can vary somehow ? If the screenshots are made with MPC (BMP then re-encoded to PNG), original Xvid and MagicYUV are undistinguishable visually but not the same size (and the screenshot from Xvid file has an alpha channel, making it appear very pale, almost transparent, which I removed before converting to PNG, restoring the normal appearance).
Still found nothing of that sort. It would have been very helpful in other instances where I had to re-do a tricky editing work after replacing a file by a better quality version. In this case it's not very complicated, just 3-4 cuts.You'd have to look at the manual. Most NLE's have a "replace" function where each instance of that clip is replaced with the one you specify. It might be called a "proxy" in some editors, or labelled something different where you replace the proxy with the real or alternative clip
My version of this software is from 2010. But from what you say it's a “staple” feature which has existed for quite a long time. Yet “Proxy Editing” is apparently anounced as a novelty on Magix's 2015 high-end editor (if that's indeed what you mean) :
http://diyvideoeditor.com/magix-movie-edit-pro-review/
Again, nothing like that, and that too would be very welcome. But from what I read before installing it, it's reputed to be globally more stable than other similarly priced softwares (Pinnacle, Cyberlink...).Some editors have a flush memory cache function (or something worded like that). Have a look in the manual
OK, that's the important part -- which I cannot verify so I'll have to trust you and go with "rec709" after all...Yes; For example if you did ConvertToYV12 with Rec601 (or something else) then RGB with 709 , and it looked "wrong" then you know to go back and double check
BD player setups use 709 for HD, that's one thing that is very consistent. But software players and varous software can be very variable, there are many steps where something can go wrong or "gotchas" .
“You can't depend on your eyes when your imagination is out of focus.” -- Mark Twain, as quoted in season two of Dexter... (back when it was a brilliant and quotable show).
“- Anyway... I see lots of references, like this one. "You can't depend on your eyes when your imagination is out of focus."
- He's a trekker! That shit's straight from "Deep space nine."
- What? Mark twain said that. It's one of his most famous quotes.
- Twain was never on "Deep space nine." He was on "Next generation."
- He didn't say it on "Star Trek."
- Okay, so what's it from?
- "A Connecticut Yankee in King Arthur's Court."” -
Originally Posted by abolibibelot
1) How were magicyuv and utvideo different from the original ? How are you determining that ? what software/decoder/renderer etc..
CRC check is only useful on a decoded image to uncompressed (raw video) . So if you decoded everything, including original to uncompressed then compare that (there are other methods people use like PSNR, SSIM etc...)
The mjpeg lossy variant is expected to be different, but the lossless versions are not
If you're using the same decoding chain/ screenshot taking method for everything, then it should all be the same between xvid decoded and converted to PNG, vs. utvideo or magicyuv decoded and converted to PNG - because the same chroma upsampling method should be used, same algorithms etc. Some might decode with a dummy alpha channel (RGB32), so that might make size differnece, but the important thing to check is the decoded uncompressed image data in native YUV - that will always be the same and that is the definition of lossless
Different PNG compressors can yield differet filesizes between PNG, but if you then convert that to uncompressed (BMP) using the same methods, they will all be the same, and difference/quality testing (SSIM, PSNR) will yield no differences
"Proxy editing" is more of a generic technique, but in all those there is some form of clip replacement. So editors that have this will have some form of "replacement" functionMy version of this software is from 2010. But from what you say it's a “staple” feature which has existed for quite a long time. Yet “Proxy Editing” is apparently anounced as a novelty on Magix's 2015 high-end editor (if that's indeed what you mean) :
http://diyvideoeditor.com/magix-movie-edit-pro-review/ -
As I said, I made screenshots with VLC Media Player (then MPC but with no visual differences), and I noticed differences just looking at those :1) How were magicyuv and utvideo different from the original ? How are you determining that ? what software/decoder/renderer etc..
CRC check is only useful on a decoded image to uncompressed (raw video) . So if you decoded everything, including original to uncompressed then compare that (there are other methods people use like PSNR, SSIM etc...)
The mjpeg lossy variant is expected to be different, but the lossless versions are not
If you're using the same decoding chain/ screenshot taking method for everything, then it should all be the same between xvid decoded and converted to PNG, vs. utvideo or magicyuv decoded and converted to PNG - because the same chroma upsampling method should be used, same algorithms etc. Some might decode with a dummy alpha channel (RGB32), so that might make size differnece, but the important thing to check is the decoded uncompressed image data in native YUV - that will always be the same and that is the definition of lossless
Different PNG compressors can yield differet filesizes between PNG, but if you then convert that to uncompressed (BMP) using the same methods, they will all be the same, and difference/quality testing (SSIM, PSNR) will yield no differences
http://share.pho.to/9XPF4
There are very subtle differences, most notably on the upper left side (shades of the sky). But I just checked, the losslessly converted files are in RGB32, yet I'm pretty sure I converted to MagicYUV "as is", i.e. without color space conversion (not so sure for UT, I might have chosen "RGB"). Could it explain those differences ? Or is it a quirk from VLC ?
I checked some options in VirtualDubMod (used for these conversions) and found "Video Color Depth", which is set with "Decompression format : 24-bit (TrueColor/16M)" and "Output format to compressor/display : 24-bit (TrueColor/16M)", if that's useful information.
What are the most common tools to check SSIM / PSNR ?
I'll finally run the final encode this morning before going to sleep (yeah, my day/night cycle is a little upside down -- and I spent most of the night checking again those damn three chunks exported for the 3rd or 4th time after making some ultimate corrections*) ; crossing fingers, hoping it'll come out right in one try... By the way, isn't there a way of pausing an encode in MeGUI ? If not that would be damn useful.
* I noticed yet another weird effect : an animated picture showing a white building appears slightly translucid, yet at 100% opacity. Could be because the white is clearly burned, or a minor bug, but oh well... As this guy says : “There are some minor adjustments that could theoretically be made, but at this stage, [...] it's easy to end up chasing an unattainable perfection. Once you hit diminishing returns, completed work trumps perfect work.” (I probably hit that point long ago.)
Found this :"Proxy editing" is more of a generic technique, but in all those there is some form of clip replacement. So editors that have this will have some form of "replacement" function
http://www.magix.info/uk/how-to-replace-one-video-clip-with-another-cut.knowledge.978321.html
But in my version at least this function (copy / paste video effects) only applies effects which modify the aspect of a clip (resize, gamma...), it doesn't reproduce the editing (cuts, transitions...).
Nothing else so far. Can you name some NLE software in the same range that do have such a function ?Last edited by abolibibelot; 30th Jun 2015 at 01:09.
-
*Update* Ran the encode with one pass CRF=23 / "slow" preset / Profile High@3.1 ; when I woke up, after 7 hours the progress bar was at 31%, about 15 hours remaining, predicted file size (which must be quite reliable by now if calculated from the average bitrate up to that point) is 3.54GB, encoding rate is about 3.5FPS. Audio is 237MB / 180kbps (with QAAC setting TrueVBR 91, must be really high quality). Seems about right. (Maybe I could have stayed below 4GB with CRF=22, but that way there's a good safety margin, and that old laptop should play it more easily.)
x264 process utilizes about 1GB of memory, I hope it won't get higher than that for stability's sake.
The script had an error : the video had to be converted to YV12 *before* applying denoising filters.
Final script used for this encode :
(I kept the "lsb=true" option after all, it really seems to better preserve/refine detail in tricky areas like that reflection in the window, and this part is only a few minutes long, it will probably slow down less than the one with MCTemporalDenoise "medium".)Code:Vid = AVISource("20140821-1D.AVI") ++ AVISource("20140821-2D'.AVI") ++ AVISource("20140821-3C.AVI") VidYV12 = ConvertToYV12(Vid,matrix="rec709") Vid00 = Trim(VidYV12,0,2249) Vid01 = Trim(VidYV12,2250,30305).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid02 = Trim(VidYV12,30306,32969) Vid03 = Trim(VidYV12,32970,48295).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid04 = Trim(VidYV12,48296,49599) Vid05 = Trim(VidYV12,49600,52420).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid06 = Trim(VidYV12,52421,54429) Vid07 = Trim(VidYV12,54430,75840).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid08 = Trim(VidYV12,75841,76889) Vid09 = Trim(VidYV12,76890,79255).MCTemporalDenoise(settings="medium") # strong denoise Vid10 = Trim(VidYV12,79256,79460).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid11 = Trim(VidYV12,79461,81149) Vid12 = Trim(VidYV12,81150,83295).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid13 = Trim(VidYV12,83296,85199) Vid14 = Trim(VidYV12,85200,97785).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid15 = Trim(VidYV12,97786,99754) Vid16 = Trim(VidYV12,99755,105195).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid17 = Trim(VidYV12,105196,105209) Vid18 = Trim(VidYV12,105210,110670).SMDegrain(tr=2,thSAD=300,contrasharp=true,refinemotion=true,lsb=true) # medium denoise Vid19 = Trim(VidYV12,110671,110684) Vid20 = Trim(VidYV12,110685,114420).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid21 = Trim(VidYV12,114421,118509) Vid22 = Trim(VidYV12,118510,126430).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid23 = Trim(VidYV12,126431,138784) Vid24 = Trim(VidYV12,138785,145980).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid25 = Trim(VidYV12,145981,147504) Vid26 = Trim(VidYV12,147505,152805).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid27 = Trim(VidYV12,152806,153899) Vid28 = Trim(VidYV12,153900,183775).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid29 = Trim(VidYV12,183776,185114) Vid30 = Trim(VidYV12,185115,231854).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid31 = Trim(VidYV12,231855,231897) Vid32 = Trim(VidYV12,231898,232004).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid33 = Trim(VidYV12,232005,232182) Vid34 = Trim(VidYV12,232183,249460).SMDegrain(tr=1,thSAD=300,contrasharp=true) # light denoise Vid35 = Trim(VidYV12,249461,0) VidDenoised = Vid00 ++ Vid01 ++ Vid02 ++ Vid03 ++ Vid04 ++ Vid05 ++ Vid06 ++ Vid07 ++ Vid08 ++ Vid09 ++ Vid10 ++ Vid11 ++ Vid12 ++ Vid13 ++ Vid14 ++ Vid15 ++ Vid16 ++ Vid17 ++ Vid18 ++ Vid19 ++ Vid20 ++ Vid21 ++ Vid22 ++ Vid23 ++ Vid24 ++ Vid25 ++ Vid26 ++ Vid27 ++ Vid28 ++ Vid29 ++ Vid30 ++ Vid31 ++ Vid32 ++ Vid33 ++ Vid34 ++ Vid35 Aud = WAVSource("20140821 collage Audacity.wav") Mix = AudioDub(VidDenoised,Aud) Return(Mix)
Here's what MediaInfo says when analyzing the partial .264 file :
Is everything correct, compatibility-wise ?Format : AVC
Format/Info : Advanced Video Codec
Profil du format : High@L3.1
Paramètres du format, CABAC : Oui
Paramètres du format, RefFrames : 5 images
Largeur : 1 280 pixels
Hauteur : 720 pixels
Format à l'écran : 16/9
Images par seconde : 25,000 Im/s
Résolution : 24 bits
Colorimétrie : 4:2:0
Type d'image : Progressif
Bibliothèque utilisée : x264 core 146 r2538 121396c
Paramètres d'encodage : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00: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=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / 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=cqp / mbtree=0 / qp=23 / ip_ratio=1.40 / pb_ratio=1.30 / aq=0 -
Compatible with what delivery format? 1280x720p @25fps is not compatible with BluRay/AVCHD, if that's what you're asking. https://www.videohelp.com/hd#tech. OK for PC and most external players and data storage sources. Not for authored BD disc or DVD media.Originally Posted by abolibibelot
Last edited by LMotlow; 30th Jun 2015 at 11:38.
- My sister Ann's brother -
I know you said you tested some settings, and your target player can supposedly play various "files", but 720p25 is not compatible with BD or "avchd" on DVD5/9 media . It needs double pulldown or hard duplicate frames for 720p50. Those aren't BD compatible x264 settings either . Many players might be able to play it (because many modern players can play non-compliant content) , but I'd be a bit worried. You should always have a buffer and maxrate set for devices, because bit rate spikes can cause stuttering . It will play fine on some devices, not on others. On the other hand if you used "avchd" compatible settings for DVD5/9 there is a higher chance it will play on most devices - but those settings reduce comrpression efficiency from what you have now
-
mm. @poisondeathray, I plumb forgot about the plans for DVD media. Thanks for reminding me.
- My sister Ann's brother -
Originally Posted by abolibibelot
There are definite differences in the screenshots. Possible reasons: 1) Make sure the decoding chain for xvid is the same - some xvid decoders have postprocessing or deblocking enabled . eg. if you have xvid vfw for the vdubmod encode, check the advance settings. VLC uses ffmpeg/libavcodec for xvid decoding. 2) MagicYUV is fairly new, so a proper decoder might now have made it into VLC yet . 3) If vdubmod wasn't set to video=>fast recompress, then it converted to RGB. So there would be an expected quality difference between the native Xvid file, which will be in YV12. It's probably #2, because you said that MPC didn't show differences
Common tools for psnr/ssim testing would be msu vqmt, avisynth's compare, and ffmpeg has a psnr filter . But when you are doing lossless testing, it either is or isn't. It's all or none. That's why it's great for confirmation of "losslessness" .(Athough PSNR/SSIM and other metrics are objective measures of "quality", they are problematic for lossy quality testing in that they don't necessarily have a very high correlation with human visual perception of "quality". It's easy to optimize for higher "scores", but yet have worse subjective visual quality)
Visualization techniques include difference or subtract (and amplifed differences or subtract) testing - they make it easier to "see" where the problems are or whether or not something is lossless or not. You can do that easily in most NLE's ,just put 2 versions on top of another and set their blending mode to difference (in some programs it might be called composite mode). You can apply various filters to amplify the differences
I don't know if megui can pause, I think not because it's a commonly requested feature (for all GUI's not just megui)
Those weird bugs seem like bugs with the NLE. But random, non repeatable could also suggest HW issues, like overheating, bad PSU, memory corruption
Maybe sony vegas movie studio platinum ? They have several different versions. I know the pro version has replace function as well as proxy editing, but it's more expensive
Found this :
http://www.magix.info/uk/how-to-replace-one-video-clip-with-another-cut.knowledge.978321.html
But in my version at least this function (copy / paste video effects) only applies effects which modify the aspect of a clip (resize, gamma...), it doesn't reproduce the editing (cuts, transitions...).
Nothing else so far. Can you name some NLE software in the same range that do have such a function ? -
Compatible with what delivery format? 1280x720p @25fps is not compatible with BluRay/AVCHD, if that's what you're asking. https://www.videohelp.com/hd#tech. OK for PC and most external players and data storage sources. Not for authored BD disc or DVD media.I never tried to make a proper "AVCHD" type DVD and that wasn't the plan from the begining. I had my brother try two test encodes made with roughly the same settings on his BR player (through an external hard drive) and on his 2004 laptop computer : CRF=20 profile Main@L4.1, CRF=22 profile Main@L3.1 (both with Nero AAC but the audio encoder is probably not an issue as long as it's standard AAC) ; the standalone player played both fine, the computer had more trouble with the first one. This time I used CRF=23 and profile High@L3.1 following what you (“poisondeathray”) wrote earlier : “As a general rule, currently most devices are limited to High@L4.1” (I chose 3.1 to stay on the safe side). MediaInfo report for those two test files (which, I repeat, worked with that particular BD player, model LG BD550) :I know you said you tested some settings, and your target player can supposedly play various "files", but 720p25 is not compatible with BD or "avchd" on DVD5/9 media . It needs double pulldown or hard duplicate frames for 720p50. Those aren't BD compatible x264 settings either . Many players might be able to play it (because many modern players can play non-compliant content) , but I'd be a bit worried. You should always have a buffer and maxrate set for devices, because bit rate spikes can cause stuttering . It will play fine on some devices, not on others. On the other hand if you used "avchd" compatible settings for DVD5/9 there is a higher chance it will play on most devices - but those settings reduce comrpression efficiency from what you have now
So the question is : are there any significant parameters that are different between the file currently encoding and those two ?Code:Format : AVC Format/Info : Advanced Video Codec Profil du format : Main@L4.1 Paramètres du format, CABAC : Oui Paramètres du format, RefFrames : 5 images Identifiant du codec : avc1 Identifiant du codec/Info : Advanced Video Coding Durée : 2mn 1s Type de débit : Variable Débit : 4 293 Kbps Débit maximum : 14,3 Mb/s Largeur : 1 280 pixels Hauteur : 720 pixels Format à l'écran : 16/9 Type d'images/s : Constant Images par seconde : 25,000 Im/s Résolution : 24 bits Colorimétrie : 4:2:0 Type d'image : Progressif Bits/(Pixel*Image) : 0.186 Taille du flux : 62,3 Mio (96%) Bibliothèque utilisée : x264 core 146 r2538 121396c Paramètres d'encodage : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / 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=cqp / mbtree=0 / qp=20 / ip_ratio=1.40 / pb_ratio=1.30 / aq=0 Format : AVC Format/Info : Advanced Video Codec Profil du format : Main@L3.1 Paramètres du format, CABAC : Oui Paramètres du format, RefFrames : 5 images Identifiant du codec : avc1 Identifiant du codec/Info : Advanced Video Coding Durée : 2mn 1s Type de débit : Variable Débit : 3 311 Kbps Débit maximum : 11,3 Mb/s Largeur : 1 280 pixels Hauteur : 720 pixels Format à l'écran : 16/9 Type d'images/s : Constant Images par seconde : 25,000 Im/s Résolution : 24 bits Colorimétrie : 4:2:0 Type d'image : Progressif Bits/(Pixel*Image) : 0.144 Taille du flux : 48,1 Mio (95%) Bibliothèque utilisée : x264 core 146 r2538 121396c Paramètres d'encodage : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / 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=cqp / mbtree=0 / qp=22 / ip_ratio=1.40 / pb_ratio=1.30 / aq=0
I wish it could also be played on that 2010 Thomson TV (grandma's), but I still don't know what model it is and if it even has a USB port and MP4 reading ability, so I couldn't take it into account and couldn't wait forever... If that doesn't work I'll try to find another option.
Here is the MediaInfo report for a MKV file that this BR player apparently can not play (it does play other MKVs) :
By the way, is there a way I could make this file (it's a movie, has nothing to do with this current video I'm encoding) playable without fully reencoding it ? I tried remuxing it with MKVMerge (keeping only the french language audio stream and no subtitle), converting it to MP4 with Avidemux or FFMPEG, so far no luck. I learned about a tool called H264LevelEditor but it probably won't help in this case (profile Main@L3.0 shoudn't be the issue).Code:Format : Matroska Taille du fichier : 1,39 Gio Durée : 1h 41mn Débit global moyen : 1 963 Kbps Application utilisée : HandBrake svn3707 Bibliothèque utilisée : libmkv 0.6.4.1 Format : AVC Format/Info : Advanced Video Codec Profil du format : Main@L3.0 Paramètres du format, CABAC : Oui Paramètres du format, RefFrames : 4 images Type de muxing : Container profile=Unknown@3.0 Identifiant du codec : V_MPEG4/ISO/AVC Durée : 1h 41mn Largeur : 656 pixels Hauteur : 572 pixels Format à l'écran : 1,629 Format à l'écran d'origine : 1,631 Type d'images/s : Variable Images par seconde : 25,000 Im/s Résolution : 24 bits Colorimétrie : 4:2:0 Type d'image : Progressif Bibliothèque utilisée : x264 core 110 Paramètres d'encodage : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=2 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=0 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 colour_primaries : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M transfer_characteristics : BT.709-5, BT.1361 matrix_coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
I don't think that was mentioned earlier. Where can those settings be modified ? What do you call a bit rate spike (i.e. absolute or relative value), and isn't the risk of such a problem mitigated by the relatively high CRF value plus the denoising filters ? The CRF=20 test sample had a max bitrate of 14.3mbps, which seems already very high for that type of content and encoding parameters, I doubt the whole movie will have peaks much higher than that. Anyway, if this encode finishes (now at 67%, 6 hours ETA -- took me some time to finish this post, now 81%) and it looks fine, I'll send that file and hope for the best, then, as Ivan Drago would say, if it stutters, it stutters...You should always have a buffer and maxrate set for devices, because bit rate spikes can cause stuttering .
1) So is ffmpeg/libavcodec perfectly reliable in the way it decodes Xvid ? Or VLC's screenshot taking method ?There are definite differences in the screenshots. Possible reasons: 1) Make sure the decoding chain for xvid is the same - some xvid decoders have postprocessing or deblocking enabled . eg. if you have xvid vfw for the vdubmod encode, check the advance settings. VLC uses ffmpeg/libavcodec for xvid decoding. 2) MagicYUV is fairly new, so a proper decoder might now have made it into VLC yet . 3) If vdubmod wasn't set to video=>fast recompress, then it converted to RGB. So there would be an expected quality difference between the native Xvid file, which will be in YV12. It's probably #2, because you said that MPC didn't show differences
2) You mean “a proper decoder might not have made it into VLC yet”, right ? UT seems older (version number 12.xx) and the screenshot with that codec is exactly identical. At first I had chosen a frame which was repeated twice (old cartoon animation), and was even more befuddled by the result (screenshots from both lossless conversions were different, very probably because it was not the exact same frame), but then I realized it and I chose one that appeared only once (the one you saw).
3) It was set to "Full processing". (I only use "Direct stream copy" when only cutting, and "Full processing" when transcoding, not sure what the other two modes are for.)
It's just for curiosity's sake, though, I trust those codecs to be indeed lossless otherwise they wouldn't be used and recommanded for that purpose, but it's more reassuring to have a clear proof once before relying on it. (And even respected experts on these forums, like “lordsmurf” here, seem to have doubts about the actual “losslessness” of lossless codecs... Quite surprising, as in other instances this guy definitely knows what he's talking about.)
Here's the file if you want to verify : https://www.mediafire.com/?n5pb9ped73617uv [6MB]
I think MVD has such a function, which I never tried.Common tools for psnr/ssim testing would be msu vqmt, avisynth's compare, and ffmpeg has a psnr filter . But when you are doing lossless testing, it either is or isn't. It's all or none. That's why it's great for confirmation of "losslessness" .(Athough PSNR/SSIM and other metrics are objective measures of "quality", they are problematic for lossy quality testing in that they don't necessarily have a very high correlation with human visual perception of "quality". It's easy to optimize for higher "scores", but yet have worse subjective visual quality)
Visualization techniques include difference or subtract (and amplifed differences or subtract) testing - they make it easier to "see" where the problems are or whether or not something is lossless or not. You can do that easily in most NLE's ,just put 2 versions on top of another and set their blending mode to difference (in some programs it might be called composite mode). You can apply various filters to amplify the differences
82%...Last edited by abolibibelot; 30th Jun 2015 at 17:24.
-
Likely this is the problem - VFRBy the way, is there a way I could make this file (it's a movie, has nothing to do with this current video I'm encoding) playable without fully reencoding it ? I tried remuxing it with MKVMerge (keeping only the french language audio stream and no subtitle), converting it to MP4 with Avidemux or FFMPEG, so far no luck.
It's probably really CFR, try mp4box and mux itType d'images/s : Variable
Optical disc has a limitation on transfer rates. It can only spin and transfer data so fast. DVD5/9 is less than BD25/50. You should use --vbv-maxrate 15000 --vbv-bufsize 15000 for DVD media. It's unlikely that you will encounter an issue with your low target bitrates .I don't think that was mentioned earlier.You should always have a buffer and maxrate set for devices, because bit rate spikes can cause stuttering .
"Bitrate spike" is different context ; you can't measure it with bitrate viewer - you need to use a VBV verifier to "measure" it. It's a different level of abstraction. The commonly used analogy and explantion is a "leaky bucket" model. The bucket holding the water is the buffer. Water enters and fills the bucket from the disc (that's the transfer rate). Decoding pictures draws water (the data) from the bucket. If you run out of water, you get a "buffer underrun" and stuttering. Even on non optical media, devices have limitations on what they can decode. They have fixed function decoders that follow the same rules . Different devices have different numbers for the buffer and maxrate. Maxrate isn't the maximum bitrate, it's the maximum rate of data transfer.
Yes, for magicyuv which is newer2) You mean “a proper decoder might not have made it into VLC yet”, right ?
Full processing mode always converts to RGB in between. If you're not using vdub filters, you should use "fast recompress" and you will stay in YUV (if original was YUV, and decoded as YUV)3) It was set to "Full processing". (I only use "Direct stream copy" when only cutting, and "Full processing" when transcoding, not sure what the other two modes are for.)
They are only lossless when used correctly . If you incur a colorspace conversion, or it gets interpreted it incorrectly (handling of the recieving software is improper) then it's not lossless. For example, some host applications do not treat UT video (or magicyuv, or lagarith etc...) in YUV as lossless, because it gets converted to RGB.It's just for curiosity's sake, though, I trust those codecs to be indeed lossless otherwise they wouldn't be used and recommanded for that purpose, but it's more reassuring to have a clear proof once before relying on it. (And even respected experts on these forums, like “lordsmurf” here, seem to have doubts about the actual “losslessness” of lossless codecs... Quite surprising, as in other instances this guy definitely knows what he's talking about.) -
Just remux it, with no special setting ? Why did remuxing with the other tools I tried not fix that ? I'll try that anyway.It's probably really CFR, try mp4box and mux it
OK, but anyway the DVD is just a cheap transportation medium in this case, it will most likely be copied to the external hard drive and accessed through it.Optical disc has a limitation on transfer rates. It can only spin and transfer data so fast. DVD5/9 is less than BD25/50. You should use --vbv-maxrate 15000 --vbv-bufsize 15000 for DVD media. It's unlikely that you will encounter an issue with your low target bitrates .
Sorry if that's a dumb question, but isn't that the definition of bitrate ? Or do you mean that it's not the individual peaks that matters here, but the average amount of data over a given amount of time, depending on the size of the buffer, so that (if I understand correctly) a very high individual spike will cause less trouble than a succession of smaller ones above the threshold capacity of the device ?"Bitrate spike" is different context ; you can't measure it with bitrate viewer - you need to use a VBV verifier to "measure" it. It's a different level of abstraction. The commonly used analogy and explantion is a "leaky bucket" model. The bucket holding the water is the buffer. Water enters and fills the bucket from the disc (that's the transfer rate). Decoding pictures draws water (the data) from the bucket. If you run out of water, you get a "buffer underrun" and stuttering. Even on non optical media, devices have limitations on what they can decode. They have fixed function decoders that follow the same rules . Different devices have different numbers for the buffer and maxrate. Maxrate isn't the maximum bitrate, it's the maximum rate of data transfer.
***
Encoding is finished, took a little less than 19 hours. Here's MediaInfo's report :
Code:Général Nom complet : E:\20140821 HuffYUV\20140821.mp4 Format : MPEG-4 Profil du format : Base Media Identifiant du codec : isom Taille du fichier : 3,68 Gio Durée : 3h 3mn Débit global moyen : 2 882 Kbps Date d'encodage : UTC 2015-07-01 00:52:57 Date de marquage : UTC 2015-07-01 00:52:57 Vidéo ID : 1 Format : AVC Format/Info : Advanced Video Codec Profil du format : High@L3.1 Paramètres du format, CABAC : Oui Paramètres du format, RefFrames : 5 images Identifiant du codec : avc1 Identifiant du codec/Info : Advanced Video Coding Durée : 3h 3mn Type de débit : Variable Débit : 2 697 Kbps Débit maximum : 24,6 Mb/s Largeur : 1 280 pixels Hauteur : 720 pixels Format à l'écran : 16/9 Type d'images/s : Constant Images par seconde : 25,000 Im/s Résolution : 24 bits Colorimétrie : 4:2:0 Type d'image : Progressif Bits/(Pixel*Image) : 0.117 Taille du flux : 3,45 Gio (94%) Bibliothèque utilisée : x264 core 146 r2538 121396c Paramètres d'encodage : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00: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=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / 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=cqp / mbtree=0 / qp=23 / ip_ratio=1.40 / pb_ratio=1.30 / aq=0 Date d'encodage : UTC 2015-07-01 00:52:57 Date de marquage : UTC 2015-07-01 00:57:05 Audio ID : 2 Format : AAC Format/Info : Advanced Audio Codec Version du format : Version 4 Profil du format : LC Paramètres du format, SBR : Non Identifiant du codec : 40 Durée : 3h 3mn Type de débit : Variable Débit : 180 Kbps Débit maximum : 234 Kbps Canaux : 2 canaux Position des cannaux : L R Echantillonnage : 48,0 KHz Résolution : 16 bits Taille du flux : 236 Mio (6%) Langue : Français Date d'encodage : UTC 2015-06-30 06:17:02 Date de marquage : UTC 2015-07-01 00:57:05
And bitrate profile from Bitrate Viewer :
http://share.pho.to/9XhQO
There are a few peaks above 12500kbps, it's consistent with the content (the highest at 23969kbps is during a heavy rain segment, then there are two complex transitions, a short segment filmed on the road and a fast camera pan with a crossfade stitching two different takes of the same shot).
The colors are wrong with VLC, as expected, but correct with MPC and that AVS script :
There's a slight audio desynchronization that way, though (not with VLC). And, very weird, if I then play the file directly in MPC (quite old version as already mentioned, but it usually plays MP4 files fine) the audio is completely distorted, sometimes too fast, sometimes too slow, and sounding like there was heavy reverb applied, at the begining there's even a dialogue from way later in the film playing over the normal sound from the intro... *But* after simply changing the file's name, it's played normally again -- don't know what happened there (maybe the Avisynth script is still active somehow ?). And then if I put back the original name, the audio issue returns just the same. If anyone has a clue...Code:DirectShowSource("E:\20140821 HuffYUV\20140821.mp4") ConvertToRGB(matrix="Rec709")
So, is there a way to have the correct color matrix with VLC ? Here someone who is apparently a VideoLan developper says it's a video driver issue, not sure what he means by that.
Otherwise, I'm halfway through verifying that file, evreything looks good so far, the quality is satisfying, the noise is well attenuated and stabilized, I only see some mild artifacting on a plain colored wall, I have to search for it, nothing distracting (and I read that H264 generally has trouble with large areas of plain colors, or shadings, especially at constrained bitrates, I've seen that sort of issues even on professional videos). As Hannibal Smith from “The A-Team” (in french “L'agence tous risques”, my brother's favorite series) would say : “J'adore quand un plan se déroule sans accroc !” (“I love it when a plan comes together”). Thanks again to those who helped me, especially “poisondeathray” and “cornucopia”.Last edited by abolibibelot; 1st Jul 2015 at 10:28.
Quote
Similar Threads
-
mkvmerge append playback error when joining 2 mkv files from diff sources
By Owdrai in forum EditingReplies: 1Last Post: 26th Mar 2015, 10:53 -
I want to re-encode a AVI, MP4 or MKV
By Balema in forum Newbie / General discussionsReplies: 4Last Post: 22nd Feb 2014, 01:37 -
MKV guide, Play MKV, MKV to AVI, MKV to DVD, MKV to MP4, MKV to Blu-ray
By Baldrick in forum Newbie / General discussionsReplies: 55Last Post: 29th Jun 2012, 11:19 -
Pixelation on mkv, mp4 and avi files
By ajkrishock in forum Newbie / General discussionsReplies: 10Last Post: 24th Nov 2010, 06:12 -
MP4 X.264 to AVI XviD - Hard Sub with ssa subtitles (1 step or 2 step?)
By ssray23 in forum SubtitleReplies: 4Last Post: 29th Aug 2010, 19:35