HandBrake

BradleyS wrote: ↑

Mon Sep 24, 2018 4:35 pm

The file does not open in QuickTime Player on macOS 10.13.6. I'm not seeing anything of substance indicating it's an MP4 container aside from the file extension.

Ah, I just assumed it was that old problem again. Seems it is a mis-named PS file that we just fail to see any video stream in.

This is another case of our PS demux mistakenly recognizing an mp4 file as PS. I won't have time to do a deeper dive to see if there is anything we can do about it for a couple of weeks. But this should be added to a github issue so it doesn't get overlooked.

This discussion comes up all the time. Every framerate can't be represented perfectly by the clock HandBrake uses internally. HandBrake uses the standard 90khz clock used by all transport streams and program streams. This is the same clock used by all broadcast TV, Blurays (including UHD), and DVDs....

Correct

It's not possible. There are lots of complications when dealing with multiple directories of files. I chose not to deal with those complications when initially writing batch support and haven't had the motivation to go back and work through the issues to enhance it.

To be clear, we are not against SRT passthru support. It's just not high on anyone's priority list and there are lots of other interesting things to do.

Ugh, I stated something backwards. "Align A/V start" *prevents* the insertion of an "empty edit". Empty edits confuse some players.

Previous post edited and corrected.

..and may be you know why these "pro tool" (like AE) while being such a PRO could possibly get wrong one of the most popular video format on earth? The "mp4 spec" is a bit of a mess. Apple created it's QT spec based on mp4 and did things their own way for a very long time. Then there is the officia...

Is this an intermediate file that you will be re-encoding again? If so, why placebo? For intermediates, it's a whole lot faster to just use more disk space to preserve quality. Even if it's not an intermediate, placebo has it's name for a reason. The amount of gain you might get with placebo can be ...

For SD content, you are starting out with a low quality source. If you want to refrain from degrading much further, you use a lower RF. For HD content, you could apply the same logic as above. I.e. "you want to refrain from degrading it much further". But this is overkill for the vast majority of pe...

1. Ultrafast is "less effecient" at compression. What this means is that for a given desired quality, the filesize will most likely be larger. The quality slider only provides a rough control of the actual output quality. Changing other settings (e.g. changing from placebo to ultrafast) slightly cha...

I had a look at the files you supplied. Both the uncompressed and encoded version have 968 video frames. When I single step through both the original and encoded version, I see the logo appear at frame 14 and hear a blip at frame 17 (playing back with mpv). If I had to guess, AE is ignoring or not p...

Hmm, I wonder if the nightly build would make any difference. It's a different avi demux.

Can you supply a source sample we can test with and see the problem first hand?

BTW, just right now I've encode 4 videos and everything is fine. They all were rendered from AE into uncompressed avi, 23.976, grainy. But they all have video and audio right from the very 1st frame and they all are very short (~1 min). Can you post another log of one of these videos that encoded c...

After Effects may be broken. This is why I ask. Have you tried other players and stepped through the video. VLC would be a good option.

The encoded output definitely has 6811 frames, from your log: [00:03:46] mux: track 0, 6811 frames, 1304093854 bytes, 36725.28 kbps, fifo 512 This line in the log comes from the muxer (very last stage in the encoding pipeline). It counts every frame that gets output. How are you determining the numb...

If you run your own tests (as MiniSiets has done), you can see the difference in both quality and file size of 10 bit vs. 8 bit encoded content even when starting with an 8 bit source. The visual differences are most pronounced in flat-ish backgrounds and darker areas where an 8 bit encode will typi...

Do you know how many frames are actually in your original video? The log says the duration is 4:44.07 (284.07 seconds). At a framerate of 23.976, that's 6810.86232 frames. The log reports that 6811 frames were output. So the numbers all add up. Nothing missing according to what's reported in the log...

Ahh, that explains it. DVDs can have CC "tracks". CC are special in that they are not really separate tracks at all but are embedded in the the video track. HandBrake detects their presence and presents them in the UI as a subtitle "track" and labels the track "Closed Caption". CC are text and HandB...

To clarify Woodstock's comment, DVD (and BD PGS) subtitles are images. SSA is text. To convert from the images to text requires optical character recognition which HandBrake does not do. We require an activity log of your encode to help you further. Your description of your problem makes no sense be...

The title is sometimes available depending on the source. BD and DVD often (but not always) store the title in the volume info. Other formats often have the title in metadata tags. The CLI doesn't show this by default, but there is a "--json" option that outputs status information including the full...

HandBrake has no such error code and I've never seen that value emitted when running HandBrake.

The log shows that it created 2 audio tracks and that data was written to those tracks. There are not other similar reports, so it's unlikely that the data is all silence. But maybe you gave us the wrong log? You said the audio is mp3, but in this log the source audio is AAC and the 2 output tracs a...

What mduell said... Also, I've never seen hard telecine in a 23.976 fps source (it's soft telecined if it's a DVD source). It would be very unusual for there to be a mix of hard and soft telecine in the same source.