VideoHelp Forum




+ Reply to Thread
Page 2 of 2
FirstFirst 1 2
Results 31 to 32 of 32
  1. Banned
    Join Date
    Oct 2023
    Location
    Los Angeles
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Originally Posted by Jay123210599 View Post
    Well, I was gonna convert the clips into either apng or gif files and upload them to DeviantArt, but I don't know which ones have the higher quality. Do you know?
    unless your "videos" are extremely simple, apng will be higher in quality, because gif only supports 256 colors. 8bit apng will support 16.3 million colors

    It's bad etiquette to upload large files and embed in websites, and your apng will be large unless you downscale it, or edit it down to a few frames. See your other thread - many times larger than the input video. That's a big reason gif is used more often despite the very low quality


    https://forum.videohelp.com/threads/412810-Video-to-APNG

    Originally Posted by poisondeathray View Post
    If I didn't downscale, just keep 8bit RGB the apng is massive - 12.7MB source video balloons to 474MB (!)

    Even with downscaling it's still 59.3MB .

    No downscaling plus 16bit RGB ballons to 1.15GB(!!)

    apng's are meant to be used in very specific display scenarios, not general use
    Here's the information for them.
    Image Attached Files
    • File Type: txt g.txt (7.0 KB, 29 views)
    Quote Quote  
  2. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    Originally Posted by Jay123210599 View Post
    Originally Posted by Cornucopia View Post
    You keep asking ahead of trying, but have you actually tried anything?

    It's always a compromise of some sort. Try different variations and find a compromise you can accept.


    Scott
    Well, I'm gonna trust in what this video about the tool has to say.
    https://www.youtube.com/watch?v=JE2zPxDuohk
    You should NOT just blindly trust what a marketing promo has to say. They clearly have an agenda to sell their own product, and they clearly are glossing over details of the truth to emphasize the stated benefit of their product over alternatives.

    What they DON'T say, and what I will explain here are these rules (which apply to ALL tools, because it applies to video in general):

    1. Video can be stored as a sequence of all independent whole pictures (keframes, or I-frames), or it can be stored as a sequence of GOPs (groups of pictures), which are comprised of independent whole pictures and delta pictures aka frames recorded only as changes made to pictures (compared to reference independent whole pictures). With modern GOP structures, those delta frames can either be mono-directional Predicted frames, or Bi-directional frames (which use a combo of I frames and P and possibly other B frames).

    2. Any time there is change to the integrity of a frame, it needs to be re-assessed and that new assessment needs to be re-encoded.
    That's why processing requires re-encoding, because it always changes the integrity of individual pixels within a frame.

    3. Editing merely changes the order of the frames in the sequence, so doesn't necessarily change pixels...except when operating on GOPs. Since all those delta frames must refer to the keyframes/I-frames to compute their differences, the structure of a GOP must remain intact. This is why editing must choose how granular it can edit depending on the structure.

    4. Apps that are more intelligently designed can realize it might not be necessary to have to re-encode sections that aren't referenced in an edit, and so they can narrow the re-encoding to just the affected area(s). This gives rise to varying levels of "smartness" in editing apps (I have written about this before):

    A. Level 0 - apps are so dumb, they will re-encode EVERYTHING, regardless of whether processing was done or not, or editing was on keyframes or not.
    B. Level 1a - apps will re-encode when processing or when cutting within GOPs, but with do a stream copy of the whole thing if all the edits are on keyframes.
    C. Level 1b - apps will only edit, and only cut on keyframes, so no re-encoding is necessary, but editing timing fineness/functionality is reduced.
    D. Level 2 - apps, known as Smart-rendering apps, will *with certain supported codecs and codec settings*, re-encode only when processing, or only when needing to re-assess & re-encode an affected edited GOP (when not on keyframes), and will do a stream copy of the other sections of the file.
    E. Level 3 -apps, will analyze each frame and each GOP, and only re-encode the GOP or frame that is affected, whether processing or editing, and if edits are not on a keyframe, will determine whether intermediate delta frames are truly affected within a GOP, and if they aren't they also are allowed to pass through via stream copy.

    Ffmpeg can act as a 1a or 1b type
    Tmpeg acts as a type 2. As can some other smart-rendering apps.
    Other than in specialty professional codec tools for broadcast & authoring (which are all $$$), there are no apps which use type 3, just because it is so complex to do that analysis (especially with open Gops and with h265-type expanded referencing).

    The caveat with smart-rendering and streamcopy of course is that you must keep the same codec & codec properties as the source. This usually is not an issue since that is what most are going for, but you have already said you want to end up with APNG.


    Scott
    Last edited by Cornucopia; 27th Dec 2023 at 01:59.
    Quote Quote  



Similar Threads

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