On 2016-03-11 03:04, Carlos E. R. wrote:
On 2016-03-11 02:36, Carlos E. R. wrote:
On 2016-03-10 09:22, Carlos E. R. wrote:
On 2016-03-05 19:39, Carlos E. R. wrote:
I got a suggestion offlist to try to code each stream separately. I did:
ffmpeg -i "input-file.mpeg" -ss 00:20:00.00 -t 00:5:00.00 \ -map 0:0 -c:v libx264 -preset ultrafast -vf crop=1920:804:0:138 \ -c:a copy output-file_0.mkv
then -map 0:1 y luego map 0:2
And yes indeed, the video stream is choppy, but not the two audio streams. This matches the results with ProjectX, that finds the video unusable.
I got another suggestion from the same person: -copyts Do not process input timestamps, but keep their values without trying to sanitize them. In particular, do not remove the initial start time offset value. Note that, depending on the vsync option or on specific muxer processing (e.g. in case the format option avoid_negative_ts is enabled) the output timestamps may mismatch with the input timestamps even when this option is selected. The idea is that it seems that the timestamps would simply be passed on from the transport stream to the output, as players are able to correctly play the input stream, instead of trying to write the correct timestamp, and failing. It would be like this: ffmpeg -i "inputstream.mpeg" -copyts-ss 00:20:00.00 -t 00:5:00.00 \ -map 0:0 -map 0:1 -map 0:2 -c:v libx264 \ -preset ultrafast -vf crop=1920:804:0:138 -c:a copy output.mkv And indeed, this test section now plays well :-) With this method, I think I can easily process videos on which I only have to remove a region from the start and end, not the middle. For those I would have to design a modification. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)