[mythtvnz] Cutting H.264 DVB-T files with ffmpeg without transcoding

[David Moore]

Stephen Worthington wrote:
> On Mon, 19 Jul 2010 16:46:02 +1200, you wrote:
> 
>> Craig Blaikie wrote:
>>> Jonathan Hoskin wrote:
>>>>     Anybody worked out a reliable way to cut recordings from Freeview
>>>>     terrestrial using ffmpeg?
>>>>
>>>>  
>>>> Nope. I wonder if the developers have properly addressed it / been made 
>>>> aware of it.
>>>>
>>>>
>>>>
>>>> I've seen a lot of posts from (I think) ffmpeg devs on various lists 
>>>> which seem to say "too bad, it's the recording that's bad, not a bug in 
>>>> ffmpeg".
>>>>
>>>>     ffmpeg -async 1 -ss [start time] -t [duration] -i recording.mpg
>>> -vcodec
>>>>     copy -acodec ac3 -ab 384k -f dvd cut_recording.mpg
>>>>
>>>>     The "-async 1" seems to be needed to keep audio in sync with video.
>>> The
>>>>     "-f dvd" might (not sure yet) be a fix for av mux errors. Audio is
>>>>     transcoded to AC3 since most channels only have LATM AAC audio.
>>>>
>>>>
>>>> "-f dvd" uses a MPEG2-PS container - H.264 isn't supported in the 
>>>> MPEG-PS file format:
>>>> http://www.gossamer-threads.com/lists/mythtv/mythtvnz/417130#417130
>>>
>>> David Moore wrote 
>>>> Thanks for that. I have tried MPEG-TS format as well but also with no 
>>>> joy. Latest semi-successful attempts have involved extracting the video 
>>>> to raw H264 format and transcoding the audio to raw AC3 then remuxing to 
>>>> mpg (without the -f dvd option). Unfortunately I get audio/video sync 
>>>> problems now. I don't see how I can easily resolve this because (I 
>>>> assume) the raw formats have no timestamps or have timestamps which are 
>>>> slightly out of sync.
>>>>
>>>> Seems that timestamps may be the root of the problem because I was 
>>>> previously getting the ffmpeg "non-monotone timestamp" error and weird 
>>>> start times reported by ffmpeg. I have no idea how to fix this without a 
>>>> lot of manual audio/video syncing. I wonder how myth copes with the same 
>>>> recordings when ffmpeg has problems? Might have to dig into the myth and 
>>>> ffmpeg source code to try and find the differences.
>>> You could try using vlc, as I found it was able to play the recorded video
>>> files with sound, use it to convert the audio to mp4a and then use ffmpeg to
>>> do the cutting or compression, I know it's an extra step, and you end
>>> needing free space to have an almost identical copy of the file there, but
>>> it seems to work, and the audio appears to stay in sync. I couldn't get VLC
>>> to cut and convert the video without totally messing it up, hence the extra
>>> ffmpeg step.
>>>
>>> Use command line version of VLC to copy video and transcode audio.
>>>
>>> nice -n 15 cvlc input_filename.mpg --sout="#transcode{acodec=mp4a, ab=192,
>>> channels=2, samplerate=48000}:standard{mux=ts, dst=temp_filename.mp4,
>>> access=file}:sout-transcode-soverlay=0" vlc://quit
>>>
>>> then use ffmpeg to cut, or in this example, convert to iPod.
>>>
>>> nice -n 15 ffmpeg -i temp_filename.mp4 -vcodec libxvid -b 512kb -qmin 3
>>> -qmax 5 -bufsize 4096 -g 300 -acodec libfaac -ab 192kb -s 736x416 -aspect
>>> 16:9 output_filename.mp4
>>>
>>> Cheers,
>>>   Craig
>>>
>> Thanks Craig. Your advice about using VLC helped a lot. I still took a 
>> while to fully solve my problems though. What I wanted to do was snip 
>> about 15 mins off the end of one recording and then join it to another 
>> recording. Here is what I did:
>>
>>
>> Step 1: Transcode the whole of the first file with VLC:
>>
>> cvlc 2 file1.mpg :sout="#transcode{acodec=a52, ab=384, channels=2, 
>> samplerate=48000}:standard{mux=ps, dst=file1a.mpg, 
>> access=file}:sout-transcode-soverlay=0" vlc://quit
>>
>> Step 2: Snip the end off the transcoded file with ffmpeg:
>>
>> ffmpeg -async 1 -ss 01:55:17 -i file1a.mpg -vcodec copy -acodec copy 
>> file1b.mpg
>>
>> Step 3: Transcode the second file with VLC:
>>
>> cvlc file2.mpg --sout="#transcode{acodec=a52, ab=384, channels=2, 
>> samplerate=48000}:standard{mux=ps, dst=file2a.mpg, 
>> access=file}:sout-transcode-soverlay=0" vlc://quit
>>
>> Step 4: Fix the timestamps in file2a so that they start just after the 
>> end of file1b. (Before I did this ffmpeg reported a start time of around 
>> 8800 seconds for file2a!? I've seen this sort of thing on lots of my 
>> recordings.)
>>
>> ffmpeg -itsoffset 881.58 -i file2a.mpg -vcodec copy -acodec copy file2b.mpg
>>
>> Step 5: Cat the two files into the final product:
>>
>> cat file1b.mpg file2b.mpg > final_file.mpg
>>
>>
>> This may not be the most efficient way to get what I wanted but the end 
>> result looks good with only a minor glitch at the join, good audio/video 
>> sync and is seekable.
>>
>> I found the vlc "mux=ps" option to be a lot faster than "mux=ts".
>>
>> The ffmpeg "itsoffset" option didn't work as I expected. It seems to 
>> need an absolute time, not an offset time. The value I entered ended up 
>> as the value for the start time of the second file. This value was the 
>> length of the first file so "catting" the files together ended up with 
>> good timestamps in the final file, if you follow what I'm trying to say.
>>
>> I'm still pretty sure that most of my problems are due to bad 
>> timestamps. Need to do more tests to find a final solution.
> 
> Just using cat to join those files is not valid.  There are headers on
> the front of each file .mpg file.  So you will probably get a playback
> glitch when the second set headers gets read as bad data.
> 

I'm not sure how significant the mpg headers are but the file does play 
with only a small glitch at the join and the time/duration reported by 
myth as it plays is correct. The glitch may be due to missing frames in 
the original recording and it is very minor and would be hard to spot if 
I didn't kow where it was.

I have seen other stuff on the web that says you can cat mpg files but 
the timestamps in the final file need reprocessing. This is essentially 
what I did by processing the second file so that it had timestamps 
starting at the duration of the first file. Not saying my method is 
fool-proof but seems to work so far.