Pixelation in place of cut (I frame)

[M.C.H.]

Hello,

I have got pixelation in place of cut in version 5.4.84.771. May I upload somewhere a sample of original video file so you could make diagnostic and fix it?
In the original video there are no artefacts. source is H264 HD video and output is H264 elementary stream.

Thanks

 

[Dan203]

Is this something you see when you open the edited file in VideoReDo? Or only your player of choice? If only in your player did you use MP4 or MKV for output?

 

[M.C.H.]

Output is elementary stream *.h264 so I cannot open it again in VRD. I see it in Media Player Classic. If I recode it with x264 into mkv or mp4 pixilation is of course still there. May I upload you test stream and project file, you can try it yourself. I used trim function so the test file is only 60MB.

And just a note, source is HDTV.

 

[Dan203]

ES files have no timing information, so it's possible this pixelation is coming from MPC. Can you please try outputting the same file as a TS and see if it has the same issue. If it does then please upload the source file, not the cut file, so we can try to replicate the issue on our end.

 

[M.C.H.]

Even if the output is TS pixelation is still there. No mtter if I open it with MPC or VRD...
Here is sample file: https://ufile.io/x0olp
password sent in PM

 

[Dan203]

Sorry we're not able to accept files this way. Please upload the file to our support system using these instructions....

https://videoredo.net/msgBoard/inde...-samples-to-videoredo-customer-support.34717/

 

[M.C.H.]

uploaded followed your instructions

 

[Saiyan]

Same problem here. I hope you can fix it in the next build. thx

 

[M.C.H.]

This email "ping-pong" on videoredo support email makes me crazy. Every response take 24hours. And with every email I have to repeat instructions how to work with uploaded files to catch the pixelation bug. But probably the other side dont understands me. I have uploaded (using your service) also video with guide How I cut this video to get pixelation. I hope this will finally lead to better understandings. Thanks

 

[Otter]

I'm curious. Why are you outputting Elementary stream? What kind of situation needs that packaging?

You seem to be cutting on frames that don't contain proper reference info to allow VRD to recode across the splice.

When I record 1080i or 1080p HDTV, my raw capture files are AVC/h264 and audio muxed in either .TS or ,MP4 - both of which load and edit fine in VRD
In thousands of files, I've never had frame reference errors when cutting like you describe. The VRD recode routine is so good, I don't even have to watch my frame types when cutting - can cut on IDR, I, B, P - whatever and VRD splices all my segments perfectly, even when using Fast Recode.

Unless some special application has you stuck with Elementary Stream, I'd switch to something that works.

 

[M.C.H.]

Sorry, but your comment is offtopic. The h264 elementary stream isnt the problem, it is just my prefered output option. Ill get the same pixelation if I cut this sample video just to its original h264 *.ts. I like elementary stream because it is pure video. My software can handle elementary stream so I dont need use other like *.ts or others even if my software can handle them also.

I have also thousands of recordings from HDTV (AVC/H.264) in *.ts and in most cases VRD works very well on all types of frames. But sometimes it has problems on recordings from specific channel and/or cutting on non I frame. The same situation was some longer time ago. I sent a sample video and VRD support team fixed their h.264 cutting engine to be able properly cut also my sample. I hoped in this case the situation will be the same. I am just disapointed from current misunderstandings on videoredo support email which leads to longer solving this issue.

I got news that VRD support finally try to investigate the root cause of the pixelation in my sample.

Otter if you want I can send you also the sample and you can try yourself that cutting engine dont work well in this case.

 

[M.C.H.]

Today I have found next two streams from different TV channels which produced also pixelation in place of cut. First one is cut on P frame and second one on B frame. I am going to upload both to support team. Each sample is from different TV channel.

 

[M.C.H.]

Next sample from another TV channel... Sample video including project uploaded again to support team. Cutting on P frame.

 

[M.C.H.]

Next sample from another TV channel... Sample video including project uploaded again to support team. Cutting on I frame.

 

[Winnewup]

Hello,
I sometimes also get those pixelation especially if I try to join files (.ts) with cuts on I-frames. I never found out why, because it is not so often. Sometimes the pixelation isn't there if I save the cuttet files first. If this doesn't work I found a workaround:
First I make the cuts not on the exact position where I will combine the files. I will take some extra frames (e.g. 4, only B-frames!) on both sides (so VRD will render on the cutting point).
Then I join the files.
After that I cut the useless frames away (so VRD has to render again).
Using this method I can join every file that makes problems using the normal easy way. If you have problems at the beginning of a vid, you can make the cut in two steps using some extra frames in the first run.

I think the reason might be that video files contain IDR and I-frames. IDR-frames clear the reference, so that frames after an IDR-frame can't have a reference to frames before the IDR-frame. Mostly it is the same with I-frames. In unusual cases frames after I-frames can have references to frames before the I-frame. I you catch one of those rare cases on the cutting point the result will be pixelation, because the reference is missing; maybe the (very very good) rendering engine of VRD can't detect this special I-frames and doesn't render a longer part (just cut it). If you join files at a cutting point with an "unusual I-frame" the result is the same, pixelation (reference to wrong new frames before the I-frame) at the connecting point. This would explain the effect with the workaround where VRD must render both files on the cutting point and puts IDR-frames on the cut.
I don't know if this might be possible but I think I read it somewhere and it will be very difficult to detect I-frames, where following frames have references to frames before. The solution would probably be to cut just at IDR-frames, but this would result in long rendering parts.

I think one of the admins can explain this much better.

Best regards and sorry for my bad English
Frank

 

[Saiyan]

this is a big problem Im having the same issue with a lot of .ts files

 

[Dan203]

VideoReDo has two ways of cutting H.264 files. We back up 5 seconds from the cut point and search for an IDR frame. If one exists we cut the video there and recode all frames from that point forward using the Main Concept encoder. This is significantly faster and the only time it can cause issues is when the original frames use encoding parameters that we can't duplicate in the MC encoder. Even then it really depends on the player. We update the SPS/PPS in the NALs to reflect the different encoding parameters so some players can handle the change just fine. However others can produce a bit of pixelation from the transition. If there are no IDR frames then we use a different technique. We search the frames around the cut points for references to the frames that are being cut out. Any frame that references a cut out frame is recoded uses a special reference encoder so that we can precisely match the frame type and macroblock structure of that frame. The reference encoder we use is pretty robust, so it can match most encoding params, but it is also super slow. You can usually tell which technique is being used by how fast the output is. If you see it slowly counting "recoding frame 1/20" or similar then it's using the second technique. If it's relatively fast then it's using the first.

I'm guessing that it's using the first as that is the one most likely to cause the type of pixelation you describe. Unfortunately there is no way to force the second technique to kick in. Which one is used is based entirely on the presence of IDR frames in the source. We're discussing the possibility of making this an option in v6 so the user can choose which option they prefer.

 

[M.C.H.]

All samples I have uploaded, dont have any IDR, so it should use second slower but more accurate processing. But even with this processing it make pixelation. I think problem is somewhere else or you did not described it properly.

Are you going to fix it in next v5 version? I think this is major issue of your cutting engine and it should be fixed as soon as possible in v5 istead of telling us "We will fix it in upcoming beta v6". You promissed v6 beta already few years ago and it is still not here. I think you should at first fix stable v5 and then continue to v6. v6 is mainly about hevc support but here we are talking about cutting h264. Moreover v6 will be paid update so v5 legitimate users will not be able to use fixed cutting engine in v6.

 

[Dan203]

All samples I have uploaded, dont have any IDR, so it should use second slower but more accurate processing. But even with this processing it make pixelation. I think problem is somewhere else or you did not described it properly.

Are you going to fix it in next v5 version? I think this is major issue of your cutting engine and it should be fixed as soon as possible in v5 istead of telling us "We will fix it in upcoming beta v6". You promissed v6 beta already few years ago and it is still not here. I think you should at first fix stable v5 and then continue to v6. v6 is mainly about hevc support but here we are talking about cutting h264. Moreover v6 will be paid update so v5 legitimate users will not be able to use fixed cutting engine in v6.

There are other reasons this can happen. If your source file uses uncommon H.264 encoding parameters it's possible that even the second method can't match the source encoding exactly. Even the reference encoder we use for that method has some features it doesn’t support. It's possible that your source files simply can't be edited in this way.

As for the "next v5 version".... we are currently focused entirely on v6. We have no plans to release any more builds of v5. If we determine your issue is caused by a bug, and not just a limition if the encoder, then we might fix it and release a new beta. But that decision is up to DanR.

 

[M.C.H.]

There are other reasons this can happen. If your source file uses uncommon H.264 encoding parameters it's possible that even the second method can't match the source encoding exactly. Even the reference encoder we use for that method has some features it doesn’t support. It's possible that your source files simply can't be edited in this way.

As for the "next v5 version".... we are currently focused entirely on v6. We have no plans to release any more builds of v5. If we determine your issue is caused by a bug, and not just a limition if the encoder, then we might fix it and release a new beta. But that decision is up to DanR.

Did you analyze my samples or not? Does it have uncommon H.264 parameters or not? I have uploaded samples from four different TV channels from cable HDTV. Really all these TV channels use uncommon parameters? And if so, why you could not find solution for v5 and could for v6?