These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

My EVE

 
  • Topic is locked indefinitely.
Previous page12
 

Editing advice
Author
Previous Topic Next Topic
Daneel Trevize
Give my 11percent back
#21 - 2013-03-15 00:30:00 UTC  |  Edited by: Daneel Trevize
Yes, H.264 specifies it, and x264 implements it.
Quote:
High 10 Profile (Hi10P)
Going beyond typical mainstream consumer product capabilities, this profile builds on top of the High Profile, adding support for up to 10 bits per sample of decoded picture precision.
High 4:2:2 Profile (Hi422P)
Primarily targeting professional applications that use interlaced video, this profile builds on top of the High 10 Profile, adding support for the 4:2:2 chroma subsampling format while using up to 10 bits per sample of decoded picture precision.
High 4:4:4 Predictive Profile (Hi444PP)
This profile builds on top of the High 4:2:2 Profile, supporting up to 4:4:4 chroma sampling, up to 14 bits per sample, and additionally supporting efficient lossless region coding and the coding of each picture as three separate color planes.
See the 'x264' column, 'Extended chroma formats' row in the previously linked 'AVC software implementations' table. Smile
http://en.wikipedia.org/wiki/X264#x264_frontends
Hoarr
Caldari Provisions
Caldari State
#22 - 2013-03-15 02:20:43 UTC
I'm not arguing that it CAN be done, it's just that I haven't found a program that has either of those profiles and will use them to encode video. If you can find one that does, that would be awesome.
Daneel Trevize
Give my 11percent back
#23 - 2013-03-15 11:20:37 UTC  |  Edited by: Daneel Trevize
Well, on reading around, anything using x264 can take several arguments to invoke that encoding.
Either --profile high444 and/or --output-csp i444
http://mewiki.project357.com/wiki/X264_Settings#output-csp
Though I note from the profile portion of that page
Quote:
If you set this option, you cannot use lossless encoding (--qp 0 or --crf 0).
I leave it for you to read more of these details & combinations.

Googling for VLC in particular, I see the in-development 2.1 branch news has the note
Quote:
Changes between 2.0.x and 2.1.0-git:
Encoders:
* high10, high422 and high444 encoding support in h264
So, MediaCoder, MeGUI, Handbrake, etc might have support already, VLC specifically is about to get it, and the backend/upstream x264 library has had it for years.

Also, discussions of 10bit & 4:4:4 seem to also raise the point that not all decoders can cope, and also there's notable processing overhead in doing so, meaning some people's media clients might struggle/be unable to view your lovely high quality files.

That and H265 is on the horizon. Lol
Daneel Trevize
Give my 11percent back
#24 - 2013-03-15 11:32:07 UTC
P.S. Found this explaination vid for anyone caring about w.t.f. 4:2:2 4:4:4 etc are on about.

http://www.youtube.com/watch?v=7JYZDnenaGc
Kyra Quinn
Garoun Investment Bank
Gallente Federation
#25 - 2013-03-15 15:30:26 UTC
That even made sense to me even though most of the rest of the discussion is a bit beyond my realm of understanding. How does that "translate" to the practical situation of choosing programs, codecs or settings?
Daneel Trevize
Give my 11percent back
#26 - 2013-03-15 16:24:37 UTC
I guess mostly, once you have tools with the options, it lets you understand the tradeoffs being made in encoding resource requirements (usually CPU time when 'rendering'), and resulting file size/bitrate differences, as well as induced kinds of compression artifacts.
If you see chroma drift from a several stage production process, or the comb kind of motion artifacts described on the wiki page, you now know a way to try target & correct them, or the specific part of the tool's implementation that you might want to google for known bugs (unless you're dealing with a greyscale clip Blink).
Hoarr
Caldari Provisions
Caldari State
#27 - 2013-03-15 16:51:52 UTC
All that stuff is awesome and all, but have you found a way to actually DO it? I'm genuinely interested cause that would be awesome to play around with.

Confirm that h265 is going to be awesome.
Daneel Trevize
Give my 11percent back
#28 - 2013-03-15 17:23:16 UTC
Honestly IDK that I have some source material that's 10bit & of sufficient colour complexity to make using that High444 profile useful. But if I did, I'd just use those arguments/options in whichever app. So for VLC I'd put them in the transcode section of something like that bat file I use (and source from a file, not :Screen). Or find it in the GUI, probably under some advanced convert/save profile settings. VLC isn't suited to this task, I just benefit from the fact it can do it, and rather trivially via scripts rather than having to click through GUIs every time, if even just to select custom profiles/combos of such options. Similarly editing via Avidemux can be scripted in various languages, and this can often let you get complex in the choice of encoding options, without handy screenshots to find online & link for you, instead only command line listings.

Maybe I'll poke with it later, but unless you can point me to some sample media that demonstrates the difference in chosen profile at the quality level, and/or an easy-to-use&free media comparison tool, the best evidence I can expect to produce is a successful file with media info stating it's 4:4:4 and no obvious quality problems. And that's probably after I get the VLC 2.1 dev branch, or another tool like Handbrake.

Handbrake seems to have the following command line option
Quote:
--x264-profile When using x264, ensures compliance with the string specified h.264 profile:
baseline/main/high/high10/high422/high444
Quote:
--x264-profile: tell x264 to conform to the specified H.264 profile (options: baseline, main, high, high10, high422, high444; default: high). Only works with the x264 encoder. Applies after --x264-preset, --x264-tune and --encopts; overrides them all.
So I have faith that in 2013, these x264 apps can do it, and if you're using one already, you can find the advanced menu option, or put in the profile name to some options field, or edit your batch/script file. Smile

**** this forum, it also can't detect what's HTML or just XML or just use of angular brackets in text, and it ate half my post.
Daneel Trevize
Give my 11percent back
#29 - 2013-03-15 17:43:40 UTC  |  Edited by: Daneel Trevize
TL;DR: See Edit2 near the end of this post.

Re-reading this thread, I think you want to reconsider your use of VirtualDub to transcode from the FRAPS format to one that you edit with. I couldn't find much in a quick google to imply that VirtualDub can actually support High444, so if it's losing quality in that part, it's not going to help you if/when your editing suite tries to output to the same target. Assuming your suit also supports 4:4:4. -Actually I was confusing things here, VirtualDub can probably do it if the chosen codec within can do it-.

If you were to use MeGUI, I think you'd have the option to meet the high444 profile specs, and deal with any FRAPS -> whatever colour space translation (which you said depends the user's choice of FRAPS recording compression). The only problem in demonstrating how to do this is, again, people like to script these transcoding tools rather than screenshot themselves clicking through GUIs it would seem.

Perhaps see another FHC thread by Suleiman Shouaa about his method of using MeGUI to both transcode and edit his Eve fight segments into a video all via script.

Also, I take it you've read up on your favoured Lagarith codec to check it is able to pass your recorded footage through at the 4:4:4/lossless quality you seek?
AKA where exactly in your production chain are you struggling to enable High444?

It seems Lagarith as a 'codec' is as much the implementation in binary form as it is a spec for others to code to, and is something to drop into/enable for Windows apps that use VideoForWindows framework. VfW as a technolofgy seems to have some major depreciation concerns, as well as cross platform issues, and so people seem to be suggesting other, newer codecs too.

Edit: reading that thread, it seems you might want to add the VfW implementations of other lossless codecs to your system/suites. That seems to be how to support such quality options. -Removed a line about formats, All these codecs are working to the same MPEG feature specs, it's quite how well they implement them that's the difference in formats&code.-

Edit2: Thinking it through a bit more, Lagarith seems to be another FOSS rival implementation of (HD) video encoding-decoding software (codecs), supporting much of the same MPEG standards. VfW, DirectShow, MediaFoundation are all Windows-specific ways of adding these rival implementations to your system & editing apps. The x264 project also has derived works to put in these mechanisms, but is also used more directly in the coding/creation of media apps like MyGUI, Handbrake, VLC.
It's your choice of which app/library/codec that will dictate which feature sets you have supported in your tools, which lossless compression specs are fully implemented.

For those interested, if you know anything about entropy & things like Huffman encoding, the Lagarith page rather simply explains how it was derived from Huffyuv and what it is/was doing to be better.

I simply assume that all the rival FOSS codecs are trying/now capable of matching its colour support, so that when you specify high444 profile in x264, you don't tradeoff some conversion issue w.r.t. colours sourced from FRAP's output.

With all that said, I think we're back to: where are you having trouble telling your chosen codec (within your chosen editing suite/apps) to use "High 4:4:4 Predictive Profile (Hi444PP)" or however they name it.
Hoarr
Caldari Provisions
Caldari State
#30 - 2013-03-15 22:33:44 UTC  |  Edited by: Hoarr
I think that we've gone fairly far off topic, Daneel. While I am certainly interested in continuing this conversation in private (especially about the handbrake stuff that you've found), I think that most people are really looking for more practical advice here. With that in mind, I want to break some of what we've talked about down for people.


When encoding EVE videos, there are really two problems that people will be running into that most other people who make videos will not run in to.

1) Standard Chroma subsampling.

You've seen Daneel and I talk fairly in depth about chroma subsampling (4:4:4, 4:2:2, 4:2:0) in this thread. The reason why it is important specifically for EVE videos is that severe chroma subsampling really only has a large impact when you are dealing with drastic color changes in a very short range of pixels. Because of the way that EVE is structured, that pretty much explains all of what you see in game. Eve does not have a lot of shading like you would see in real life with gradual changes in color from one area to another.
Here is a perfect example of the problems brought on by subsampling:

Without Subsampling: http://i.imgur.com/C4Kh6S4.png
With Subsampling: http://i.imgur.com/7IGwQfO.png

Pay more attention to the blurriness and difficulty of reading the images more than the change in color. We'll get to that in a second. This change in quality especially shows up in the reds and blues when using subsampling. Which I don't need to tell you, can make up a **** load of the information that you use in EVE videos.

2) Going from Computer Colors to Broadcast Colors.

Because of the way that TVs have developed and therefore the standards for them, TVs and broadcasters will only support color ranges from 16-235. Computers, however will support ranges from 0-255. You might say, "well, how much data can you really hold in those ranges anyhow??" Here is a really crudely thrown together palate showing the difference between 255 and safe broadcast colors: http://i.imgur.com/XlDIegs.png That is where the second problem comes in. EVE uses a lot of these "Illegal" colors during gameplay because they are really vibrant and eye catching, etc. Think about what your modules look like, especially when overheating. Because of the way that they have been developed, most (or all) of the codecs that you will see have been developed with these broadcast standards in mind, and therefore use the broadcast color space. This is kind of a pain in the ass for people using computers the entire way through the process from initial capture to final viewing (which is an admitedly HILARIOUSLY small percentage of the population).

That is the reason why Daneel and I got so into this discussion and why it would be really nice to find a codec that will play nice with a computer color space. However, almost all of the standards that have been created are created with television broadcast in mind, going all the way back to how the color spaces themselves are created. Should I figure out how to do it, I will definitely by posting a guide here. As a side note, If anyone DOES know how to record in a full computer color space, PLEASE let me know.

Getting back on topic though, does anyone else have any questions about how to set up your editing program or things that you should be looking to do?
Kyra Quinn
Garoun Investment Bank
Gallente Federation
#31 - 2013-03-15 22:56:01 UTC  |  Edited by: Kyra Quinn
Lets try a few really simple questions :)

- Does Fraps in any way hinder 4:4:4 sampling? (Probably not because it doesn't render as such, but it has to be asked)
- Does Vegas render in 4:4:4 and which settings would be needed for it

That, to me, is the only thing that matters because it's indeed the text "degradation" that's my main concern.
Hoarr
Caldari Provisions
Caldari State
#32 - 2013-03-16 16:16:41 UTC  |  Edited by: Hoarr
If you click the force lossless checkbox in FRAPS, It will record with 4:4:4 subsampling. Vegas can output in a 4:4:4 as well. That's not the issue though, the issue is that chroma subsampling is one of the primary ways to compress video data. You can find lossless codecs which render out massive video files that will be more than happy to use a 4:4:4 chroma subsampling. The issue is trying to find a good lossy encoder that will use a 4:2:2 chroma subsampling, one which I have not been able to do.

The other issue, and the one that was the reason I stopped chasing this the last time that I started looking at this stuff is that YouTube will encode all uploaded videos in the rec. 709 color space. Rec. 709 uses the 16-235 primaries that I discussed in an above post. Because of this, I have stopped using the force lossless capture button in FRAPS since there is no point having the extra information since it is going to be lost anyhow.

If I find anything else out about this, I will be sure to let you guys know.
Previous page12