VideoHelp Forum
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 42
Thread
  1. Is there any utility or method out there to find out how many keyframes are in a given sample video?
    Quote Quote  
  2. It depends on the video type, compression used

    One way is to use ffmpeg/ffmbc or similar utilities like ffdshow's osd to print out a list of frametypes, then tally up the IDR frames

    Note when dealing with h264, IDR frames are true keyframes (you can have "non keyframe" I-frames), this might not apply to other types of compression, where all I-frames are keyframes


    See these discussions for ideas and examples
    https://forum.videohelp.com/threads/342572-decoding-mpeg-video-into-frames-say-I-P-B-frames
    http://forum.doom9.org/showthread.php?t=163553
    Quote Quote  
  3. Originally Posted by poisondeathray View Post
    It depends on the video type, compression used

    One way is to use ffmpeg/ffmbc or similar utilities like ffdshow's osd to print out a list of frametypes, then tally up the IDR frames

    Note when dealing with h264, IDR frames are true keyframes (you can have "non keyframe" I-frames), this might not apply to other types of compression, where all I-frames are keyframes


    See these discussions for ideas and examples
    https://forum.videohelp.com/threads/342572-decoding-mpeg-video-into-frames-say-I-P-B-frames
    http://forum.doom9.org/showthread.php?t=163553
    Ok, I'll check those. Is a possible solution to the IDR/I-frame issue just to set every I-frame as an IDR frame? Any major increase in file size in doing this?
    Quote Quote  
  4. Originally Posted by anonymous_whatever View Post
    Originally Posted by poisondeathray View Post
    It depends on the video type, compression used

    One way is to use ffmpeg/ffmbc or similar utilities like ffdshow's osd to print out a list of frametypes, then tally up the IDR frames

    Note when dealing with h264, IDR frames are true keyframes (you can have "non keyframe" I-frames), this might not apply to other types of compression, where all I-frames are keyframes


    See these discussions for ideas and examples
    https://forum.videohelp.com/threads/342572-decoding-mpeg-video-into-frames-say-I-P-B-frames
    http://forum.doom9.org/showthread.php?t=163553
    Ok, I'll check those. Is a possible solution to the IDR/I-frame issue just to set every I-frame as an IDR frame? Any major increase in file size in doing this?
    I don't understand what do you mean by "solution" ?

    What's the problem in the first place?
    Quote Quote  
  5. Oh, I mean it seems as if a lack of IDR frames causes poor scanning throughout the video.
    Quote Quote  
  6. Originally Posted by anonymous_whatever View Post
    Oh, I mean it seems as if a lack of IDR frames causes poor scanning throughout the video.
    Clarify what do you mean by "scanning"?
    Quote Quote  

  7. What are you trying to ask?

    I didn't see any references to "scanning" in that article. Again what do you mean by "scanning" ? Seekpoints ?

    Note context is important. Encoding for rtsp streaming is different than another scenario, maybe for PC files.

    Open GOP will always be more efficient than closed. Having acceess to using non-IDR frames will always be more efficient than IDR frames only - which are are more expensive to encode.

    Latency and seektime is reduced by all IDR frames (intra) - but that's the same reason why filesizes required are huge for a given "quality" over Long GOP. Similarly the longer the GOP interval, the slower the seek, but potentially more efficient compression (you fill up the GOP with less expensive P and B frames)
    Quote Quote  
  8. Ok, I gotcha. So essentially more IDR frames = faster seek, larger file and less IDR frames = slower seek, smaller file.

    So, I'd like to ask do you think you could let me know if this is a good idea?

    1. import DV
    2. compress to intraframe x.264 with --keyint1 and -bff ( or VirtualDub's smart filter??)
    3. work with compressed intraframe x.264 to edit
    4. export as xVid for final production, double pass

    Does this sound like a good summary?
    Quote Quote  
  9. Originally Posted by anonymous_whatever View Post
    Ok, I gotcha. So essentially more IDR frames = faster seek, larger file and less IDR frames = slower seek, smaller file.
    In general , for a given type of compression and set of settings, yes!

    (But there are many factors that can affect filesize for given level of quality, seektimes, CPU usage for decoding etc...)



    So, I'd like to ask do you think you could let me know if this is a good idea?

    1. import DV
    2. compress to intraframe x.264 with --keyint1 and -bff ( or VirtualDub's smart filter??)
    3. work with compressed intraframe x.264 to edit
    4. export as xVid for final production, double pass
    What application are you using to edit?

    h.264 is a very large spec (and x264 encoder supports many of the advanced features), but beware many programs do not support everything all the bells and whistles. I mentioned this in the other thread. So even if you convert it and it works fine a media player, it might not work in a standard NLE.

    For example , in that link, Adobe flash at the time did not support open GOP - that's why you see the pixellated seek. If were to download the same video and play it locally with MPCHC (ffdshow libavcodec decoder) it would not be pixellated with the same seeking behaviour . Also some hardware devices treat non IDR "i" frames as IDR frames - so you get pixellated seeks.
    Quote Quote  
  10. note that i say this in reference to some of the other posts you've answered/contributed to
    Quote Quote  
  11. how about i ask which NLE would work best with x.264? i'll work with whatever is best for this
    Quote Quote  
  12. And why xvid for final export ?? is final format for a device ? PC ? How do you intend to play it back ?

    What about the other processing factors mentioned in the other thread? There can be night/day difference in quality between deinterlacers if that's what you're doing .

    DV usually requires a lot of pre processing (in terms of denoising, chroma handling), this can make a huge difference final quality and filesizes (noise consumes enormous amounts of bitrate)

    how about i ask which NLE would work best with x.264? i'll work with whatever is best for this
    If you have the cash to drop on a NLE, I would just get a harddrive instead. Seriously. The amount of time and wasted with that proposed workflow for a DV source is seriously wrong. Time is money for most people

    What kind of "editing" are you doing? just simple cuts ? or real editing with multiple transitions, layers, effects ?
    Quote Quote  
  13. xVid because it's the most supported. the video is for pc, playback on pc.

    i am deinterlacing, using virtualdub smart deinterlace. i'm willing to experiment with a few.

    yeah i've been considering the hard drive. what NLE's would be best?
    Quote Quote  
  14. a few cuts, some transitions, text overlays mostly
    Quote Quote  
  15. Originally Posted by anonymous_whatever View Post
    xVid because it's the most supported. the video is for pc, playback on pc.
    Well maybe... but for devices (e.g. ipod/pad/phone, android etc...), h.264 is more supported these days

    MPEG2 would probably be the most supported overall



    i am deinterlacing, using virtualdub smart deinterlace. i'm willing to experiment with a few.
    This is a huge topic, and a lot of information can be found in various threads

    "smart deinterlace" is very poor, even 5 years ago.

    Have a look at an old comparison between some popular deinterlacers as the time
    (right click, save as) . TGMC has been replaced by QTGMC these days
    https://forum.videohelp.com/images/guides/p1934885/stockholma_0-520_q3_yadif_mvbobmod_t...mca4_tdtmm.avi

    The more stable output means fewer difference between frames (instead of flickering and shimmer, which will "eat up" bitrate) - so your xvid output will require less bitrate as well (smaller filesizes and better quality)

    Also , for a DV source, you should be bob-deinterlacing instead of throwing away half the fields (ie. 59.94i => 59.94p instead of 29.97p)




    yeah i've been considering the hard drive. what NLE's would be best?
    You can get x264 (I frame only) to work with premiere pro or sony vegas . Not sure about the consumer versions (premiere elements, vegas studio) . It also takes some extra work, interpreting the footage AR and field order (it not a commonly used format, as compared to DV-AVI, which you just pop in and edit right away, and AR and field order are automatically correct). But on a P4, I'm not sure you want to do this at all. NLE's add extra overhead, so even though it might play ok in a media player, it still might be sluggish in a NLE. DV-AVI will edit ok on a P4.
    Quote Quote  
  16. Ok, I got a QTGMC AVIsynth script and I'll load this up into virtualdub.

    I really like DV, but I wonder if I can save the hassle here. It seems to me that the final output quality is ultimately going to be the same, if I edit in DV or h.264, it's ultimately going to end up in xVid. I may as well just drop the DV early, no?
    Quote Quote  
  17. DV --> xVid

    =

    DV --> x.264 --> xVid

    no?
    Quote Quote  
  18. minus some generational recompression loss, which I can put up with and which I doubt will be very noticeable
    Quote Quote  
  19. Not using intra at low bitrates; most of the tremendous compression gains using x264 are from long GOP. There is not much point using x264 and intra when you have a DV file all ready to do

    What were your expectations for the intermediate bitrate ?

    Also, maybe your level of acceptable quality loss is different. You have to try it out and see if it's "good enough" for this case in your eyes
    Quote Quote  
  20. ok, i'm gonna play around with these codecs and see what i come up with. long GOP at a high bitrate will still be more difficult to edit than x264 intra, no?
    Quote Quote  
  21. Originally Posted by anonymous_whatever View Post
    ok, i'm gonna play around with these codecs and see what i come up with. long GOP at a high bitrate will still be more difficult to edit than x264 intra, no?

    The point of long gop is so that you can use lower bitrates than intra, but it's less suitable for editing because of higher latency. I think you might have problems editing long gop h.264 on a P4. Its meant for distribution, final format goal, not editing

    ie. Intra would require that you use high bitrates for a certain level of "quality". Intra requires high bitrates . Period. Any format. Yes you better compression with h264 intra over say MJPEG or MPEG2 intra, but it still going to be huge compared to a long GOP. Most intra intermediates are HIGHER than the original bitrate. SO many times the original filesize. So don't complain about DV size.


    That's why I suggested non intra MPEG2 as an acceptable alternative. At ~12-15Mb/s (roughly 2-2.5x what DVD would use), it's decent quality at about a 1/2 the size of your DV starting point . It's also widely accepted and compatible in programs. Small sized , constant GOP (~15 frames) make it easier to edit as well. It lacks some of the features of h.264, so it makes it easier to edit (no CABAC, no inloop filtering) . You could get similar quality using all the features of long GOP x264 as that 12-15Mb/s MPEG2 but at about 6-9Mb/s, so much smaller but more difficult to edit - very likely unusable on a P4 (you'll be frustrated an pulling out your hair)
    Last edited by poisondeathray; 11th Feb 2012 at 17:12.
    Quote Quote  
  22. Ok, I do have a more powerful computer available to use as well, just the initial capture is done on a P4. I wonder how the theoretical part plays out here.

    If DV is intra, wouldn't an intra compression reduce the size even more? How can it increase file size if you're further compressing?

    with mpeg non intra, constant bitrate, 15 frames, would i be able to make cuts at less than 15 frames and maintain quality? or would cuts have to occur only every 15th frame?

    argh...
    Quote Quote  
  23. your comment in the other post was concise. i want reduced DV filesize for editing and storage. end of story. processing power is not a concern. any particular, dominant mpeg2 encoder you would recommend to give it a shot?
    Last edited by anonymous_whatever; 11th Feb 2012 at 23:42.
    Quote Quote  
  24. Originally Posted by anonymous_whatever View Post
    If DV is intra, wouldn't an intra compression reduce the size even more? How can it increase file size if you're further compressing?
    No. Filesize = bitrate x running time

    So if you want , you can choose 1/10 the bitrate (thus 1/10 the size), but it will look like absolute garbage. In fact , even 1/2 the bitrate will pretty much look like garbage using any intra encoding (unless it's very simple complexity, like a blank wall)

    But if you use intra compression, you need enormous amounts of bitrate to maintain a certain level of quality

    Lossy compression vs lossless compression . Everything is compared to uncompressed. So if you use lossy compression the quality will always decrease, and if you want slightly less quality, but close, using intra, the filesize will actually be larger

    If you're familiar with audio, and example would be mp3. If you re-encode mp3 over and over again , data gets thrown away each time, you minimize that loss by using higher bitrates. You can never get the same quality back. It's only downhill with lossy compression

    with mpeg non intra, constant bitrate, 15 frames, would i be able to make cuts at less than 15 frames and maintain quality? or would cuts have to occur only every 15th frame?
    If you have a smart rendering editor (e.g vegas can for mpeg2, but premiere cannot without 3rd party plugins), then only cuts within the GOP are re-encoded, everything else is passed thorough untouched. But you are incurring more loss by going to MPEG2 than keeping it DV in the first place. Also this smart rendering point is moot in your case, because you have already re-encoded it, and are going to re-encode it again to xvid. Smart rendering would only benenfit you if you were keeping MPEG2 (the same input format)

    Also if you use any global filters, like color correction, overlays those sorts of things, everything is re-rendered anyways
    Quote Quote  
  25. Originally Posted by anonymous_whatever View Post
    your comment in the other post was concise. i want reduced DV filesize for editing and storage. end of story. processing power is not a concern. any particular, dominant mpeg2 encoder you would recommend to give it a shot?

    If processing power isn't a concern, then go ahead and use h.264, long gop. That's the best compression bar none. You can customize various settings for faster decoding, or higher compression, maybe faster encoding is your goal etc...ie. you can customize x264 considerably , very highly configurable encoder
    http://mewiki.project357.com/wiki/X264_Settings

    At SD sizes, modern computers (quadcore or more) can handle it fine. It's only when you get to HD sizes, that h.264 becomes a pig and editing slow

    If you still wanted to use MPEG2, you can use free programs: HCEnc (but it requires avisynth knowledge), ffmpeg (easier to batch process with command line, but MPEG2 quality is definitely worse than HCEnc) , or paid programs like CCE, Mainconcept Reference
    Quote Quote  
  26. ok, i'll look into some long GOP h264 and see what i get.

    just as an aside, i played around with x.264 --keyint 1 and i managed to reduce filesize to 20% of the DV with no insane loss of quality. it looks worse, but not terribly so. being intra and easier to edit, would this be a viable solution?
    Quote Quote  
  27. i wanna beat this dead horse until i can get some meat from it, because whatever method i find to be best will be used for a large mass of video. and i don't want to go back and re-evaluate compression methods after i start
    Quote Quote  
  28. A good answer for the original question on this post is the GSpot utility. There is a button labelled "VGS" in the video panel that, once clicked, shows a literal mapping of all the frames in a given video (I, B, P frames).
    Quote Quote  
  29. Member
    Join Date
    Mar 2006
    Location
    Russian Federation
    Search Comp PM
    Originally Posted by anonymous_whatever View Post
    Is there any utility or method out there to find out how many keyframes are in a given sample video?
    May I ask what is a sense to know a number of K-frames?
    Quote Quote  



Similar Threads

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