FF through recording jumps back to beginning

Robti

Robti

Member
Hi I will take emmerdale as an example I record in HD and use detectadds to crop the recording, now quite a few times but not every time if I watch the recording and get to a bit I’m not interested in I press fast forward and the recording skips back in time. Anything I can check ?
Thanks
 
No. It's due to the sidecar files not being correct after the crop process has mangled them.
Don't use crop.
 
If you install the sidecar package, you can re-generate the sidecar files which will fix the problem.
 
I was going to post this earlier - but thought it might not be correct -
In an unposted remark EEPhil said:
Sounds similar to the problem I have navigating mpg files with no indexing. Jump forward using the appropriate remote control button and the video jumps backwards. Suggest there is something wrong with the nts file.
Click to expand...
:roflmao: Would have been a correct diagnosis!
 
prpr said:
No. It's due to the sidecar files not being correct after the crop process has mangled them.
Don't use crop.
Click to expand...
Would it not be a good idea to run the sidecar package automagically after the crop has finished its mangling?
 
I never have problems with crop, but then I probably don't do much FF/RW of a cropped programme
 
Trev said:
Would it not be a good idea to run the sidecar package automagically after the crop has finished its mangling?
Click to expand...
It probably would, but it all adds to the time taken.
I find the edit points quite unpleasant - there's quite a bit of breakup on the picture and a loss of sound for several seconds.
 
prpr said:
It probably would, but it all adds to the time taken.
I find the edit points quite unpleasant - there's quite a bit of breakup on the picture and a loss of sound for several seconds.
Click to expand...
To counter act the loss of sound before I crop I always bring forward the end point of adverts by 4 seconds, (or 7 seconds if I want to make sure of preserving AD).
 
prpr said:
It probably would, but it all adds to the time taken.
I find the edit points quite unpleasant - there's quite a bit of breakup on the picture and a loss of sound for several seconds.
Click to expand...
Almost all of my cropping comes from detectads and I've adjusted the cut points.. generally it works perfectly going from the channel ident just before the adverts to the one afterwards fairly seamlessly.
 
The ideal would be to fix nicesplice to generate the sidecar files correctly whilst it is doing the cropping.
Unfortunately I have little knowledge of the structure of the broadcast streams - Is there a readable description that would help me understand what nicesplice needs to do

I am close to releasing a new detectads, but life keeps getting in the way, which among other things will allow for padding the crop points to reduce the sound problems at crop points but wont address the FF problems
 
Try doing this the old fashioned way (no sodding bookmarks on the 2000T and obviously no CF etc). It's either FF or jump/jump/jump to get through unwanted material. Knackers the remote control, so I use the the more robust arrow keys around the OK button.
o.jpg
Only trouble is that OK, arrows, i, opt+ have lost their labels through over use. You just can't win. My thumb gets lots of exercise though. :D
 
I have not seen this problem with nicesplice-cropped recordings, though I have seen it occasionally when playing across a network; when this has happened the playback time on the front panel was wrong. I assumed that it was due to a problem writing to the remote hmt file.
The difficulty with nicesplice-cropped recordings is that there is a jump in the DTS and PTS timestamps at each join. This is what causes the audio dropouts. You can fix this with ffmpeg but it would add to the processing overhead and would not be easy to automate, depending on the streams present, and you would have to patch the original hmt file and create a new nts file.
If you take the nicesplice-cropped ts file and create new sidecars (with sidecar) the recording duration will be incorrect and you get jumps in the timebar when you reach a joined section. If you use the original hmt file, the duration will be correct, but you will run out of timebar towards the end of the recording. It will still fast forward and rewind past the end of the timebar but if you stop playback it will go back to the start when you resume playback.
Is it possible to create a utility to set the timestamps of the next section to be joined to start from the end of the previous section, without remuxing the streams? If so you could then just join all the sections with the 'cat' command. This would fix the audio dropouts and solve playback issues on other devices.
 
Are you talking about timestamps in the .ts file or the .nts file or both?

Fixing the timestamps in the nts file within nicesplice should be possible and I think would help with the FF and skipping but I am not sure about those in the .ts.
Are the timestamps at fixed offsets within each frame?
 
MymsMan said:
Are you talking about timestamps in the .ts file or the .nts file or both?

Fixing the timestamps in the nts file within nicesplice should be possible and I think would help with the FF and skipping but I am not sure about those in the .ts.
Are the timestamps at fixed offsets within each frame?
Click to expand...
I was talking about the timestamps within the ts files. I thought that nicesplice fixed the timestamps in the nts files already, or does it just remove the chunks of data corresponding to the bits cropped out?
I think that the offset is uniform, in that the same offset is applied to each frame. So say the add break is 240 seconds long, you subtract 240 seconds from each timestamp in the next joined section. Then after that you keep adding the additional gaps to the offset with each new joined section.
 
By offset I meant position within the frame e.g. the playtime within an nts record is at 0x18, I haven't seen a mapping for the .ts frame

nicesplice does adjust the playtime in the nts but I will need to double check whether it is doing it correctly. AFAIK it doesn't do anything with .ts data other than removing chunks..
What would be the ffmpeg parameters needed to correct timestamps - I could possibly run it in the pipeline after nicesplice to avoid taking extra time
 
MymsMan said:
By offset I meant position within the frame e.g. the playtime within an nts record is at 0x18, I haven't seen a mapping for the .ts frame

nicesplice does adjust the playtime in the nts but I will need to double check whether it is doing it correctly. AFAIK it doesn't do anything with .ts data other than removing chunks..
What would be the ffmpeg parameters needed to correct timestamps - I could possibly run it in the pipeline after nicesplice to avoid taking extra time
Click to expand...
Simply remuxing the output with ffmpeg will fix the timestamps. However, there are problems with the audiodesciption track as described here. In addition, there is a problem with the channel Dave and sometimes ITV2+1 (plus probably some other channels) in that the audio description channel seems to piggyback its timestamps from the main audio channel. If you remux, ffmpeg throws out lots of 'non-monotonic' errors and you end up with the audio description bunched up at the start of the file, out of sync with the programme. You can avoid this but it is a faff: you need the -copyts flag to preserve the stream structure, applying a large negative offset to set the start of the section to zero (e.g. '-output_ts_offset -100000'). Then in a second pass you apply a positive offset to the second and subsequent sections to manually fix the timestamps (e.g. if the first section is fifteen minutes long, you add a 15 minute timestamp offset to the second section and so on, ultimately joining the sections with 'cat'. Without the AD track it is much easier!
 
You must log in or register to reply here.
Back
Top