Yes.
Press "Display" button on the remote when not in another menu to bring up this menu, go to "Picture".
I thought of this because the sharp edges in the U chroma look a bit "residual" to me, which is an artefact by temporal noise reduction.
@ Brad
That's a neat trick. HDMI RGB Output Range is not in the menus of many Panasonics. Maybe this implies the ones without this option do not output RGB via HDMI at all? If I'm not mistaken, 8 Bit 4:2:2 is mandatory for anything with HDMI, so there should never be a need for RGB. The manual of my DMR-EH 575 doesn't say anything at all about color formats via HDMI.
+ Reply to Thread
Results 181 to 210 of 368
-
-
I thought of this because the sharp edges in the U chroma look a bit "residual" to me, which is an artefact by temporal noise reduction.
That's why the best sharpener do not touch the chroma, or we set to copy back the chroma from the video before sharpening at the end of the processing.
For sure the Panasonic NR is not that accurate as what we do in AviSynth... -
-
You believe it is worth it because you've learned about video and its specs? Or because you've spent time and money assembling your rig? It seems you haven't noticed significant quality differences in terms of macroblocking or lost detail, the major differences are variations of the levels and saturation. So, aren't you simply justifying the efforts you've spent, and discounting the DV route just because it is too simplistic?
A true comparison would be a series of samples, converted into the same codec and adjusted to have the same levels, temperature and saturation, so that you would not know which is which, then you would compare them without having a preconceived opinion.
That is, if you actually want a true scientific test. -
Oh please, hardly above 100€... That's not even half the price my NLE cost me. And definitely not a reason for me to now pretend I like analogue capturing more than DV, if I actually didn't...
No. Ever since I've had those 2008 DV files, the question has been in the back of my mind whether it was not a "proper" capture. The more I researched and the more I stumbled upon this "war of opinions" regarding DV vs lossless, the more I was determined to eventually do it "properly". I've always been some sort of perfectionist. Not only in this field here. Even if I saw not a single visual difference between a DV sample and a lossless one, I'd still prefer the lossless one, as it is... well... LOSSLESS. Maybe it's a psychological thing, but just KNOWING that it has been captured the best way possible, that is, without any compression artifacts (be they ever so minor) is enough for me to feel right about the whole thing. After all, I want to create a solid foundation which can then be used for everything else: master files, unedited, as raw and natural as possible. No filters, no effects. That's the foundation, so to speak. And from there I can venture on editing, cleaning, exporting in more viewable file formats, what else not.
I believe, the beginning / foundation should always be a lossless format which comes as close to the original as possible. And a DV format, for me, is simply not as close to the original as possible. It has compression, it has flaws. And in my opinion isn't a suitable format for long-time archival purposes. Who knows if in 10 or 20 years we can even read DV file formats? Maybe we would have to re-encode all of them into a more contemporary format by then. The DV standard is pretty dated as it is.
True. Then again, this is not a double-blinded, randomized Phase-3 study for scientific purposes whose results should be statistically significant.
If you, or so it seems, do like the DV file format for long-time archival purposes and to base your future editing processes on, then feel free to do it that way.
The changes I've seen here comparing the two, no matter how small they might have been, together with the fact that I now feel good about a lossless capture reinforce my undertaking. -
I've always been some sort of perfectionist. Not only in this field here. Even if I saw not a single visual difference between a DV sample and a lossless one, I'd still prefer the lossless one, as it is... well... LOSSLESS. Maybe it's a psychological thing, but just KNOWING that it has been captured the best way possible, that is, without any compression artifacts (be they ever so minor) is enough for me to feel right about the whole thing.
I already had the same exhange of opinion with Bwaak as you some time ago: https://forum.videohelp.com/threads/409707-Youtube-Workflow#post2693306 -
It does not matter what I think. I am not trying to sell you anything. It just seems to me that your preference to lossless is not strictly fact-based, but because ever since you've had those 2008 DV files, the question has been in the back of your mind whether it was a "proper" capture.
Then again, why not, if you have a working workflow? -
Yes, so? What is not fact-based about this feeling / question in the back of my head? Or in other words: what are the facts that would favor a DV capture over a lossless one?
As you might have noticed reading all the posts here, I actually DID re-capture all the tapes to DV first just to see if and what it might yield in terms of quality improvement. And even this re-capture did improve things: glitches or other flaws that appeared in the 2008 DV capture many times did not appear in my re-capture. Meaning I gained additional picture and sound information with which I could improve the 2008 files. Many times only for a frame or two, but why take a picture with a glitch or horizontal static when I can have one that doesn't...
And then I thought: what if there is even more to squeeze out of these tapes, and then I decided to try the analogue / lossless route. -
I do not advertise the DV route. I simply say that without a double-blind test you were deliberately looking for improvements in the lossless version, your judgement was skewed from the beginning.
Right, but this is not about DV vs lossless, this is about 2008 DV vs 2023 DV.
Sure. Again, if you like the result, it is all that matters. -
Just to "pile on" a bit ...
I'm a scientist and engineer by both training and practice. I try as hard as I can to remove emotion from any decision. Here is my take on everything discussed so far in this thread.
1. You are concerned that the old DV captures may not be "proper." Originally, I think most of us thought you meant that using a better capture system would give you video that was significantly visually superior to the old captures. Now that you've had half a dozen eyes look critically at the differences, no one -- not even you -- are saying that the new captures are going to give you an improved viewing experience. There are, at most, a few small differences, almost all of which could be corrected with a little work in the Vegas Color Corrector (I have used Vegas for almost a quarter century, so I know what it can do).
So, the new captures really aren't any better, and the differences probably won't be noticed, once you correct the saturation.
2. You think that uncompressed is somehow better simply because it is uncompressed. This is where the engineer and scientist in me suppresses any emotion I might feel about this. The truth is, there is absolutely zero difference between uncompressed and a lossless compression codec like HuffYUV, Lagarith, etc. What's more, if you do some reading and do some experimentation, you will find that there is another group of codecs called "intermediate codecs." These are lossy codecs, so they give you much smaller file sizes, but they are designed so that even a professional cannot spot any visual differences from the original. They are also designed to let you recompress multiple times without getting additive degradation (like you do on a Xerox copy machine when you make a copy of a copy of a copy). So, you can recompress several times (if your edit cannot be done all at once) without visually reducing the quality.
One of the original and still one of the best intermediate codecs is Cineform. They got bought by GoPro and for many years you could get this for free by downloading GoPro's editing suite. Vegas used to include Cineform back when Sony owned it, but I don't think Magix still includes it (I haven't upgraded since Magix bought the product). I know that Magix's version of Vegas has the Magix intermediate which is a version of ProRes and I'm sure it will work as well as Cineform.
BTW, Cineform was used by the broadcast industry, back when they were still editing SD video at the turn of this century, so it met their standards. If it was good enough for them, it will be good enough for you!
3. Another reason for my recommendation to NOT use uncompressed is that it is a TERRIBLE thing to edit with. You have only been focusing on storage, and say you have infinite storage and therefore don't care about ridiculously and needlessly large files that uncompressed creates. Fine, but you are missing much more important points. First of all, Vegas will struggle to give you 25 fps on the timeline with uncompressed. Then, if you want to do color correction, composite, add titles, add other fX, etc. and do so with the Preview set to Best-Full, you will be lucky to get 2-3 fps.
Do the same thing with an intermediate version of your video, and your system will fly.
Also, if you do any editing which requires you to render to a file and then re-import that file back into Vegas, if you do that a few times and save everything as uncompressed you WILL start running out of disk space, unless you have a big disk farm.
So, in summary, uncompressed provides absolutely no advantage over lossless compression, and has virtually no visual difference from an intermediate codec. Broadcast video professionals use intermediate codecs, and they are even more demanding than you, and have more disk space, if they need it, so there must be reasons, and I've given you a few above.
Get Cineform or use the MAGIX codec, use one of those, and your results will be visually indistinguishable from using uncompressed, but you will get to the endpoint of your project MUCH faster, and with far fewer headaches. -
The advantage of lossless is no DV compression macroblocks. That's a fact .
You can see the blocks in your examples . For the people with bad eyes, zoom in on the original fields. I can post demonstration if someone wants . Yes they are minor - and if you have to zoom in to see them, that tells you they are minor . For casual use, watching in real time, you're not going to see the difference
BUT - The problem with many current "state of the art machine learning algorithms" is compression artifacts such as macroblocks from DV (or any lossy codec) - will typically be enhanced by many types of models. Visit any forum that deal with machine learning upscaling, and you will see this is a problem. There are other models with denoise/deblock, but results are more blurry , less detail. (Maybe one day, there will be specific training for DV and/or other compression artifacts, right now it's a problem)
This means is you have to additionally deblock the DV version (on top of whatever filters you're already using for both, for example the horizontal lines that appear in individual fields), and that will degrade the details even farther, before you even begin additional processing. It's impossible to effectively deblock without losing some details or softening image. -
Now that you've had half a dozen eyes look critically at the differences
To have the full picture, we should run the same experiment with a capture in the classic Analog workflow, i.e. high-end player with TBC correction feeding one of the recommended USB capture cards or one of the high end capture cards.
And what master poisondeathray added, is a confirmation of what we say since longtime: if a restoration is needed, the lossy DV coding/decoding is not adequate, and a lossless capture to work with is preferable. -
Beware that YUV lossless codecs are only "lossless" if they are handled properly
NLE's like Vegas, Premiere do NOT handle them properly . Huffyuv, lagarith etc... are not YUV lossless in Vegas - they get converted to "computer RGB". The main issue is clipping of uncorrected superbrights, but there can other problems . -
In-camera DV route: analog -> digital (in-camera A/D) -> TBC/NR in digital domain (optional) -> compression to DV
HDMI route: analog -> SVideo to DVD recorder -> digital -> TBC/NR in digital domain (optional) -> uncompressed over HDMI
Traditional lossless route: analog -> SVideo to DVD recorder/TBC -> digital -> TBC/NR in digital domain -> D/A back to analog -> USB or PCI A/D converter -> digital -> uncompressed over USB
Traditional lossless route with an outboard TBC incurs an extra A/D/A conversion.
The HDMI route has fewer conversions. -
As I said in my previous post, I haven't upgraded Vegas since Sony owned it (version 13). What you say was definitely true back then. Is it still true?
I think you are talking about the 15-235 to 0-256 conversions. Once you are aware of this and do the right things, it doesn't cause a problem. -
It's stiill a problem
For newer Magix vegas pro versions - they now have the ability to work in studio RGB or computer RGB. But that only helps if the imported asset was treated as YUV to begin with - and that's not the case for Magix Vegas in terms of the "lossless" YUV codecs such as huffyuv, lagarith, ut video etc... They incur a limited range YUV to full range RGB before you can do anything in vegas. That means clipping, plus other errors
Premiere has a native YUV timeline, so it *really* shouldn't matter - but still clips - why ???
The underlying problem is the common "lossless" codec in YUV 422 configuration (huffyuv, lagarith, ut video etc...) are not decoded as fourcc UYVY 422 . They are decoded as fourcc YUY2 . YUY2 is still uncompressed 8bit 422, but that forces a limited range YUV to full range RGB conversion immediately, because YUY2 is not a valid pixel type for windows NLE's. The problem is right after the decoder and how the NLE receives the data from the decoder . Had the decoder output UYVY, it would probably be lossless in premiere (native YUV timeline) , and lossless in vegas if working in 32bit float (All versions of vegas work in RGB only, and 32bit float would be required for lossless YUV input, otherwise it's a lossy transform YUV=> RGB will produce many negative RGB value combinations which will be clipped to zero when working in integer)
It's not just Y 0-15, 236-255 range clipping - those are just the problems you can easily see right away. The YUV=>8 bit RGB=>YUV potentially loses millions of unique combinations . Some of them are only slightly off, but that defeats the purpose of "losslessness"
The "Lossless" YUV codecs above are truly lossless in Open source NLE's based on ffmpeg /libavcodec (e.g. shotcut, kdenlive). They are decoded through libavcodec and treated as YUV, and not decoded through the VFW windows decoder. They do not have that intermediate limited range YUV to full range RGB clipping step that "pro" NLE's haveLast edited by poisondeathray; 25th Jun 2023 at 20:32.
-
@poisondeathray, what about Cineform support in Vegas, 8-bit and 10-bit? VDub2 has a native Cineform codec, this is what I use for capturing.
Regarding Vegas, someone posted a link to a page that I have since lost, where different color/levels modes of Vegas have been explained depending on codec and container. What drives me crazy is that at one time I thought that Vegas uses "video" levels by default, then I would drop "video-to-computer" levels to check how it would look when the final render would be watched, then I would turn it off, render with "video" levels, and usually everything worked out ok. But sometimes this does not work, and the "video" levels are not expanded during viewing. I suppose, Vegas uses "video" levels during editing, but sets "full" levels on the rendered file? Ugh. So I usually render a small portion of a video with deep blacks to test how it would look like when uploaded to youtube. -
Cineform is not natively supported (need 3rd party install), but it works fine in all versions of vegas. It's one of the best intermediate near lossless codecs for vegas for a long time. Much faster than prores, dnxhd/dnxhr, other near lossless intermediates on windows .
Not sure what you mean by 8bit ? "proper" YUV cineform is 10bit422 . Even from 8bit source, when handled correctly the 10bit to 8bit down conversion is basically perfect. The only losses are from lossy compression (which is very minimal at filmscan2/3). In vdub2, the vdub native CFHD encoder works fine - it doesn't matter if you use 10 or 16 bit intermediate processing (I've never tried 8) . It's the open source decoder in libavcodec for CFHD that still has a few remaining bugs. That doesn't affect vegas, because decoder is different
cfhd decodes as fourcc "v210", or 10bit packed 4:2:2 => This is the native pixel format for most pro NLE's (not just vegas) and it's handled correctly in all versions of vegas (there is no intermediate decoding clipping step, such as with those other "lossless" YUV codecs).
Regarding Vegas, someone posted a link to a page that I have since lost, where different color/levels modes of Vegas have been explained depending on codec and container. What drives me crazy is that at one time I thought that Vegas uses "video" levels by default, then I would drop "video-to-computer" levels to check how it would look when the final render would be watched, then I would turn it off, render with "video" levels, and usually everything worked out ok. But sometimes this does not work, and the "video" levels are not expanded during viewing. I suppose, Vegas uses "video" levels during editing, but sets "full" levels on the rendered file? Ugh. So I usually render a small portion of a video with deep blacks to test how it would look like when uploaded to youtube.
Vegas can still use studio vs. computer RGB levels for different input / output formats (you might have to use computer/studio RGB filter as you've been doing). But in the Magix version, now you can interpret (assign) the video levels to the individual assets (right click clip in the bin) , and you have more choices on the timeline properties pixel format . However, it still can render different output formats to different levels depending on the export format chosen, because it expects certain levels for those formats (hence the use of computer/studio RGB filter) -
Ugh, here we go again. No, I do NOT and I'm actually still surprised what made you think that. All I care about is LOSSLESS. Not compression.. A file could be compressed down to 1 byte file size for all I care and I'd absolutely love it as long as it is lossless in nature...
If you had read #127 carefully enough, then you could have spared yourself enormous effort and time and stopped this post right after you finished paragraph 1.), which is the only of these 3 that I would partly agree with even..
See, now we're getting closer to what I could actually live with and embrace working with...
No-one ever claimed that, myself included.
That's where it's getting interesting, like I said above...Last edited by Marvolo; 26th Jun 2023 at 01:16.
-
This was the exact reason why I dropped MAGIX/Vegas somewhat frustrated and switched to Shotcut. I discovered then that Shotcut didn't handle the chroma of interlaced 4:2:0 sources properly. It produced some color bleeding between fields. I reported this in their Github, provided test files and they kindly fixed the issue. So it works well now since their recent June 2023 release for interlaced huffyuv, UTvideo, ffv1 for interlaced 4:2:2 as well as 4:2:0 IMO.
The color panel in Shotcut shows the RGB parade and one will see any RGB clipping immediately. One will also find that it is not always possible to exploit the full 16......235 luma range in VHS captures, but one may have to re-adjust (normally reduce) brightness, contrast, saturation (levels in general terms) to prevent RGB gamut violations. Buzzword: the inner RGB cube within the YUV color space.
Maybe someone else wants to confirm (hopefully) Shotcut's correct handling of interlaced 4:2:2 and 4:2:0.
As Kdenlive uses the same framework from MLT it should handle interlaced 4:2:0 correctly as well now, but I didn't test it as I am not using it.
Added:
See the RGB clipping in the 'sample_uncompressed.avi' file. It's not dramatic, but it's there:Last edited by Sharc; 26th Jun 2023 at 02:27. Reason: Picture added
-
Exactly what I had in mind as well. I just do not think that ANY form of lossy capture would qualify for master files which you then try to enhance or alter in any digital way imaginable. The foundation that comes BEFORE digital enhancement and restoration cannot be a lossy format in the first place - in my eyes. It needs to be as pristine and close to the original as possible.
And again - this has nothing to do with COMPRESSION. We're solely talking about lossy vs. lossless. Actually, that has always and even been the topic of this thread.. See the thread headline... There's nothing written there about compression. I don't know why @johnmeyer became so fixated on compression. -
I said that several times, to “describe” the HDMI approach.
However, the quality of the A/D conversions easily overcomes the number of them (it is more important!).
The digitization (and the rest of the processing) of the best capture cards is generally better than the Panasonic or similar.
Btw, the external TBC, and extra A/D conversion in classic workflow is not always required. -
-
-
In terms of converting the recorded "uncompressed YUF" files into HuffYuf, VirtualDub offers several options.
First question: is HuffYuf better / worse than Largarith or the other lossless codecs listet there, for example x.265 (lossless) or FFV1? Which of these should I choose?
If I go for HuffYuf, are these options correct? Not RGB but YUV 4:2:2?
[Attachment 72061 - Click to enlarge] -
Looks ok to me, using the ffmpeg Huffy codec.
It reduces the filesize by lossless compression of your raw uncompressed capture, but it doesn't fix any YUV <-> RGB conversion issues.Last edited by Sharc; 26th Jun 2023 at 05:09.
-
You mean, the thing that @Brad mentioned in #157?
I thought we had solved this by turning the AV-in NR off, as @Skiller proposed??
So, you would recommend the Huffy codec? None of the other lossless ones listed there? Wasn't HuffYuf problematic when importing into NLEs which then interpret it as RGB or so I read? -
It may have the same root cause, but I am not sure.
I am talking about valid 8 bit YUV (Y'CbCr) tristimuli which - when converted to RGB for filtering or just for viewing on a monitor - produce out-of-gamut i.e. illegal RGB tristimuli (<0 or >255) which get normally clipped to 255 or 0 (see post#200) and cause color distortions.
In extreme case it may boil down to deciding between a brilliant, high contrast/high saturation picture loosing some details, versus a less "shining" but 'technically correct' picture preserving all details and gradients.
In the picture below only YUV (aka Y'CbCr) tristimuli which are within the inner RGB cube produce valid RGB tristimuli, useful for viewing on a display.
https://www.intel.com/content/www/us/en/docs/ipp/developer-reference/2021-7/color-mode...en?language=en
Uh, I may have opened another can of worms ....
You find a lot about this in posts and tutorials in this and in the doom9 forum from jagabo and poisondeathray et al. Just google.Last edited by Sharc; 26th Jun 2023 at 07:10.
-
...and here a nice demo from Gavino which shows - for a given Y - which U and V (aka Cb,Cr) give valid RGB values (shown for the usual TV or 'limited' range in the attached video).
https://forum.doom9.org/showpost.php?p=1402183&postcount=1Last edited by Sharc; 26th Jun 2023 at 06:56. Reason: Link added
-
Better/worse in what way ?
All the "lossless" compressors have pros/cons in terms of encoding speed, decoding speed, compatibility with various programs, quircks, compression ratio. If you're doing it offline (after capture as a 2nd step), encoding speed is less of an issue (other wise you might drop frames during capture)
Highest compression is usually x264 in lossless mode with temporal compression, or FFV1 with temporal compression (long GOP), but they are the least compatible, most slow to edit (higher compression usually means slower encoding/decoding speed)
Lagarith usually has the highest I-frame compression. UT video or magicyuv usually have the highest encoding/decoding speed , lowest overhead (fast editing, fast performance for capture), but speed is usually not an issue for SD material. HD / UHD it becomes more noticable
x265 is the worst for your case. The lossless compression ratio is somehow always worse than x264, and compatibility lower and decoders gernerally do not support interlace
That screenshot is FFVHUFF, it's a libavcodec/ffmpeg variation on the original Huffyuv . Many capture guys swear on huffyuv 2.1.1 CCESP2 patch version for some reason. It just works for them. It's one of the few that has an interlace flag (but some programs still do not read the flag)
In short, it depends on how you're going to be using it. Beware of mishandling issues with NLE's as discussed above
Similar Threads
-
"code":400,"error":true,"message" on http://getwvkeys.cc
By johnsonkiss in forum Video Streaming DownloadingReplies: 14Last Post: 25th Jul 2024, 21:45 -
{"code": 2048, "message": "Authentication failed"} when getting license
By warmachine in forum Video Streaming DownloadingReplies: 2Last Post: 26th May 2023, 16:34 -
Non linear audio delay in VirtualDub2 after "lossless encoding"
By Hunterh in forum Newbie / General discussionsReplies: 6Last Post: 16th Jan 2022, 07:21 -
"Honestech VHStoDVD Deluxe 8" Shaky video transfer-8mm camcorder cassettes
By Edna Oomen in forum Newbie / General discussionsReplies: 1Last Post: 27th Feb 2021, 14:31 -
"Lossless" NVENC bitrate vs x265
By savvyguy in forum Newbie / General discussionsReplies: 0Last Post: 18th Aug 2018, 22:28