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

[Stephen Worthington]

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.