Cropped .TS Won't Play on Smart TV

Black Hole

May contain traces of nut
I created an "edited highlights" of a HiDef recording using bookmarks and crop, for playback on a friend's "smart" TV (Samsung) from USB. Everything was fine until the first edit point, when the TV complained about an unsupported audio format and dropped playback. I suppose this is a consequence of the encoded audio stream having incomplete frames at the edit point (and it's very dim of the TV not to simply ignore the audio stream until the next valid frame).

The TV transport offered time index search, so I was (with persistence) able to resume playback after each edit point, but the TV was getting mightily confused with the file and wouldn't access anything after the fifth edit point.

Anybody suggest the easiest way to patch this up?
 
Last edited:

MontysEvilTwin

Well-Known Member
Maybe some magic ffmpeg incantation?
Nicesplice does not fix the stream timestamps so at each join there is a jump. The video is cropped at an i-frame, but the audio isn't necessarily so the audio stream may start a little earlier than the video: this can confuse some players. The easiest fix is to remux the edited file with ffmpeg. Try this:
Code:
ffmpeg -probesize 60M -analyzeduration 60M -i File.ts -muxdelay 0 -map 0 -ignore_unknown -c copy File.m2ts
 
Last edited:

cdmackay

Active Member
Possibly by coincidence, I found yesterday that a cropped T2 TS file wouldn't play properly with Kodi; it played, but not for long, with a terrible colour cast.

Unfortunately, I deleted the original, so can't say if that had the same problem. But I use Kodi to view my archive of T2 recordings, via NFS, and it's never happened before. I don't routinely crop.

It was a recording from sony classic movies (or similar). Cropped beginning, end, and the split in the middle. Cropped recording plays fine on the T2.

I'll try that ffmppeg too, ta.
 
OP
Black Hole

Black Hole

May contain traces of nut
My WebShell session timed out running that command, so I had to retry within an abduco session. I'll test the product later today.
 

Luke

Well-Knwοn Мember
It was a recording from sony classic movies (or similar). Cropped beginning, end, and the split in the middle. Cropped recording plays fine on the T2.

I'll try that ffmppeg too, ta.
Sony Classic wouldn't be HD and so if you do try that ffmppeg with an SD recording then the file extension of the output should be "ts" instead of "m2ts". Fmpeg takes some of its defaults from the type of file that is being created and so the extension does need to be appropriate.
My WebShell session timed out running that command, so I had to retry within an abduco session. I'll test the product later today.
Ive recently run a similar remux without converrsion on an HD file for a friend (but not for Samsung) without a time out issue on an old laptop (i.e. slow CPU) . It took about as long as I would expect a direct copy to take. I'm wondering about the -probsize and analyzeduration as these are about 12 times the normal default.
 

MontysEvilTwin

Well-Known Member
Sony Classic wouldn't be HD and so if you do try that ffmppeg with an SD recording then the file extension of the output should be "ts" instead of "m2ts". Fmpeg takes some of its defaults from the type of file that is being created and so the extension does need to be appropriate.
To play on a Smart TV it probably doesn't matter if you remux to 'ts' or 'm2ts' but all native recordings on the HDR-FOX are in 'm2ts' format and are just (incorrectly) given a 'ts' extension. For both HD and SD recordings you need to keep the 'm2ts' format, and manually change the extension to 'ts' for it to play on the HDR-FOX. If you specify a 'ts' file as output in ffmpeg, it will create a file in 'ts' format. It will play but you won't be able to create sidecar files.
Ive recently run a similar remux without converrsion on an HD file for a friend (but not for Samsung) without a time out issue on an old laptop (i.e. slow CPU) . It took about as long as I would expect a direct copy to take. I'm wondering about the -probsize and analyzeduration as these are about 12 times the normal default.
The 'probesize' and 'analyzeduration' settings in my post above work fine on the HDR-FOX and don't significantly increase the processing time. With the default settings for these parameters, ffmpeg may not correctly identify the format of the audio description stream and the process will quit.
 
OP
Black Hole

Black Hole

May contain traces of nut
Right, well, I ran the ffmpeg command (as per post 3) in an abduco session on HD-FOX (having enabled a swap file because without it ffmpeg crashed the HDR-FOX), and got out a file which is 1.81GB compared with 1.72GB cropped original. Having squirrelled away the original and renamed the output .ts, it wouldn't play on the HD-FOX unless I deleted the sidecars and played it naked, and it also plays having recreated the sidecars.

Whether it plays on the smart TV remains to be seen.

My WebShell session timed out running that command, so I had to retry within an abduco session. I'll test the product later today.
I'm dubious whether that actually did anything at all, I don't remember the circumstances now.
 
OP
Black Hole

Black Hole

May contain traces of nut
Whether it plays on the smart TV remains to be seen.
It does. Obviously the joins are not imperceptible (the sound drops out for a second or two), but playback does not get upset.

Many thanks @MontysEvilTwin

Any chance of a command line streamfix command, which:
  1. Checks for swap file and invokes if necessary (including HD-FOX);
  2. Starts an abduco session;
  3. Runs ffmpeg;
  4. Cleans up.
?
 
Top