logo

Live Production Software Forums


Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
mark2020  
#1 Posted : Monday, February 22, 2021 10:59:35 AM(UTC)
mark2020

Rank: Member

Groups: Registered
Joined: 12/11/2020(UTC)
Posts: 29

Thanks: 4 times
Originally Posted by: Clint Cruz Go to Quoted Post
...I have a MP4 File...At certain time of my live stream i want to play book mark #1 then at another time i want to play bookmark number 4....So what im asking if i already know the timestamp of the videos and want to play them at certain times of my livestream, how can i trigger it to play at that timestamp (Bookmark)?

...


Originally Posted by: kjones9999 Go to Quoted Post
My personal preference based on experience is Mpeg2.


Quote:
* Improved codec support for video playback.


Quote:
* Fixed playback issue with some video formats such as HEVC.



Hi,

There are a lot of recommendations for recording (and playback already). But I'm seeing updates on vMix video rendering for playback and was wondering about *current* optimal codec.

I'd bet the following describes [relatively] common playback desires, but thanks in advance given the detail. What might ya'll recommend for one that is best *in vMix* with considerations in roughly the following order?

-Directly importable and editable (even if not ideally so) in Premiere and Resolve
-*No stuttering, in vMix, on a decent system with production resource usage overhead*
-Acceptable quality (at 1080P30) for 4k or large screens
-Whatever compression, ideally does not exceed 25-35 Mbps for the above quality (i.e. uncompressed, 4:4:4 and/or high bit depth are excessive)
-vMix places the load on the GPU
-Barring that, minimal CPU usage (e.g. mpeg-2 over h.265)
-Excellent apparent quality if played back on 'regular' screen sizes at or below 1080 resolution
-Ideally does not exceed 8-10 Mbps for the above quality
-Max bit rate aside, lower rate for the same quality preferred (e.g. h.264 over mpeg-2)
-Per Clint (and in-thread reply), a format with some decent precision using the SetPosition command
-Other things being fairly equal, minimal NLE render time
Vince Beck  
#2 Posted : Monday, February 22, 2021 11:18:56 AM(UTC)
Vince Beck

Rank: Advanced Member

Groups: Registered
Joined: 7/28/2019(UTC)
Posts: 348
United States
Location: Santa Rosa

Thanks: 1 times
Was thanked: 50 time(s) in 50 post(s)
You should not get stuttering on the External output with most formats. We usually stick with CBR mp4 and I have never seen a dropped frame. 4K is a different animal, but h.264 is curently less processor heavy than h.265.

My bitrates are usually at 20 Mbps CBR.
thanks 1 user thanked Vince Beck for this useful post.
mark2020 on 2/22/2021(UTC)
mark2020  
#3 Posted : Monday, February 22, 2021 2:20:48 PM(UTC)
mark2020

Rank: Member

Groups: Registered
Joined: 12/11/2020(UTC)
Posts: 29

Thanks: 4 times
Originally Posted by: Vince Beck Go to Quoted Post
You should not get stuttering on the External output with most formats. We usually stick with CBR mp4 and I have never seen a dropped frame. 4K is a different animal, but h.264 is curently less processor heavy than h.265.

My bitrates are usually at 20 Mbps CBR.


Thanks for the reply. Just to clarify, I'm not getting any stuttering, but put it there (really, should have been the top) since that's probably something everyone can agree on and have seen it crop up for other users.

To this day I still have a 10+ year old .mpg somewhere that brings modern CPUs/GPUs to their knees :D

I also use mp4, but dual playback (video background + media file) adds a noticeable bump to CPU and nothing to GPU, vs no playback at all. That, and imprecise in/out points are my biggest drivers in looking for an alternative.
RichShumaker  
#4 Posted : Saturday, May 14, 2022 5:08:10 AM(UTC)
RichShumaker

Rank: Advanced Member

Groups: Registered
Joined: 4/4/2016(UTC)
Posts: 173
United States
Location: Not Los Angeles CA

Thanks: 82 times
Was thanked: 26 time(s) in 21 post(s)
This is an older thread I just wanted to add something techie to this.

Modern consumer(read consumable) Codec's typically are not frame independent. Mpeg-2 All-I "IS" and many other codecs are "frame independent". Mainstream "normal" codecs typically are not.

I bring this up because it is the reason that when I set a Mark In or Mark Out on say an H264 compressed video it seems to Jump in a direction, typically back on Mark In and Forward on Mark Out

That jump is the computer and codec working together to get you to an Independent frame(i-frame).

I know for frame accuracy almost all modern compression struggles to be "frame" accurate because of the method of compression.

Hence the reason many transcode(convert to a different Codec) compressed footage before ingest into an editor.

Also most IFrame Codecs are less intensive on the CPU as it does not need to lift as much. So a Motion JPeg Codec(literally jpeg for each frame) is easy on a PC VS H265 which is highly optimized for speed and size. To get that optimization that makes it smaller and easier to transfer(not view just send) means compressing like JPeg for each frame then compressing between frames.
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.