On 26/06/2020 16:20, DaveD wrote: > On 6/25/20 7:29 PM, Leo Butler wrote:
>> DaveD <firstname.lastname@example.org> writes:
>>> On 6/23/20 3:09 PM, John Pilkington wrote:
>>>> On 23/06/2020 15:21, DaveD wrote:
>>>>> A while back (few weeks?) someone posted info about a technique to
>>>>> strip the first few megabytes from the beginning of a recording
>>>>> using dd. It involved a discussion about the new video rendering
>>>>> system crashing the frontend (or casing decoder errors) on
>>>>> recordings where the format changes soon after the recording
>>>>> starts. I swear I saved that message somewhere because I have a
>>>>> lot of those (thanks to Comcast and my firewire recordings) but
>>>>> I'll be dipped if I can find it. I've searched the archives, too,
>>>>> with no luck. I could probably figure it our from the dd man page,
>>>>> but thought I'd ask for a re-post of that info since it's a tried
>>>>> and tested method. Thanks,
>>>>> Dave D.
>>>> I think you might be remembering this:
>>>> which looked for an appropriate skip value. applied it, and then
>>>> rebuilt the seektable. The output file doesn't start at a keyframe,
>>>> but that doesn't seem to matter.
>>>> John P
>>> That's it! No wonder I couldn't find it in my old emails. It was in
>>> my bookmarks. Thanks you!
>> FWIW, I would recommend using mythffmpeg or ffmpeg rather than dd. The
>> former tools present no significant risk to your system.
>> ffmpeg -ss 00:00:30 -i input.ts -codec copy -map 0 output.ts
>> will seek (-ss) to the 30 second point in input.ts and copy each stream
>> in the input to the output. The copy codec is very fast and the safety
>> is worth the few extra seconds.
>> I will guess that files with a mangled stream structure will cause
>> ffmpeg to error out, but I don't have a sample to check that guess on.
>> In either event, you can increase the seek time to try to find the
>> beginning of a stable stream structure.
> Unfortunately I ran your command without looking up what -map 0 does and
> it left me with only the audio. Next time I'll try it without the -map
> option (and leave a backup! duh!). When it ran, it gave the same raft
> of errors at first, just like ffprobe shows (not surprising), then it
> created a nice, audio-only file. Good to know if I want to extract the
> audio from a recording some time. :)
> Dave D.
Some time ago I spent longer than was reasonable trying to get ffmpeg to
cut h264 recordings; eventually it worked fairly well but only with a
pre-run to reject all but 1 video and 1 audio stream - and playback
needs to be working to establish the cutpoints.
I also have a small python script that does byte-accurate cuts of 'any'
file. I've just updated the posted version of that to python3. There
are probably more elegant ways of coding it, but it works. Usually I
use Project-X for cutting mpeg2 video content, but this is a calling
script created as routine during a recent run:
ionice -c3 ~/pycut.py '/mnt/dat2/RSG3/10005_20200625195800.ts.old'
'/mnt/dat2/RSG3/10005_20200625195800.ts' 75221244 76677116 80142144
218640804 282500644 541396008 612756860 797066044 862314640 1054189132
1121304756 1364012756 1431629588 1568680460
All here: https://www.mythtv.org/wiki/MythDVBcut
Mostly pycut.py gets used now to cut DVB radio recordings before
extracting the audio.
mythtv-users mailing list
email@example.com http://lists.mythtv.org/mailman/listinfo/mythtv-users http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org