MagicYUV - a new fast lossless video codec

[Ignus2]

Well, as long as the codec gets YUV and outputs YUV and doesn't do conversions to/from RGB, it doesn't matter what YUV Range is selected in the codec, you'll get back the same numbers as you gave the codec, so the codec does no explicit clipping of YUV data (that is done only when converting to/from RGB).

Greets,
I.

[sausuke]

can anyone know how to have thumbnail on windows when recording using magicYUV, it doesn't have thumbnail on raw files thanks

[Ignus2]

can anyone know how to have thumbnail on windows when recording using magicYUV, it doesn't have thumbnail on raw files thanks

Thumbnail in explorer for MagicYUV compressed avi files should just work without doing anything special (apart from having the codec installed).

Greets,
I.

[[SLiM]D12]

So i've capped an avi with MagicYUV -- how does one go about extracting the audio out of the file? I've not found a way to demux the audio out.

thx

[De-M-oN]

Virtualdub

[[SLiM]D12]

Virtualdub

doesn't let me extract the wav, comes out to 0 bytes.

[De-M-oN]

Then your system is broken. It definitely works.

[[SLiM]D12]

Then your system is broken. It definitely works.

kinda hard to believe that. it's a brand new vm with nothing on it really -- and it acts this way on several machines, so nope.

[Sparktank]

Alternatively, you can use ffmpeg:

ffmpeg -i source.avi -map 0:1 -acodec pcm_s24le output.wav

change -map to the actual audio stream (can run it blank in ffmpeg or use ffprobe). and change pcm format if needed (pcm_s16le).

[WorBry]

Bumped by Spartank's post but was going to ask:

Does the source MagicYUV-WAV avi file even play OK, with audio, in VDub?

Are you sure the audio is WAV? What does File Information report?

If yes to both, it's difficult to understand why there would be a problem.

Otherwise, like Spartank said.

[[SLiM]D12]

Alternatively, you can use ffmpeg:

ffmpeg -i source.avi -map 0:1 -acodec pcm_s24le output.wav

change -map to the actual audio stream (can run it blank in ffmpeg or use ffprobe). and change pcm format if needed (pcm_s16le).

thanks this worked!

[Mick]

@WorBry
"Smart Rendering" or "Intelli-Rendering" prevents the NLE to re-compress Audio/Video Material (Streams) if they are in the same (!) Format and Frame Rate.

Example:
Video has NTSC DV (dvsd) as a Codec and Audio is PCM. If you load the Video in the NLE, make the cuts needed and save it again without changing anything else then the NLE makes a "Direct Stream" copy to uphold the quality, just like VirtualDub does in "Direct Stream copy" mode. Every re-compression costs quality and that is where "Smart/Intelli-Rendering" kicks in.

BUT: If you take a Sequence to resize it or to save it with a different Frame Rate, THEN Smart/Intelli-Rendering does NOT work and the NLE re-encodes the whole Material or selected Sequence. In the Parts where Titles or Overlays are added, Color grading and so on, then the same thing happens, the Material gets re-encoded.

If you do NOT Scale or change the Frame Rate and Colors, then ONLY the Parts with Titles and/or Overlays are re-encoded, the rest is untouched with Smart/Intelli-Rendering.

Main thing is, Smart/Intelli-Rendering saves you a heck amount of Time and a 2 hour Movie for example is done is a couple of Minutes. Without Smart/Intelli-Rendering it can take up to Days, depending on your material and complexity.

In a proper NLE/Ingest Setup you use the same Codec for your Previews too. If you load a Video encoded with MagicYUV then select MagicYUV for your Previews too. Why ? Simple: That way you can track errors and is the fastest way to display your Material in a NLE without the need to re-encode the Previews.

You wrote:
"The effective 16-255 luma range is pretty standard for consumer-level digital camcorders and the way it has been since the DV camcorder days."

That's wrong, it's never been 16-255, always 16-235 for Luma and 16-240 for Chroma by definition. 16-255 does not exist, at least as far i know and would not make any sense.

@Ignus2
During my tests with the MagicYUV RC4, Smart/Intelli-Rendering worked absolutely fine if the Source was TFF and encoded with MagicYUV/UtVideo and was exported with MagicYUV/UtVideo. Hate to mention this again but BFF did not work and caused an unusable File with MagicYUV/UtVideo at the end when Smart/Intelli-Rendering was used.

Lagarith and HuffYUV caused no problems with TFF/BFF here and also worked fine with Smart/Intelli-Rendering.

Cheers
Mick

[WorBry]

@WorBry
"Smart Rendering" or "Intelli-Rendering" prevents the NLE to re-compress Audio/Video Material (Streams) if they are in the same (!) Format and Frame Rate.

Example:
Video has NTSC DV (dvsd) as a Codec and Audio is PCM. If you load the Video in the NLE, make the cuts needed and save it again without changing anything else then the NLE makes a "Direct Stream" copy to uphold the quality, just like VirtualDub does in "Direct Stream copy" mode. Every re-compression costs quality and that is where "Smart/Intelli-Rendering" kicks in.

BUT: If you take a Sequence to resize it or to save it with a different Frame Rate, THEN Smart/Intelli-Rendering does NOT work and the NLE re-encodes the whole Material or selected Sequence. In the Parts where Titles or Overlays are added, Color grading and so on, then the same thing happens, the Material gets re-encoded.

If you do NOT Scale or change the Frame Rate and Colors, then ONLY the Parts with Titles and/or Overlays are re-encoded, the rest is untouched with Smart/Intelli-Rendering.

Main thing is, Smart/Intelli-Rendering saves you a heck amount of Time and a 2 hour Movie for example is done is a couple of Minutes. Without Smart/Intelli-Rendering it can take up to Days, depending on your material and complexity.

In a proper NLE/Ingest Setup you use the same Codec for your Previews too. If you load a Video encoded with MagicYUV then select MagicYUV for your Previews too. Why ? Simple: That way you can track errors and is the fastest way to display your Material in a NLE without the need to re-encode the Previews.

Yes, that's what I do and why I do it.

You wrote:
"The effective 16-255 luma range is pretty standard for consumer-level digital camcorders and the way it has been since the DV camcorder days."

That's wrong, it's never been 16-255, always 16-235 for Luma and 16-240 for Chroma by definition. 16-255 does not exist, at least as far i know and would not make any sense.

Please don't ask me to defend that statement as the discussion would go on forever. A cursory web search along the lines of "YV12 16-255 luma scale" would reveal that the 16-255 species does indeed exist and has been a subject of discussion for at least the last 10 years up to present....not least in the context of NLE's and their respective tendencies to interpret and treat the luma levels correctly or incorrectly.

A popular opinion is that camcorder engineers, from all of the major companies, exploited allowances in the Rec.601 and then Rec.709 standards for 8-bit encoding in the 236-254 range to accommodate filter overshoot, transient signals and specular highlights, and used this as a way of gaining a little extra dynamic range and headroom for grading. To what extent that's true or simply that full scale YV12 decoding reveals these "super-white" excursions, I'm not sure.

I do not own a DSLR myself, but, from what I understand on some cameras that record HD video there is even a option to select 16-255 scaling.

@Ignus2
During my tests with the MagicYUV RC4, Smart/Intelli-Rendering worked absolutely fine if the Source was TFF and encoded with MagicYUV/UtVideo and was exported with MagicYUV/UtVideo. Hate to mention this again but BFF did not work and caused an unusable File with MagicYUV/UtVideo at the end when Smart/Intelli-Rendering was used.

Lagarith and HuffYUV caused no problems with TFF/BFF here and also worked fine with Smart/Intelli-Rendering.


What NLE was this with, out of interest?

[Mick]

@WorBry
About Smart/Intelli-Rendering: I don't want to live without it anymore, a real time-saver :)

About YV12 16-255: To be honest, this is new to me and never heard anything about that. Do you have any References (Links) about that ? I certainly did not try to make you look "stupid" here and i apologize if it came over like that.

About my NLE: I use a Cinegy Ingest System on my Workstation and Aist/Cinegy MoviePack Pro and Serif MoviePlus on my Laptop. Occasionally i also use Ulead Media Studio. For the problematic Stuff i use VirtualDub and AviSynth when i can't import Material properly.

Cheers
Mick

[WorBry]

@WorBry
About YV12 16-255: To be honest, this is new to me and never heard anything about that. Do you have any References (Links) about that ? I certainly did not try to make you look "stupid" here and i apologize if it came over like that.

No problem, my self esteem is still intact....just ;)

As for references - well I don't have any definitive reference on file if that's what you mean. But, as I said, a cursory web search would pull up a plethora of forum posts where this has been the topic of discussion, or comes up in the course of. Just a few examples picked at random:

http://forum.videohelp.com/threads/293041-Any-harm-in-using-ConvertToRGB24%28%29-by-default?p=1790620&viewfull=1#post1790620http://

http://forum.doom9.org/showthread.php?t=88512

http://forum.doom9.org/showthread.php?t=165003

http://forum.videohelp.com/threads/296018-DVD-to-DVD-YV12-to-RGB-to-YV12-color-problem?p=1808200&viewfull=1#post1808200

http://forum.doom9.org/showthread.php?p=1540659#post1540659


About my NLE: I use a Cinegy Ingest System on my Workstation and Aist/Cinegy MoviePack Pro and Serif MoviePlus on my Laptop. Occasionally i also use Ulead Media Studio. For the problematic Stuff i use VirtualDub and AviSynth when i can't import Material properly.


I'm not familiar with the first three. Cinegy is broadcast level software right? Ulead Media Studio is what Video Studio Pro was before Corel took it over, a good few years back. Still uses the same old Ulead H264 encoder -one of the reasons why I prefer to do my encoding outside of VSPro with x264.

So, which is the NLE that you tested with MagicYUV and Smart/Intelli Rendering ?

[WorBry]

Pending your reply:


During my tests with the MagicYUV RC4, Smart/Intelli-Rendering worked absolutely fine if the Source was TFF and encoded with MagicYUV/UtVideo and was exported with MagicYUV/UtVideo. Hate to mention this again but BFF did not work and caused an unusable File with MagicYUV/UtVideo at the end when Smart/Intelli-Rendering was used.

I don't normally shoot 60i AVCHD on my Canon HF-G10, but I've just tested this myself with VideoStudio Pro x8 and found that 'smart rendering' does not work at all with 60i MagicYUV or UTVideo YV12 transcodes, only progressive.

I wondered if the reason for this is that the 'smart rendering' process expects BFF, as it would for DV. So I prepared a MagicYUV YV12 transcode from a test 60i MTS clip with the field order changed from TFF to BFF (using the AVISynth Reverse Field Dominance plugin). Loaded that into VSPro x8, re-configured the Project profile settings (for MagicYUV ) to Field Type: Lower Field First. Then split the clip on the timeline to apply an effect (Rotate 180o) to one of the segments and rendered out to MagicYUV as per the Project settings, with Smart Rendering applied.

The rendered avi file emerged with the BFF field order preserved and was perfectly usable except that (as in the first TFF 60i test ) the original 16-255 luma range was clipped to 16-235, indicating that the entire clip had been re-encoded and not 'smart rendered'.

Repeated the test using UTVideo, in like manner, with the same result.

So it's interesting you say that 'smart rendering' worked in your tests using MagicYUV and UTVideo encodes of TFF interlaced sources - and also that:

Lagarith and HuffYUV caused no problems with TFF/BFF here and also worked fine with Smart/Intelli-Rendering.


I suppose I could go on to test that myself but I wouldn't be that interested in using Lagarith or HuffYuv in any case.

Which HuffYuv was that by the way - I'm assuming the FFDShow (ffmpeg) variant in YV12 mode ? And again, in what NLE did you do your tests ?

[Mick]

@WorBry
"Smart Rendering" is used with Ulead Software (now Corel) and "Intelli-Rendering" with Aist/Cinegy Software. And yes, Cinegy is the Broadcast Level Software, including a NLE and Transfer Modules. Aist MoviePack Pro is the NLE Variant of the Cinegy Software.

I still use the Ulead Media Studio 6 on my Laptop, not a Corel Version. As long as TFF was used, MagicYUV and UtVideo worked and caused Problems with BFF when Smart/Intelli-Rendering was used. HuffYUV (CCESP Patch 0.2.5) and Lagarith caused no Problems with TFF or BFF.

Progressive Content is never a Problem using Smart/Intelli-Rendering and with MagicYUV/UtVideo only BFF caused the Problems while TFF worked fine. Many of my Colleagues in Mastering Labs and Studios monitored the same behavior and Problems.

With the Aist/Cinegy Software i can exchange the Render Engines (Direct3D, OpenGL, OpenCL, ProPro, Intel M3 and M4) for Intelli-Rendering and MagicYUV/UtVideo caused Problems with all the Engines (BFF) while HuffYUV/Lagarith worked fine (TFF/BFF).

About YV12 16-255:
I also found some Links and find it rather curious, really, because to me it makes no Sense, but that is another Story. Thank you anyway for the Links and you're right, we should leave this out in this Thread, okay ?

About your 60i Material:
Well, it looks like Smart Rendering did not work if the Clips have 16-235 after the Export instead of 16-255 and is rather strange. How long was the Time to Export the Video ? If it was just a couple of minutes then it might be that MagicYUV clipped the 255 itself to 235. At this point I have no Clue about the behavior of UtVideo you monitored. Did you encode your Material with your NLE or another Tool like VirtualDub to MagicYUV/UtVideo ?

You are on a new Windows Version like 7/8/10 ? If so, then seek the Net for "dxcpl.exe" from Microsoft. It's a little Tool from Microsoft to re-activate the Hardware Acceleration for your Audio/Video Hardware. God only knows why Microsoft deactivated the Hardware Acceleration and the Options from DirectX and the Chances are good that Smart-Rendering then will work properly.

BE CAREFUL: You might find some Registry Hacks to re-activate the Hardware Acceleration in Windows. DO NOT USE THESE HACKS ! The Tool from Microsoft works reliably while the Registry Stuff can really screw up your System, okay ?

The Tool is also included in the "DXSDK_Jun2010" Package from Microsoft. You also find the Tool on certain DVD's of Windows.

Here is a Link: (in German)
http://www.3dcenter.org/download/directx-control-panel

Useful Information about the Tool: (in German)
http://www.wintotal.de/tipparchiv/?id=1804

Microsoft Link:
http://www.microsoft.com/en-us/download/details.aspx?id=6812

Cheers
Mick

[WorBry]

"Smart Rendering" is used with Ulead Software (now Corel)...
I still use the Ulead Media Studio 6 on my Laptop, not a Corel Version.

Wow..Ulead Media Studio 6 was one of the early versions from way back in 2002. Does HD material even run on it? You must surely be editing SD ?

Things have come a long way since then, not least in performance - hardware acceleration and MT support. Corel VideoStudio Pro x7, released in 2013, introduced full 64-bit support and the latest version x8.5 brought further performance boosts, making editing HD with MagicYUV just like DV in the old days. And that's all running on multi-core CPU clout; I only have an MB-integrated Radeon HD3000 graphics unit.


About YV12 16-255:
I also found some Links and find it rather curious, really, because to me it makes no Sense, but that is another Story. Thank you anyway for the Links and you're right, we should leave this out in this Thread, okay ?

Okay.

...it might be that MagicYUV clipped the 255 itself to 235.

Well yes, although its not "clipping" per se- for those frames that are re-encoded MagicYUV is simply taking the 0-255 RGB output and applying Rec709 conversion to yield YV12 with a 16-235 luma range. Whereas those 'smart rendered' frames that are 'passed through' retain the original 16-255 luma. Simple as that. That's why I mentioned above that I do not select the 'Full YUV Range' option in MagicYUV, as then the luma of the re-encoded frames is expanded to 0-255 i.e. with the black point shifted from 16 to 0, making the image darker and I don't want that.

... Did you encode your Material with your NLE or another Tool like VirtualDub to MagicYUV/UtVideo ?

As per my workflow that I outlined above:


....To prepare AVCHD (1080/30PsF) mts clips from my camcorder for editing, I transcode to MagicYUV (with WAV audio) using DGIndexIM and AVISynth via VDub (32-bit).



...
You are on a new Windows Version like 7/8/10 ? If so, then seek the Net for "dxcpl.exe" from Microsoft. It's a little Tool from Microsoft to re-activate the Hardware Acceleration for your Audio/Video Hardware. God only knows why Microsoft deactivated the Hardware Acceleration and the Options from DirectX and the Chances are good that Smart-Rendering then will work properly


Thanks for the info, but I'm really not inclined to meddle with what, for me, "ain't broken". I'm not that interested in smart-rendering of interlaced material or figuring out why it didn't work in this case, as I rarely, if ever shoot interlaced these days.

Cheers.

[Mick]

@WorBry
Ulead Media Studio 6 goes up to 800x600 and I mainly use it for SD Material and Ulead can not deal with HD content. Aist MoviePack Pro goes up to 4K, just like the Cinegy Ingest System. Ulead, Aist and Cinegy use Multi-Processor, Intel IPL, IPP and LeadTools Library's. I use Ulead Media Studio and Aist MoviePack Pro on my Laptop for my own Films when I am abroad to edit, view or to prepare my recordings. For my Clients I use the Cinegy Ingest System.

I specialized myself for VHS/S-VHS Tape Transfers for TV Stations and Film Studios from around the World. I have to deal with many different formats all the time, that's why I had problems with MagicYUV and UtVideo when Clients wanted NTSC with BFF just like the original Content of the Tapes.

The current Format "Hit-List" looks like this:
Uncompressed 4:2:2 16 Bit (YUY2) (Drastic)
JPEG-2000 (MainConcept)
Motion-JPEG (MainConcept)
DV50 (MainConcept)
HuffYUV (YUY2)
HDV MPEG-2 (HonesTech)
DVSD (MainConcept)

Audio is always 48.000 Hz, Stereo/Dual Mono, 16 Bits PCM. The Video Container is either AVI (OpenDML) or QuickTime MOV, both Interlaced.

These are the most demanded Formats of my Clients when I send the Material back to them along with the Tapes after I transferred them. Many Clients tried MagicYUV and UtVideo upon my request but rejected them and wanted HuffYUV back instead. Only a few Clients ask for Lagarith instead of HuffYUV and I can count them on one Hand.

Don't get me wrong, MagicYUV and UtVideo are great codecs but still have some Problems and I am sure they will be solved one day by the Authors. I am not trying to make these codecs look "bad", not at all, they have great potential. At the Moment they just can't make it in the professional Field and need further development, that's all.

Once all the little Bugs are solved, both could replace DNxHD, ProRes or HQX easily one Day. None of my Clients ever wanted DNxHD, ProRes or HQX, not even H264/AVC1 in a MP4 Container. It's funny and makes me wonder if these codecs are really the "Cream of the Crop" as many others claim.

My Goal and the demand of my Clients is to uphold the Quality as much as possible. That's why I use YUY2 in 80 percent of the cases and compress at the very end when everything is done, Grading, Edit, Intro, Outro, Time-codes, Subtitles, Master File and so on, not before.

About Smart/Intelli-Rendering: I forgot the Cinegy MX Renderer, also did not work with MagicYUV/UtVideo in BFF Mode.

About new Systems: Sure, the Systems got faster but better ? Well, that is another Story that we don't dig deeper here into this Sphere, okay ?

About Hardware Acceleration: If it works fine for you being deactivated then don't fiddle with it. God only knows why Microsoft deactivated this great Feature by default. ;)

Cheers
Mick

[WorBry]

Out of curiosity I've run some tests with HuffYUV.

A few years back, before MagicYUV came along, I did some tests with the FFDShow (ffmeg) variant of HuffYuV (in YV12) and it didn't smart render in VideoStudio Pro. Now, with a 64-bit system, the VFW component of 64bit FFDShow (Official and CLSID build) doesn't even show up in the list of available VFW codecs in the VSPro project settings. Why, I'm not that bothered to find out. So that's a non-starter.

Tried instead using the 64-bit version of 'classic' HuffYUV (v2.1.1). Encoded a HuffYUV YUY2 input file and set-up HuffYUV as the Project video format, with default settings. Predictably, the rendered file (with or without Smart Rendering selected) came out RGB. Tried setting the RGB compression option to "Convert to YUY2" and VSPro would have none of it and rendered a corrupt, unplayable file.

So based on that, should I assert that HuffYUV is not fit for professional use and is need of further development simply because it did not behave the way I wanted it to in the particular system I use? Of course not.

I don't know about your Cinegy set-up, but "Smart-Rendering" in VSPro was designed to work with DV. The fact that it works at all with some AVI codecs is fortunate. Cineform doesn't smart-render at all in the VFW environment, so does that mean it's also unfit for professional use? Hardly.

Get my point? It's "horses for courses". I really don't understand what you hope to achieve with these statements, or, more to the point, are expecting from MagicYUV. The fact that it happens to be smart-renderable in one set of circumstances and not another is neither here nor there, and has absolutely no bearing on it's quality and value as a lossless vfw codec. Same goes for any third-party codec.

If 'smart rendering' is so important to you, yet problematic, why not edit in DV - you might find even DV50 works also, as I recall it did when I tested it way back.

nuff said?

Here - I've just been running a trial of Sony Movie Studio 13 Platinum. These are the formats that it smart renders:

http://postimg.org/image/fzph5fak9/

Tried MagicYUV and UTVideo in YV12 mode (input and output) and they definitely don't 'smart render'. Unlike Corel VideoStudio Pro, there's no provision to use third party codecs as the Project video medium, so that's not surprising. But get this - if I configure MagicYUV or UTVideo (YV12) as the output format (in place of default Sony YUV), in both cases the luma gets clipped, not to 16-235, but to 32-235; not good. But, if I instead select the "Full YUV Range" option in MagicYUV, lo and behold, the source 16-255 luma range is re-instated. Magic, huh? So for me, in that system, MagicYUV would be a viable option.

Serves to emphasize the point - different system, different behavior and find the one that works for you.

[Mick]

@WorBry
About Smart Rendering: Ulead and Aist/Cinegy work fine with HuffYUV (CCESP patch 0.2.5) and Lagarith. Right, DV was "the" Format those Days but Smart Rendering is not specially designed for the DV Format. The main thing is that the Input and Output Settings are the same, means Resolution, Field Order and Frame Rate. Changing one of those disables Smart Rendering already.

You seem to misunderstand me, Smart/Intelli-Rendering is no problem on my Systems and is not bound to a specific Codec. MagicYUV and UtVideo just did not work for me if the Field Order is BFF instead of TFF, that's all.

You wrote:
"Serves to emphasize the point - different system, different behavior and find the one that works for you."

That's right and is true. It certainly took me a long time to find my Setup that is stable, fast and reliable. Wouldn't it be great if you could by Hardware and Software that causes no Problems ? ;) As you said... "Different System, different behavior" :)

Cheers
Mick

[WorBry]

About Smart Rendering: Ulead and Aist/Cinegy work fine with HuffYUV (CCESP patch 0.2.5) and Lagarith. Right, DV was "the" Format those Days but Smart Rendering is not specially designed for the DV Format. The main thing is that the Input and Output Settings are the same, means Resolution, Field Order and Frame Rate. Changing one of those disables Smart Rendering already.

Oh boy, this is going round in circles. I was specifically referring to VideoStudio Pro where in order to set-up a project with a third party avi codec, one has to go into a DV profile preset and set-up a custom profile. Once the codec has been selected (from the drop down list of installed codecs) one can then change the Resolution, Field Order and Frame Rate accordingly, in as far as those parameters are permitted by the codec in question. Like so:

http://postimg.org/image/veoyrx4xl/

http://postimg.org/image/h9j5q3vw9/

And then render out as per the Project settings with Smart Rendering:

http://postimg.org/image/ueynw7prt/

None of the other video format presets allow that (the Project configuration, that is).

You seem to misunderstand me, Smart/Intelli-Rendering is no problem on my Systems and is not bound to a specific Codec. MagicYUV and UtVideo just did not work for me if the Field Order is BFF instead of TFF, that's all.

So why even bring it up if BFF interlace editing is not important to you? And if it is, your second statement negates the first.

Wouldn't it be great if you could by Hardware and Software that causes no Problems ? ;)

Depends what you want to do and how much you are prepared to pay. For budget-constrained persons such as I, the choices are limited.

And whilst I'm posting images, this is what the mysterious 16-255 the luma range looks like:

http://postimg.org/image/wxkcwwbi1/

OK, enough now. :o

[[SLiM]D12]

Hi,

Trying to cap with AmaRecTV and i'm getting "Can not support colorspace by video codec"

The only format that lets me see my card in Amarec is

1920x1080 @59.94 fps fcc=r210, bit=30

Any ideas or advice as to how i can cap this with MagicYUV?

thx in advance!

[kolak]

Your card pipes only r210?
This is good: 10bit 444, but not many losses codecs supports it.
MagicYUV does but not in free version.

[[SLiM]D12]

Your card pipes only r210?
This is good: 10bit 444, but not many losses codecs supports it.
MagicYUV does but not in free version.

Ahh and how do you get the paid version? What amount of donation gets you the paid version?

[WorBry]

D12;1753455']Ahh and how do you get the paid version? What amount of donation gets you the paid version?

LOL Good question.

[kolak]

http://magicyuv.com/index.php/contact

ask here.

[kolak]

D12;1753455']Ahh and how do you get the paid version? What amount of donation gets you the paid version?

If you are using Decklink card than switch it to YUV 8bit pixel format.

[De-M-oN]

There is a problem with the auto detection of input with the TMPGEnc 6 NLE.

It always detects 4:2:0 from TMPGEnc and so it is encoded in this color subsampling by MagicYUV, while if I choose UTVideo RGB or any other codec which lets me choose RGB directly, it encodes to RGB and the output video has RGB quality.

[[SLiM]D12]

If you are using Decklink card than switch it to YUV 8bit pixel format.



If I do this, the colors become all washed out. 10 bit has proper color.

[kolak]

It means data is not properly converted from RGB range to YUV range. You should also have 8bit RGB based pixel format, no?

[Ignus2]

D12;1753455']Ahh and how do you get the paid version? What amount of donation gets you the paid version?

None of the released versions have 10-bit encoding. Application support for 10bit+ compressed formats through the general codec interfaces is very weak, a few apps work with it and even there you have to be very careful. It would create too much confusion and give false impressions, that's the main reason it's not included.
Regarding donations, everything is explained on the codec website and the gumroad page.

Greets,
I.

[Ignus2]

There is a problem with the auto detection of input with the TMPGEnc 6 NLE.

It always detects 4:2:0 from TMPGEnc and so it is encoded in this color subsampling by MagicYUV, while if I choose UTVideo RGB or any other codec which lets me choose RGB directly, it encodes to RGB and the output video has RGB quality.

Could you explain your setup here (what kind of input do you encode)?
You can force the codec to RGB by selecting RGB as "Accepted colorspace" in the config dialog. That will restrict the codec to accept RGB only.

Greets,
I.

[[SLiM]D12]

It means data is not properly converted from RGB range to YUV range. You should also have 8bit RGB based pixel format, no?

I think, but i'm not sure how i can force that in Amarectv -- i only get video appear when i set it as i stated above, and i get that error -- maybe i'm doing something wrong?

[kolak]

Set it in the BM directshow filter- you should have access to it in Amarectv. There should be a list of pixel formats to choose from.

[kolak]

None of the released versions have 10-bit encoding. Application support for 10bit+ compressed formats through the general codec interfaces is very weak, a few apps work with it and even there you have to be very careful. It would create too much confusion and give false impressions, that's the main reason it's not included.
Regarding donations, everything is explained on the codec website and the gumroad page.

Greets,
I.

He is using BlackMagic card which sends r210 pixel format, so this wold work well with MagicYUV as it has native support for this format. I've tested it and it was working well when connected to BM directshow filter.

[[SLiM]D12]

Set it in the BM directshow filter- you should have access to it in Amarectv. There should be a list of pixel formats to choose from.

Hrm i'll have to check it out -- i think you mean under "Device Setting" option, but i tried to change that to different settings and none of em worked, i always got the same error about wrong colorspace.

[[SLiM]D12]

He is using BlackMagic card which sends r210 pixel format, so this wold work well with MagicYUV as it has native support for this format. I've tested it and it was working well when connected to BM directshow filter.

Hi,

I've still not been able to figure this out -- any insight or help you can provide would be appreciated.

Thanks,

[djonline]

I still not have MagicYUV in Premiere cc 2015 ->Sequence Settings -> Video Preview -> Codec.

[Ignus2]

I still not have MagicYUV in Premiere cc 2015 ->Sequence Settings -> Video Preview -> Codec.

I'm in the dark here, as I don't have Premiere. Maybe it has a cache and refuses to search for new codecs? Maybe these links can be of some help:
https://forums.adobe.com/message/4595051
https://helpx.adobe.com/premiere-pro/kb/features-presets-missing-premiere-pro.html
Though I doubt this is the problem, but might worth browsing through those posts...

Greets,
I.

[Ghostlamer]

Ignus2, MagicYUV sometimes crash Adobe Premiere Pro CC 2015, premiere crash occurs when magicyuv.dll_unloaded (in windows events).
For example, while sony vegas keeps magicyuv.dll always loaded, Adobe Premiere Pro periodically load (when i play video at timeline)/unload (when playback is stopped) magicyuv.dll.

[wiak]

i find this codec to be twice as fast as lagarith on my 4-core amd laptop
thats the good thing, but the bad thing is that it would been nice if there was a open source decoder* that can be compiled into ffmpeg
currently i dont think this codec will be useful for archiving, what will happend down the line when the homepage is gone? and we cant download the decoder?

please release a open source decoder on github etc

[[SLiM]D12]

So today i've got a weird problem. On a machine that i cap on, i'm getting severe banding, but if i move to another machine, there is no banding at all. My avs only has avisource and the spline36resize command -- so i'm looking for guidance as to what could be the reason for banding on one pc and no banding on the other?

http://puu.sh/nb9yw/867bc04d02.jpg

http://puu.sh/nb9zf/817105e63d.jpg


Edit: I just tried this on a couple more pc's -- installed the Magic codec and no banding there -- so not sure what's going on my capping/encoding box -- hopefully somebody can point me in the right direction-- thx!


I got it sorted -- seems my rdp session to this remote pc wasn't set to 32bit -- oops.

[Ignus2]

Ignus2, MagicYUV sometimes crash Adobe Premiere Pro CC 2015, premiere crash occurs when magicyuv.dll_unloaded (in windows events).
For example, while sony vegas keeps magicyuv.dll always loaded, Adobe Premiere Pro periodically load (when i play video at timeline)/unload (when playback is stopped) magicyuv.dll.

Which version of the codec?

Greets,
I.

[Ignus2]

please release a open source decoder on github etc

There are plans about this, but I am currently swamped with other work. But unless a bus hits me till that time, the format will be released at some point :)

Greets,
I.

[Ghostlamer]

Which version of the codec?
Latest - 1.2.

[Ignus2]

Latest - 1.2.

There was a bug in the 1.1 release that specifically occured when the codec DLL was unloaded and then reloaded, but it should have been fixed in 1.2.
As I don't have Premiere I don't know when/if I'll be able to debug it.
In any case if you can provide steps to reproduce that would be helpful.

Greets,
I.

[[SLiM]D12]

very excited for the 10-bit encoding for this codec -- i've emailed for the private release, is there any other process or do i just wait? PM here perhaps? i wasn't 100% sure.

thx!!

[ChiDragon]

I've finally paid for this fantastic piece of software! After freeloading for 2 years. ;)

A couple feature suggestions, since the Gumroad page asks for them and the text box there looks small. Plus I didn't think of the first one until now. :o

Add Auto mode selection for YUV color matrix setting, based on SD vs HD resolution (picture height) of input. Or keep the existing dropdown as it is, and add a checkbox to override that selection with Auto when the input exactly matches a standard: [720|640]x480, [720|768]x576, 1280x720, 1920x1080, 3840x2160, 7680x4320. I frequently switch between doing SD/ED and HD captures using the same capture device, so I have to go into the Compression menu merely to toggle this option.
Tossing in my support for the previous "open source decoder" desires echoed by several people. If you take a look at forum discussions of lossless codecs, people tend to frown upon MagicYUV due to its lack of FOSS decoding.

[Ignus2]

Thanks for your support! :)
1. Auto mode for YUV matrix makes sense. Can you give an exact list when it should be SD?
2. Yes, it is on my list. My only problem right now is time, I am simply too overwhelmed with various work right now, which I hope will consolidate on a more manageable level in the near future.

Greets,
I.