Adding lossless audio to video / replacing audio track

[poisondeathray]

I don't understand - The original calculations in the earlier post #52 make sense to me, that's what I would use. That should match perfectly for length. I wouldn't make the audio shorter, certainly not 100ms shorter. Why are you saying there should be "more" after the end ?

My reasoning is this: Let's say VirtualDub and FFMPEG are giving me a longer video duration than it actually is (for whatever reason). In that case, by making my audio have the same duration as the supposed video duration, I'd be literally making the audio track longer. And seeing how longer audio than video could lead to problems, I assumed it would be "safer" to leave a little room at the end. If not 100 ms, then maybe 50 ms.

Perhaps my reasoning is faulty.

In VLC it played back perfectly though.

either "overhanging" audio or video can potentially cause problems.

What makes you think longer video duration ? The fact that 2 different software give you the same duration should give more support that it's the correct value

You can figure it out by math too. You have a frame count, and a fps. Framecount/FPS will give you the actual duration .

[Jacobson]

either "overhanging" audio or video can potentially cause problems.

I believe you.

What makes you think longer video duration ? The fact that 2 different software give you the same duration should give more support that it's the correct value

I know, but it's mostly what comes after the last "000" that bothers me. Because I don't see the rest of the "length". Maybe this sounds a bit crazy, lol.

You can figure it out by math too. You have a frame count, and a fps. Framecount/FPS will give you the actual duration .

Thanks, great idea. I'll try to figure that out tomorrow.

By the way, when fusing the video and audio together, while at the same time converting MP4 to MOV, I get some "yellow" messages from FFMPEG, although the result is fine at the end:

Guessed Channel Layout for Input Stream #1.0 : stereo

[mov @ 04fa1880] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codepar instead.

[mov @ 04fa1880] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly

Is this bad? Do you know what this could mean?

[Jacobson]

Alright, I didn't want to go to bed before trying your Framecount/FPS advice:

VirtualDub lists frame count as 3113.

Frame rate is 29.970 fps.

3113 divided by 29.970 = 103.8705372038705

Not sure what this is telling me. I assume I now have to use another formula to convert this number to find out the duration?

[poisondeathray]

Alright, I didn't want to go to bed before trying your Framecount/FPS advice:

VirtualDub lists frame count as 3113.

Frame rate is 29.970 fps.

3113 divided by 29.970 = 103.8705372038705

Not sure what this is telling me. I assume I now have to use another formula to convert this number to find out the duration?

It's seconds. But the "actual" NTSC frame rate is 30000/1001. It reads as 29.97 because it's easier to show on a screen

(3113 frames) * (1 second/ 29.97 frames) ~ 103.8705 second

But

(3113 frames) * (1 second/ 30000/1001 frames) ~ 103.8704 second

That's why it showed up as Duration: 00:01:43.87 , to ms accuracy, the .8704 is rounded down to .870 . 29.970000 would have been rounded up to .871.

ms accuracy is what is typically used.

By the way, when fusing the video and audio together, while at the same time converting MP4 to MOV, I get some "yellow" messages from FFMPEG, although the result is fine at the end:

Guessed Channel Layout for Input Stream #1.0 : stereo

[mov @ 04fa1880] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codepar instead.

[mov @ 04fa1880] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly

Is this bad? Do you know what this could mean?

No problems. Ignore them. 1st is when the stream map isn't specified or metadata, 2nd is when you use the old -codec notation instead of -c . For example -c:v is video codec instead of -vcodec . 3rd is because of the way you muxed the mp4, it won't affect the output .

[Jacobson]

Great work! Just awesome.

Now, if I make the audio 00:01:43:870, wouldn't it still technically be shorter than the video?

[Jacobson]

I also found this somewhat interesting:

http://www.streamingmedia.com/articles/editorial/featured-articles/Encoding-for-YouTub...lts-83876.aspx

Although I'm confused about what is meant with the need to insert a "moov atom" at the start of a video file in order for YouTube to process it correctly?

[poisondeathray]

I also found this somewhat interesting:

http://www.streamingmedia.com/articles/editorial/featured-articles/Encoding-for-YouTub...lts-83876.aspx

Although I'm confused about what is meant with the need to insert a "moov atom" at the start of a video file in order for YouTube to process it correctly?

It's not necessary. Because youtube re-encodes everything.

It's only necessary if you host your own site and stream the file yourself. This enables immediate playback, instead of having to wait for the entire file to download locally before playback

But it doesn't "hurt" to move it, the only "negative" is it's slower to process , because you have to run the file through a 2nd pass. In ffmpeg you would add to the commandline ( it will still mux as you have been doing, but it will run the file through a 2nd pass)

-movflags faststart

[Jacobson]

I just wanted to get some final feedback from you about what I said in post #65:

Now, if I make the audio 00:01:43:870, wouldn't it still technically be shorter than the video?

What I wanted to say was, you can only be that much precise, so what should the goal be with the audio length? Obviously, the duration of the video is longer, in this case it would be 103.8704 video length vs 103.8700 audio length. It is less than 1 millisecond, but it is still "different". So my question is, would it be wiser/safer at all to make the audio about 1 millisecond shorter? I mean, is there any reason to do that? If you say absolutely not, I have no reason to doubt you, and will not discuss this further.

Regarding the "movflags" thing, this official Google page also recommends adding it to the video:

https://support.google.com/youtube/answer/1722171?hl=en

It also says, "No Edit Lists (or the video might not get processed correctly)".

My final questions, along with the duration thing I mentioned above, would be:

1.) Do I need to do -movflags faststart to the final file which already has the added audio in it and converted to MOV, or should I do it at the same time as I insert the audio and convert to MOV?

2.) Is there any advantage to first converting the MP4 to MOV, and then adding the audio to the newly created MOV?

3.) How do I check if my video has those "edit lists" prior to uploading?

After this has been answered, I'll have no further questions. And once again I can't express how helpful your contributions have been.

[Jacobson]

Something interesting just I noticed regarding frame rate:

The original videos I took with my phone have 30.000 fps according to VirtualDub.

I cut those same videos using AviDemux, and the resulting videos have 30.051 fps according to VirtualDub.

The same videos edited/joined together in Shotcut and exported in MP4 H264 have 29.970 fps according to VirtualDub.

This MP4 file, converted to MOV with FFMPEG and audio added, also has 29.970 fps according to VirtualDub.

There are three slightly different numbers here. Is this something to worry about?

[poisondeathray]

I really don't know the answer to <1 ms difference. A few ms is safe either way. You can only have 0.0333667s (ie. 33.3667ms) accuracy in "29.97" (30000/1001) video, because that is a single frame duration . 1 / (30000/1001) . You cannot have "half" a frame. Those are "coarse" increments compared to audio.

-movflags faststart has to be added to the final file only, if you wanted to add it

No advantage to converting MP4 to MOV first

You don't have edit lists - don't worry about it

[Jacobson]

I really don't know the answer to <1 ms difference. A few ms is safe either way. You can only have 0.0333667s (ie. 33.3667ms) accuracy in "29.97" (30000/1001) video, because that is a single frame duration . 1 / (30000/1001) . You cannot have "half" a frame. Those are "coarse" increments compared to audio.

If you can only have 33.3667 ms accuracy, would there be anything wrong/unsafe with making the audio "34 ms" or "40 ms" shorter at the end?

Regarding those frame rates, please take a look at post #69 above, when you find some time.

-movflags faststart has to be added to the final file only, if you wanted to add it

No advantage to converting MP4 to MOV first

You don't have edit lists - don't worry about it

Great. Thanks.

[Jacobson]

Some more info, although probably not important:

All three of the original files made with my phone, which have regular audio tracks (nothing added/edited whatsoever), opened in AviDemux, all show the audio being longer than the video (File -> Information), ranging from about 300 - 400 ms. They also show Frame Rate as 30.051 vs. 30.000 on VirtualDub. They also show the total video duration being longer than where the last frame (Go -> Last Frame) is located, although you cannot seek beyond that last frame.

When I open the final .MOV (with added audio) in AviDemux, it doesn't work right. No audio will play, and the audio information is messed up. I am pretty sure this is due to AviDemux not supporting 24-bit audio, and maybe also the fact that it is a .MOV file. It works well in VirtualDub and plays back in VLC player flawlessly.

Perhaps I am now obsessing about details that are totally irrelevant to what I'm doing. I think I'm just going to upload this as soon as possible and get it over with, so I can begin working on the next video. It would however, be much appreciated if you could only shed some insight into my last reply, regarding leaving about 40 ms audio "emptiness" at the end, to avoid accidentally making the audio slightly longer than the video.

[Jacobson]

To whom it may concern, here is an update:

I finalized the audio track for the video by leaving only 5 ms at the end. Poisondeathray said that "a few ms is safe either way", and he advised against making it around 100 ms, so I settled on just 5 ms. The result, in terms of audio and video working together, is without any problems.

I uploaded the video onto YouTube... and while the audio was really good and didn't seem to lose quality (not noticable at least), the video was disappointing. At 720p it is very good, almost exactly like when I play the original file on my computer. However, 480p looks pretty bad. It is blurry, and there are hints of artifacts at certain points.

While I'm fully aware that 480p has to look "worse" than 720p, I've also seen many other YouTube videos where 480p looks much better than what I have. The difference between 720p and 480p in my video is pretty drastic.

I experimented changing the bitrate and uploading again, and it didn't help, but I think my approach was incorrect. I have an idea what could be causing this, so after I try it out, I'll report back with the details.

And in case I'm talking to myself at this point, it's not a problem. You never know, there might be someone in the future with similar issues, Google-ing around, and he could find this thread helpful.