HandBrake

Description of problem or question:

I have a number of screen recordings made using Quicktime where I have already used QT to trim them. You can't control QT's screen recording bit rate so the files are big - so I want to convert them to mp4 files with the same frame rate but lower bit rate. That's all fine. Trouble is when I do it some frames appear in the mp4 at the start which have apparently been removed in the QT edit. I presume that's because QT can only cut at a key frame so the mov container simply instructs the QT player to ignore the first X frames. I have validated that theory by playing the mov files in VLC, which upon opening start at the correct point but you can scroll back to see the unwanted frames. However, when reencoding Handbrake doesn't appear to take any notice of the 'don't play these frames' instruction and encodes them. Is there any way to force it to take notice of the container instruction so it doesn't encode the unwanted frames? Or failing that, any way to find out how many frames to manually tell it to skip? I can't see any way in QT or MediaInfo to find out how many frames the player is being instructed to skip.


Steps to reproduce the problem (If Applicable):




HandBrake version (e.g., 1.0.0):

1.1.0


Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):

MacOS 10.13.4


HandBrake Activity Log ***required*** (see How-to get an activity log)

Could you please post your logs, instructions can be found here:

https://handbrake.fr/docs/en/latest/hel ... y-log.html

An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.

My request is for general advice on how the Quicktime .mov container works, not a specific technical issue with a technical cause within Handbrake. My log cannot be of any possible value here and means i have to re-make an mp4 for the log to tell you anything!

Anyway, forget it, I'll go and find another forum where people are actually helpful.

Firstly, Logs are stored to disk, so no need to re-encode.
Second, I'd want to see exactly what HandBrake / The decoders did and any errors/warnigns it produced before making any recommendations. Heck,t here could even be a bug in the decoder here. I don't know.

OK, apologies for being [Censored] - I just really dislike revealing facts about my system on a public board - or even privately to moderators. I can live with it when it seems essential, but I guess I'm just paranoid!

I've put the log file for one encode that did this in here:

https://www.dropbox.com/sh/32wyo0tp5sh3 ... lzEna?dl=0

But my feeling is that this is expected behaviour. I have found the seconds offset thing, but that only seems to work in whole seconds? So I either have five frames I don't want or lose 20 that I do!

Obviously now I know about this I won't bother trimming the movs in future, but as the offset tool is a bit clunky (as you have to calculate the end point in seconds), it's a bit of a nuisance.

Duration: 00:56:25.53, start: 0.666667, bitrate: 10109 kb/s
[08:23:39] sync: got 184089 frames, 184092 expected

So, it ended up 3 frames short of the total. The above seems to suggest it should have been ~20 frames. (Bit of a guess as I think your content might be Variable Framerate)

If you know the number, you could try setting the "Range" option on the Source row to the first keyframe and encoding. Might require some experimentation with short encodes though.

Does look like there is a bit of an issue handling this though that could probably be fixed.

Content is indeed variable frame rate. AFAIK you don't get to choose with QT - it does what it thinks best with screen recordings, so the frame rate varies between 10-ish and 60fps.

If my theory is right that the mov container contains the instruction where to start playback, all you would need is for that to be picked up by Handbrake.VLC seems to detect it and start in the right place, but will let you scroll back to the unwanted frames as well.

tsp1965 wrote: ↑Sun May 13, 2018 7:36 amHowever, when reencoding Handbrake doesn't appear to take any notice of the 'don't play these frames' instruction and encodes them. Is there any way to force it to take notice of the container instruction so it doesn't encode the unwanted frames?

tsp1965 wrote: ↑Sun May 13, 2018 12:27 pmMy request is for general advice on how the Quicktime .mov container works, not a specific technical issue with a technical cause within Handbrake.

I call BS! You're literally asking about a specific technical issue with a technical cause within HB. How the QT container works is not relevant when HB doesn't support that QT container feature.

tsp1965 wrote: ↑Sun May 13, 2018 12:27 pmmeans i have to re-make an mp4 for the log to tell you anything!

Which demonstrates you haven't made even the slightest effort to read the linked to documentation.

HandBrake doesn't support mov edit lists, so every mov trimmed with QuickTime won't convert properly in HandBrake.