[Cin] MTS files; concat demuxer / protocol

[Terje J. Hanssen]

Den 17.09.2024 18:55, skrev Terje J. Hanssen:
>
>
> Den 17.09.2024 14:11, skrev Stefan de Konink via Cin:
>> There are quite some topics online mentioning the when MTS files 
>> (exceeding 2GB) are naively added to a timeline. The problem that 
>> then appears is that the audio is typically "shorter" than the video, 
>> and it does not appear in the interface. Cinelerra will even shift 
>> the audio track under the previous track.
>>
>> It is mentioned that Adobe Premiere is able to parse an AVCHD 
>> structure, including the ability to use meta information such as 
>> timecode, which is not available from MTS files directly.
>>
>> Other workarounds that are mentioned to first join the MTS files. 
>> FFmpeg has the option concat demuxer and concat protocol. But it 
>> pulls another surprise...
>
>
> Have you tried simple "cat" to join clips in a Linux terminal?
>
> I have not tested this with MTS files, but it works for my HDV.m2t 
> files (mpeg2 video/mp2 audio)
>
>     cat file1 file2 > file1+2
>
> file1+2 may load directly in Cingg if the clips were continuously 
> auto-clipped.
>
> For random clips, there might arise a black segment between the clips.
>
> In my experience this is possible to cleanup first with
>
>     fmpeg -hide_banner -i file1+2 -reset_timestamps 1 -c copy 
> file1+2_cleanup
>
>
> ffmpeg or ffprobe may still complain about single "Packet corrupt" or 
> "timestamp discontinuity", which I simply have ignored.


An alternative, and possibly better way, may be to first cleanup each 
clip-file individually:

     fmpeg -hide_banner -i file1 -reset_timestamps 1 -c copy file1_cleanup
     fmpeg -hide_banner -i file2 -reset_timestamps 1 -c copy file2_cleanup


At least for m2t (and dv), these files can be loaded and added 
successful into CinGG
or if of interest, cat'ed together.


>
>
>>
>>
>> ffmpeg -i "concat:00152.MTS|00153.MTS|00154.MTS" -vcodec copy -acodec 
>> copy test.ts
>> ffmpeg version n7.0.1 Copyright (c) 2000-2024 the FFmpeg developers
>>   built with gcc 14.1.1 (GCC) 20240522
>>   configuration: --prefix=/usr --disable-debug --disable-static 
>> --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm 
>> --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp 
>> --enable-gpl --enable-ladspa --enable-libaom --enable-libass 
>> --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm 
>> --enable-libdvdnav --enable-libdvdread --enable-libfreetype 
>> --enable-libfribidi --enable-libgsm --enable-libharfbuzz 
>> --enable-libiec61883 --enable-libjack --enable-libjxl 
>> --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb 
>> --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt 
>> --enable-libopus --enable-libplacebo --enable-libpulse 
>> --enable-librav1e --enable-librsvg --enable-librubberband 
>> --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt 
>> --enable-libssh --enable-libsvtav1 --enable-libtheora 
>> --enable-libv4l2 --enable-libvidstab --enable-libvmaf 
>> --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp 
>> --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 
>> --enable-libxvid --enable-libzimg --enable-mbedtls --enable-nvdec 
>> --enable-nvenc --enable-opencl --enable-opengl --enable-shared 
>> --enable-vapoursynth --enable-version3 --enable-vulkan
>>   libavutil      59.  8.100 / 59.  8.100
>>   libavcodec     61.  3.100 / 61.  3.100
>>   libavformat    61.  1.100 / 61.  1.100
>>   libavdevice    61.  1.100 / 61.  1.100
>>   libavfilter    10.  1.100 / 10.  1.100
>>   libswscale      8.  1.100 /  8.  1.100
>>   libswresample   5.  1.100 /  5.  1.100
>>   libpostproc    58.  1.100 / 58.  1.100
>> Input #0, mpegts, from 'concat:00152.MTS|00153.MTS|00154.MTS':
>>   Duration: 00:25:04.36, start: 1.040000, bitrate: 24022 kb/s
>>   Program 1
>>   Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), 
>> yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k 
>> tbn
>>   Stream #0:1[0x1100]: Audio: pcm_bluray (HDMV / 0x564D4448), 48000 
>> Hz, stereo, s16, 1536 kb/s
>>   Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle (pgssub) 
>> ([144][0][0][0] / 0x0090), 1920x1080
>> File 'test.ts' already exists. Overwrite? [y/N] y
>> Stream mapping:
>>   Stream #0:0 -> #0:0 (copy)
>>   Stream #0:1 -> #0:1 (copy)
>> Output #0, mpegts, to 'test.ts':
>>   Metadata:
>>     encoder         : Lavf61.1.100
>>   Stream #0:0: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top 
>> first), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 25 tbr, 90k tbn
>>   Stream #0:1: Audio: pcm_bluray (HDMV / 0x564D4448), 48000 Hz, 
>> stereo, s16, 1536 kb/s
>> Press [q] to stop, [?] for help
>> [mpegts @ 0x600ed54cf540] Stream 1, codec pcm_bluray, is muxed as a 
>> private data stream and may not be recognized upon reading.
>>
>> This results in a video file cinelerra (and others) cannot read.
>>
>> Instead if we would say do it in pcm_sb16le we would be able to show 
>> that the MTS file does contain the audio and FFmpeg is able to read 
>> it. I have attached a screenshot showing what happens.
>>
>> I wonder: could we in Cinelerra implement something that would not 
>> open a file as single file or EDL, but instead a concat set of files?
>>
>> Something in the drop down: "Create a single new resource only". That 
>> single resource should be opened via the concat protocol, and then be 
>> able as single instance. An EDL, but then at protocol level.
>>
>> I think this would make sense for many recordings that are split due 
>> to filesystem limits, but even for image sequences, if they could be 
>> directly opened and edited as if they were single files.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240917/d2e2c07d/attachment.htm>