Decoding Problems (possibly)

[TimW]

Hi all, I was wondering if anyone has encountered the problem below and/or found a workaround.

When encoding very long (>1 hour) broadcast h264 files (.ts), I sometimes (but not with all files) find the encoding is fine for an hour or more but then collapses into an almost uniform grey mush with faint signs of movement.  AVI Demux doesn't detect a problem and the encoding seems to have worked normally - the problem is only apparent on playback.  I suspect, though I am only guessing, that it is something do with the decoding rather than AVI Demux itself.  The reason I say this is that exactly the same thing happens with Bdrebuilder ('BRB').  BRB has the option to change the decoder, and I have found that changing the decoder, but leaving all other settings exactly the same, and applying to the same files usually does the trick.  The most reliable decoder with BRB is DGDecNV, but usually if one decoder doesn't work, one of the others will.  However with AVI Demux I don't think the option to change the decoder is available (I apologise if I have merely overlooked it).

Has anyone else noticed this and is there a solution?  I did find a possible way of changing the decoder using AVSProxy, but I haven't been able to try it as I didn't understand a word of it.

[Jan Gruuthuse]

>8>8 When encoding very long (>1 hour) broadcast h264 files (.ts), ... >8>8

What is the source of the recording: DVB-T, DVB-T2, DVB-C, DVB-C2, DVB-S or DVB-S2 in SD or HD.
If something goes wrong, try demux mpeg-ts thru mkvtoolnix and process the new .mkv file, sometimes this clears some issues.
On windows: shut down none essential programs
Be sure your PC and CPU is cooling correctly: dust clogging inside could be a big issue.
Processing big video files requires approx. 2.5 times the available space.
Don't process off line video (on nas, usb media, ...) Local is always recommended.
If you have such a file try another video display in Menu: Edit: Preferences: Display.
See if disabling there "Enable openGL support" changes behaviour?
In threading use autodetect, if already doing so, switch to custom and set to only real cpu cores and not including HT cores (virtual core)
Core i7 would be 4 cores and not the advertised 8.
Consider doubling your present ram 4 or 8 is very minimal depending what windows flavour you're running.
Don't use software compressed hard disk (increased hd space: virtual)

See if disabling HW accel helps, could be some issue.

Consider a 2nd bootable OS (Linux) on 2nd hard disk. Be careful doing so, you could lose your windows, if not done correctly. Get expert help doing so.

[TimW]

Many thanks for these helpful suggestions.  It might take me a while to run some tests but I'll update back here if I get it working.

Things I can mention straight away:

1. Source is DVB-S2 HD, trying to encode with x264.
2. If I repackage the .ts with mkvtoolnix into mkv, load into AVIDemux, and then cut out a section for adverts, I can no longer seek back prior to the cut point.  Perhaps this is to be expected?  No problem seeking with the .ts version, but thought I'd mention it.
3. Disk space not a problem - got loads of it, and drives are internal, not software compressed.  Might it help if source and target are on different drives?  I don't usually bother with this as it doesn't seem to speed things up much when using an SSD (different from the one windows is installed on), but I'll give it a try just in case.
4. OpenGL already disabled, might try with it enabled.
5. RAM is 4 but I guess it is not worth increasing it for 32 bit?
6. I couldn't figure out how to disable hardware acceleration I'm afraid.

It makes sense to me that it could be something to do with the things you mention, since the only decoder that never produces this problem in BRB is DGDecNV, and in that case, as I understand it, the decoding is farmed out to the video card, so that probably helps - again I am just guessing but it sounds reasonable!

Will post again if and when I have something to report, thanks again for the suggestions.

[mean]

You should be able to seek after cutting
The only known bug is if you video does not start at zero
In that case, cut a few seconds at the beginning and it should be ok afterward

[TimW]

mean - Many thanks, cutting a few seconds out earlier in the clip worked just the way you said it would.

Jan - Will try testing most of the other suggestions as time allows.  Don't think I'll be trying the Linux test, however - sounds like a recipe for disaster for someone with my level of technical skills!  Thanks for the suggestion anyway.  Will follow up again when I have something to report.

[Jan Gruuthuse]

2. If I repackage the .ts with mkvtoolnix into mkv, load into AVIDemux, and then cut out a section for adverts, I can no longer seek back prior to the cut point.  Perhaps this is to be expected?  No problem seeking with the .ts version, but thought I'd mention it.

I've just tested again with a bbc2HD recording (on openpli 4.0 STB). After remux you should be able to move around in the video.
It is important when cutting commercials in between, you do this on keyframe:
@start point of this commercial block move only forward/backward with up/down keyboard arrow to select cutting point and mark with [A ]
@end point of this commercial block move only forward/backward with up/down keyboard arrow to select cutting point and mark with [ B]
make cut with simultaneous keyboard key press: [Ctrl][X].

If the issue is still there, make a one minute recording, upload to a publicly internet service: no login or registration (dropbox, cloud, ...) and provide download link to it.
The issue should not be there on French,UK and German FTA recordings.

3. Disk space not a problem - got loads of it, and drives are internal, not software compressed.  Might it help if source and target are on different drives?  I don't usually bother with this as it doesn't seem to speed things up much when using an SSD (different from the one windows is installed on), but I'll give it a try just in case.

Most likely the speed gain will be minimal and ssd deterioration will increase (read write operation on ssd)

5. RAM is 4 but I guess it is not worth increasing it for 32 bit?

If you've not planned new computer over the next year. And if you can do it economical, doubling your memory would be the best improvement you can make. If you PC supports dual channel and there is slot free (if both slots are taken up: 2x2GB -> 2x4GB or 2x8GB, if the OS supports this.

[TimW]

Haven't had time to do most of the tests yet but can I just clarify...

1. I thought cutting on keyframes was only necessary when in copy mode i.e. not recoding?  In any case I have never noticed an issue when cutting on non-keyframes in the past, provided the video is being recoded.  Also mean's suggestion worked anyway - it is only the first cut where the seeking goes wrong so this workaround is fine for all subsequent cuts, even if not on keyframes.  Am I missing something?

2. Alas, the extra memory is not really an option, going to 64 bit is too much hassle and there's no point going higher than 4GB for win 32, but thanks for the suggestion.

I'll keep trying the other tests asap.

[Jan Gruuthuse]

2. If I repackage the .ts with mkvtoolnix into mkv, load into AVIDemux, and then cut out a section for adverts, I can no longer seek back prior to the cut point.  Perhaps this is to be expected?  No problem seeking with the .ts version, but thought I'd mention it.

You did not mention recoding here, re-mux is similar to using copy for audio and video in avidemux.
If you re-encode video, there should be no issue, unless there are flaws in the video or audio. One could be a audio AC3 drop, switch from 5.1 to stereo with commercials. Signal loss/drop in reception (bird on lnb, plane, thunder storm, lightning, ...)
32-bit 4GB your correct on that, seems only 8.1 has trick to surpass this:

Some operating systems like Linux implement a feature called Physical Address Extension or PAE mode, which switches to 36-bit memory addressing, allowing for access to a grand total of 64GB of main system memory, which is a massive improvement. Likewise, Microsoft has implemented PAE in the Windows kernel, albeit disabled by default and only accessible on server editions of Windows. To that end, a proper patch of the Windows kernel will be necessary on desktop editions in order to attain the same memory access benefit.

[TimW]

Update: with cores restricted to four, OpenGL enabled and using a different disc (Windows on one SSD, source on another SSD, target on a third separate HDD), we have lift off!

Thanks to Jan and mean for your patience and helpful suggestions.