VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Page 4 of 4
FirstFirst ... 2 3 4
Results 91 to 116 of 116
Thread
  1. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    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.
    Quote Quote  
  2. Originally Posted by chrisofsweden View Post
    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? )
    Quote Quote  
  3. Originally Posted by poisondeathray View Post
    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.

    Originally Posted by poisondeathray View Post
    Or you can use MKV container, where AV delays eitherway will work
    A much better option.
    Quote Quote  
  4. > 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
    Quote Quote  
  5. Originally Posted by Selur View Post
    depends on what you need it for, personally I rarely use mkv
    I rarely use MP4.
    Quote Quote  
  6. Originally Posted by Selur View Post
    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 ?
    Quote Quote  
  7. 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)
    Quote Quote  
  8. Originally Posted by Selur View Post
    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?
    Quote Quote  
  9. 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)
    Quote Quote  
  10. 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
    Quote Quote  
  11. 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
    Quote Quote  
  12. Originally Posted by Selur View Post
    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
    Quote Quote  
  13. 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?
    Quote Quote  
  14. Originally Posted by chrisofsweden View Post
    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
    Quote Quote  
  15. Originally Posted by poisondeathray View Post
    Originally Posted by chrisofsweden View Post
    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.
    Quote Quote  
  16. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    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
    Quote Quote  
  17. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    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.
    Last edited by budwzr; 12th Apr 2013 at 19:13.
    Quote Quote  
  18. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    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
    Quote Quote  
  19. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    Originally Posted by Cornucopia View Post
    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.
    Quote Quote  
  20. AC3 is compressed, PCM is uncompressed, and loading AC3 into Audacity is decompressed.
    Quote Quote  
  21. 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.
    Quote Quote  
  22. 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.
    Quote Quote  
  23. Originally Posted by Selur View Post
    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.
    Quote Quote  
  24. 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
    Quote Quote  
  25. 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
    Last edited by chrisofsweden; 15th Apr 2013 at 03:43.
    Quote Quote  
  26. Originally Posted by chrisofsweden View Post
    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.

    Originally Posted by chrisofsweden View Post
    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.

    Originally Posted by chrisofsweden View Post
    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.
    Quote Quote  



Similar Threads