Bookmark changes between 5.1 and Stereo audio?

That's strange, I don't see how the original file could be shrunk, with ad. detection while still encrypted.
 
xyz321 said:
That's strange, I don't see how the original file could be shrunk, with ad. detection while still encrypted.
Click to expand...
The original file absolutely was decrypted (and AdDetected / Shrunk). The original .hmt as copied to another machine shows:
Flags: HD,Unlimited Copies,Thumbnail,Shrunk,Deduped,Addetection,
I can only assume that when the Humax tried and failed to play the updated, unplayable .ts with the same name it updated the corresponding .hmt (which still has all of its other info intact..) to:
Flags: HD,Unlimited Copies,ODEncrypted,Shrunk,Deduped,Addetection,
A test would be to rename the new, improved, playable updated .ts to match the original .hmt and see if the file now plays and the Flag gets reset, although for now I'm more keen to find a way for ffmpeg to create a playable file..
 
florca said:
Moving forward, but still some work to do...
Running the Cut/Concat output file through VideoReDo's "Quick Stream Fix" produces a message "57 Audio Resync Frames Removed" and a file which will now play quite happily with perfect audio synch on the Humax and indexes / displays properly after running Sidecar against it. ...
Click to expand...
A VRD developer describes what the message means here. The lost frames are not "resync frames" but good frames removed to match the audio track. I suppose you could resample the audio but that would make the whole process very slow.

Maybe this problem of slightly different video timebases when concatenating explains what is happening, and perhaps how to fix it (-video_track_timescale)?
 
I don't know how practical it would be, especially on a Humax, but it appears that ffmpeg has trim and atrim filters to remove section of video and audio from recordings which might provide an alternate approach from the split into chunks and concatenate method.

Any reading of ffmpeg documentation tends to leave me comatose and in in need of a stiff G&T, I find it difficult to interpret the meaning of even fairly simple ffmpeg incantations.
 
Thanks both.. I'm also wondering whether the method by which ffmpeg makes -ss / -to cuts is the problem. As I understand it, when you specify a -ss start value for a cut then ffmpeg will locate the video I-Frame prior to that point and starts the output there - maybe IDR-Frame for h.264, which will be even further adrift! All of the audio frames are keyframes according to the ffprobe output, so by specifying very precise Start points based on audio frame timestamps we are likely to end up with quite severe divergence between the file order of audio and video frames and their Presentation Timestamp values, which VLC may be able to handle but perhaps too rich for the Humax? From a few sample probes I think the Timebase values across the original file are consistent, so not convinced that explicitly setting them is going to change much, but maybe worth trying..
Will try some experiments with trim & atrim to see what difference that makes, although if it's a Filter then the impact will be pretty horrible (and lose quality) as most (all?) of the ffmpeg Filters require a full decode / encode rather than straight codec copy :(
 
xyz321 said:
What is the output from stripts -E -d1 <rootfilename>?
Click to expand...
Hi - after the Sidecar built HMT had been attached, this is the output from both -E and -E -d1 for the playable version of the file...

Code: 
HumaxLounge# stripts -E -d1 S01E05\ -\ Episode\ 5b
+ Version: 1.4.5
+ Debugging level set to 1
+ Input:  S01E05 - Episode 5b
+ Output: NULL
+ Opening input HMT file.
HD recording.
Encrypted: 0
Shrunk: 1
Video PID: 256, Audio PID: 257, PMTPID: 0, SID: 0
Event ID: 0
+ Opening S01E05 - Episode 5b.ts
+ Total size: 1345844736
Found start of PAT at offset 0xc0 len 13
00000000: 00 00 01 2c 47 40 00 11 00 00 b0 0d 00 01 c3 00  ...,G@..........
00000010: 00 00 01 f0 00 b4 1f d4 90 ff ff ff ff ff ff ff  ................
00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
000000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
000000b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
47 0 (Cont: 1) TEI/PUS/PRI: 0/1/0 S: None A: No, payload only
End of PAT
1
Processed in: 0.06s
HumaxLounge# stripts -E  S01E05\ -\ Episode\ 5b
1
Processed in: 0.01s
HumaxLounge#

and from the unplayable version prior to QuickStreamFix...

Code: 
HumaxLounge# stripts -E -d1 S01E05\ -\ Episode\ 5
+ Version: 1.4.5
+ Debugging level set to 1
+ Input:  S01E05 - Episode 5
+ Output: NULL
+ Opening input HMT file.
HD recording.
Encrypted: 1
Shrunk: 1
Video PID: 301, Audio PID: 302, PMTPID: 300, SID: 17664
Event ID: 31912
+ Opening S01E05 - Episode 5.ts
+ Total size: 1405362816
Found start of PAT at offset 0x180 len 13
00000000: 35 8b 62 28 47 40 00 10 00 00 b0 0d 00 01 c1 00  5.b(G@..........
00000010: 00 00 01 f0 00 2a b1 04 b2 ff ff ff ff ff ff ff  .....*..........
00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
000000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
000000b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
47 0 (Cont: 0) TEI/PUS/PRI: 0/1/0 S: None A: No, payload only
End of PAT
1
Processed in: 0.01s
HumaxLounge# stripts -E S01E05\ -\ Episode\ 5
1
Processed in: 0.00s
HumaxLounge#
 
Cracked it, at least partially, after some web searching... (still some issues over what stripts is reporting and need to do some further tests on different files, but what was failing before is now working..)

adding -async 1 -fflags +genpts to the ffmpeg "concat" step results in a file which plays cleanly on the Humax with no audio sync problems. Haven't tried playing all the way through yet, but skipping ahead to positions through the file works OK, again with no loss of sync. The ffmpeg documentation is a bit cryptic, but the net result seems to be a re-written and consistent set of Presentation Timestamps in the concatonated file.

new ffmpeg concat line in the script should now read...

Bash: 
# Concatonate all the segments together...

echo "ffmpeg -hide_banner -loglevel error -stats -i "${concat%??}" -y -async 1 -fflags +genpts -c copy \""$root".m2ts\" >>\""$root".log\" 2>&1" >>"$root".sh;

# And go do the edit

but need to make some other changes to create a backup of the original file as well, so won't put up the whole script. I think this does open the door to using the ffmpeg cut/concat technique for an alternative version of DetectAds if that's desirable?
 
florca said:
Where is the dustbin??
Click to expand...
From /mod/sbin/empty_dustbin:
Code: 
if [ "`cat /etc/model`" = HD ]; then
      mediaroot=/media/drive1/Video
else
      mediaroot="/mnt/hd2/My Video"
fi

if [ -f /mod/boot/dustbin.name ]; then
      dustbin_dir="`cat /mod/boot/dustbin.name | sed 's/\//_/g'`"
else
      dustbin_dir="[Deleted Items]"
fi

dustbin="$mediaroot/$dustbin_dir"
echo "Dustbin: $dustbin"
 
Customised firmware package move recordings to the dustbin by invoking the safe_delete function which is a JIM function in the /mod/webif/lib tree

AFAIK it has never been exposed for use by command line or other shell languages.
It would be quite trivial and vey useeful to provide a front end to it so that it could be invoked more easily.
 
Ezra Pound said:
This question has produced the most comprehensive collection of answers I have seen for a long time
Click to expand...
I was rather expecting someone to say "in the sideway, collected every other Thursday...";)
MymsMan said:
It would be quite trivial and vey useeful to provide a front end to it so that it could be invoked more easily
Click to expand...
That would certainly be useful for this script, although I'm trying hard to make this as generic as possible so that the same script will run cleanly in both Humax and non-Humax environments. On that note, is there a reliable test which will return whether the script is currently running on a Humax Fox T2?
 
MymsMan said:
...
AFAIK [safe_delete] has never been exposed for use by command line or other shell languages.
It would be quite trivial and very useful to provide a front end to it so that it could be invoked more easily.
Click to expand...
I think it would need to be refactored with some way of controlling what happens when the "safe" method might not be used:
  • when undelete isn't installed;
  • when the victim file is not on the same device as the dustbin;
  • what should happen to any related .hmi file.
 
florca said:
...is there a reliable test which will return whether the script is currently running on a Humax Fox T2?
Click to expand...
Among other possibilities, grep -qE '^HDR?' /etc/model 2>/dev/null. One might prefer to use uname, but it's in the coreutils package which may not be installed; some packages are dependencies of WebIf and can be expected to be present when scripts that manipulate recordings are running, but that's not one of them.
 
A quick update... I've been running some tests on a variety of recordings which has thrown up the need for some changes to cater for different cases (recording has and starts with a single 5.1 section with Stereo at the end, similar with Stereo only at the start and, most significantly, the potential for the PTS to wrap mid-recording). I've also decided that the best way to maintain a generic script which works across multiple platforms is to generate an "aaa.m2ts" file from the "aaa.ts" input and leave any cleanup / renaming / postprocessing to a platform-specific calling wrapper.

I've also been testing alternative ways to specify the ffmpeg "concat" step which seem to show that more by luck than judgement the method I used initially to cut into multiple aaan.m2ts files using -ss / -to timecodes and then splice using
-i concat:"aaa1.m2ts"|"aaa2.m2ts"|...etc. etc
seems to be the only one which works reliably, in contrast to the superficially similar (and quicker / "better") way of specifying a concat input file with identical timecodes in the format
Code: 
ffconcat version 1.0

file 'S01E05 - Episode 5.ts'
inpoint 18.453333
outpoint 926.400000

file 'S01E05 - Episode 5.ts'
inpoint 1170.453333
outpoint 1798.400000

file 'S01E05 - Episode 5.ts'
inpoint 2042.410667
outpoint 2399.424000

file 'S01E05 - Episode 5.ts'
inpoint 2643.413333
outpoint 3213.440000

which I don't quite understand, so for now I'm sticking with what works...
I'll publish a revised version after some more tests.
 
You must log in or register to reply here.
Back
Top