getfps - h264


    Mar 26 2007 | 2:16 pm
    Hi everybody,
    I work with an h264 encoded file. Is it normal to have the getfps message which gives 0.000 ?????
    I confirm that files encoded with others codecs give me right fps.
    -
    Moreover I can't record in h264 with jit.qt.record, max tells me "bad codec specified"
    I confirm h264 is available in jitter 1.6 (message "getcodeclist"), not in jitter 1.5
    -
    are you experienced ... ? :) thank you.
    Derrick

    • Mar 26 2007 | 2:25 pm
      H264 uses features of QuickTime 7 which we haven't implemented. Although one can read movies encoded with the codec, editing and recording are not supported. The getfps message probably doesn't know how to handle the kind of media samples used by the codec.
      We're planning to add support for additional QuickTime 7-specific features with the next major version of Jitter.
      jb
      Am 26.03.2007 um 16:16 schrieb derrickgiscloux:
      > I work with an h264 encoded file. > Is it normal to have the getfps message which gives 0.000 ????? > > I confirm that files encoded with others codecs give me right fps. > > - > > Moreover I can't record in h264 with jit.qt.record, max tells me > "bad codec specified" > > I confirm h264 is available in jitter 1.6 (message "getcodeclist"), > not in jitter 1.5
    • Mar 26 2007 | 3:30 pm
      FWIW, these days I like to record in apple_intermediate_codec @ lossless quality (which all the fashionable kids say is the new jpeg) and the use quicktime to re-encode to whatever compressed format I need, from there.
      On Mar 26, 2007, at 3:25 PM, Jeremy Bernstein wrote:
      > H264 uses features of QuickTime 7 which we haven't implemented. > Although one can read movies encoded with the codec, editing and > recording are not supported. The getfps message probably doesn't > know how to handle the kind of media samples used by the codec. > > We're planning to add support for additional QuickTime 7-specific > features with the next major version of Jitter. > > jb > > Am 26.03.2007 um 16:16 schrieb derrickgiscloux: > >> I work with an h264 encoded file. >> Is it normal to have the getfps message which gives 0.000 ????? >> >> I confirm that files encoded with others codecs give me right fps. >> >> - >> >> Moreover I can't record in h264 with jit.qt.record, max tells me >> "bad codec specified" >> >> I confirm h264 is available in jitter 1.6 (message >> "getcodeclist"), not in jitter 1.5 >
    • Mar 26 2007 | 5:25 pm
      On Mar 26, 2007, at 8:30 AM, evan.raskob [lists] wrote:
      > FWIW, these days I like to record in apple_intermediate_codec @ > lossless quality (which all the fashionable kids say is the new jpeg)
      Not sure about vertical chroma resolution though (4:2:0). Sounds like it'll be worse than Photo JPEG, but I haven't done any tests specifically, and of course it won't matter if your source footage is 4:2:0 or worse. Also not sure about performance w/r/t JPEG, but it should be much faster than H.264 and HDV, when it is not disk limited.
      -Joshua
    • Mar 26 2007 | 5:36 pm
      I just did a comparison test with AIC vs PhotoJPEG in Jitter with 1400x1050 source files both performed roughly equally as well in terms of playback performance (i was able to play 2 streams, one per disk without dropping frames) - the quality is only ~slightly better with photojpeg, of course will also depend on the source material. photojpeg felt maybe slightly faster as well. this is a very subjective test, i have no metrics available. note photojpeg was at 75% quality. The decompression speed of photojpeg is logarithmic with the quality slider (higher = much slower)
      filesizes are still much lower with jpeg, so imho its still the reigning queen of RT codecs.
      --deKam
      >> FWIW, these days I like to record in apple_intermediate_codec @ >> lossless quality (which all the fashionable kids say is the new jpeg) > > Not sure about vertical chroma resolution though (4:2:0). Sounds > like it'll be worse than Photo JPEG, but I haven't done any tests > specifically, and of course it won't matter if your source footage > is 4:2:0 or worse. Also not sure about performance w/r/t JPEG, but > it should be much faster than H.264 and HDV, when it is not disk > limited.
    • Mar 27 2007 | 1:44 pm
      hmmm... my tests were all completely non-scientific. that's what i get for being fashionable. i should actually attempt something scientific in the near future.
      on a side note, just when you think you've finally heard all the technical terms possible for video, someone throws "4:2:0 vertical chroma resolution" at you. i swear, i think you're making that up, josh, just to bust my balls...
      -evan
      On Mar 26, 2007, at 6:36 PM, dekam wrote:
      > I just did a comparison test with AIC vs PhotoJPEG in Jitter with > 1400x1050 source files > both performed roughly equally as well in terms of playback > performance (i was able to play 2 streams, one per disk without > dropping frames) - the quality is only ~slightly better with > photojpeg, of course will also depend on the source material. > photojpeg felt maybe slightly faster as well. this is a very > subjective test, i have no metrics available. note photojpeg was > at 75% quality. The decompression speed of photojpeg is logarithmic > with the quality slider (higher = much slower) > > filesizes are still much lower with jpeg, so imho its still the > reigning queen of RT codecs. > > --deKam > > > >>> FWIW, these days I like to record in apple_intermediate_codec @ >>> lossless quality (which all the fashionable kids say is the new >>> jpeg) >> >> Not sure about vertical chroma resolution though (4:2:0). Sounds >> like it'll be worse than Photo JPEG, but I haven't done any tests >> specifically, and of course it won't matter if your source footage >> is 4:2:0 or worse. Also not sure about performance w/r/t JPEG, but >> it should be much faster than H.264 and HDV, when it is not disk >> limited. >
    • Mar 27 2007 | 3:41 pm
      On Mar 27, 2007, at 6:44 AM, evan.raskob [lists] wrote:
      > on a side note, just when you think you've finally heard all the > technical terms possible for video, someone throws "4:2:0 vertical > chroma resolution" at you. i swear, i think you're making that up, > josh, just to bust my balls...
      -Joshua
    • Mar 27 2007 | 5:03 pm
      Here is a great page that I used today to explain the sampling nomenclature in video, really good stuff:
      On Mar 27, 2007, at 5:41 PM, Joshua Kit Clayton wrote:
      > > On Mar 27, 2007, at 6:44 AM, evan.raskob [lists] wrote: > >> on a side note, just when you think you've finally heard all the >> technical terms possible for video, someone throws "4:2:0 vertical >> chroma resolution" at you. i swear, i think you're making that >> up, josh, just to bust my balls... > > > http://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0 > > http://docs.info.apple.com/article.html?artnum=301599 > > -Joshua > >
      v a d e //
      www.vade.info abstrakt.vade.info
    • Mar 27 2007 | 7:20 pm
      ok i believe you :)
      thanks for the links (thanks to vade, too)
      On Mar 27, 2007, at 4:41 PM, Joshua Kit Clayton wrote:
      > > On Mar 27, 2007, at 6:44 AM, evan.raskob [lists] wrote: > >> on a side note, just when you think you've finally heard all the >> technical terms possible for video, someone throws "4:2:0 vertical >> chroma resolution" at you. i swear, i think you're making that >> up, josh, just to bust my balls... > > > http://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0 > > http://docs.info.apple.com/article.html?artnum=301599 > > -Joshua > >