VideoHelp Forum
+ Reply to Thread
Page 4 of 4
FirstFirst ... 2 3 4
Results 91 to 117 of 117
Thread
  1. 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
    Quote Quote  
  2. Originally Posted by poisondeathray View Post
    Technically, neither handbrake or xvid4psp options will be "lossless", because xvid4psp uses avisynth in the backend (jpegs it will be decoded to RGB first). Also the conversion for the output YUV will be limited range 16-235 YUV , not full range 0-255 YUV like the original jpegs

    Why not just keep the original jpegs , and a different lossy, lower resolution version for playback ? Even you said you couldn't tell the difference and you were actually weren't using lossless files . And your "lossless" file wasn't even CRF0 and it was subsampled farther

    You will have playback difficulty with the lossless intermediates at full resolution, levels problems if you use full range YUV and don't configure the player properly (Most players don't expect full range YUV, they expect "normal range" levels) . The only types of video that "play out of the box" properly on all setups , even hardware players like media boxes without hassle are 8bit 4:2:0, lossy encoding.
    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?

    Originally Posted by Selur View Post
    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.
    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 04:18.
    Quote Quote  
  3. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by Track View Post
    ............

    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?

    ...........

    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.
    One possibility: create a Motion-JPEG file with ffmpeg, and then add the appropriate timecodes with MKVmerge.

    Just my R$1.99
    Last edited by El Heggunte; 7th Sep 2013 at 05:28.
    Quote Quote  
  4. Originally Posted by El Heggunte View Post
    Originally Posted by Track View Post
    ............

    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?

    ...........

    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.
    One possibility: create a Motion-JPEG file with ffmpeg, and then add the appropriate timecodes with MKVmerge.

    Just my R$1.99
    Isn't that a command line application..? I don't know how to work that..
    Quote Quote  
  5. Originally Posted by Track View Post
    Originally Posted by poisondeathray View Post
    Technically, neither handbrake or xvid4psp options will be "lossless", because xvid4psp uses avisynth in the backend (jpegs it will be decoded to RGB first). Also the conversion for the output YUV will be limited range 16-235 YUV , not full range 0-255 YUV like the original jpegs

    Why not just keep the original jpegs , and a different lossy, lower resolution version for playback ? Even you said you couldn't tell the difference and you were actually weren't using lossless files . And your "lossless" file wasn't even CRF0 and it was subsampled farther

    You will have playback difficulty with the lossless intermediates at full resolution, levels problems if you use full range YUV and don't configure the player properly (Most players don't expect full range YUV, they expect "normal range" levels) . The only types of video that "play out of the box" properly on all setups , even hardware players like media boxes without hassle are 8bit 4:2:0, lossy encoding.
    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?
    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.
    Technically before the lagarith step , you 've already incurred a loss because it's been decoded to RGB. IF you used lagarith RGB, then it would be "less" lossy, but still lossy compared to the original JPG. IMO, it doesn't matter, because when you "view" anything, it's been converted to RGB already. When you view the original JPEG, it's been converted to RGB for you to "see" it on the monitor. Almost all display devices work in RGB 99.999999999% . So if you encoded with lagarith RGB, the decoded output is bit for bit identical as the decoded JPEG output as RGB (it's still "lossy" in the sense that the original JPEG was full range YUV, but you won't be able to see the difference, because when you "see", you are viewing in RGB anyways! You don't view anything in YUV)
    Last edited by poisondeathray; 7th Sep 2013 at 09:45.
    Quote Quote  
  6. I seem to recall there is a program that will take a list of JPG files and create an MJPEG AVI by simply muxing them into an AVI container. Maybe that's what El Heggunte was referring to with ffmpeg.
    Quote Quote  
  7. Originally Posted by jagabo View Post
    I seem to recall there is a program that will take a list of JPG files and create an MJPEG AVI by simply muxing them into an AVI container. Maybe that's what El Heggunte was referring to with ffmpeg.
    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
    Quote Quote  
  8. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    I don't understand the need for perfection. That example still is fuzzy anyway.
    Quote Quote  
  9. nobody understands, but this thread turned into nice RGB, YUV exrcise and x264 lossless encoding, it is mind blowing to read this ...
    Quote Quote  
  10. Originally Posted by poisondeathray View Post
    use --input-csp and --output-csp as in the example above with high444, you don't have to set the profile (you can let it automatically pick). If you set profile manually, you must use high444, otherwise lossless isn't supported . Then you use --input-csp and --output-csp for specifying the chroma subsampling

    See the documentation

    - high422:
    No lossless.
    Support for bit depth 8-10.
    Support for 4:2:0/4:2:2 chroma subsampling.

    - high444:
    Support for bit depth 8-10.
    Support for 4:2:0/4:2:2/4:4:4 chroma subsampling.
    So what you're saying is x264 doesn't support 422 lossless directly -- which is what I've been saying. But that you can losslessly convert to 444, compress losslessly as 444, and convert back to 422 losslessly -- to effectively get lossless 422 compression.
    Quote Quote  
  11. Originally Posted by jagabo View Post
    Originally Posted by poisondeathray View Post
    use --input-csp and --output-csp as in the example above with high444, you don't have to set the profile (you can let it automatically pick). If you set profile manually, you must use high444, otherwise lossless isn't supported . Then you use --input-csp and --output-csp for specifying the chroma subsampling

    See the documentation

    - high422:
    No lossless.
    Support for bit depth 8-10.
    Support for 4:2:0/4:2:2 chroma subsampling.

    - high444:
    Support for bit depth 8-10.
    Support for 4:2:0/4:2:2/4:4:4 chroma subsampling.
    So what you're saying is x264 doesn't support 422 lossless directly -- which is what I've been saying. But that you can losslessly convert to 444, compress losslessly as 444, and convert back to 422 losslessly -- to effectively get lossless 422 compression.

    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
    Quote Quote  
  12. in short: lossless encoding -> profile needs to be High444 or unrestricted, used input&output color space should be that of the source
    Quote Quote  
  13. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    Originally Posted by _Al_ View Post
    nobody understands, but this thread turned into nice RGB, YUV exrcise and x264 lossless encoding, it is mind blowing to read this ...
    Yeah, when those two get going a whole encyclopedia comes out. V-Help should save their brains in a jar in the future.
    Quote Quote  
  14. 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
    Quote Quote  
  15. 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?
    Quote Quote  
  16. Originally Posted by Track View Post
    Okay, so two things:

    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?
    Unless you're using RAW files you've already discarded much of the information and compressed the remainder anyway. How far back do you want to go to preserve quality?
    Quote Quote  
  17. Originally Posted by Track View Post
    Okay, so two things:

    1.) I can't use command prompt. Is there another way?
    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?
    No, they are not "screwed" ; Internally, all JPEG's use YUV as a color model for storing information. Most video formats use YUV as well.

    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).
    Quote Quote  
  18. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    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 creativity
    Last edited by budwzr; 7th Sep 2013 at 13:07.
    Quote Quote  
  19. 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
    Quote Quote  
  20. 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.
    Quote Quote  
  21. 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 .
    Quote Quote  
  22. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    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.
    Quote Quote  
  23. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    Originally Posted by jagabo View Post
    ...So you don't even start with separate red, green, and blue sub-pixels for each pixel.
    The upside is that also makes the green channel very useful for coloring.
    Quote Quote  
  24. 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.
    Quote Quote  
  25. 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.
    Quote Quote  
  26. I learned a lot about Handbrake. I don't really use the program so I'm not sure I needed to!
    Quote Quote  
  27. 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
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!