Jump to content

RieGo

Members
  • Posts

    30
  • Joined

  • Last visited

About RieGo

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

RieGo's Achievements

Member

Member (2/5)

24

Reputation

  1. thanks a lot for the detailed explanation. i really enjoyed reading through it! I guess you have to rethink this. the camera doesn't actually encode 120 frames per second. it encodes 30 frames (my tests showed it's probably 25 frames) in one second of realtime. once it finished (or more probably also while) recording it tells the container that this, say 1000 frames, should be played back at 120f/s. which makes it basically really fast -> timelapse. camera didn't have to do any more work than in 30p. btw take a look at http://***URL removed***/forums/post/57866447 for framerate/resolution/slot tests and sample files
  2. just in case anyone missed it and wants to help: vasile started a gofundme for a sacrificial hack camera. all details here: https://www.gofundme.com/22d7kj8
  3. true. also many people are watching it on 1080p monitors, which obviously downsamples as well....
  4. i completely forgot about this! so what do nx500 people think?
  5. regarding the sharpness: i'm starting to believe -10 = no post sharpening, like someone else suggested. i did some tests with many details and sharpening -10. i couldn't find any interpolated edge sharpening, which is usually visible by ringing artifacts. my consumption: the oversharpening some are seeing is a result of a downsampler, probably bicubic ... is there a way to change this? i don't know.
  6. so there is a little misconception: the higher the bitrate/quality the encoder has to output the more work he has to do. so it's usual (at least in my experience) for encoders to get slower while bitrate increases. you can try a simple x264 crf 18 vs x264 crf 30 to see what i'm talking about. also don't forget: a major quality decrease at 120p compared to 30p/60p comes from no full sensor readout, which also makes it harder to compress because of more noise.
  7. i manually worked through all values by inputting them and looking at the camera icon. don't know if there's an easier way... btw: ignore the "seems like 9 sets it to fhd24" was a misconception 9 is just undefined like any other value >14
  8. This is still true. the final file HAS 180MBit/s so they ARE used. This is no fill up data or anything like this.... well i can't proof that, but i'm pretty sure there is no such thing as filling data in mp4 containers... only television packets use filling data because they have to use a defined constant data rate. sorry, that was a lot of "filling data" but "filling data" is the only way i know to make bits disappear
  9. alright, my bad. anyways "resolution show" doesn't give any output on terminal. maybe it's just in log or something... i'm just running the video tests. just looks like a bunch of small videos in different resolutions... btw: at "basic" and "full" test my battery turned from 50% to 0% in like 5 minutes until camera turned off... maybe that's part of the test or my battery is broken
  10. just tried "st app nx record start" and "st app nx record stop". works just as expected, starts and stops video recording. but i have no clue how to use the resolution parameter... i tried but couldn't get to change anything. is this even what you are thinking about? i have no clue resolution [show,name] -> this arguments seem like only predefined resolutions can be used
  11. MOV_SIZE on NX1: dc24p=0 uhd30=1 uhd24=2 uhd23.98=3 fhd120=4 fhd60=5 fhd30=6 fhd24=7 fhd23.98=8 hd60=10 hd30=11 vga60=12 vga=13 mjpeg=14 i think i give 9 a try lol -> seems like 9 sets it to fhd24 btw: someone did the same for NX500 at dpreview: http://***URL removed***/forums/thread/3985980
  12. that's doable. i can upload my nx1 rootfs dump and you can do whatever you want with it. or maybe someone else. i haven't looked at it very much. http://www14.zippyshare.com/v/H7PRdH4S/file.html btw: an nx500 dump would be nice to see, so we could compare stuff...
  13. it SHOULD not make any problems. it's disabled on mine since that hack came up. but please make sure to follow the manual closely. you don't need to disable recording limit for this.
  14. averaging two frames should be completely equal to doubling the shutter time. i think we can agree on that if you're into avisynth: qtgmc contains a part where it can simulate motion blur, i.e. when you discard one field on interlaced source, making it half shutter angle. OR when you set your shutter speed too high, cause this is something that's not as easy. but that's a very exceptional case...
  15. yeah, i didn't know that this is available on average cameras. this is new to me. 1/30 is no hardcoded limit, as it's 1/25 (i think) on 24p and pal 25p, so it's linked to video framerate
×
×
  • Create New...