Page 5 of 7 FirstFirst 1234567 LastLast
Results 41 to 50 of 65
  1. Collapse Details
    #41
    Default
    I am working on third-party patches support for pTool.
    But it is not ready yet.

    Do you want to add all this constants?

    Code changing around constants on right screenshot is used in preset bitrates as far as I remember.


     

  2. Collapse Details
    #42
    Senior Member
    Join Date
    Aug 2006
    Location
    Colorado Springs
    Posts
    473
    Default
    Actually I'm more interested in the first one (the one with only two constants). If you add all of them, though, I'll run them through their paces.

    Am I right in understanding that the constants on the right are changed according to Presets changes, but not the ones on the left? Which ones? I don't recognize any of the numbers from PTool.

    Chris
    Last edited by cbrandin; 09-16-2010 at 06:45 PM.


     

  3. Collapse Details
    #43
    Default
    Download PTool, all constants added (plus one more 234 constant, used in loop).

    As for Preset bitrate, you can see that it is 234 by default :-) Actually it also involves code changes so always only this option (from all set) will be used.


     

  4. Collapse Details
    #44
    Default
    I also suggest to look at this
    "cmp 0x12D, D0" - slightly above right screenshot.
    If D0 will be larger it jumps to set error code (as I understand).
    Same comparison is right before this error set location.

    Really I do not believe that something very useful can be done changing this constants only (as they are selected based on some bitrate related things, again, look at part above).


     

  5. Collapse Details
    #45
    Senior Member
    Join Date
    Aug 2006
    Location
    Colorado Springs
    Posts
    473
    Default
    Thanks

    Chris


     

  6. Collapse Details
    #46
    Default
    Quote Originally Posted by Vitaliy Kiselev View Post
    Download PTool, all constants added (plus one more 234 constant, used in loop).
    Vitaliy, could you add the latest GH1 AVCHD Research patches to the GF1 side of PTool as well? I've gotten several requests for a GF1 version of the 50Mbps AVCHD Fast Action Patch, and these patches are what I need to support the GF1 as well as the GH1.


     

  7. Collapse Details
    #47
    Default
    Quote Originally Posted by lpowell View Post
    Vitaliy, could you add the latest GH1 AVCHD Research patches to the GF1 side of PTool as well? I've gotten several requests for a GF1 version of the 50Mbps AVCHD Fast Action Patch, and these patches are what I need to support the GF1 as well as the GH1.
    And more specifically? Which ones do you need?


     

  8. Collapse Details
    #48
    Default
    Quote Originally Posted by Vitaliy Kiselev View Post
    And more specifically? Which ones do you need?
    Thanks, there's just one that I need for the GF1 50Mbps AVCHD patch:

    Constant for 720p


     

  9. Collapse Details
    #49
    Senior Member
    Join Date
    Aug 2006
    Location
    Colorado Springs
    Posts
    473
    Default
    Vitaliy,

    I've been digging deeper into the video plug-ins. Here are my findings so far:

    Video_Encode_Plugin is for FHD mode. I'm fairly certain about this.

    Video_Encode_Plugin_0 is for SH, H, and L modes.

    The new patches I asked for appear to be P frame quality settings. If I raise them too high the codec appears to run out of steam easily with big P frames and then eventually empty P frames right before the next I frame. The I frames also appear to be a little too small, like they have been robbed of bitrate allocation. Interestingly, though, the codec appears to only make the last P frame empty - like a GOP value calculation used for individual frame size is off by 1 frame. I think the "pulsing" is caused by this. Making these smaller seems to eliminate empty frames (or, at least reduce their frequency). When I doubled their value absolutely every last P frame before an I frame was empty when shooting a detailed static scene. Also, up until the empty frame the P frame sizes increased the closer they got to the end of the GOP. Without increasing these numbers the P frame sizes were pretty consistent (flat).

    It's the video encoders that appear to be assembling the raw stream for the Mux, including audio. There are a couple of subroutines in them that call the audio encoder.

    Native mode still crashes with a write error. A couple of times, however, there was no crash but the MTS file contained invalid packets. This leads me to believe that we are seeing a buffer overrun caused by an inadequate buffer allocation for full 1080p frames vs half 1080p frames (or, maybe full 720p frames). I'm going to study the invalid frames to see if I can determine anything about the data in them - they appear not to be video data of any kind, they are something else.

    It appears that pulsing and crashing aren't related - they are two separate issues.

    Chris


     

  10. Collapse Details
    #50
    Default
    You can also try to look at frame slices.
    As I understand, encoder do not know about 1080p mode, so use slices sizes for 720p, making too many slices in one frame.


     

Page 5 of 7 FirstFirst 1234567 LastLast

Posting Permissions

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