Problems encoding long-running mp4s

808Veg wrote on 8/14/2010, 6:45 PM
I have been encoding some hour+ long SD AVI files to mp4 and have been coming up with files that cannot be played. With some experimenting I found that if the AVIs are less than 30mins, the mp4s play fine. I am using the Main Concept AVC encoder with VBR at 8M and double pass. I am using a WD TV Live player to play the mp4s but even Quicktime will not play the long files. When I use Handbrake to encode to mp4 the long files work fine but I prefer to render out of the timeline because I can do some corrections before rendering. I thought maybe the filters did something to corrupt the output but even just straight AVIs does not encode correctly if they are over 30 mins. I am using V8c.

Comments

musicvid10 wrote on 8/14/2010, 8:15 PM
I too have WDTV Live, and do all of my editing in Vegas, and then encoding in Handbrake for a number of reasons.

I have taken to using MXF 25 as my intermediate, and I am really pleased with the results (other intermediates either don't work or have the x264 colorspace bug).

But to your original question, I will take a long file and encode it in Vegas to see if I can duplicate your problem. I too have 8.0c. If you will post the complete render settings including resolution it will eliminate other variables.

I would not use Quicktime player to view anything, ever. VLC and SMPlayer are both better alternatives.
Cohibaman wrote on 8/14/2010, 11:56 PM
Musicvid, I was wondering to your reference "other intermediates either don't work or have the x264 colorspace bug" if you don't mind expanding on this quote, as to what you mean by the "colorspace bug", thanks, in advance.
808Veg wrote on 8/15/2010, 12:25 AM
Thanks musicvid. I too am curious to understand more the concept of the intermediate.

Anyway, here are my encoding specs:

Rendering quality - Best
Frame size - 640x480 NTSC square pixel
Profile - Baseline
Frame rate - 30
Pixel aspect ratio - 1.0
VBR - max-12M, avg-8M with 2-pass
Audio - 48k @ 128bps
amendegw wrote on 8/15/2010, 6:59 AM
This is just a guess, but you may need to apply mp4faststart (or a similar utility that re-arranges the mp4 moov atom).

Good Luck!
...Jerry

System Model:     Alienware M18 R1
System:           Windows 11 Pro
Processor:        13th Gen Intel(R) Core(TM) i9-13980HX, 2200 Mhz, 24 Core(s), 32 Logical Processor(s)

Installed Memory: 64.0 GB
Display Adapter:  NVIDIA GeForce RTX 4090 Laptop GPU (16GB), Nvidia Studio Driver 566.14 Nov 2024
Overclock Off

Display:          1920x1200 240 hertz
Storage (8TB Total):
    OS Drive:       NVMe KIOXIA 4096GB
        Data Drive:     NVMe Samsung SSD 990 PRO 4TB
        Data Drive:     Glyph Blackbox Pro 14TB

Vegas Pro 22 Build 239

Cameras:
Canon R5 Mark II
Canon R3
Sony A9

musicvid10 wrote on 8/15/2010, 8:06 AM
"if you don't mind expanding on this quote, as to what you mean by the "colorspace bug", thanks, in advance."

http://forum.handbrake.fr/viewtopic.php?f=11&t=17364
It's similar (identical) to the issue Nick Hope raised with using x264 in Avisynth last year.
Unfortunately, there is not a command line parameter in Handbrake to fix it.
Don't know if they are planning a fix or not.