Page 22 of 22 FirstFirst ... 121819202122
Results 211 to 220 of 220
  1. Collapse Details
    Bronze Member
    Join Date
    Apr 2010
    Posts
    2,415
    Default
    Quote Originally Posted by cbrandin View Post
    Yup, I found all that. The hard thing is that it looks to be mostly table driven and back-tracing pointers to pointers, to addresses in the plug-ins and back to pointers to tables and offsets is rather time consuming.

    Chris
    Yep. They also like to copy memory parts in other routines (or even tasks).
    So, you are looking at references to certain structures but can't find any.
    Because they copy large part (including structure) to other place (or instead something to this place).
    All firmware is based on tables.
    But as soon as we'll start to realise how this works it is to our adventage.
    In reality they frequenly use special codes (they are easy to find, as they are quite unique most of the time) to select some function from the table.
    Last edited by Vitaliy Kiselev; 09-14-2010 at 01:55 PM.


     

  2. Collapse Details
    Junior Member
    Join Date
    Jul 2010
    Posts
    2
    Default
    This hmc153 PAL 1920 50I avchd stream




    1280 50P's

    Last edited by xiyiding; 09-18-2010 at 03:24 AM.


     

  3. Collapse Details
    Senior Member
    Join Date
    Aug 2006
    Location
    Colorado Springs
    Posts
    473
    Default
    Stream Parser is only set up to do GH! clips. Obviously different frame type flagss are being used here so frame types are not being correctly identified. It looks like these streams also contain B frames - is that correct?

    This gives me an idea. I could add a feature to stream parser where you can manually enter PID's and frame type flags.

    Chris
    Last edited by cbrandin; 09-18-2010 at 09:27 AM.


     

  4. Collapse Details
    Senior Member
    Join Date
    Mar 2010
    Posts
    2,524
    Default
    If do a new rev of Stream Parser, could you calculate two more stats in the info window: peak and average bitrate of the entire stream. I've had to estimate these by eye balling the charts.


     

  5. Collapse Details
    Senior Member
    Join Date
    Aug 2006
    Location
    Colorado Springs
    Posts
    473
    Default
    Quote Originally Posted by lpowell View Post
    If do a new rev of Stream Parser, could you calculate two more stats in the info window: peak and average bitrate of the entire stream. I've had to estimate these by eye balling the charts.
    OK, will do.

    Chris


     

  6. Collapse Details
    Senior Member
    Join Date
    Mar 2010
    Posts
    2,524
    Default
    I've been researching low-light recording failures in SH 720p30 mode with my Fast Action 3-Frame GOP Patch. From what I've seen, if the illumination is low enough, the bitrate will drop below 5Mbps and the recording will terminate after about 7 seconds, leaving a zero-length file. The camera then displays a write-speed limitation error, with both slow Class 4 and fast Class 10 SD cards alike. Here's a Stream Parser screen grab of a video I saved before the 7-second limit:



    My guess is that the camera builds up unused bit allocation that it can't find a use for over each one-second interval. It then writes out the surplus as a single huge P-frame which overwhelms the SD card's write-speed limits. Anyone know of a patch that may fix this problem?


     

  7. Collapse Details
    Bronze Member
    Join Date
    Apr 2010
    Posts
    2,415
    Default
    No.

    But this behaviour is common to GH1 encoder.
    It has problem with last P frame in GOP sometimes.
    Like on your picture.
    But P frame size on your picture seems pretty small to cause any write problems.


     

  8. Collapse Details
    Senior Member
    Join Date
    Mar 2010
    Posts
    2,524
    Default
    Each recording aborts predictably after 7 seconds have elapsed, so it seems there's probably something else building up to an overflow condition behind the scenes...


     

  9. Collapse Details
    Senior Member
    Join Date
    Aug 2006
    Location
    Colorado Springs
    Posts
    473
    Default
    I've seen this pattern with dark tests in all modes. When you raise bitrates the big P frames get bigger. I assumed that it was just maintaining a minimum bitrate as the big P frames contain mostly nulls in my tests (you might want to check that). The bitrate looks pretty small, so I doubt the write function is being overrun. You might try upping the Overall Bitrate anyway, that speeds up the camera's ability to write. One thing I noticed about 720p mode is that there seems to be some sort of threshold condition that has to be met before it will put anything in a P frame. Oddly, 1080 mode doesn't seem to have that. I posted something about that earlier in this thread: http://www.dvxuser.com/V6/showpost.p...&postcount=206.

    Chris
    Last edited by cbrandin; 09-23-2010 at 08:27 PM.


     

  10. Collapse Details
    Default
    Maybe there's another parameter in the firmware that lower bounds the encoder output bit rate. If the encoder can't satisfy that lower bound, it aborts with a "write speed error"? Not unlike the upper bound that Chris investigated.

    Why would Panasonic implement such a parameter? Like Chris's upper bound, programming convenience. It's probably easier to track how much data the encoder is outputting in a window than it is to measure the instantaneous card writing speed or to track card write errors. If the encoder outputs too much data, then the firmware assumes without proof that the card can't keep up and it raises a write speed error. If the encoder outputs too little data in the window, then the firmware assumes without proof that the card writing subroutine must be getting hung up and it raises a write speed error.

    Just a thought.


     

Page 22 of 22 FirstFirst ... 121819202122

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •