VideoRedo TVSuite - What are the best output settings?

NeilN

Member
Hi guys.

I've got V4 and V5 of VideoRedo TVSuite.
I tend use V4 as it has the option to turn off the timecode overlay on recoded frames.
When making cutpoint selections on HD T2 recordings. Where do you find is the best place to make the start and end selection points based on frame type I, B, P, IDR?
I know you have to output as m2ts file to maintain the video packet length and then re-name extension to .ts.
I use mostly the default settings with a few minor tweaks in advanced settings. What file output settings and advance options do you guys find best to get an error free video output result.
I quite often get PTS underflows on the output results and resync frame removals.
The net result is an interruption in the video somewhere between 1 and 2 secs after the edit point.

TIA for any advice.
 
I take it you want to re-import the edited video to the HDR-FOX, and to keep all the facilities associated with .TS. Otherwise I wouldn't bother exporting (M2)TS and just go straight to MP4 (AVC+AAC).

The net result is an interruption in the video somewhere between 1 and 2 secs after the edit point.
I'm not sure what's going on here. I'm not in the habit of doing this, but the whole point (and cost) of VideoReDo is that it intelligently re-encodes only where necessary. In other words, where there would be a loss of decoding sync because of a break in the I-P-P-P... sequence (because after a splice a P turns up without its associated preceding I), VRD is supposed to calculate and insert an I to plug the gap. I don't think the HDR-FOX spits out any B frames, and I don't know what an IDR is.

Have you perhaps turned off the re-encoding, thinking that's not what you want?
 
I take it you want to re-import the edited video to the HDR-FOX, and to keep all the facilities associated with .TS. Otherwise I wouldn't bother exporting (M2)TS and just go straight to MP4 (AVC+AAC).


I'm not sure what's going on here. I'm not in the habit of doing this, but the whole point (and cost) of VideoReDo is that it intelligently re-encodes only where necessary. In other words, where there would be a loss of decoding sync because of a break in the I-P-P-P... sequence (because after a splice a P turns up without its associated preceding I), VRD is supposed to calculate and insert an I to plug the gap. I don't think the HDR-FOX spits out any B frames, and I don't know what an IDR is.

Have you perhaps turned off the re-encoding, thinking that's not what you want?
Yes i want to maintain the the side cars. No I dont recode the video, I use intelligent recode. I had a feeling it was because of the cutpoints i'm making disprupt the sync. I've also noticed that I frames do seem to be generally preceded by a B frame.
If I can i try to make the cutpoint end frame be the one before an I frame or an IDR frame. I think it may be where i make the cut point start frame. So need to work out where to make the cut points to maintain decoding sync.
Will continue work on this by looking framing structures of edited recordings that were the result was a clean no errored output, and comparing against one the errored.
I have noted that on all recordings made, the first frame is an I frame.
 
I have noted that on all recordings made, the first frame is an I frame.
It can't be anything else.
If, for example, you have I-frames on frames 1, 11 and 21, then an edit should remove 11-20 inclusive if you want to minimise the work the software has to do in re-coding stuff.
 
It can't be anything else.
If, for example, you have I-frames on frames 1, 11 and 21, then an edit should remove 11-20 inclusive if you want to minimise the work the software has to do in re-coding stuff.
Will give it a go. I've got one recording where there are 5 cuts. The first cut precedes an I frame at the movie start, So no prob at start. The 2nd cut (ads) starts on a P frame and ends on a B that precedes an IDR frame on the next segment of the movie and the join is perfect. The 3rd and 4th cuts however are currently on B preceeding P and ending on P preceding B. And after the 3rd cut their is a small disprution in the video. The 4th cut has a very severe dispruption lasting about 3 secs.
I forgot i had VRD TVSuite V6. So have been experimenting. I tried output as a match source Intelligent recode mp4 and ended up with the same result as m2ts o/p.
I re-did but used forced recode (NVEnc encoder) a set some of the H264 settings in advanced options to match the T2 recording.
This resulted in perfect playback on the HDR-FOX at all of the joins, as i suspected it would.
I'll redo the 3rd and 4th cuts on I-frames which will unfortunately leave some of the C5 logo at the joins.
 
I'll redo the 3rd and 4th cuts on I-frames which will unfortunately leave some of the C5 logo at the joins.
It surprises me there isn't a new I-Frame at significant video transitions like this. One might expect that it would be more economical to generate an I-Frame and then subsequent P/B-Frames than try to describe the video as a series of P/B-Frames.

(I don't understand B-Frames – it seems to me that by requiring a future frame before a current frame can be constructed, it's building variable delays into the video chain.)
 
It surprises me there isn't a new I-Frame at significant video transitions like this. One might expect that it would be more economical to generate an I-Frame and then subsequent P/B-Frames than try to describe the video as a series of P/B-Frames.

(I don't understand B-Frames – it seems to me that by requiring a future frame before a current frame can be constructed, it's building variable delays into the video chain.)
Yeah I thought that when going through frame by frame trying to determine the framing structure. And it definately looks like it is building delays which worsen with the number of cutpoints added.
I did try recutting on I frames for the 3rd and 4th cuts in the the previously mentioned video. Guess what. VRD returned and error free output as reported in the VRD dialog box. But when playing the file on the HDR the disruptions to the video were still present. I outputted as m2ts and mp4. Same result on both.
When I outputted a match source intelligent recode mp4. There was no recoding done at the start and second cut. On the third and forth cuts it recoded 16 frames on each cut.
I also tried a forced recode as and m2ts and the number of PTS underflows made it not worth transfferring to the HDR and testing the result. I had feeling that would be the case, based on your comment about using forced recode in your first reply to this thread.

So far the only successful method to get an edited HDR FOX recording that plays on the HDR without any errors at the joins when viewing, seem to be forcing the recode as an h264/AAC mp4.
 
Last edited:
and I don't know what an IDR is.
@ Black Hole
Here is a brief description of what and IDR-frame is, that i found on the web.

An encoder sends an IDR (Instantaneous Decoder Refresh) coded picture (made up of I- or SI-slices) to clear the contents of the reference picture buffer. On receiving an IDR coded picture, the decoder marks all pictures in the reference buffer as ‘unused for reference’. All subsequent transmitted slices can be decoded without reference to any frame decoded prior to the IDR picture. The first picture in a coded video sequence is always an IDR picture.

This explains why the second cut in troublesome video results in a perfect join. There is a P frame prior to the selection start for the cut and last frame of the cut is also a P frame, which precedes an IDR frame. The output will correctly maintain P-frame before IDR frame order and the decoder in the HDR gets refreshed as above therefore resulting in normal playback.

And as you said when working with I-P-P-P structures slicing on a P can upset the decoder. There is upto a maximum 31 frames between two I frames or I and IDR frame, also never more the 7 B frames in sequence between P frames or between I an P frame.
 
I did try recutting on I frames for the 3rd and 4th cuts in the the previously mentioned video. Guess what. VRD returned and error free output as reported in the VRD dialog box. But when playing the file on the HDR the disruptions to the video were still present.
Have you been regenerating the sidecars or just transplanting the .ts?

I outputted as m2ts and mp4. Same result on both.
This, however, seems to be a contra-indication. The HDR-FOX media player won't be relying on .nts information for a .mp4, even if the codec is the same as a standard .ts.

I wonder whether this is VRD not performing effectively as we expect, or some inadequacy in the HDR-FOX decoder being confronted by something which VRD regards as within spec but the HDR-FOX was not designed for. I would put my money on the latter, and if so this is a problem which has no solution.

Here is a brief description of what and IDR-frame is, that i found on the web.
Yes, I did similar googling. These IDR Frames are what I thought I-Frames were. The whole thing is like a house of cards.
 
Back
Top