some additional infos that might help do understand things:
- changing the frame rate will not change the number of frames
- the frame rate is just an info for the decoder about how fast to playback the given content, it does not matter how many frames there are
- looking and frame rate and null frames no problem occurs, since the changing the frame rate simply tells the decoder do represent the copied frame faster. Normally null frames are only allowed for adjacent frames, so null frame do not really chase rerepresentation of frames but simply showing the previous frame a longer time. So if you got a normal frame and three null frames the normal frame will simply be displayer 3 times longer and the frame rate simply specifies how long the base representation time is. For 25fps it's 40ms and for 50fps it's 20ms.)
- color representation on displays is normally in RGB and classically PCs and TVs represent colors differently in RGB. Black on a PC is (0,0,0) and on a TV it's (16,16,16). A PC uses (0-255) and a TV uses (16-235) to represent colors. So whenever a YUV<>RGB conversion is done you need to know if the colors where encoded in TV or PC scale, otherwise you will shift the colors a bit. Most people don't really see this because their TV/PC isn't properly calibrated or the graphic card drivers or the TV firmware is configured to do some additional color changing,... -> the whole PC (full range) vs. TV (normal range) scale thing isn't always easy to handle. H.264 is one of the few formats which allows to signal what color scale you have, but the problem is a lot of hardware does not respect these infos and simply assumes the content is either full or normal range,.. So since a lot of hardware always assumes the input to be TV scale, it sometimes is a good idea to encode to TV scale to have some control over the color changes that take place.
Cu Selur
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 91 to 117 of 117
Thread
-
-
Like I said, I want a truly lossless file to replace the JPGs so that I can then extract individual frames from the video that would be equivalent to the JPGs (full-range YUV and all).
How do I do that? You're saying that even Lagarith loses something in the conversion.. so is there no way to get what I want?
Well, when I encode using Handbrake it changes the color depth to normal range, but when I encode with Xvid4PSP, it keeps the full luma.
Are you saying that if I re-encode my Lagarith to H.264 using Xvid4PSP it will truly be lossless because there won't be any color depth switching (YUV to RGB, full range to normal range and vice versa)?
But my #1 issue is still the creation of the Lagarith file..
Because I need to know that when I create a video out of my JPGs, it has 100% of the quality of said JPGs, so that I can delete them.Last edited by Track; 7th Sep 2013 at 03:18.
-
-
Then just keep the jpg's - they are already extracted
Yes there is a way, with x264 CLI using the command line mentioned earlier .
But that format is going to give you potential issues with playback as mentioned earlier, levels issues unless you configure playback/display chain correctly , and it's not possible to "extract back" the equivalent jpg . It is possible to extract back the bmp, tiff, or png of the original . The reason is when you use lossless compression, the original jpegs are decoded to UNCOMPRESSED first (usually RGB, but some can give you the original full range YUV as mentioned above) . You can NEVER get back the original JPEG compression if you use a lossless format. You can only get back the decoded UNCOMPRESSED data. Of course, the equivalent png, tiff or even png is going to be huge. If you recompress with JPEG compression, there is going to be quality loss. That's reason #1052 for keeping the original jpegs .
Are you saying that if I re-encode my Lagarith to H.264 using Xvid4PSP it will truly be lossless because there won't be any color depth switching (YUV to RGB, full range to normal range and vice versa)?
But my #1 issue is still the creation of the Lagarith file..
Because I need to know that when I create a video out of my JPGs, it has 100% of the quality of said JPGs, so that I can delete them.Last edited by poisondeathray; 7th Sep 2013 at 08:45.
-
Another option would be to use an avs script to "play" an image sequence . The benefit is you can control the size, AR, cropping etc... without "damaging" the originals
But it's difficult to play a sequence of 8-12MB jpegs at "regular" framerates unless you have a SSD or raid0 HDD setup, or you run into disk I/O bandwith issues -
I don't understand the need for perfection. That example still is fuzzy anyway.
-
nobody understands, but this thread turned into nice RGB, YUV exrcise and x264 lossless encoding, it is mind blowing to read this ...
-
-
No, I'm saying it does directly
I'm saying using --profile high422 is a switch that will prevent you from using lossless mode
e.g. I can use profile high444 even though a video is 4:2:0 . The "profile" is just a limiter and a "label". You can encode below, but not above . I can label a video high@L5.1 even though it conforms to high@L3.1 specs. It doesn't necessarily do an intermediate conversion to 444 . You can test this with difference masks. This jpeg example was truly lossless. There was no intermediate conversion -
in short: lossless encoding -> profile needs to be High444 or unrestricted, used input&output color space should be that of the source
-
-
Another way of saying this , lossless predicitive encoding by AVC (and only x264 can do this, other AVC encoders can't) is only allowed by Hi444 profile
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
Even when you encode a "regular" 4:2:0 DVD or blu-ray, when you use lossless mode, x264 will automatically select Hi444 , even though the source is 4:2:0
In the past with x264, --level was completely a "label" , and did not limit anything, or do anything. e.g. people might have encoded high@L4.1 with 16 ref frames, which of course is not allowed. Now, when used with VBV settings it actually limits things like --ref to stay compliant within the level setting according to AVC specs -
Okay, so two things:
1.) I can't use command prompt. Is there another way?
2.) You're suggesting that all JPGs are screwed to begin with because they're shot with YUV and the monitor they are displayed on displays them as RGB? -
-
Some GUI's let you enter commands in a command line box, you might be able to do that. Handbrake allows you to enter some, megui does too. You might be able to figure something out
2.) You're suggesting that all JPGs are screwed to begin with because they're shot with YUV and the monitor they are displayed on displays them as RGB?
Chroma subsampling isn't possible with RGB (RGB is always full color). Subsampling is used as a method of saving bandwidth -because human eyes aren't very sensitive to color resolution. But your JPEGs are 4:2:2 internally (ie. there is 1/2 the color information as the black & white information 2592x1728 vs 5184x3456 in your example) . Most lower quality web JPEGS are actually 4:2:0 and would contain 1/4 of the color information
But almost all JPEG decoders output RGB, because 99.99999999% of display devices use RGB as a color model . Otherwise you couldn't "see" anything (or what you're supposed to see, it will look black & white if looking at Y separately). -
YUV is analog. RBG is digital.
I suppose you can play your motion jpegs out to a Hauppage recorder and capture as RGB. The recorder has tweaks for luminance, chroma, etc.
Not sure how to do this though in practice, but I know moviemakers convert film to digital all the time. And they do all kinds of things to the colors nowadays. Like Technicolor and squashed blacks.
Nobody will even know or care what the originals looked like. You're making an art piece, not a medical CT scan Let loose on the butt cheeks a little, and grab some creativityLast edited by budwzr; 7th Sep 2013 at 12:07.
-
BTW, when people say "YUV" on these forums, they actually mean "Y'CbCr" . Technically YUV is analog, Y'CbCr is the digital equivalent of YUV
-
It's even more complicated. Digital cameras usually start out with reg, green, and blue sensors in a Bayer pattern. That has 2x as many green sensors as it does blue and red:
http://en.wikipedia.org/wiki/Bayer_pattern
So you don't even start with separate red, green, and blue sub-pixels for each pixel. -
And that's also why people shoot in RAW like smrpix suggested above. Not only do you avoid lossy jpeg compression , and have a lot more information (especially in overbrights) - you also have the control over the debayer algorithm used with various RAW software .
-
Yeah, but raw files are like 20MB each. And each one has to be colorized. Raw files are flat and dull, so you have to wing it on the lighting changes.
-
-
What I'm getting from all of this is that I should either do something crazy to get a 100% lossless compression or just forget about it.
-
The takeaway should be (IMHO) you can't get what you want at the target size/format you would prefer. So best to seek an altenate strategy. Some good ones have been suggested.
And to echo what _AI_ said earlier, thank you for starting an interesting conversation. -
My takeaway is that you can have the quality you want if you're willing to give up size restrictions (which is fine), and that there is no such thing as a 100% lossless time-lapse video because JPGs are shot using a color depth that simply has to be converted in some way.
I feel quite envious of all of you and especially jagabo who knows so much more than me he can probably encode video in his toaster
Similar Threads
-
Need help getting optimal quality for DVD-5
By BlackThought in forum Video ConversionReplies: 8Last Post: 4th Apr 2012, 22:37 -
Optimal settings for conversion
By airwolfUK in forum Video ConversionReplies: 1Last Post: 17th Feb 2011, 14:08 -
Is there a better way to get optimal quality converting from .flv to DV?
By brassplyer in forum Video ConversionReplies: 7Last Post: 5th Jan 2011, 19:26 -
Optimal mpeg2avi conversion.
By mery in forum Video ConversionReplies: 1Last Post: 16th Dec 2010, 18:50 -
Best h.264 setting for optimal size/quality with handbrake.
By frickfrock99 in forum Newbie / General discussionsReplies: 4Last Post: 1st Oct 2010, 02:09