Video encoding and Bitrate/Quality, Newbie needs help understanding

[budwzr]

AC-3 IS already PCM, so there's no loss converting to PCM, except you lose the surround effect, it's just a remux, no conversion.

[poisondeathray]

Yes I know there's an option for it and believe you me I was all "yay" but indeed it does not work. It adds a flag in the MP4 for players to read that the audio should be delayed by the amount specified. But once again, does not work.

And I've googled it and got the general feeling that it's not generally supported by alot of players.

Sorry, I was wrong. It appears MP4 container is problematic for positive audio delays, only negative delays appear to work (shift audio early)

Or you can use MKV container, where AV delays eitherway will work

But I don't understand why you would have a delay at all, coming out of vegas ? (or why didn't you "fix" it in vegas , or is this now a different topic? )

[jagabo]

Sorry, I was wrong. It appears MP4 container is problematic for positive audio delays, only negative delays appear to work (shift audio early)

How utterly useless.

Or you can use MKV container, where AV delays eitherway will work

A much better option.

[Selur]

> How utterly useless.
Delays can be handled fine with mp4. You simply have to delay the video instead of the audio. (I do that for years without problems.)

> A much better option.
depends on what you need it for, personally I rarely use mkv

[jagabo]

depends on what you need it for, personally I rarely use mkv

I rarely use MP4.

[poisondeathray]

Delays can be handled fine with mp4. You simply have to delay the video instead of the audio. (I do that for years without problems.)

I tested this, and it didn't work (negative delay on the video, since he wants to shift audio later ; or positive delay on the audio)

What muxer did you use ?

[Selur]

What muxer did you use ?

mp4box (normally I use the latest nightly build)
also, some splitter/players do not support mp4box properly and simply ignore some delays (but the same is true for some of the mkv features)

[poisondeathray]

What muxer did you use ?

mp4box (normally I use the latest nightly build)
also, some splitter/players do not support mp4box properly and simply ignore some delays (but the same is true for some of the mkv features)

In my tests, mkv AV muxing +/- delay was universally supported, I couldn't find one, software or hardware that didn't (I tested about 10-15 different ones)

MP4 was never supported for positive audio delay, or negative video delay (but I only tested 6 software players, no hardware players) ; but negative audio delay is ok

I just repeated with MP4 tests the nightly 32bit gpac windows binary, and same results , not even osmo, the included player supported it




Which players, splitter, decoder combination works for you?

[Selur]

I normally use: MPC-HC or MPC-BE with LAV Filters on Windows, SMPlayer or KMPlayer on Linux and MPlayer or Quicktime on Mac, on Android I use BsPlayer and some other player I don't remember atm. (back when I tested only software player that did have problem was VLC, which didn't bother me since I normally don't use it)

[poisondeathray]

Ditto; those are the usual suspects I have at home, but only on PC. And I have a separate test computer setup configured with haali+ffdshow for MP4 instead of LAV

Do they all work for you with a negative video delay ?

To clarify, I'm testing with h.264 / 5.1 AC3 . Maybe something wrong with the streams I'm using , I'll repeat some testing later with differnt streams, maybe use a larger delay to make it more noticable

[Selur]

Do they all work for you with a negative video delay ?

as far as I remember: yes

And I have a separate test computer setup configured with haali+ffdshow for MP4 instead of LAV

I never use haali for mp4 (or avi) only lav or mpcs own splitter.

I'll repeat some testing later with differnt streams, maybe use a larger delay to make it more noticable

If you have a sample with a larger delay, I can also look at it tomorrow, if it doesn't work. (had a nice test sample with a -500ms delay, but I lost it some time ago,...)

Cu Selur

Ps.: http://forum.doom9.org/showthread.php?t=167074 might also be interesting

[poisondeathray]

I never use haali for mp4 (or avi) only lav or mpcs own splitter.

I typically use lav only too for directshow players (if I'm not using mplayer or derivatives like KM), but I have a few computers that I used for rendering configured differently (also used for testing)


Don't worry - It's not that important to me Although I use MP4 for things like web, I rarely have A/V delays for that. And the materials that do have some AV delays, I never use MP4 for... It's more for curiosity than anything else...

Ps.: http://forum.doom9.org/showthread.php?t=167074 might also be interesting

LOL..What a mess... At least the option to do real AV sync (instead of muxing AV delays) will work in all cases

[chrisofsweden]

Ah nice to see I wasn't all wrong about the delay not working (so far most often it's my own questionable understanding of these things that make things go bad)

Anyway, I ended up just installing the FFMpeg dlls for Audacity and just opened the AC3 file and added a 100ms at the beginning and exported it back to AC3. All good now.

I have one tricky question though. When I did this, the AC3 file shrunk with 50%. From 114Mb to 57Mb.
I muxed it together anyway and I honestly can't hear a difference. But there MUST be some sort of quality loss?

[poisondeathray]

I have one tricky question though. When I did this, the AC3 file shrunk with 50%. From 114Mb to 57Mb.
I muxed it together anyway and I honestly can't hear a difference. But there MUST be some sort of quality loss?

You're re-encoding it (and at a lower bitrate) , so yes there is loss

Try delaycut instead as mentioned earlier

[chrisofsweden]

I have one tricky question though. When I did this, the AC3 file shrunk with 50%. From 114Mb to 57Mb.
I muxed it together anyway and I honestly can't hear a difference. But there MUST be some sort of quality loss?

You're re-encoding it (and at a lower bitrate) , so yes there is loss

Try delaycut instead as mentioned earlier

Done did that, simple tool! I like simple Remuxed. Much better now, thanks.

[Cornucopia]

Yes, budwzr was mistaken above, AC-3 is NOT PCM, but using the ffmpeg dlls for Audacity, once it's been imported into the app, the AC-3 has now been decoded into PCM, so when you go back out to AC-3 on export, you are re-encoding, whether you are using the same bitrate as before or not (higher or lower or same filesize). Regardless, you would be losing SOME quality (though it may not be noticeable).

Scott

[budwzr]

OK, it's .WAV then, or ADPCM ? That's what Audacity labels it on the timeline. I can get a screenshot.

Hahaha, I didn't read the whole post because I thought somebody finally outted me, but I'm kind of still in there right? Just a simple foe paw.

Sniff sniff

P.S. I could have bluffed my way through by claiming "That's what I meant...", and just tie in to the same outcome.

[Cornucopia]

Close...It's just not AC-3 anymore once it's actually inside of Audacity. Probably headerless raw LPCM streams (equivalent to WAV, but without the headers/wrapper & chunk packetizing - at least until it were to be saved/exported).
Kind of just semantics, but that kind of difference can be enough to F#%k with your outcomes in this business, as you probably know.
I'm guessing that IS "what you meant".

Scott

[budwzr]

I'm guessing that IS "what you meant".

Scott

Absolutely.

I don't have a lot of deep audio knowledge, but I knew Dolby Digital is an infrastructure, not the actual sound. And I knew that pure clean audio is going to be PCM.

And I always enjoy reading your posts! Very informative.

[Brad]

AC3 is compressed, PCM is uncompressed, and loading AC3 into Audacity is decompressed.

[hello_hello]

I'm probably a little late to the party, but I went through the MPC-HC, MP4, audio delay thing a while back. See this thread.

As per my last post there, the only way I could get MPC-HC to obey the audio delay in MP4 files was to disable it's internal MP4 splitter and use the LAV splitter instead (Haali doesn't work correctly either).

I still don't fully understand the cause of the problem (I pretty much never use MP4 myself) but it appears audio delay implementation in MP4 files is a bit of a mess. For MP4 the best method is to probably re-encode the audio while manually adding the required delay as blank audio to the beginning.... or is there any easy method to append blank audio to the beginning of an existing stream without re-encoding it, using something like eac3to or DelayCut?
Or use MKV instead. I've never noticed a problem with MPC-HC ignoring the audio delay in MKV files.

[Selur]

or is there any easy method to append blank audio to the beginning of an existing stream without re-encoding it, using something like eac3to or DelayCut?

DelayCut should work if it supports the audio format,...

it appears audio delay implementation in MP4 files is a bit of a mess

not especially,.. I mean nearly all container implementations have their tricky parts, the problems is that if you miss something on first implementation it's not always easy to adjust you existing code, which is probably why Haali&MPC still lack proper MP4 support in this regard.


Cu Selur

Ps.: as a side note: Avoid using ffmpeg for mp4 creation (always run ffmpeg created mp4 content through mp4box/l-slash/mp4creator) since ffmpeg is known to sometimes mess up.

[hello_hello]

not especially,.. I mean nearly all container implementations have their tricky parts, the problems is that if you miss something on first implementation it's not always easy to adjust you existing code, which is probably why Haali&MPC still lack proper MP4 support in this regard.

Is Haali still being actively developed?
To me it's kind of odd that a player such as MPC-HC, which is actively developed, still has a problem with MP4 audio delay. It seems to date way back to the old MPC days. You'd think the use of the MP4 container is commonplace enough for someone to decide "we really should fix this", but then again, I've no idea what's involved in doing so.

It does make me wonder why lots of people aren't complaining about it though. I mean, I noticed the problem and MP4 would make up about 0.001% of my video collection.

[Selur]

Is Haali still being actively developed?

kind of, see: http://forum.doom9.org/showthread.php?p=1623522#post1623522

It does make me wonder why lots of people aren't complaining about it though.

a. most people don't create content, they just consume
b. delay can change due to reencoding (encoder delay), this can either compensate or heighten existing delay
c. a lot of people don't realize if their content is +/- 120ms off regarding delay
d. even if you create/reencode content, yourself depending on the tools you use and how you configure them you don't have to worry about the delay, since it is automatically compensated by the tool. (Hybrid in example, offers an option to compensate the delay through delaycut, assuming the input format is supported by delaycut.)
e. most of the time you don't need to delay the video stream since, the delay is in the other direction

Cu Selur

[chrisofsweden]

Thank you all for your contributions to this thread. The project was completed on time and the end result turned out great in the end! All of my friends super enjoyed the film (The project was a skitrip with 6 friends of mine).

In the beginning of the thread I talked about size of the final MP4 as an important factor but I soon realized it wasn't possible to keep my 40 minutes below 4GB and still delivering the HQ that I wanted. I'm a bit of a perfectionist I suppose. When I, close to the projects end, realized I wasn't coming anywhere near 4GB, I cranked the CRF value instead to come close to a 8GB limit instead. Think CRF 14 was used.

Another reflection; I never really understood what the x264 speed presets did except for the impact on file size, and the obvious speed difference.
Does the very slow speed preset also encode/compress in a more effective way but also making it harder for computers to play back/decompress?

I tried playing the film on my Acer Aspire One NetBook (AMD C-50 Dual Core 1Ghz) and it choked within 3 seconds. Playing the raw 1080p footage from the camera is fine for 30fps. It has no problems with regular 1080p movies either. The final render ended up beeing ~24Mbps. That means the HDD has to deliver ~3Mbyte/s which I have a hard time believing it would have a problem with.

Anyone know if I'm correct? If I would have encoded with speed preset very fast instead, would it have been easier to play back for the low end comps?


I would have liked to let you watch the final video, my very first project, the baby that you all helped deliver But I don't think all of my friends who are in the film would be comfortable being uploaded to the internet. But anyway, I thank you all! I'm now here to stay.

/Chris

[jagabo]

I never really understood what the x264 speed presets did except for the impact on file size, and the obvious speed difference.
Does the very slow speed preset also encode/compress in a more effective way

Yes. The higher the preset the more exhaustive the search for ways to compress the video, and with better quality.

but also making it harder for computers to play back/decompress?

I don't know about that. Surely some of the advanced features may take more CPU power to decompress. On the other hand it can take less time to decompress less data.

I tried playing the film on my Acer Aspire One NetBook (AMD C-50 Dual Core 1Ghz) and it choked

That could be a hardware limitation -- if the netbook is using the GPU to decompress the video it may not support some of the advanced features of h.264 (too many consecutive b frames, too many reference frames, etc.). You'd have to try modifying individual parameters to see what's causing the problem.