Quality of Processed Video

[gbeyer]

Using v1.36.33. I am using Monitor / Storage /Encode so that I can get date/time stamp on my videos, not just live and thumbnails. Which does work. Output is h264 and Encoder is libx264. However, when I view event videos, the quality is not nearly that of what it was with Camera Passthrough. I did set crf=1 (down from the default of 23). But that seems to make no difference in quality. Is there somewhere else where I can set the quality of the recorded event vids to be as good as what they were with passthrough? Thanks much!

[mikb]

Using v1.36.33. I am using Monitor / Storage /Encode so that I can get date/time stamp on my videos, not just live and thumbnails. Which does work. Output is h264 and Encoder is libx264. However, when I view event videos, the quality is not nearly that of what it was with Camera Passthrough. I did set crf=1 (down from the default of 23). But that seems to make no difference in quality. Is there somewhere else where I can set the quality of the recorded event vids to be as good as what they were with passthrough? Thanks much!

For crf -- 0 is truly lossless. But that seems to be rather extreme as 18 is allegedley "lossless to the human eye" (see also .mp3, .jpg ... lossy, but not noticeably when done right). So 23 as a default shouldn't be trashing your video. If the crf parameter isn't being used, could you have a -b parameter for BITRATE control which overrides it? You would need to increase or remove the bitrate limit.

[gbeyer]

Thanks mikb. In the Optional Encoder Parameters box the only entry there is crf. The first three lines are # commmented out explanations.

[mikb]

Hmmm. Comparing a video recorded in passthrough, versus one recorded with recoding, what does

Code: Select all

ffprobe /path/to/video.mp4

say about the video bitrates, are they really hugely different? Pick out the line with Video: in ... e.g.

Code: Select all

Stream #0:0(und): *** Video: ***  h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 480x360,  *** 150 kb/s *** , SAR 1:1 DAR 4:3, 25.02 fps, 25 tbr, 900k tbn, 180k tbc (default)

[gbeyer]

Here's the result of ffprobe comparison:

Passthrough video

Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 1520 kb/s, 22.04 fps, 100 tbr, 90k tbn, 60 tbc (default)

Encoded video

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 480x270, 1891 kb/s, 30.09 fps, 29.97 tbr, 90k tbn, 2000k tbc (default)

[mikb]

Here's the result of ffprobe comparison:

Passthrough video

Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 1520 kb/s, 22.04 fps, 100 tbr, 90k tbn, 60 tbc (default)

Encoded video

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 480x270, 1891 kb/s, 30.09 fps, 29.97 tbr, 90k tbn, 2000k tbc (default)

OK. That makes NO sense at all -- your original unmolested video is 1920x1080 at 1.5Megabits per second from the camera.

Your recoded video is 480x270 (so hugely lower resolution/pixel count, did you INTEND to scale it down that small? 25% size? That might make it look a bit ropey if blown up to HD) but is at a HIGHER bitrate than the original! (1.89Megabits/second).

My gut reaction is that with *more* bits per second being used for a one-sixteenth area image ... you really shouldn't be having low-quality problems. Maybe soft/blurry (because of low pixel count), but bitrate isn't your problem.

[gbeyer]

Yes, I did intend to scale it down, under advice of @burger. He/she also put that suggestion into the "dummies" wiki article. So I'm a dummy in this kinda stuff, I admit it. I do what I'm told to do by folks who know better.

[mikb]

Yes, I did intend to scale it down

Fair enough, just checking it was intended and not accidental! ... Inevitably there will be SOME quality loss from reducing HD down to a quarter of the X/Y resolution.

I hope someone reading this can see the lunacy -- that a lower-pixel count stream of HIGHER bitrate than the FullHD source looks ropey.

It doesn't seem right to me either. crf parameter working or not!

[gbeyer]

Maybe I'll try to bring up the pixels. Maybe 1/2 instead of 1/4 the size, see what happens.