H.264 codec or equivalent?

I’ve been getting low-res results with prepping files for YouTube. YT is big on H.264 but I don’t see it explicitly named in setting up rendering the project. Where is it, or what’s the equivalent? Related to that, I think: what exactly does the “quality” setting do - I kinda can roughly what it does from the name, but a better explanation would help. [/smile]

BTW all of this with the Linux version (I was using the Win10 version previously).

I suspect as with JPEG IQ the quality setting relates to how much compression is applied.
For example, 60% quality would indicate that 40% compression will be applied. This will work in conjunction with the Rate choice (bitrate)

1 Like

Doh… I should have spotted that codec.

I’m currently rendering a 100% quality project. I’ll report back with the results. It’ll be a while, this poor machine is only slightly faster than a steam-driven abacus. Sigh…

Um… there’s more pixelation than on the original material. At 1080 and 30 fps (not 60) crispness while moving isn’t that great, but the rendered output is disappointing. There’s a lossless H.264 listed in the export list, too. Rather than spending a lot of time watching clips render sooooo sssslllloooowwwwllllyyyy, can anyone help me cut to the high res chase? The project will go to YouTube, who’ll do their usual image-destroying compression. I’m hoping that really clean high res video won’t suffer quite as much.

Surely you don’t expect there to be less than the source??

What are your source files from? Which codec is used and what are their bitrates?
You need to start with source material at least 15Mbps bitrate if you want to upload HD (1080p) footage to youtube. If your camera can’t manage that then you’ll need to use SD (720p)

Oh, no, I expect the same level of pixilation, coming from ShotCut. Once the video hits YouTube, yeah well…

The source is/are the file(s) sitting on the camera (Sena Prism - motorcycle helmet cam).

It’s the export codecs that I’m struggling with. The playback screen shows things basically as they appear when played back by VLC or Videos (Linux video playback app). I’m lost on where you see the bitrate bottleneck.

It’s a lossy format, you not going to see the same level of pixelation you will see marginally more unless you go for lossless export and no filter use.
A tiny 5mp sensor helmet cam (similar to an older smartphone) has next to no dynamic range or room for editing, therefore as soon as you tweak brightness/contrast/saturation/sharpness or color grading you will degrade the output.
Not to mention that recording a bike ride which has a lot of detail whizzing past, you’re definitely going to get a breaking up and smudging of the detail.
I’ve reviewed some of the Sena Prism Bluetooth cam files on YouTube and they are typical of all dashcam/action cam files. Adequate for the purpose by very low quality with lots of artifacting of course (yes, we can blame YouTube for some it )

You can use ‘MediaInfo’ to see what the bitrate the source files are.

Basically, the higher the bitrate of the source the better the resolution [detail] captured and the more wiggle room you have for tweaking in post. Of course you can’t export at a higher bitrate than the source and expect better IQ.
In short, the better the source quality the better the export (in spite of what the Shotcut preview window shows).

Any chance you can upload a 60 sec sample from the camera?

I wish the Prism were 5Mp! Sena calls it 3.5Mp. [/frown]

I’m trying to get a clip uploaded to Photobucket, but they may well decide to compress the file further than .zip did.
Unfortunately I don’t have a good way to stop that.

Plan B is a promo series from Sena. The bike footage is identifiable relative to the …uh… non-bike footage. However, what they show is a fair representation of raw footage. 60 fps will definitely improve things, but that’s not what Sena did. The control from the 20S intercom is a very strong plus for the system.

Sigh… photobucket seems to be “helping” the file - at least they’re being terminally slow. Grrrr
ADDED: Forget it - Photobucket won’t take a 75M file. I’ll try Dropbox tomorrow.

Anyway, check out the snippets in the promos for at least a hint of what comes from the camera.

The camera is pretty good with color balance and exposure. I’ve shot some stuff very late in the afternoon, and it came out fine. Opposing headlights bloom a bit, but there’s no vertical streak from a row or column being saturated. Ditto for shooting into the sun. There’s a large, round patch of glare but, again, no signs of the overall sensor being overwhelmed. I’ve also shot some time lapse with 1/30 sec. exposures, usually with the sun crossing the FOV. No worries - the sky keeps the same color and ditto for a neutral grey railing in the picture. Bottom line: not bad for a $250 camera.

In any event, using zip compression won’t make much difference as your video files are heavily compressed already.

FPS doesn’t improve quality, only how many frame are captured per second. In fact, you might get worse IQ because the processor needs to do more work to process those extra frames coming off the sensor.
Experiment. 60FPS will let you do some slo-mo in post though.

Yes, that will be better.

It’s 5mp. It depends on the aspect ratio you’re capturing at as to how many pixels it crops to.

Sigh… Sena listed 3.5 Mp in one specs page, and, as you posted, they think it’s something else in another. Their products are pretty good, but their communications leave much to be desired(!). Moving on…

Took a look, with MediaInfo, at the video that’s the center of my questions and got back the following (how do I do an attach - no a link??):
11.1 mps - 1920x1080 (16:9) 29.97 fps, AVC (main@L4) (CABAC/2 Ref. Frames) Ambarella AVC

Nothing seems to be obviously wrong here.

I haven’t forgotten about putting something on Dropbox - life is just interfering…

Deleted as the forum software has placed the message chronologically incorrectly…

Now somewhat redundant, but here’s the full report:

Here’s sample from the original video on the camera and edited (filtered for lens correction. which zooms slightly)

Try these 40 second clips for a sense of standard camera output.

Well the footage is as I expected for this type of camera, lot’s of compression artifacts and micro blocking where there’s detail and movement. The encoder is using variable bitrates which sacrifices detail when the bitrate drops so that the processor can keep up. As the human eye can’t see this easily when the video is playing at 30fps it is generally acceptable for viewing, but not at all good for editing…
Lens correction is definitely going to degrade the quality owing to the zoom factor alone, however from your screenshot it also appears you may have exported with a lower than 60% quality.
Trying to edit such footage is going to be a compromise but is in no way a direct result of using Shotcut,

I’m confused about which of your comments apply to which samples.

In general, the photo without filtering is acceptable, given the circumstances. The processed sample is much like the nozzle end of a working vacuum cleaner…

Since Dropbox doesn’t seem disposed to “improve” the zips’ content, I’ll put up a clip from the source and processed material that was in the photos. However, I’ll leave out filters and use 100% quality for the rendered version.

For the finished video, I obviously took the render settings as gospel, and not as a suggestion - my error.

I’m referring to the OOC video samples you posted to Dropbox, what else could I be writing about?

Please explain this comment.

This will result in a file size many times larger as there will be zero compression applied, but won’t improve the quality in the slightest.
Remember, your OOC (Out Of Camera) files are already heavily compressed. They are Decompressed when open in any video editor (just as compressed JPEG images are decompressed when opened in any photo editor).

The default settings are generally based on best output and give good results I have found. But if you apply any filter it will degrade the quality, if you zoom even the slightest amount you are amplifying [magnifying visually] the original artifacts and also invoking interpolation which adds pixels in order to fill the 1920x1080 space. This always results in more ‘mushiness’ [smearing].

In short, my conclusion is that your footage is not forgiving of editing because it is low quality highly compressed video from a tiny sensor in the first place. Play one of those video files and pause it, you can see lot’s of pixelization, smearing and other compression artifacts, so you’re starting with a poor quality source file to begin with.

Example: Here’s a still taken from your original video file, with a crop which highlights your problem with your source.
1920x1080 frame capture.

100% crop

Try as you may, you will never get results even the same as this once edited (especially with filters applied) then re compressed for export. Of course you then have Youtube to contend with. You might find that you need to export at 720p [SD] for more acceptable results.

Sigh… I seem to be fighting with entropy and entropy will not be denied…

Great thanks for all of your help. I’ll leave up the files to date for a while before doing some housecleaning.

If the camera has the options, lower the contrast, sharpness and saturation to absolute minimum to give the flattest [dullest] look possible. This will give the processor less to do and can often result in files which are better for editing.

This camera, unlike GoPro, for example, is very much one-size-fits-all. The only video options are video, single shot, burst shot, or time lapse. The later does look pretty crisp. I’ve done sky watch videos that catch jets leaving contrails (at 10 fpm, they zip by like bullets in a Matrix movie). V. crisp indeed.

The big selling point is hands off control. Hands off is worth a lot once a camera is squared up on a helmet. Tapping the stop/go button often does Bad Things to alignment.

Ya pays yer money, ya takes yer choice…

Yes, Time lapse will always look heaps better as it only has to deal with one single shot [frame] at a time every ‘x’ seconds rather than 30 shots per second for 30fps video.