Re: [FFmpeg-user] Is there a way to cut a video at an exact time ?
On 13/04/2024 17.27, Jim Worrall wrote: On Apr 13, 2024, at 01:57, bbb wrote: Sorry for bothering you. It only behaves like this when I use "-codec copy". Without that option it accepts the exact time I've specified. On 4/13/24 13:47, bbb wrote: I want to cut off the start of a video. When I tell ffmpeg to start at an exact time, it refuses to do so and instead starts at a time that's somehow "convenient" for ffmpeg. I can only assume that it's probably depending on something like a keyframe or an important frame for the compression algorithm but I don't really know. the command: ffmpeg -ss 0:32.08 -i video.mkv -codec copy -map 0 video.cut.mkv makes the output start around 0:31 (even when I change the parameter value a bit, the result is exactly the same). Is there a way to make ffmpeg start at the exact time that I specified? Does it maybe depend on the codec and would it help if I recode it before cutting? It would be even better if I were able to start at a specific frame number but I didn't find a parameter to set that. To set a frame offset seems only possible when you're exporting to images. ___ I think this has everything you need to know. Bottom line as I understand it: it’s not possible to cut video precisely while copying streams. https://trac.ffmpeg.org/wiki/Seeking -bsf:v noise=drop='lt(pts\,503957216)' //cuts frames that have PTS<503957216. The noise -- yes, noise -- bit stream filter works -- thank you, Gyan. But it doesn't work right with open GOPs. I'm trying to craft a workaround for the errors. However, right now I'm busy working on determining whether TS streams include nav packets. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] 'setts=dts' is changing all PTSs instead
Does anyone see what I'm doing wrong? BEFORE. 0, 503945955, 503957216, 3753, 640646, 0x90f222e3 0, 503957216, 503964723, 3753, 125904, 0x3f60a4e2 0, 503960970, 503960970, 3753, 106426, 0xe5c85d36 0, 503964723, 503975985, 3753, 126806, 0x9c5d46c5 COMMAND to change the 1st frame's DTS from 503945955 to 503953462. ffmpeg -copyts -i in.m2ts -map 0 -bsf:v setts=dts='if(eq(DTS\,503945955)\,503953462\,DTS)' -c copy -dn -muxdelay 0 out.m2ts PROVOKED: [vost#0:0/copy @ 02ac04c0] Invalid DTS: 503953462 PTS: 503945955, replacing by guess AFTER, all the PTSs have been changed. 0, 503945955, 503945955, 3753, 640646, 0x90f222e3 0, 503957216, 503957216, 3753, 125904, 0x3f60a4e2 0, 503960970, 503960970, 3753, 106426, 0xe5c85d36 0, 503964723, 503964723, 3753, 126806, 0x9c5d46c5 in.m2ts, there is _no_ PTS==503945955. FFmpeg appears to be mixing up PTS with DTS. Terminal output is below. Thanks, Mark. C:\Windows\System32>ffmpeg -copyts -i c:\in.m2ts -map 0 -bsf:v setts=dts='if(eq(DTS\,503945955)\,503953463\,DTS)' -c copy -dn -muxdelay 0 c:\out.m2ts ffmpeg version 2024-04-04-git-478d97f303-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers built with gcc 13.2.0 (Rev5, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-li bxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --en able-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libxevd --enab le-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom - -enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbu zz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d 12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-li bcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame -- enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-lads pa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 59. 13.100 / 59. 13.100 libavcodec 61. 5.101 / 61. 5.101 libavformat61. 3.100 / 61. 3.100 libavdevice61. 2.100 / 61. 2.100 libavfilter10. 2.101 / 10. 2.101 libswscale 8. 2.100 / 8. 2.100 libswresample 5. 2.100 / 5. 2.100 libpostproc58. 2.100 / 58. 2.100 [mpegts @ 005631c0] start time for stream 2 is not set in estimate_timings_from_pts [mpegts @ 005631c0] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub) ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (500) options Input #0, mpegts, from 'c:\in.m2ts': Duration: 00:03:04.85, start: 5599.524622, bitrate: 15195 kb/s Program 1 Metadata: service_name: Service01 service_provider: FFmpeg Stream #0:0[0x1011]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn Stream #0:1[0x1100]: Audio: dts (dca) (DTS-HD MA) ([130][0][0][0] / 0x0082), 48000 Hz, mono, s32p (24 bit) Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle (pgssub) ([144][0][0][0] / 0x0090) File 'c:\out.m2ts' already exists. Overwrite? [y/N] y Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (copy) Stream #0:2 -> #0:2 (copy) Output #0, mpegts, to 'c:\out.m2ts': Metadata: encoder : Lavf61.3.100 Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 23.98 tbr, 90k tbn Stream #0:1: Audio: dts (DTS-HD MA) ([130][0][0][0] / 0x0082), 48000 Hz, mono, s32p (24 bit) Stream #0:2: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Press [q] to stop, [?] for help [vost#0:0/copy @ 03a9f980] Invalid DTS: 503953463 PTS: 503945955, replacing by guess [out#0/mpegts @ 004f7340] video:302944KiB audio:23295KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 5.101183%
[FFmpeg-user] SCR (System Clock Reference)
Does FFmpeg provide any way to write packet SCR (System Clock Reference) (i.e., at PS_PACKET_HEADER + 4 bytes)? I will need to rewrite SCRs for all ps packets via a math eval. I searched but could not find. Thanks, --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] How to make IDR cuts
Is there more to this? If there is, it's not evident to me. If there are several B-frames in a row, then adjust your mind to 'see' larger shifts across the multiple B-frames and adjust PTSs & DTSs to match. Cutting off a leading open GOP:<—closed GOP——> PTS order [_I_][_B_][_P_][_B_][_I_][_B_][_P_][_B_][_P_][_I_] __/ ___¦___/ ___¦___/ ___¦___/ ___¦___/ __/ // ¦ / ¦ / ¦ / ¦ / DTS order [_I_][_P_][_B_][_I_][_B_][_P_][_B_][_P_][_B_][_I_] XXX X PTS order [_I_][_B_][_P_][_B_][_P_][_I_] __/ ___¦___/ ___¦___/ __/ // ¦ / ¦ / DTS order [_I_][_P_][_B_][_P_][_B_][_I_] Cut on PTS, then fix up the 1st DTS & packet SCRs. Or, I don't think it's going to hurt anything to leave this: PTS order [_I_][_B_][_P_][_B_][_P_][_I_] ___/ ___¦___/ ___¦___/ __/ / / ¦ / ¦ / DTS order[_I_] [_P_][_B_][_P_][_B_][_I_] and just fix-up the packet SCRs. = Cutting off a leading closed GOP: <—closed GOP——> PTS order [_I_][_B_][_P_][_B_][_P_][_I_][_B_][_P_][_B_][_I_] __/ ___¦___/ ___¦___/ __/ ___¦___/ ___¦___/ // ¦ / ¦ // ¦ / ¦ DTS order [_I_][_P_][_B_][_P_][_B_][_I_][_P_][_B_][_I_][_B_] XXXXX PTS order [_I_][_B_][_P_][_B_][_I_] __/ ___¦___/ ___¦___/ // ¦ / ¦ DTS order [_I_][_P_][_B_][_I_][_B_] Just cut it and fix-up the packet SCRs. = Cutting off a trailing GOP from a closed GOP: <—closed GOP——> PTS order [_I_][_B_][_P_][_B_][_P_][_I_].. __/ ___¦___/ ___¦___/ // ¦ / ¦ DTS order [_I_][_P_][_B_][_P_][_B_] Just cut at the end of the closed GOP. = Cutting off a trailing GOP from an open GOP: PTS order [_I_][_B_][_P_][_B_][_I_].. __/ ___¦___/ ___¦___/ // ¦ / ¦ DTS order [_I_][_P_][_B_][_I_][_B_] PTS order [_I_][_B_][_P_][_B_][_I_] __/ ___¦___/ ___¦___/ // ¦ / ¦ DTS order [_I_][_P_][_B_][_I_][_B_] Cut retaining an ending I-frame, only. Honestly, I don't know why the MPEG folks don't supply illustrations instead of their torturous text. This isn't magic, it's Legos. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] '-show_frames' is broken
On 03/04/2024 04.05, Paul B Mahol wrote: On Wed, Apr 3, 2024 at 6:10 AM Mark Filipak wrote: Dear Developers, Thank you for adding 'pkt_dts' and 'pict_type' to '-show_frames'. Those will make things easier. Now, could you fix it? '-show_frames' shows pts < dts. frames.frame.133975.pts=503957216 <-+ These are actually 3 frames frames.frame.133975.pkt_dts=503968477 <-+ apart in the wrong direction frames.frame.133975.pict_type="I" '-show_frames' shows pts < dts for ALL frames (all frames are in open GOPs). = '-f framecrc' is correct I think -- I can't confirm because I can't parse M2TS. dts pts 0, 503945955, 503957216, 3753, 640646, 0x90f222e3, S=1,1 = And '-vf showinfo' is now finding 6 DTS discountinuities instead of 165. (But I don't believe there are any DTS discountinuities.) = Is the problem with 'show_frames' and '-vf showinfo's due to something more internal, more basic? Could it explain why I'm having so much trouble with cutting & joining? I reckon the issue is with open GOPs. I hope that's all. Regards, Mark. PS: You know, when you change/fix something, it would be nice to tell us. That way we could all work together to test/validate the code and track bugs. Sure, in mean time we will consume thin air to stay alive. I don't know what you're responding to, Paul. Can you clarify? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] '-show_frames' is broken
Dear Developers, Thank you for adding 'pkt_dts' and 'pict_type' to '-show_frames'. Those will make things easier. Now, could you fix it? '-show_frames' shows pts < dts. frames.frame.133975.pts=503957216 <-+ These are actually 3 frames frames.frame.133975.pkt_dts=503968477 <-+ apart in the wrong direction frames.frame.133975.pict_type="I" '-show_frames' shows pts < dts for ALL frames (all frames are in open GOPs). = '-f framecrc' is correct I think -- I can't confirm because I can't parse M2TS. dts pts 0, 503945955, 503957216, 3753, 640646, 0x90f222e3, S=1,1 = And '-vf showinfo' is now finding 6 DTS discountinuities instead of 165. (But I don't believe there are any DTS discountinuities.) = Is the problem with 'show_frames' and '-vf showinfo's due to something more internal, more basic? Could it explain why I'm having so much trouble with cutting & joining? I reckon the issue is with open GOPs. I hope that's all. Regards, Mark. PS: You know, when you change/fix something, it would be nice to tell us. That way we could all work together to test/validate the code and track bugs. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] MPEG 'broken_link' flag -- How do I set it?
Thank you, Mark. On 25/03/2024 16.45, Mark Thompson wrote: On 24/03/2024 15:48, Mark Filipak wrote: I cut at the end of an open GOP. When I did that, FFmpeg did not set the MPEG 'broken_link' flag to '1'. The frame following the cut has to be flagged: 'closed_gop' = '0' because it's an open GOP, also, and 'broken_link' = '1'. How do I do that? I searched but did not find. The ffmpeg utility does not edit the internals of the bitstream when cutting (packets are effectively opaque to it); you would need a BSF to make this change. Yes, a bit stream filter is what I seek. Making such a BSF should be straightforward: use CBS BSF with a single update_fragment function which edits the GOP header on any I frame with a discontinuity before it. What's a CBS bit stream filter? There's 2 segments, so 4 cuts. They are both 100% open GOPs. The concatenation is 6 seconds of video. There are 29 GOPs. As you can see, all 29 have identical GOPs. My parse shows that they claim to be closed and not broken. That is 100% false. The use of packet time codes is obsolete, but the 'closed_gop' & 'broken_link' flags aren't. 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 00 00 01 B8 41 A2 95 47 GOP_start_code 00 00 01 B8 time_code == == == == 41 A2 95 47 //Re: H.262 §6.3.8 .—' '—. drop_frame_flag 0--- //'1': drop, '0' don't drop time_code_hours -100 00-- //= 16 time_code_minutes --01 1010 //= 26 marker_bit 0--- time_code_seconds -010 100- //= 20 time_code_pictures ---1 0101 0--- //= 42; time code = 16:26:20.42 closed_gop -1-- //'1': closed GOP; '0': open GOP broken_link --0- //'1': GOP edited, B-frames have lost their reference frames; '0': GOP not edited ? ---0 0111 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] MPEG 'broken_link' flag -- How do I set it?
I cut at the end of an open GOP. When I did that, FFmpeg did not set the MPEG 'broken_link' flag to '1'. The frame following the cut has to be flagged: 'closed_gop' = '0' because it's an open GOP, also, and 'broken_link' = '1'. How do I do that? I searched but did not find. Thanks --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Mark's New Content - SAR
I have new content for anyone interested in what I hope will be the future of FFmpeg. New Digital_Camera_'SAR'-v-Film_Scanner_SAR https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.Digital_Camera_'SAR'-v-Film_Scanner_SAR.html Stride-Match With Decombing Examples https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.Stride-Match_With_Decombing_Examples.html Six Element Objects & 12 Stream Objects https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.Six_Element_Objects_&_12_Stream_Objects.html Streams https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.Streams.html GOP & Frame Reordering https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.GOP_&_Frame_Reordering.html This will all come together at the end. That's because I've pretty much worked it all out already. I've been revising, revising, revising and simplifying, simplifying, simplifying. If you care to comment: https://github.com/markfilipak/Video-Object-Notation/discussions/1 --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Mark's New Content - deeper into it
I have new content for anyone interested in what I hope will be the future of FFmpeg. New Stride-Match With Decombing Examples https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.Stride-Match_With_Decombing_Examples.html Six Element Objects & 12 Stream Objects https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.Six_Element_Objects_&_12_Stream_Objects.html Streams https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.Streams.html GOP & Frame Reordering https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.GOP_&_Frame_Reordering.html This will all come together at the end. That's because I've pretty much worked it all out already. I've been revising, revising, revising and simplifying, simplifying, simplifying. If you care to comment: https://github.com/markfilipak/Video-Object-Notation/discussions/1 --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Mark's New Content
I have new content for anyone interested in what I hope will be the future of FFmpeg. New Six Element Objects & 12 Stream Objects https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.Six_Element_Objects_&_12_Stream_Objects.html Streams https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.Streams.html GOP & Frame Reordering https://markfilipak.github.io/Video-Object-Notation/OFFmpeg.GOP_&_Frame_Reordering.html This will all come together at the end. That's because I've pretty much worked it all out already. I've been revising, revising, revising and simplifying, simplifying, simplifying. If you care to comment: https://github.com/markfilipak/Video-Object-Notation/discussions/1 --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Illustration review, Streams and GOP Frame Reordering [was: a couple of things to look at]
On 04/03/2024 06.25, Rob Hallam wrote: The visuals look good! Nice work. I don't want to detract from that, but: Thank you, Rob. You're right about style inheritance but that's not the issue. Firefox doesn't scale font-size linearly or consistently whereas other browsers do. You can see that by changing Firefox's zoom. Firefox has always been that way. Everybody knows it and I gave up complaining about it many years ago. CSS pretends to make scaling rules, then allows browser developers to scale text however they want to in order to make the text look good to them. So, there's really no specification on scaling. Firefox doesn't support font-size properly and I avoid browser fix-ups. That's what I should have written. Sorry. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Illustration review, Streams and GOP Frame Reordering [was: a couple of things to look at]
On 03/03/2024 18.33, Jim DeLaHunt wrote: Mark: On 2024-03-02 19:51, Mark Filipak wrote: I have a couple of things to look at. https://markfilipak.github.io/Video-Object-Notation/Streams.html https://markfilipak.github.io/Video-Object-Notation/GOP%20%26%20Frame%20Reordering.html Comments are welcome. Please be brutal. 'Streams' is crucial. Good work! Thank you. Regarding the Streams illustration <https://markfilipak.github.io/Video-Object-Notation/Streams.html>: The macroblock to slice to picdata transition is clear. Showing 45 macroblocks in a horizontal slice works. Good work. ... It is hard to count out 45 from single-digit numbers. 00..44 would be much clearer. I agree, and I would have "0..44" if I could. If I used 2-digit numbers, I'd have to almost double the table width. The issue is that FireFox doesn't support 'font-size' style, so making the font smaller to fit can't be done. The complete list of 0..29 slices is visually overwhelming, and not necessary. I think you could keep slices 0..2, elide slices 3..27 with a vertical ellipsis, and keep slices 28..29. That would get the slice structure across. I'm going for visual impact, too. Do you find what I have confusing? The slice structure lacks a comment with size, of the sort you included for macroblock and picdata. The full slice structure does not leave any room for such a comment. Well, I felt that with all 30 slices and all 1350 macroblocks explicitly shown, comments were superfluous. They will get looked at one time, then ignored for the rest of time. Regarding the GOP & Frame Reordering illustration, <https://markfilipak.github.io/Video-Object-Notation/GOP%20%26%20Frame%20Reordering.html>: Time is plastic in illustration space also. You have term definitions which happen after the first use of those terms. It would be easier to follow if the term definitions could come at first use. The opening text, "an I-frame followed by P-frames and optional B-frames", could be improved by adding term definitions. e.g. "an I-frame (complete unto itself, sometimes called keyframe) followed by P-frames (predictive based on differences with the preceding I-frame) and optional B-frames (bipredictive based on differences with the preceding P-frame and I-frame)". Thanks, Jim. That's your style. The first rectangle, GOP specimen, gives a particular frame order. Which order is this? Is this the order of frames in the incoming data stream, before reording? That specimen seems to be in PTS order. Is this necessary, or coincidental? Yes, frames in the stream are in PTS order. What reordering happens in the first step? Is it reordering from incoming stream order to DTS order? Yes. I don't get how the conveyor belt metaphor and illustrations add value. They can easily be visualized and they are memorable. Then show arrows from that sequence down to the same frames, in PTS order. It is not clear to me why the final two B-frames have later DTSs than the following I-frame, but earlier PTSs. Why would these B-frames not be relative to the first I-frame? They are between the last P-frame and the next I-frame of the next GOP. They have no relation to the I-frame back at the beginning of their own GOP other than through the P-frame. If they are relative to the second I-frame, why would that I-frame not have an earlier DTS? It does. When reordered, the next GOP's I-frame is decoded before the previous GOP's B-frames. You see that every time in every video that has B-frames. Are the B-frames relative to the final P-frame before them? To my understanding, yes. That's what the page is about. What is going on visually that the encoder would choose to sequence things this way? To my understanding, it's complying with the specifications: MPEG ISO & ITU. It is great to have a reference to the specification which you are illustrating, "ITU-T H.262 (02/2012)". It would be even better to have that at the beginning. The illustration might explain its goal, e.g. "This illustrates the Group of Pictures and frame reordering operations as described in ITU-T H.262 (02/2012)." It's a matter of writing style. I prefer to not justify something until after I've said it, if at all. And, these diagrams are amazing works of character graphics. They would be even more amazing as works of vector graphics. But drawing them in vector graphics would require a different skill-set. They can be swipe-copied and pasted as plain text. You can't do that with either tables or vector graphics. I consider that important. Thanks for your thoughts, Jim --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] a couple of things to look at
I have a couple of things to look at. https://markfilipak.github.io/Video-Object-Notation/Streams.html https://markfilipak.github.io/Video-Object-Notation/GOP%20%26%20Frame%20Reordering.html Comments are welcome. Please be brutal. 'Streams' is crucial. I have little knowledge of transport streams beyond being 188 bytes/packet and beginning with 0x47. For example, if there are transport streams, are there program streams inside them or not? I would guess there are but I don't have a single TS to evaluate. Thanks --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Streams
Hi All, I'm taking a break from my "errors in trimming and concatenation" pursuits. Here is a single-page HTML about streams. https://markfilipak.github.io/Video-Object-Notation/Streams.html ...this will eventually be FFmpeg documentation if possible, _not_ a book... If you see anything wrong or questionable about it -- anything at all, no matter how small -- kindly let me know. I've approached this from pixels to PS/TS, building up, rather than the usual PS/TS to pixels, pulling apart. I think it works better that way. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Streams
Well, the attachment, which was only 50kB, got stripped off. I'm trying again. Hi All, I'm taking a break from my "errors in trimming and concatenation" pursuits. I've attached a single-page HTML about streams. ...this will eventually be FFmpeg documentation if possible, _not_ a book... If you see anything wrong or questionable about it -- anything at all, no matter how small -- kindly let me know. I've approached this from pixels to PS/TS, building up, rather than the usual PS/TS to pixels, pulling apart. I think it works better that way. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Streams
Hi All, I'm taking a break from my "errors in trimming and concatenation" pursuits. I've attached a single-page HTML about streams. ...this will eventually be FFmpeg documentation if possible, _not_ a book... If you see anything wrong or questionable about it -- anything at all, no matter how small -- kindly let me know. I've approached this from pixels to PS/TS, building up, rather than the usual PS/TS to pixels, pulling apart. I think it works better that way. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ISSUE ABOUT EXTRACTING
On 29/02/2024 17.40, Ferdi Scholten wrote: Hi, Ferdi, Thank you for the tip. I checked it against what I'm doing. The 'pts_time's that it returns do not correlate with the exact times that are computed from frame counts. For example, pts_time=760.607200 should be exactly 760.3[364635..] (based on PTS=2854113 in a 24/1.001fps video having timebase = 90kHz). That is from my investigation into cutting/concatenation errors that I'm continuing to work on. There truly is something amiss inside FFmpeg's computations. It would be welcome to have someone check my work. It's lonely work and incredibly meticulous. --Mark. Hi Mark I have been following your work on this, and admire your persistence in it. However I think this is also related to the type of codec and container that is used. I can't imagine why that would be. Your work as far as I know is about Transport Streams. Not at all, program streams only. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ISSUE ABOUT EXTRACTING
On 29/02/2024 12.19, Ferdi Scholten wrote: The following command will show all key frames and they're time in the video. ffprobe -loglevel error -skip_frame nokey -select_streams v:0 -show_entries frame=pts_time sourcevideo.mkv Hi, Ferdi, Thank you for the tip. I checked it against what I'm doing. The 'pts_time's that it returns do not correlate with the exact times that are computed from frame counts. For example, pts_time=760.607200 should be exactly 760.3[364635..] (based on PTS=2854113 in a 24/1.001fps video having timebase = 90kHz). That is from my investigation into cutting/concatenation errors that I'm continuing to work on. There truly is something amiss inside FFmpeg's computations. It would be welcome to have someone check my work. It's lonely work and incredibly meticulous. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] concat - C needs to go before B - How?
On 21/02/2024 05.20, Paul B Mahol wrote: On Wed, Feb 21, 2024 at 10:12 AM Mark Filipak wrote: Gyan, Paul, Devin, Jim, anyone. Help! You folks have been following my trim+concat adventure. I think I may have found the problem, not just for me. It's a general problem. "N" signifies one frame time. All times are relative to ptsA. __DTS__ _PTS__ ptsA-2N ptsAI-frame with DTS-to-PTS=2N <- call this frame "A" ptsA-N ptsA-N B-frame with DTS-to-PTS=0 <- call this frame "B" --- join here --- ptsA-2N ptsA+N I-frame with DTS-to-PTS=3N <- call this frame "C" You see, dtsC is before dtsB, so C needs to go before B. That's not happening. I don't know of a way to force C to be before B in order to test whether that fixes the glitch. Do you? Aside: Is it okay if dtsC==dtsA? dts can be anything, and for decoding only pts are relevant. DTS cannot be 'anything'. ITU H.262: "2.1.24 decoding time-stamp (DTS) (system): A field that may be present in a PES packet header that indicates the time that an access unit is decoded in the system target decoder." More relevant is that DTS is directly used to control when access units are removed from various buffers. ITU H.222 goes on quite a bit about buffer management, including equations in which DTS appears. It also covers when DTS is not present in PESs but that's not the case here because DTS is present. Rather than providing a single state machine model (i.e., a state diagram showing circles and arrows), ITU H.222's 'explanation' is text that is scattered across various paragraphs that 'explain' the various PES header tags. It's one of the things that makes reading such narrowly crafted specifications so much 'fun'. Gyan suggested a discontinuity flag. ITU H.222 says something about that and that there are two instances but I'm not sure what exactly Gyan was referring to -- what I tried didn't provoke any FFmpeg complaints but it didn't work, either. I had a thought before falling asleep last night. If I recall correctly, there's a tag that instructs the decoder to duplicate a decoded 'picture' either once or twice. It may be possible to assert that tag to the current decoder rather than to some future decoder. I think the best way to handle the case of the 1st frame of the 2nd segment needing to simultaneously be on both sides of the join: before the join by DTS and after the join by PTS, may be to remove the B-frame that ends the 1st segment, and to duplicate the current 'picture' (i.e., the current decoded P-/I-frame) by using that duplication tag, instead. That would preserve the number of frames (and the running time) while eliminating DTS (buffer) issues and allow the 2nd segment's I-frame to stay in the 2nd segment. Of course, there's audio and subtitle packets with their own DTSs that get in the way, but it should be trivial to simply give them new DTSs that 'move' them into the 2nd segment -- the 'error' would be undetectable. Comment: It appears to me that mpegts decoding and buffering has gone through quite a bit of modification over the years as problems have cropped up and understanding has increased -- extensions and new tags have been created. I think the tag to which I referred in the previous paragraph is one such creation. Unfortunately, specifications don't usually talk about why such-and-such is created. They usually only present the new tags. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] concat - C needs to go before B - How?
Gyan, Paul, Devin, Jim, anyone. Help! You folks have been following my trim+concat adventure. I think I may have found the problem, not just for me. It's a general problem. "N" signifies one frame time. All times are relative to ptsA. __DTS__ _PTS__ ptsA-2N ptsAI-frame with DTS-to-PTS=2N <- call this frame "A" ptsA-N ptsA-N B-frame with DTS-to-PTS=0 <- call this frame "B" --- join here --- ptsA-2N ptsA+N I-frame with DTS-to-PTS=3N <- call this frame "C" You see, dtsC is before dtsB, so C needs to go before B. That's not happening. I don't know of a way to force C to be before B in order to test whether that fixes the glitch. Do you? Aside: Is it okay if dtsC==dtsA? --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Packet corrupt on cut, notice on concat
I don't know how "DTS" became "000". Sorry. It's 3AM and I'm a little punchy. I found the problem. FFmpeg is corrupting the last B-frame at the end of cuts. It shows up during subsequent concatenation. Why it's happening is unknown of course. There is no workaround that I can conceive of. --Mark. DTS PTS video 1 video 2 < 504197456 504204963 N=133560 _B[P]B_B_P_B_I_ _I_B_P_ <== 3 < 504201210 504201210 N=133559 [B]P_B_B_P_B_I_ _I_B_P_ < 504204963 504216225 N=133563 _B_P_B_B[P]B_I_ _I_B_P_ <== 2 < 504208717 504208717 N=133561 _B_P[B]B_P_B_I_ _I_B_P_ < 504212471 504212471 N=133562 _B_P_B[B]P_B_I_ _I_B_P_ < 504216225 504223732 N=133565 _B_P_B_B_P_B[I] _I_B_P_ <== 1 < 504219978 504219978 N=133564 _B_P_B_B_P[B]I_ _I_B_P_ join here > 504219979 504227486 N=133566 _B_P_B_B_P_B_I_ [I]B_P_ > 504227486 504234994 N=133568 _B_P_B_B_P_B_I_ _I_B[P] > 504231240 504231240 N=133567 _B_P_B_B_P_B_I_ _I[B]P_ 1 - If I trim the end of video 1 at the I-frame at N=133565 ffmpeg -copyts -i this.m2ts -map 0 -bsf:v noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' -bsf:a noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' -bsf:s noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' %CODE% -muxdelay 0 "%TARGET%" I get "Packet corrupt (stream = 0, dts = 504219978)" and there's a glitch during play. 2 - If I back up and trim the end of video 1 at the P-frame at N=133563 ffmpeg -copyts -i this.m2ts -map 0 -bsf:v noise=drop='lt(pts\,2854113)+gt(pts\,504216225)' -bsf:a noise=drop='lt(pts\,2854113)+gt(pts\,504216225)' -bsf:s noise=drop='lt(pts\,2854113)+gt(pts\,504216225)' %CODE% -muxdelay 0 "%TARGET%" I get "Packet corrupt (stream = 0, dts = 504208717)" and there's a glitch during play. 3 - If I back up again and trim the end of video 1 at the P-frame at N=133560 ffmpeg -copyts -i this.m2ts -map 0 -bsf:v noise=drop='lt(pts\,2854113)+gt(pts\,504204963)' -bsf:a noise=drop='lt(pts\,2854113)+gt(pts\,504204963)' -bsf:s noise=drop='lt(pts\,2854113)+gt(pts\,504204963)' %CODE% -muxdelay 0 "%TARGET%" I get "Packet corrupt (stream = 0, dts = 504201210)" and there's a glitch during play. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Packet corrupt on cut, notice on concat
I found the problem. FFmpeg is corrupting the last B-frame at the end of cuts. It shows up during subsequent concatenation. Why it's happening is unknown of course. There is no workaround that I can conceive of. --Mark. 000 PTS video 1 video 2 < 504197456 504204963 N=133560 _B[P]B_B_P_B_I_ _I_B_P_ <== 3 < 504201210 504201210 N=133559 [B]P_B_B_P_B_I_ _I_B_P_ < 504204963 504216225 N=133563 _B_P_B_B[P]B_I_ _I_B_P_ <== 2 < 504208717 504208717 N=133561 _B_P[B]B_P_B_I_ _I_B_P_ < 504212471 504212471 N=133562 _B_P_B[B]P_B_I_ _I_B_P_ < 504216225 504223732 N=133565 _B_P_B_B_P_B[I] _I_B_P_ <== 1 < 504219978 504219978 N=133564 _B_P_B_B_P[B]I_ _I_B_P_ join here > 504219979 504227486 N=133566 _B_P_B_B_P_B_I_ [I]B_P_ > 504227486 504234994 N=133568 _B_P_B_B_P_B_I_ _I_B[P] > 504231240 504231240 N=133567 _B_P_B_B_P_B_I_ _I[B]P_ 1 - If I trim the end of video 1 at the I-frame at N=133565 ffmpeg -copyts -i this.m2ts -map 0 -bsf:v noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' -bsf:a noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' -bsf:s noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' %CODE% -muxdelay 0 "%TARGET%" I get "Packet corrupt (stream = 0, dts = 504219978)" and there's a glitch during play. 2 - If I back up and trim the end of video 1 at the P-frame at N=133563 ffmpeg -copyts -i this.m2ts -map 0 -bsf:v noise=drop='lt(pts\,2854113)+gt(pts\,504216225)' -bsf:a noise=drop='lt(pts\,2854113)+gt(pts\,504216225)' -bsf:s noise=drop='lt(pts\,2854113)+gt(pts\,504216225)' %CODE% -muxdelay 0 "%TARGET%" I get "Packet corrupt (stream = 0, dts = 504208717)" and there's a glitch during play. 3 - If I back up again and trim the end of video 1 at the P-frame at N=133560 ffmpeg -copyts -i this.m2ts -map 0 -bsf:v noise=drop='lt(pts\,2854113)+gt(pts\,504204963)' -bsf:a noise=drop='lt(pts\,2854113)+gt(pts\,504204963)' -bsf:s noise=drop='lt(pts\,2854113)+gt(pts\,504204963)' %CODE% -muxdelay 0 "%TARGET%" I get "Packet corrupt (stream = 0, dts = 504201210)" and there's a glitch during play. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] To make a PTS, FFmpeg is truncating *up*
On 15/02/2024 13.55, Diederick C. Niehorster wrote: Hi Mark, On Thu, Feb 15, 2024, 19:42 Mark Filipak wrote: Here is my first finding. Can someone who reads 'C' code locate the code and investigate? As told to you many times now, you need to provide a complete command line, with accessible input files, so that others can reproduce. Else no one can help investigate, should they wish to. This is not an ordinary how-do-I-make-this-work issue. This is part of a long investigation. Typical commands I've used are these: ffmpeg -copyts -i this.m2ts -map 0 -bsf:v noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' -bsf:a noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' -bsf:s noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' %CODE% -muxdelay 0 that.m2ts -- which worked. ffmpeg -copyts -i "concat:that1.m2ts|that2.m2ts" -map 0 -c copy -dn -muxdelay 0 that3.m2ts -- which worked. that3.m2ts has beautiful structure, like it was mastered as a single video, not joined from trims of two other videos. Except, it has a glitch. The glitch appears to result from bad PTSs. I noticed that FFmpeg is truncating badly. I don't know what I would post, or how. I have tons of material. I need someone who has great knowledge of the source code to help me. Contact me directly and I'll share all I have. I'll tell you one thing: ffmpeg -ss -i this.m2ts -map 0 -c copy -sn -dn that.m2ts is junk. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] To make a PTS, FFmpeg is truncating *up*
Here is my first finding. Can someone who reads 'C' code locate the code and investigate? It looks suspicious to me because everywhere else, timestamps appear to be truncated in the usual way. Here, to make a PTS, FFmpeg is truncating _up_. If N*3753.75 is an integer, it's used as PTS. But if N*3753.75 is a decimal, the PTS becomes int(N*3753.75 + 1). Here's the proof: 133559*3753.75+2854113=504201209.25 /¯¯¯ 0, 504201210, 504201210, 3753, 608, 0xdece0f07 Frame 133559 is a B-frame near where I've joined two sections that have both been trimmed on both ends. I chose that frame for no particular reason. The joined video and audio packet streams appear to be perfectly timestamped, but there is 3 frames of flashing ...black-black-picture-black-picture-black-picture-black-picture-picture... at the join preceded by a 1 second jump in MPV. I'm crawling through the framecrc listings of three videos: The 'prefix' video that has been trimmed. The 'suffix' video that has been trimmed. The 'join' video after 'prefix' & 'suffix' have been joined. Everything looks beautiful. Even the audio packets appear to be smoothly joined. But I'm crawling thorough it all checking everything. I stopped to compose this message because the truncations bother me. I really need some assistance. This is insanely meticulous work. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] How can I delete packets?
On 14/02/2024 11.42, Gyan Doshi wrote: Like the noise bsf. But it does not compute or look at payload CRC. https://ffmpeg.org//ffmpeg-bitstream-filters.html#noise Regards, Gyan Thank you, Gyan! ffmpeg -copyts -i this.m2ts -map 0 -bsf:v noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' -bsf:a noise=drop='lt(pts\,2854113)+gt(pts\,504223732)' -c copy -dn -muxdelay 0 that.m2ts It works perfectly for video audio & subtitles. Thank you very, very much, Mark. It's called "noise", eh? Hahaha... Good name. No one would look there for a trimmer. Hahaha... ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] How can I delete packets?
Can anyone suggest a way to delete the marked packets? 0: video, 1: audio / DTS PTSticksbytes packet_CRC 1,2798640,2798640, 960, 60, 0xec16103f <== : 48 more <== 1,2845680,2845680, 960, 1084, 0xe54d2b6f <== 0,2846606,2854113, 3753, 640646, 0x3a5a0c45 1,2846640,2846640, 960, 1084, 0xe54d2b6f <== 1,2847600,2847600, 960, 1084, 0xe54d2b6f <== 1,2848560,2848560, 960, 1084, 0xe54d2b6f <== 1,2849520,2849520, 960, 1084, 0xe54d2b6f <== 0,2850360,2850360, 3753, 640646, 0xfed1d09a <== 1,2850480,2850480, 960, 1084, 0xe54d2b6f <== 1,2851440,2851440, 960, 1084, 0xe54d2b6f <== 1,2852400,2852400, 960, 1084, 0xe54d2b6f <== 1,2853360,2853360, 960, 1084, 0xe54d2b6f <== 0,2854113,2861621, 3753, 640646, 0x02208727 Thanks. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] How does the decoder know to make a frame ready for receiving?
A , I apologize for highjacking your topic. I thought it was related to mine. My fault. Please start a new topic with a new subject and I'll butt out. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] How does the decoder know to make a frame ready for receiving?
On 14/02/2024 02.47, Paul B Mahol wrote: Your response is off topic. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] How does the decoder know to make a frame ready for receiving?
I'm top posting and if someone doesn't like it, that's your problem.
A, this is why some of the code needs to be dynamic 'build up-tear down' code. Static code just
can't do the job. --Mark.
On 13/02/2024 20.37, A wrote:
Let's say I have a video with I, P and B frames. My understanding is
that these frames are sorted by DTS when in the file (but not
necessarily by PTS).
I go through the packets in the file (which are in DTS order I
assume), and feed them to the decoder. If it's an I-frame, the decoder
can make it available right away to the caller of
avcodec_receive_frame().
However, if it's a B frame, how does the decoder know whether to
buffer the frame internally or make it available to the user? Since
the decoder has to make frames available to the user in PTS order, how
does it know this frame is the *frame with the lowest PTS since the
previously made-available-frame*?
A trivial example: let's say we have the following frames in DTS order:
DTS: 1 2 3 4 5 10
PTS: 1 9 7 5 6 10
TYPE: I P B B B I
We are feeding them to the decoder in DTS order by calling
avcodec_send_packet(). Note that we don't have uniform gaps between
DTS or PTS because the stream has variable frame rate.
We need to display the frames in the following order:
PTS=1, 5, 6, 7, 9, 10, ...
That means avcodec_receive_frame() needs to return frames in that
order. IIUC, avcodec_receive_frame() returns frames in increasing PTS
order.
Now when the decoder gets fed the {DTS=3,PTS=7} frame, somehow it
needs to not make this frame available to avcodec_receive_frame().
Instead we must return AVERROR(EAGAIN) to the user when the user calls
avcodec_receive_frame().
When the decoder gets fed the {DTS=4,PTS=5) frame, somehow it needs to
realize that this is the frame with the lowest PTS that it will ever
encounter in the future. And it needs to make it available to the user
when the user calls avcodec_receive_frame().
My questions:
1. How does the decoder guarantee that the frame it is returning will
be the lowest PTS it will ever encounter in the future?
Does it rely upon monotonically increasing DTS and maintain a set of
frames in increasing PTS and just make one available to the user when
the lowest in the set has PTS <= DTS (since for any frame PTS >= DTS)?
Could the decoder not run into a situation where it has to hold a lot
of frames in memory because it can't determine it is safe to make any
available to avcodec_receive_frame()?
2. Is it possible to know the PTS of the next frame without reading it
from the stream? Assuming the stream will not be corrupted, etc.?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] FFmpeg Architecture
On 13/02/2024 20.27, amindfv--- via ffmpeg-user wrote: params *before* "-i" are *input params* params *after* "-i" are *output params* that has *always* been the case at least for 15 years and so it's logical that you can't place a param at a random position by common sense and expect the same result Thank you, Harald. I knew that but your gentle reminder is welcome. It has helped me to better see the problem. This is documented in the first 2 sections here: https://trac.ffmpeg.org/wiki/Seeking Yes, Tom, and it essentially says they are very different in execution time but identical in result, which they're not, not even close. Also, '-i'-before-'-ss' is ignoring '-copyts'. Also, 'too-early' video packets are being output instead of cut. Also, 'too-early' audio packets are being output instead of cut. Also, the first audio packet that is erroneously passed is much smaller and has a different CRC than it should have even though this is a remuxing operation. The evidence of bugs throughout is overwhelming. Contrary to what's written, '-i this.m2ts -ss 20 -to 60' outputs 40 seconds, not 60. Shall I go on? My question once again, in this thread's first post: Why are these different? ffmpeg -ss 20.061708333 -copyts -i %SOURCE% -map 0 -c copy -sn -dn -muxdelay 0 %TARGET% ffmpeg -copyts -i %SOURCE% -map 0 -ss 20.061708333 -c copy -sn -dn -muxdelay 0 %TARGET% Note that "20.061708333" is a time, not a PTS. Why are they hundreds of frames different? We are over 35 posts in this thread (not counting 2 other threads of related stuff) and no one has even said whether they should or should not be the same. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] FFmpeg Architecture
On 13/02/2024 14.13, Reindl Harald wrote: Am 13.02.24 um 19:39 schrieb Paul B Mahol: On Tue, Feb 13, 2024 at 7:21 PM Mark Filipak wrote: On 13/02/2024 03.24, Paul B Mahol wrote: On Tue, Feb 13, 2024 at 12:37 AM Carl Zwanzig wrote: Paul, Carl, I assume you are both familiar with the source code. I'm not. Fact: '-ss'-before-'-i' and '-i'-before-'-ss' _do_ give different results. I suggested that the difference might result from the way that FFmpeg is designed. Not fact, your logic and math skills are really poor, reconsider additional real educational summer camp. params *before* "-i" are *input params* params *after* "-i" are *output params* that has *always* been the case at least for 15 years and so it's logical that you can't place a param at a random position by common sense and expect the same result Thank you, Harald. I knew that but your gentle reminder is welcome. It has helped me to better see the problem. '-i'-before-'-ss' is not honoring '-copyts' and possibly '-muxdelay 0' so the output's PTSs do not match what '-ss' is asking for because '-ss' is citing input PTSs. Is that what you're 'saying'? --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] FFmpeg Architecture
On 13/02/2024 03.24, Paul B Mahol wrote: On Tue, Feb 13, 2024 at 12:37 AM Carl Zwanzig wrote: Paul, Carl, I assume you are both familiar with the source code. I'm not. Fact: '-ss'-before-'-i' and '-i'-before-'-ss' _do_ give different results. I suggested that the difference might result from the way that FFmpeg is designed. I mentioned dynamic versus static architectures. When thinking about dynamic versus static think "build up/tear down" versus "call". "Build up/tear down" versus "call" has to do with implementation -- how FFmpeg runs jobs -- not whether the job is streaming or real-time. In H.222, ISO & ITU imply (to me) that they had "build up/tear down" in mind when they created the system model they created. The question is this: Should '-ss'-before-'-i' and '-i'-before-'-ss' give different results? They _do_, but _should_ they? Set aside for the moment that '-ss'-before-'-i' and '-i'-before-'-ss' make differing cuts (at differing PTSs) that are hundreds of frames different. Set aside for the moment that '-ss'-before-'-i' honors '-muxdelay 0' but '-i'-before-'-ss' doesn't. Set aside for the moment that both of them cut the 'earliest' audio packets but both leave some 'too-early' audio packets in their results. Set aside for the moment that both of them include video packets that have 'too-early' PTSs that should have been cut. None of that matters for now. I can't submit a bug ticket unless I know whether '-ss'-before-'-i' and '-i'-before-'-ss' should give the same results. After that is established and I submit a ticket, assuming the answer is that they should be the same, then all the other details will be hashed out and all the fighting will occur in ... github? Is it github? I think so. Please help with this if you can. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] FFmpeg Architecture (was: Codec copy with -ss before -i and after -i is not documented)
On 12/02/2024 11.30, Paul B Mahol wrote: On Mon, Feb 12, 2024 at 9:48 AM Mark Filipak wrote: Does FFmpeg do any internal scripting or dynamic code building/linking? Please define what you mean by these concepts. Happy to, Paul. Internal scripting is when a task is built using a scripting language (or pseudo language) that is then run by submitting it to a built-in interpreter -- much as you script a task in a terminal -- except that the interpreter and the script aren't made or seen by the user. I think that in video, such an internal script is sometimes called a workflow but I'm unsure of that. After the script has been run, it's usually discarded. Dynamic, as opposed to static, means that execution changes based on run-time conditions that usually are not explicitly controlled by the user. It appears that FFmpeg currently does not use any dynamic code. Conditional logic alone does not make code dynamic. Code building is when existing code blocks, such as library functions, are copied and linked. The behavior is very much like internal scripting but with faster execution. Code linking accomplishes the same result but via code blocks that accept parameters and are re-entrant. Dynamic code building/linking means that the copying/linking happens at run-time based on run-time conditions that are not explicitly controlled by the user. Because they are run-time code structures, the dynamic stuff isn't suited to streaming because run-time in streaming means real-time. Dynamic is not well suited to real-time processing. Running an interpreter of any kind is not well suited to real-time, either. Even though I used the word "or" in my post, the use of any of the architectural techniques can be mixed. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] FFmpeg Architecture (was: Codec copy with -ss before -i and after -i is not documented)
On 12/02/2024 03.21, Paul B Mahol wrote: Mark wants single command example to work 100% correct in 100% situations and that output is 100% correct 100% of time. Yes. Of course. That is possible only for very trivial containers only currently. And because libs are very low level it can not be done at all with current state of code. Now I think we're making some progress. Tell me, Paul, does FFmpeg do anything beyond what its encoders do? I'm pretty sure the answer is "yes" for '-vf' and '-bsf'. Are there any others? Does FFmpeg do any internal scripting or dynamic code building/linking? --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
On 11/02/2024 17.39, Paul B Mahol wrote: On Sun, Feb 11, 2024 at 11:08 PM Mark Filipak wrote: On 11/02/2024 16.42, Paul B Mahol wrote: Codec copy with -ss before -i and after -i is not documented that it gives different results Does that make sense? I think it's not documented because no one knows how to explain the results. It is self explanatory. Hahaha... That's funny. You're a comedian, Paul. because once you do not decode everything from start you basically can not expect to get always (for any container and for any input) frame-accurate results in both cases. I don't think decoding is being done. The cutting/trimming can be by dropping packets & remuxing. The packets have to be 'opened' to read the PTSs, but I don't think there's actual decoding. Packets here are just demuxed, not decoded. So -c copy will demux, so sample accurate audio seeking is not possible. '-ss'-before-'-i' is cutting at the right point. That one actually seeks without demuxing each packet from start. I think we're getting closer to my problem. So '-ss'-before-'-i' looks at the packet headers and the PES headers, but only individually. It doesn't form streams until it gets to the cut point. Then it begins forming the various streams. Is that what you mean? '-i'-before-'-ss' is cutting at the wrong point. This one does not seek at all, it just demux from start and drops packets up to certain point. So, wouldn't the end result be the same? Many people have said that but that's not been my experience. Not at all. For -c copy, that one demuxes from start (without any seeking, but just skipping packets processing) but gives output only after timeline point. Sorry. "That one"? Which one? They both have '-c copy' of course. Which is kind of logical because it does not decode at all. And for complex codec that have different forward/backward frame predictions it will give incorrect results because PTS may not match DTS - presentation timestamp vs demux timestamp. DTS is not demux timestamp. And what do you mean by "it"? What is the antecedent of "it"? I'm lost in your explanation. So for '-c copy' -ss after -i is mostly not useful, exp. for complex video/audio codecs with complex interframe coding. As I wrote earlier in this thread, I did '-i'-before-'-ss' on a lark to see if it would be better. It was worse. So, it seems like I have the operations right and that they should be the same but they're not. Correct? Are you saying that '-ss'-before-'-i' & '-i'-before-'-ss' should be identical? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
On 11/02/2024 16.42, Paul B Mahol wrote: Codec copy with -ss before -i and after -i is not documented that it gives different results Does that make sense? I think it's not documented because no one knows how to explain the results. because once you do not decode everything from start you basically can not expect to get always (for any container and for any input) frame-accurate results in both cases. I don't think decoding is being done. The cutting/trimming can be by dropping packets & remuxing. The packets have to be 'opened' to read the PTSs, but I don't think there's actual decoding. '-ss'-before-'-i' is cutting at the right point. '-i'-before-'-ss' is cutting at the wrong point. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
-- Forgive me if this is a duplicate (trouble with email client, again) -- I think I can help out here, Vincent. On 11/02/2024 14.53, Vincent Deconinck wrote: Hi, I will probably get flamed because I'm for jumping into this conversation while being a complete newbie :-), but I think nobody replied with an answer to Mark's question "why". Before "why" there's the question of "should". I backed off "why" and am now simply trying to determine whether '-ss'-before-'-i' _should_ be the same as '-i'-before-'-ss'. All I know is the ffmpeg page on seeking - https://trac.ffmpeg.org/wiki/Seeking - ends with a paragraph saying: "Using -ss as input/output option *together with -c:v copy might not be accurate* since ffmpeg is forced to only use/split on i-frames" (emphasis mine) I split/trim _only_ on I-frames via '-ss value' in which 'value' has nanosecond resolution. I have confirmed that the trim PTSs are correct for '-ss'-before-'-i' but wrong by hundreds of frames for '-i'-before-'-ss'. The page also states that: "As of FFmpeg 2.1, when transcoding with ffmpeg (*i.e. not stream copying*), -ss is now also "frame-accurate" even when used as an input option" I am not transcoding. My understanding is thus that with input seeking, the requested start time will not be satisfied without transcoding Your quotation is "when transcoding with ffmpeg". It apparently doesn't apply to "without transcoding". I asked Should Command 1 and Command 2 make the same outputs? "Yes" or "No"? Arguing (or even citing) the so-called documentation is pointless. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
I think I can help out here, Vincent. On 11/02/2024 14.53, Vincent Deconinck wrote: Hi, I will probably get flamed because I'm for jumping into this conversation while being a complete newbie :-), but I think nobody replied with an answer to Mark's question "why". Before "why" there's the question of "should". I backed off "why" and am now simply trying to determine whether '-ss'-before-'-i' _should_ be the same as '-i'-before-'-ss'. All I know is the ffmpeg page on seeking - https://trac.ffmpeg.org/wiki/Seeking - ends with a paragraph saying: "Using -ss as input/output option *together with -c:v copy might not be accurate* since ffmpeg is forced to only use/split on i-frames" (emphasis mine) I split/trim _only_ on I-frames via '-ss value' in which 'value' has nanosecond resolution. I have confirmed that the trim PTSs are correct for '-ss'-before-'-i' but wrong by hundreds of frames for '-i'-before-'-ss'. The page also states that: "As of FFmpeg 2.1, when transcoding with ffmpeg (*i.e. not stream copying*), -ss is now also "frame-accurate" even when used as an input option" I am not transcoding. My understanding is thus that with input seeking, the requested start time will not be satisfied without transcoding Your quotation is "when transcoding with ffmpeg". It apparently doesn't apply to "without transcoding". I asked Should Command 1 and Command 2 make the same outputs? "Yes" or "No"? Arguing (or even citing) the so-called documentation is pointless. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
On 11/02/2024 14.28, Paul B Mahol wrote: On Sun, Feb 11, 2024 at 7:12 PM Mark Filipak wrote: On 11/02/2024 13.09, Bouke / Videotoolshed wrote: So do you, so why ask the question? Now go away! I do not know the answer. In most cases you will get in most times different results for those 2 variants. Help me to understand, Paul. If '-ss' precedes '-i', then one set of code is run, but if '-i' precedes '-ss', then a differing set of code is run. Is that statement correct? Only for perfect containers and perfect implementations it will give same result in every case. Well, I wish I knew how to test whether the M2TS that's on disc is a perfect stream, and if not, how to fix it before doing any trimming. Aside: Though the actual source file is called 00305.m2ts, it appears to have only a program stream (PS); it does not contain a TS header. I checked other M2TS files on other discs. None of them actually have TSs. Regards, Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
On 11/02/2024 13.09, Bouke / Videotoolshed wrote: So do you, so why ask the question? Now go away! I do not know the answer. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
On 11/02/2024 13.00, Bouke / Videotoolshed wrote: Stop trolling. Read in on the subject. You want to write a FFmpeg manual? Go away, don’t spam the rest of us. On 11 Feb 2024, at 18:47, Mark Filipak wrote: Command 1: ffmpeg -ss 10 -copyts -i this.m2ts -map 0 -c copy -sn -dn -muxdelay 0 that.m2ts Command 2: ffmpeg -copyts -i this.m2ts -map 0 -ss 10 -c copy -sn -dn -muxdelay 0 that.m2ts Let's ignore all the errors both make. And let's ignore the individual errors that they make individually. Should Command 1 and Command 2 make the same outputs? "Yes" or "No"? You don't know the answer, do you Bouke? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
Command 1: ffmpeg -ss 10 -copyts -i this.m2ts -map 0 -c copy -sn -dn -muxdelay 0 that.m2ts Command 2: ffmpeg -copyts -i this.m2ts -map 0 -ss 10 -c copy -sn -dn -muxdelay 0 that.m2ts Let's ignore all the errors both make. And let's ignore the individual errors that they make individually. Should Command 1 and Command 2 make the same outputs? "Yes" or "No"? I'm not trying to be rude. I'm simply trying to get a definitive answer to a question that goes to the heart of what ffmpeg is and does. Regards, Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
On 08/02/2024 15.16, Paul B Mahol wrote: I think, that one of variant use seeking (in container via demuxer) and other one use frame seeking by decoding everything from start using trim filters. Nope. Neither is decoding -- too fast -- as though decoding would/should make a difference. Here's '-ss' before '-i' (definitely using demuxer): size= 247808kB time=00:01:02.90 bitrate=32273.5kbits/s speed=2.23x Here's '-i' before '-ss': size= 592384kB time=00:02:33.87 bitrate=31537.1kbits/s speed=4.35x The '-i' before '-ss' case is actually faster. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
On 08/02/2024 05.40, Paul B Mahol wrote: Read logs and compare, use common sense, brain cells, logic and intelligence. Thank you, Vladimir Vladimirovich. I'd do that if I had a brain. Why are they different? --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
On 07/02/2024 16.53, Paul B Mahol wrote: On Wed, Feb 7, 2024 at 10:28 PM Mark Filipak wrote: Hi Carl, On 07/02/2024 13.56, Carl Zwanzig wrote: On 2/7/2024 10:34 AM, Mark Filipak wrote: Okay. Why are they different? Because the containers are different? An mp4 container is not the same as an mkv (or avi or mpeg), they must have different demuxers. They are the same source, same container. The only difference is command. ffmpeg -ss 20.061708333 -copyts -i %SOURCE% -map 0 -c copy -sn -dn -muxdelay 0 %TARGET% ffmpeg -copyts -i %SOURCE% -map 0 -ss 20.061708333 -c copy -sn -dn -muxdelay 0 %TARGET% Why do the results differ? They're not a little different. They're very different. The DTSs differ. The PTSs differ. The cutting points differ by a couple hundred frames. Even some of the packet lengths differ! This is serious. I can't tell if the GOPs differ -- DTS-sorted v PTS-sorted -- because it's impossible to correlate 'framecrc' results and 'showinfo' results. use -v debug Here ya go, Paul. Logs are attached. ffmpeg started on 2024-02-07 at 19:09:53 Report written to "ffmpeg-20240207-190953.log" Log level: 48 Command line: "C:\\CMD & tiny apps\\ffmpeg\\ffmpeg.exe" -report -v debug -copyts -i "h:\\BDMV\\STREAM\\00305.m2ts" -map 0 -ss 20.061708333 -to 35 -c copy -sn -dn -muxdelay 0 "c:\\FANNY AND ALEXANDER, '-i -ss -to'.m2ts" ffmpeg version 2023-11-09-git-acf63d5350-full_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers built with gcc 12.2.0 (Rev10, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --pkg-config=pkgconf --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-dxva2 --enable libavutil 58. 32.100 / 58. 32.100 libavcodec 60. 33.100 / 60. 33.100 libavformat60. 17.100 / 60. 17.100 libavdevice60. 4.100 / 60. 4.100 libavfilter 9. 13.100 / 9. 13.100 libswscale 7. 6.100 / 7. 6.100 libswresample 4. 13.100 / 4. 13.100 libpostproc57. 4.100 / 57. 4.100 Splitting the commandline. Reading option '-report' ... matched as option 'report' (generate a report) with argument '1'. Reading option '-v' ... matched as option 'v' (set logging level) with argument 'debug'. Reading option '-copyts' ... matched as option 'copyts' (copy timestamps) with argument '1'. Reading option '-i' ... matched as output url with argument 'h:\BDMV\STREAM\00305.m2ts'. Reading option '-map' ... matched as option 'map' (set input stream mapping) with argument '0'. Reading option '-ss' ... matched as option 'ss' (set the start time offset) with argument '20.061708333'. Reading option '-to' ... matched as option 'to' (record or transcode stop time) with argument '35'. Reading option '-c' ... matched as option 'c' (codec name) with argument 'copy'. Reading option '-sn' ... matched as option 'sn' (disable subtitle) with argument '1'. Reading option '-dn' ... matched as option 'dn' (disable data) with argument '1'. Reading option '-muxdelay' ... matched as option 'muxdelay' (set the maximum demux-decode delay) with argument '0'. Reading option 'c:\FANNY AND ALEXANDER, '-i -ss -to'.m2ts' ... matched as output url. Finished splitting the commandline. Parsing a group of options: global . Applying option report (generate a report) with argument 1. Applying option v (set logging level) with argument debug. Applying option copyts (copy timestamps) with argument 1. Successfully parsed a group of options. Parsing a group of options: input url h:\BDMV\STREAM\00305.m2ts. Successfully parsed a group of options. Opening an input file: h:\BDMV\STREAM\00305.m2ts. [AVFormatContext @ 005a31c0] Opening 'h:\BDMV\STREAM\00305.m2ts' for reading [file @ 005bb740] Setting default whitelist 'file,crypto,data' [mpegts @ 005a31c0] Format mpegts probed with size=2048 and score=50 [mpegts @ 005a31c0] stream=0 stream_type=1b pid=1011 prog_reg_desc=HDMV [mpegts @ 005a31c0] stream=1 stream_type=86 pid=1100 prog_reg_desc=HDMV [mpegts @ 005a31c0] stream=2 stream_type=90 pid=1200 prog_reg_
Re: [FFmpeg-user] Why are these different?
On 07/02/2024 16.53, Paul B Mahol wrote: On Wed, Feb 7, 2024 at 10:28 PM Mark Filipak wrote: Hi Carl, On 07/02/2024 13.56, Carl Zwanzig wrote: On 2/7/2024 10:34 AM, Mark Filipak wrote: Okay. Why are they different? Because the containers are different? An mp4 container is not the same as an mkv (or avi or mpeg), they must have different demuxers. They are the same source, same container. The only difference is command. ffmpeg -ss 20.061708333 -copyts -i %SOURCE% -map 0 -c copy -sn -dn -muxdelay 0 %TARGET% ffmpeg -copyts -i %SOURCE% -map 0 -ss 20.061708333 -c copy -sn -dn -muxdelay 0 %TARGET% Why do the results differ? They're not a little different. They're very different. The DTSs differ. The PTSs differ. The cutting points differ by a couple hundred frames. Even some of the packet lengths differ! This is serious. I can't tell if the GOPs differ -- DTS-sorted v PTS-sorted -- because it's impossible to correlate 'framecrc' results and 'showinfo' results. use -v debug One of them IIRC uses trim filters for seeking I will try. Thank you. They are both trimming, just at differing points. They are both cutting off hundreds of leading audio packets but they are both leaving leading audio packets, 52 for one and 54 for the other, that should be cut off. In the first, the cut-point I-frame immediately follows the not-cut-off audio packets, but in the other, the correct cut-point I-frame is hundreds of video frames later. They both are leaving other audio packets that come after the cut point but have lower PTSs. They both leave the 'next' B-frame (which should be cut off) as though they're working on DTS-order instead of PTS-order. I think there are bugs in the frame reordering _and_ in video v audio packet handling when cutting _and_ in the '-ss' handling. I moved the location of '-ss' on a lark just to see if putting it after '-i' would produce better results; the results were worse. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
Hi Carl, On 07/02/2024 13.56, Carl Zwanzig wrote: On 2/7/2024 10:34 AM, Mark Filipak wrote: Okay. Why are they different? Because the containers are different? An mp4 container is not the same as an mkv (or avi or mpeg), they must have different demuxers. They are the same source, same container. The only difference is command. ffmpeg -ss 20.061708333 -copyts -i %SOURCE% -map 0 -c copy -sn -dn -muxdelay 0 %TARGET% ffmpeg -copyts -i %SOURCE% -map 0 -ss 20.061708333 -c copy -sn -dn -muxdelay 0 %TARGET% Why do the results differ? They're not a little different. They're very different. The DTSs differ. The PTSs differ. The cutting points differ by a couple hundred frames. Even some of the packet lengths differ! This is serious. I can't tell if the GOPs differ -- DTS-sorted v PTS-sorted -- because it's impossible to correlate 'framecrc' results and 'showinfo' results. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
On 07/02/2024 10.06, Paul B Mahol wrote: On Wed, Feb 7, 2024 at 2:43 AM Mark Filipak wrote: Why are these different? This is all about seeking, and that depends 10% on internal demuxer implementation of container. Okay. Why are they different? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Why are these different?
Why are these different? Looking only at the first 5 video frames: ffmpeg -ss 20.061708333 -copyts -i %SOURCE% -map 0 -c copy -sn -dn -muxdelay 0 %TARGET% produces this: 0,2846606,2854113, 3753, 640646, 0x3a5a0c45 0,2850360,2850360, 3753, 640646, 0xfed1d09a <== error 0,2854113,2861621, 3753, 640646, 0x02208727 0,2857867,2857867, 3753, 640646, 0x108abb16 0,2861621,2869128, 3753, 640646, 0xfd51ca41 ffmpeg -copyts -i %SOURCE% -map 0 -ss 20.061708333 -c copy -sn -dn -muxdelay 0 %TARGET% produces this: 0, 50062, 61323, 3753, 640646, 0x12a26bc2 0, 53816, 53816, 3753, 415846, 0xb16fcb71 <== error 0, 57569, 57569, 3753, 123879, 0xf2721eb8 <== error 0, 61323, 68831, 3753, 126929, 0xe73f80e5 0, 65077, 65077, 3753, 124619, 0x20a2a8d5 They have the same '-copyts'. They should have the same DTSs & PTSs. They don't. They have the same '-muxdelay 0'. They should both have no delay. The 2nd has delay. The packet with CRC=0x3a5a0c45 is packet 0 in the first and packet 264 in the second. 'showinfo' shows only frames and uses bogus PTSs. 'framecrc' shows only packets, not frames. So it doesn't seem possible to correlate their information. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Why are these different?
Why are these different? ffmpeg -ss 20.061708333 -copyts -i %SOURCE% -map 0 -c copy -sn -dn -muxdelay 0 %TARGET% ffmpeg -copyts -i %SOURCE% -map 0 -ss 20.061708333 -c copy -sn -dn -muxdelay 0 %TARGET% The DTSs are different. The PTSs are different. The cuts are at different running times. The mistakes -- they both make mistakes -- are different. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Wanted: Easy way to delete PES packets
ffmpeg -ss 20.061708333 -copyts -i %SOURCE% -map 0 -c copy -sn -dn -muxdelay 0 "%TARGET%" left behind 59 PES packets that should have been trimmed off. Short of researching the number of 2048 byte sectors in each offending PES and then deleting the sectors, can anyone suggest a better/easier way to delete the marked (<==) packets below? Pre trim, the first PTS is 1048560. Post trim, the first PTS is 2798640. It should be 2854113. 0: video, 1: audio / DTS PTSticksbytes packet_CRC 1,2798640,2798640, 960, 60, 0xec16103f <== : 48 more <== 1,2845680,2845680, 960, 1084, 0xe54d2b6f <== 0,2846606,2854113, 3753, 640646, 0x3a5a0c45 1,2846640,2846640, 960, 1084, 0xe54d2b6f <== 1,2847600,2847600, 960, 1084, 0xe54d2b6f <== 1,2848560,2848560, 960, 1084, 0xe54d2b6f <== 1,2849520,2849520, 960, 1084, 0xe54d2b6f <== 0,2850360,2850360, 3753, 640646, 0xfed1d09a <== 1,2850480,2850480, 960, 1084, 0xe54d2b6f <== 1,2851440,2851440, 960, 1084, 0xe54d2b6f <== 1,2852400,2852400, 960, 1084, 0xe54d2b6f <== 1,2853360,2853360, 960, 1084, 0xe54d2b6f <== 0,2854113,2861621, 3753, 640646, 0x02208727 There is additional strangeness: - If the frames are I B P, why do they all have 640646 bytes? Do they _really_ have 640646 bytes? - Why were some leading audio PES packets trimmed off but not the ones shown? - Why does 'showinfo' show n=0..133566 but 'framecrc' shows 133568 (by physical count)? - The audio PES at PTS=2798640 was 1084 bytes before the trim 1,2798640,2798640, 960, 1084, 0xe54d2b6f but is only 60 bytes after the trim. How is that possible if only remuxing? I'm investigating the additional strangeness and I have expert help, but any thoughts on the strangeness would be much appreciated. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] The Guild
On 01/02/2024 16.08, Reindl Harald wrote: Am 01.02.24 um 21:58 schrieb Mark Filipak: On 01/02/2024 15.48, Reindl Harald wrote: Am 01.02.24 um 20:49 schrieb Mark Filipak: On 01/02/2024 14.41, Carl Zwanzig wrote: On 2/1/2024 11:26 AM, Mark Filipak wrote: There needs to be an FFmpeg Guild and there needs to be an FFmpeg industry. You guys/gals need to make a living. How can we make that happen? Why does there need to be a "guild"? Because FFmpeg developers need to make a living. If you want one, start one. I'm not an FFmpeg developer. so why un the world do you start a topic out of the blue nobody but you don't get? it starts by opening a new thread with a random quote from god knows where Paul replied to Subject: DTSs & PTSs in MPEG2-TS streams but it was off-topic. When he did that, I changed to Subject: The Guild and replied. Carl replied to that. Pay attention. you are even too dumb to operate a mail-client, otherwise that won'thave ended in a private thread I'm not dumb at all. I made my reply to you private because it's off-topic and would only create ranker on the mailing list. Now I see you've transferred this rancor back to the mailing list. Oh, well. i do not need to pay attention when *you* start a random thread with a random quote I don't recall a random quote. To what do you refer? "Yes ffmpeg is sole problem here. Go use something better and non-free" meant "go and fuck yourself" from my point of understanding Yes, that's how I took it, but I'm trying to be a gentleman. :-) --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] DTSs & PTSs in MPEG2-TS streams
On 01/02/2024 16.09, Devin Heitmueller wrote: On Thu, Feb 1, 2024 at 1:55 PM Mark Filipak wrote: On 01/02/2024 09.54, Devin Heitmueller wrote: On Thu, Feb 1, 2024 at 1:15 AM Mark Filipak wrote: FFmpeg assigns DTSs & PTSs to P-frames and B-frames in MPEG2-TS streams. How does it determine those DTSs & PTSs? Since DTSs & PTSs don't actually exist for P-/B-frames in MPEG2-TS streams, FFmpeg must have a way that's unknown to me. P/B frames can certainly have PTS values. Well, they _can_ as in they're not prohibited, but I can't recall ever seeing a P-/B-frame in MPEG2-TS supplying a DTS or a PTS. I've parsed quite a few MPEG2-TSs. If you want to share a sample with me privately, I can take a look and possibly offer you a better explanation. P/B frames generally have PTS values. B frames *must* have both PTS and DTS since they are different values. If you're not seeing them then either your sample is broken or your parser is. There is no PES extension, so there is no place for DTS & PTS to reside. I realize that FFmpeg is creating DTSs & PTSs. That appears to be part of the problem. I've seen many reports of DTS out of sequence when the original frame, a P-/B-frame, had no DTS. It appears that FFmpeg is reporting an issue that it created. In fact, you have to have PTS values in B frames since they differ from the DTS (since with B frames the presentation order differs from the decoding order). I don't see DTS or PTS in the PES header. What I do see is 'PES_extension_flag'=='0' and 'PTS_DTS_flags'=='00', so no PES ext and no dts or pts. That's why I asked my question. The PES extension flag is mutually exclusive of whether the PTS_DTS_flags field is set. It's very common for there to PTS_DTS_flags to be non-zero while PES_extension_flag is false. Okay. If DTS & PTS are not in the PES extension because there is no PES extension, then where are they? There are only a handful of bits in an MPEG2-TS/-PS I haven't figured out. You may know more than I do. Every once in awhile I'll see 'PTS_DTS_flags'=='10' but that's unusual. Mind you, this is in MPEG2-TSs. I don't how to parse anything else. That shouldn't be unusual. It means there is a PTS but no DTS in that PES. In fact, specifying the PTS without the DTS is generally what you're supposed to do if they are the same value (which is the norm for audio streams and video streams without B frames). There are potentially cases with some streams where the PTS and/or DTS is not specified for every frame, I'd say "usually", not "potentially". in which case libavformat will interpolate those values based on the frame duration and the prior packet. Of course. But why? They're not needed. Once the TS packets are put in correct sequence via SCR, the PS packets transported by those TS packets are in presentation order. The process to reorder the PS in order to decode B-frames and then put the decoded pictures back into the original order is straight forward. It's not "tricky" at all. Um, I'm not sure what to say here. The DTS is what defines the order that the packets are announced to the decoder. The PTS defines the order in which they are presented. The SCR will constantly increment. I think perhaps you have a fundamental misunderstanding of how PTS/DTS works. Yes, the SCR (in the TS) will constantly increment. It's when the _receiver_ of the TS sees SCRs that are out of order that it knows when packets are being received out of order and how to put them into proper order. That's why TSs are called "fault tolerant". FFmpeg seems to think that DTS has that function for every frame but where is the DTS if there's no PES_ext? I think that DTS & PTS applies to GOPs, not individual frames. I think that FFmpeg is misusing DTS. But I confess that I don't know why an occasional P-frame has a PES_ext with a PTS while P-/B-frames generally don't have PES_ext or DTSs or PTSs. It has become "tricky". That's what I'm trying to investigate, but I can't read 'C' code. I'm seeing some strange things. They can't be as strange as they look because they look disastrous. At issue is the cause of non-monotonous DTSs and obviously bogus DTSs for P-frames such as '-9223372036854775808'. 9223372036854775808 is a magic number. It corresponds to the #define for AV_NOPTS_VALUE. If you see that value it means that the packet did not have a PTS or DTS value assigned to it and thus you may have to take special measures. Oh, dear. I guessed that. Magic number. Fixup. There's a million fixups. I don't see why they're needed. That's why my preliminary finding is that FFmpeg is creating its own faults through fixups. This is essentially how all demuxers/parsers work. The PES packet in the stream doesn't contain a PTS or DTS, the API tells you that, and thus the application has to use a heuristic to assign a value. Okay. So the deco
Re: [FFmpeg-user] The Guild
On 01/02/2024 14.41, Carl Zwanzig wrote: On 2/1/2024 11:26 AM, Mark Filipak wrote: There needs to be an FFmpeg Guild and there needs to be an FFmpeg industry. You guys/gals need to make a living. How can we make that happen? Why does there need to be a "guild"? Because FFmpeg developers need to make a living. If you want one, start one. I'm not an FFmpeg developer. Second, a cloud-based book that people buy. It would have to have a reader that people buy. The reader would read an encrypted cloud, would be read-only, would resist host probing/capture/screenshots, and would save _nothing_ locally. Again, why? (And of course a book would have a copyright, but that has little to do with how distribution is licensed.) You do not seem to understand open-source projects at all. The book and the reader and the private forum would have everything to do with FFmpeg but nothing to do with FFmpeg legally. If FFmpeg is to continue to be free and open source, there needs to be a for-profit business attached to FFmpeg. I will contribute to the book for free. I will donate pages that I already have and will donate more. I'm retired. I already have a guaranteed income. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] The Guild
The reader and the book would be copyrighted. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] The Guild
On 01/02/2024 14.15, Bouke / edit 'B wrote: I'd pay $25/month to belong. I pay 25 bucks for each troll head. (Or 50 per ball, makes for more fun) Bouke Stop playing the Vladimir Putin role. This isn't a movie. There needs to be an FFmpeg Guild and there needs to be an FFmpeg industry. You guys/gals need to make a living. How can we make that happen? Second, a cloud-based book that people buy. It would have to have a reader that people buy. The reader would read an encrypted cloud, would be read-only, would resist host probing/capture/screenshots, and would save _nothing_ locally. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] The Guild
On 01/02/2024 13.58, Paul B Mahol wrote: Yes ffmpeg is sole problem here. Go use something better and non-free. What's better? Paul, you're trapped, aren't you? You need to make a living but you can't make a living working on FFmpeg. Shall we discuss how the FFmpeg Guild members can make a living? First, how about a members-only, private support forum? I'd pay $25/month to belong. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] DTSs & PTSs in MPEG2-TS streams
Hey Devin, On 01/02/2024 09.54, Devin Heitmueller wrote: Hi Mark, On Thu, Feb 1, 2024 at 1:15 AM Mark Filipak wrote: FFmpeg assigns DTSs & PTSs to P-frames and B-frames in MPEG2-TS streams. How does it determine those DTSs & PTSs? Since DTSs & PTSs don't actually exist for P-/B-frames in MPEG2-TS streams, FFmpeg must have a way that's unknown to me. P/B frames can certainly have PTS values. Well, they _can_ as in they're not prohibited, but I can't recall ever seeing a P-/B-frame in MPEG2-TS supplying a DTS or a PTS. I've parsed quite a few MPEG2-TSs. In fact, you have to have PTS values in B frames since they differ from the DTS (since with B frames the presentation order differs from the decoding order). I don't see DTS or PTS in the PES header. What I do see is 'PES_extension_flag'=='0' and 'PTS_DTS_flags'=='00', so no PES ext and no dts or pts. That's why I asked my question. Every once in awhile I'll see 'PTS_DTS_flags'=='10' but that's unusual. Mind you, this is in MPEG2-TSs. I don't how to parse anything else. There are potentially cases with some streams where the PTS and/or DTS is not specified for every frame, I'd say "usually", not "potentially". in which case libavformat will interpolate those values based on the frame duration and the prior packet. Of course. But why? They're not needed. Once the TS packets are put in correct sequence via SCR, the PS packets transported by those TS packets are in presentation order. The process to reorder the PS in order to decode B-frames and then put the decoded pictures back into the original order is straight forward. It's not "tricky" at all. It has become "tricky". That's what I'm trying to investigate, but I can't read 'C' code. I'm seeing some strange things. They can't be as strange as they look because they look disastrous. At issue is the cause of non-monotonous DTSs and obviously bogus DTSs for P-frames such as '-9223372036854775808'. 9223372036854775808 is a magic number. It corresponds to the #define for AV_NOPTS_VALUE. If you see that value it means that the packet did not have a PTS or DTS value assigned to it and thus you may have to take special measures. Oh, dear. I guessed that. Magic number. Fixup. There's a million fixups. I don't see why they're needed. That's why my preliminary finding is that FFmpeg is creating its own faults through fixups. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] DTSs & PTSs in MPEG2-TS streams
FFmpeg assigns DTSs & PTSs to P-frames and B-frames in MPEG2-TS streams. How does it determine those DTSs & PTSs? Since DTSs & PTSs don't actually exist for P-/B-frames in MPEG2-TS streams, FFmpeg must have a way that's unknown to me. I'm seeing some strange things. They can't be as strange as they look because they look disastrous. At issue is the cause of non-monotonous DTSs and obviously bogus DTSs for P-frames such as '-9223372036854775808'. I'm not trying to mysterious. I'm trying to tread carefully because I've been accused of being a troll. How anyone could think I'm a troll when I've been here for years and I've always used my real name, everywhere on the Internet, is beyond me. And, no, I'm not writing a book. And I'm markfilipak.imdb because that's a leftover gmail account that still works but is otherwise useless to me since imdb closed its forum several years ago. So, please, no flames. I have been investigating trimming and concatenation problems full time for many weeks and will present a report here when I'm done. My preliminary finding is that FFmpeg is creating its own problems due to internal fixups, but that's just preliminary and I really hope I'm wrong. I can't look at the source code because, though 'C' syntax is no problem for me, actual 'C' code is a black hole. Regards, Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 2 or maybe 3 trimming bugs
I made an inconsequential mistake: : (5590.835 sec)*(24/1.001 fps) = 134045.[994005..] frames, i.e., 481..134046 should be : (5590.835 sec)*(24/1.001 fps) = 134045.[994005..] frames, i.e., 0..134045 It does not change the '-to' argument. Please excuse my error. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] 2 or maybe 3 trimming bugs
Interested and knowledgeable folks, please confirm my results prior to trac submission. I'd like to know what happens in other use-cases. If you want this video, I could make a shortened version that would allow testing of the front trim, and we could figure out how to get it to you. Thanks --Mark. set SOURCE=h:\BDMV\STREAM\00305.m2ts set TARGET=c:\FANNY AND ALEXANDER [1982(1983)] 1of4.m2ts : This is the Windows cmd script that made the target. : Issues: : 1. : 59 bogus packets are made in the target preceding frame 481: 58 audio : and frame 480, plus one that follows frame 134046: frame 134048. Note: : Even if I made a mistake placing the trim, bogus packets shouldn't be : there. Note that video timebase == audio timebase. : Clue: The bogus end frame's DTS == the valid end frame's PTS. : 2. : Something actually changes this bogus audio packet: : 1, 2798640, 2798640, 960, 1084, 0xe54d2b6f : to this: : 1, 2798640, 2798640, 960, 60, 0xec16103f : Granted, it's silent audio, but how could a remux delete 1024 bytes? : Note: That's exactly 1 disc sector. : -Begin- : Determine '-ss' and '-to' : start -- MPV says to start at 0:20.062 sec -- MPV rounds. : (20.062 sec)*(24/1.001 fps) = 481.[006993..] frames, i.e., 0..480 : (frame 481)/(24/1.001 fps) = 20.061708[3..] sec : end -- MPV says to end at 1:33:10.835 (i.e., 5590.835 sec) -- MPV rounds. : (5590.835 sec)*(24/1.001 fps) = 134045.[994005..] frames, i.e., 481..134046 : (frame 134046)/(24/1.001 fps) = 5590.83525[0..] sec set TRIM=-framespan 481..134046 ...gee, this would be simple set TRIM=-ss 20.061708333 -to 5590.83525 : PTS = 2854113.75[0..]..504223732.5[0..] set CODE=-c copy -sn -dn ffmpeg %TRIM% -copyts -i %SOURCE% -map 0 %CODE% -muxdelay 0 "%TARGET%" pause exit Tip: Highlight the 6 fields and search on them to switch back-n-forth. The source. ffmpeg -i %SOURCE% -map 0 -copyts -c copy -f framecrc - starts- in this video, '0': video, '1': audio, '2': subtitles / DTSPTS dur bytes crc 0, 1044806, 1048560, 3753, 640646, 0x900a1a7a 0 0, 1048560, 1056067, 3753, 640646, 0xe5c6cd7c 2 1, 1048560, 1048560, 960, 1084, 0xe54d2b6f 1, 1049520, 1049520, 960, 1084, 0xe54d2b6f 1, 1050480, 1050480, 960, 1084, 0xe54d2b6f 1, 1051440, 1051440, 960, 1084, 0xe54d2b6f 0, 1052313, 1052313, 3753, 640646, 0xe7f0c204 1 463 more video & 1815 more audio packets here 3..465 0, 2794053, 2801561, 3753, 73475, 0x95247b28 467 1, 2794800, 2794800, 960, 1084, 0xe54d2b6f 1, 2795760, 2795760, 960, 1084, 0xe54d2b6f 1, 2796720, 2796720, 960, 1084, 0xe54d2b6f 1, 2797680, 2797680, 960, 1084, 0xe54d2b6f 0, 2797807, 2797807, 3753, 66185, 0xffbb475c 466 1, 2798640, 2798640, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2799600, 2799600, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2800560, 2800560, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2801520, 2801520, 960, 1084, 0xe54d2b6f <== makes bogus 0, 2801561, 2809068, 3753, 68631, 0x23461eb7 469 1, 2802480, 2802480, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2803440, 2803440, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2804400, 2804400, 960, 1084, 0xe54d2b6f <== makes bogus 0, 2805315, 2805315, 3753, 60778, 0x9e687e73 468 1, 2805360, 2805360, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2806320, 2806320, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2807280, 2807280, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2808240, 2808240, 960, 1084, 0xe54d2b6f <== makes bogus 0, 2809068, 2816576, 3753, 61104, 0x2eda8064 471 1, 2809200, 2809200, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2810160, 2810160, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2811120, 2811120, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2812080, 2812080, 960, 1084, 0xe54d2b6f <== makes bogus 0, 2812822, 2812822, 3753, 56227, 0xdea54c0e 470 1, 2813040, 2813040, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2814000, 2814000, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2814960, 2814960, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2815920, 2815920, 960, 1084, 0xe54d2b6f <== makes bogus 0, 2816576, 2824083, 3753, 51687, 0xcace633b 473 1, 2816880, 2816880, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2817840, 2817840, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2818800, 2818800, 960, 1084, 0xe54d2b6f <== makes bogus 1, 2819760, 2819760, 960, 1084, 0xe54d2b6f <== makes bogus 0, 2820330, 2820330, 3753, 50741, 0x3f745fcc 472 1, 2820720, 2820720, 960, 1084, 0xe54d2b6f <== makes bogus
Re: [FFmpeg-user] '-t' versus '-to'
PS: Actually, I think '-framespan' would be a better name for such a function. -framespan 481..134046 On 13/01/2024 22.57, Carl Zwanzig wrote: On 1/13/2024 7:37 PM, DEF wrote: ...other times you want to trim,.. ...(I prefer frame numbers, myself.) I wholeheartedly agree with you, Carl. For example: -ss 20.061708 -to 5570.815250 would be -frametrim 481..134046 meaning frame 481 thru frame 134046. Since it specifies the starting and ending frames, time is not an issue and duration is explicit. Trimming the audio, subtitles, and chapter list would be automatic and based on those frames. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] '-t' versus '-to'
On 13/01/2024 22.57, Carl Zwanzig wrote: On 1/13/2024 7:37 PM, DEF wrote: ...other times you want to trim,.. ...(I prefer frame numbers, myself.) I wholeheartedly agree with you, Carl. For example: -ss 20.061708 -to 5570.815250 would be -frametrim 481..134046 meaning frame 481 thru frame 134046. Since it specifies the starting and ending frames, time is not an issue and duration is explicit. Trimming the audio, subtitles, and chapter list would be automatic and based on those frames. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] cutting mp4 with ffmpeg
This is not the way to do things, Andrew. Please do not add your notice of a trac ticket submission to my reply. It has nothing to do with my reply. Your ticket has justifiably been closed. Trac is not a place to get extra help. It is for bug reporting. Instead to a trac ticket, post your concerns here and try to gain help/confirmation/clarification here. --Mark. On 13/01/2024 22.11, Andrew Randrianasulu wrote: On Sat, Jan 13, 2024 at 10:27 PM Mark Filipak wrote: On 13/01/2024 12.50, Andrew Randrianasulu wrote: On Sat, Jan 13, 2024 at 8:57 PM Def Etienne wrote: -snip- ffmpeg -i ~/6029.mp4 -copyts c:v copy -c:acopy -t 64.600 dev/shm/6029_cut.mp4 According to Devon Heitmueller -- thanks again, Devon -- '-copyts' and '-muxdelay 0' are _both_ needed. '-copyts' -- before the input -- bypasses a routine that apparently is named "tsfixup". '-muxdelay 0' -- after the input -- bypasses another ts fixup that defaults to adding 0.7 seconds to the timestamps. Exactly why ffmpeg does those fixups is a mystery. I can confirm that when cutting off the beginning: ffmpeg -copyts -ss ... -i ... -c copy -muxdelay 0 ... works. It preserves the timestamps (DTS, PTS). Regarding cutting off the ending: ffmpeg -to ... -i ... -c copy ... I am trying to determine the behavior of '-to'. Is it PTS? Or is it ticks (i.e., duration in timebase units)? And does ffmpeg do fixups for '-to' clauses, also? It appears there are such '-to' fixups. Also be aware that MPV rounds time, and rounds to milliseconds whereas ffmpeg truncates time and truncates frame numbers, DTSs, and PTSs. So times from MPV may miss an I-frame in ffmpeg. What I do is use MPV times to find approximate frame number. Then I use '-vf showinfo' to find exact frame number. Then I compute exact DTS and exact PTS from exact frame number. Then I convert DTS and PTS to nanoseconds in the '-ss' clause. I added ticket about ffprobe/vf_showinfo displaying truncated duration: https://trac.ffmpeg.org/ticket/10799#ticket Why does 'ffmpeg -ss' use times instead of relative timebase ticks (i.e. durations) or absolute DTSs and PTSs? Your guess is as good as mine, but it is a super PITA. Why does ffmpeg apply ts fixups? Your guess is as good as mine, but it is a super PITA. Also, be aware that in this listing: [Parsed_showinfo_0 @ 0xee202580] n:1612 pts:5803200 ... the reported PTS is _not_ PTS. It is ticks (i.e., duration in timebase units) that is marked "pts" but isn't -- another super PITA. Also, remuxing from M2TS to MP4 for example, applies more unknown fixups even when they have the exact same timebase -- another super PITA -- so don't change packet type until the very end of your timming and concatenating. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] cutting mp4 with ffmpeg
On 13/01/2024 22.58, Andrew Randrianasulu wrote: вс, 14 янв. 2024 г., 06:51 Mark Filipak : On 13/01/2024 22.11, Andrew Randrianasulu wrote: -snip- I added ticket about ffprobe/vf_showinfo displaying truncated duration: https://trac.ffmpeg.org/ticket/10799#ticket Andrew, please remove that ticket. It is too early. This is ONLY about duration field in ffprobe/vf_showtime truncating time to N.xx instead of N.xxx hopefully just two printf arguments somewhere. Actual cutting problems are not yet logged. I would like everyone to know that this is not my thread and I'm not responsible for Andrew's trac ticket. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] cutting mp4 with ffmpeg
On 13/01/2024 22.11, Andrew Randrianasulu wrote: -snip- I added ticket about ffprobe/vf_showinfo displaying truncated duration: https://trac.ffmpeg.org/ticket/10799#ticket Andrew, please remove that ticket. It is too early. Your "How to reproduce" command line is incomplete and it doesn't include '-muxdelay 0'. Your ticket cites other applications as though they are authoritative. The end result of your ticket will be to sour the milk for my work. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] '-t' versus '-to'
What's the difference? -t duration (input/output) When used as an input option (before -i), limit the duration of data read from the input file. When used as an output option (before an output url), stop writing the output after its duration reaches duration. duration must be a time duration specification, see (ffmpeg-utils)the Time duration section in the ffmpeg-utils(1) manual. -to and -t are mutually exclusive and -t has priority. -to position (input/output) Stop writing the output or reading the input at position. position must be a time duration specification, see (ffmpeg-utils)the Time duration section in the ffmpeg-utils(1) manual. -to and -t are mutually exclusive and -t has priority. 'duration' and 'position' seem to both be duration. What's the difference? --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] cutting mp4 with ffmpeg
On 13/01/2024 13.22, DEF wrote: As long as you are not encoding the video, ffmpeg will cut at the nearest iframes. That appears to be not true. ffmpeg appears to cut at the next frame, not the nearest frame. If you are particular then you need to re-encode the video. That is not true. avoid using "-to" in the place of "-t" like i explained. I missed that. Would you care to explain it again. I'd really like to know. if you must not reencode and you want to use copyts then you must add the option "-avoid_negative_ts make_zero" after your copyts. I don't think that's a good idea. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] cutting mp4 with ffmpeg
On 13/01/2024 12.50, Andrew Randrianasulu wrote: On Sat, Jan 13, 2024 at 8:57 PM Def Etienne wrote: -snip- ffmpeg -i ~/6029.mp4 -copyts c:v copy -c:acopy -t 64.600 dev/shm/6029_cut.mp4 According to Devon Heitmueller -- thanks again, Devon -- '-copyts' and '-muxdelay 0' are _both_ needed. '-copyts' -- before the input -- bypasses a routine that apparently is named "tsfixup". '-muxdelay 0' -- after the input -- bypasses another ts fixup that defaults to adding 0.7 seconds to the timestamps. Exactly why ffmpeg does those fixups is a mystery. I can confirm that when cutting off the beginning: ffmpeg -copyts -ss ... -i ... -c copy -muxdelay 0 ... works. It preserves the timestamps (DTS, PTS). Regarding cutting off the ending: ffmpeg -to ... -i ... -c copy ... I am trying to determine the behavior of '-to'. Is it PTS? Or is it ticks (i.e., duration in timebase units)? And does ffmpeg do fixups for '-to' clauses, also? It appears there are such '-to' fixups. Also be aware that MPV rounds time, and rounds to milliseconds whereas ffmpeg truncates time and truncates frame numbers, DTSs, and PTSs. So times from MPV may miss an I-frame in ffmpeg. What I do is use MPV times to find approximate frame number. Then I use '-vf showinfo' to find exact frame number. Then I compute exact DTS and exact PTS from exact frame number. Then I convert DTS and PTS to nanoseconds in the '-ss' clause. Why does 'ffmpeg -ss' use times instead of relative timebase ticks (i.e. durations) or absolute DTSs and PTSs? Your guess is as good as mine, but it is a super PITA. Why does ffmpeg apply ts fixups? Your guess is as good as mine, but it is a super PITA. Also, be aware that in this listing: [Parsed_showinfo_0 @ 0xee202580] n:1612 pts:5803200 ... the reported PTS is _not_ PTS. It is ticks (i.e., duration in timebase units) that is marked "pts" but isn't -- another super PITA. Also, remuxing from M2TS to MP4 for example, applies more unknown fixups even when they have the exact same timebase -- another super PITA -- so don't change packet type until the very end of your timming and concatenating. --Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On 1/10/24 16:50, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 4:26 PM Mark Filipak wrote: The change from 1048560 to 1174560 has to be happening inside the muxer, wouldn't you say? We now know that what's going into the muxer is right. Here is what went to the target file in the last run: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1,1 Try setting -muxdelay 0 on the output options. If not specified it defaults to 0.7, and the delta between 1174560 and 1048560 is exactly 1.4 seconds. I don't know why you're getting exactly 2x the mux delay rather than just being off by 0.7s, but I suspect it's the muxdelay that is causing you to get PTS values which are not what you would expect. Devin When I wrote "That did it", I 'spoke' too soon. I'm still being driven nuts. There are 4 questions at the end. -- Mark. set TRIM=-ss 20.061708333 -to 40.12341 set SOURCE=h:\BDMV\STREAM\00305.m2ts set CODE=-c copy -sn -dn set TARGET=c:\FANNY AND ALEXANDER [1982(1983)] 1of4.mp4 ffmpeg -report %TRIM% -copyts -i %SOURCE% -map 0 %CODE% -muxdelay 0 "%TARGET%" (The report is attached.) ___ THE INPUT M2TS (the cut is PTS=2854113) : 0,2839098,2839098, 3753,25719, 0x6f77b9b6 1,2839920,2839920, 960, 1084, 0xe54d2b6f 1,2840880,2840880, 960, 1084, 0xe54d2b6f 1,2841840,2841840, 960, 1084, 0xe54d2b6f 1,2842800,2842800, 960, 1084, 0xe54d2b6f 0,2842852,2842852, 3753,22455, 0xaa9655b8 1,2843760,2843760, 960, 1084, 0xe54d2b6f 1,2844720,2844720, 960, 1084, 0xe54d2b6f 1,2845680,2845680, 960, 1084, 0xe54d2b6f -cut- +-+ 0,2846606, ¦ 2854113 ¦3753, 640646, 0x3a5a0c45 1,2846640, +-+ 960, 1084, 0xe54d2b6f 1,2847600,2847600, 960, 1084, 0xe54d2b6f 1,2848560,2848560, 960, 1084, 0xe54d2b6f 1,2849520, +-+ 960, 1084, 0xe54d2b6f 0,2850360, ¦ 2850360 ¦3753, 640646, 0xfed1d09a <= TO BE CUT 1,2850480, +-+ 960, 1084, 0xe54d2b6f 1,2851440,2851440, 960, 1084, 0xe54d2b6f 1,2852400,2852400, 960, 1084, 0xe54d2b6f 1,2853360,2853360, 960, 1084, 0xe54d2b6f 0,2854113,2861621, 3753, 640646, 0x02208727 : ___ THE OUTPUT MP4 (the cut is PTS=2854080) 1,1492608,1492608, 512, 60, 0xec16103f : 50 audio packets, total 1,1517696,1517696, 512, 1084, 0xe54d2b6f -cut- +-+ 0,2846573, ¦ 2854080 ¦3753, 640654, 0xb9811068 1,1518208, +-+ 512, 1084, 0xe54d2b6f 1,1518720,1518720, 512, 1084, 0xe54d2b6f 1,1519232,1519232, 512, 1084, 0xe54d2b6f 1,1519744, +-+ 512, 1084, 0xe54d2b6f 0,2850327, ¦ 2850327 ¦3753, 640652, 0xbf9ad2d1 <= NOT CUT 1,1520256, +-+ 512, 1084, 0xe54d2b6f 1,1520768,1520768, 512, 1084, 0xe54d2b6f 1,1521280,1521280, 512, 1084, 0xe54d2b6f 1,1521792,1521792, 512, 1084, 0xe54d2b6f 0,2854080,2861588, 3753, 640652, 0x8f98895e : Q1: How can I force the mp4 muxer to use the existing PTSs? Q2: Why are there 50 audio packets ahead of the -cut-? Q3: How can I force the mp4 audio time_base to 1/9? Q4: Why wasn't INPUT PTS=2850360 cut off? ffmpeg started on 2024-01-11 at 20:24:51 Report written to "ffmpeg-20240111-202451.log" Log level: 48 Command line: "C:\\CMD & tiny apps\\ffmpeg\\ffmpeg.exe" -report -ss 20.061708333 -to 40.12341 -copyts -i "h:\\BDMV\\STREAM\\00305.m2ts" -map 0 -c copy -sn -dn -muxdelay 0 "c:\\FANNY AND ALEXANDER [1982(1983)] 1of4.mp4" ffmpeg version 2023-11-09-git-acf63d5350-full_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers built with gcc 12.2.0 (Rev10, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --pkg-config=pkgconf --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-n
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On 1/10/24 16:50, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 4:26 PM Mark Filipak wrote: The change from 1048560 to 1174560 has to be happening inside the muxer, wouldn't you say? We now know that what's going into the muxer is right. Here is what went to the target file in the last run: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1,1 Try setting -muxdelay 0 on the output options. If not specified it defaults to 0.7, and the delta between 1174560 and 1048560 is exactly 1.4 seconds. I don't know why you're getting exactly 2x the mux delay rather than just being off by 0.7s, but I suspect it's the muxdelay that is causing you to get PTS values which are not what you would expect. Devon, you're a lifesaver. That did it. Look: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1,1 So, to summarize, I needed '-copyts' before '-i' and '-muxdelay 0' after '-i'. Is there any reason I should _not_ make those permanent and do them every time? Thanks so much for your help. I could _never_ have done that on my own. Now that there's fewer moving parts, I can maybe make more progress in my main task: Towards better trims & concatenations. But first, I have about 30 work files to delete. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On 1/10/24 15:46, Mark Filipak wrote: On 1/10/24 13:55, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 1:42 PM Mark Filipak wrote: Thanks, Devin, but nope, they're a lot closer but they're still not the same. set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0, 1044806, 1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0, 1170806, 1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 -c copy -sn -dn c:\target_1.m2ts : RESULT: 0, 1170806, 1174560, 3753, 640646, 0x900a1a7a, S=1, 1 While I'm not sure why you're not getting the expected output, you can add "-debug_ts" to your ffmpeg command line as a global option and it will show the timestamps for the packets at every stage (i.e. demux/rebasing/decoding/encoding/muxing). That should allow you to track down where in the pipeline the timestamp is changing. I have some beautified debug to paste in here, but first I need to say that here is where the packet CRCs are really needed. Too bad they're not listed by '-debug_ts'. Here is the first video packet: type pkt_pts pkt_dts duration [vist#0:0/h264...] demuxer video 1048560 1044806 3753 [vist#0:0/h264...] demuxer+tsfixup video 1048560 1044806 3753 demuxer+ffmpeg video 1048560 1044806 3753 off:0 [aost#0:1/copy...] muxer <- audio pkt_pts:1048560 pkt_dts:1048560 duration:960 size:1084 As shown in my previous post, PTS=1048560 is being changed to PTS=1174560 Confirmed: 1048560 is the lowest PTS. Confirmed: 1174560 doesn't appear anywhere. So, the change from 1048560 to 1174560 remains mysterious. The change from 1048560 to 1174560 has to be happening inside the muxer, wouldn't you say? We now know that what's going into the muxer is right. Here is what went to the target file in the last run: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1,1 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On 1/10/24 13:55, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 1:42 PM Mark Filipak wrote: Thanks, Devin, but nope, they're a lot closer but they're still not the same. set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 -c copy -sn -dn c:\target_1.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 While I'm not sure why you're not getting the expected output, you can add "-debug_ts" to your ffmpeg command line as a global option and it will show the timestamps for the packets at every stage (i.e. demux/rebasing/decoding/encoding/muxing). That should allow you to track down where in the pipeline the timestamp is changing. I have some beautified debug to paste in here, but first I need to say that here is where the packet CRCs are really needed. Too bad they're not listed by '-debug_ts'. Here is the first video packet:type pkt_pts pkt_dts duration [vist#0:0/h264...] demuxer video 1048560 1044806 3753 [vist#0:0/h264...] demuxer+tsfixup video 1048560 1044806 3753 demuxer+ffmpeg video 1048560 1044806 3753 off:0 [aost#0:1/copy...] muxer <- audio pkt_pts:1048560 pkt_dts:1048560 duration:960 size:1084 As shown in my previous post, PTS=1048560 is being changed to PTS=1174560 Confirmed: 1048560 is the lowest PTS. Confirmed: 1174560 doesn't appear anywhere. So, the change from 1048560 to 1174560 remains mysterious. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
Correction... On 1/10/24 13:21, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 12:50 PM Mark Filipak wrote: Question: How can I force the target's DTS to be the source's DTS? Add "-copyts" to the front of the command-line as a global option. The ffmpeg application will automatically rebase timestamps to zero after demuxing unless you specify this option (which is further up the pipeline than your bsf, hence the bsf has no effect). Devin Thanks, Devin, but nope, they're a lot closer but they're still not the same. set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 -c copy -sn -dn c:\target_1.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 Sorry I flubbed the command lines. These are correct. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On 1/10/24 13:21, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 12:50 PM Mark Filipak wrote: Question: How can I force the target's DTS to be the source's DTS? Add "-copyts" to the front of the command-line as a global option. The ffmpeg application will automatically rebase timestamps to zero after demuxing unless you specify this option (which is further up the pipeline than your bsf, hence the bsf has no effect). Devin Thanks, Devin, but nope, they're a lot closer but they're still not the same. set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -i %SOURCE% -map 0 -copyts %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -i %SOURCE% -map 0 -copyts-c copy -sn -dn c:\target_1.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Force target DTS == source DTS -- How?
Question: How can I force the target's DTS to be the source's DTS? I'm simply demuxing and remuxing. To make the targets: set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -i %SOURCE% -map 0 -c copy -sn -dn c:\target_1.m2ts : RESULT: 0, 126000, 129754, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0, 126000, 129754, 3753, 640646, 0x900a1a7a, S=1, 1 Thanks, Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Towards better trims & concatenations
On 1/9/24 07:04, Rob Hallam wrote: On Mon, 8 Jan 2024 at 23:02, Mark Filipak wrote: [explanation snipped] Oh, I think I see why your difficulty, Rob. Thank you for taking the time to write the explanations, they are much appreciated. My difficulty, as you guessed, is I don't know about the internals of video containers. I know DVD VOBs but none of the others. I thought it might work like being handed pages from a book- annoying if they're in the wrong order, but fixable to get the right order since there are page numbers. From what you say, it sounds like in this analogy not only are the pages (packets) in the wrong order, the page numbers (timestamps) are wrong- and not even consistently wrong? That is an excellent analogy. "Yes" to all you wrote. FFmpeg is not just scrambling the 'page numbers' (DTSs & PTSs), it's changing the 'page numbers' so that the page marked "23" is not page 23. In the hardbound version of the book (m2ts), page 23 has been marked "54" and in the softbound version of the book (mp4), page 23 has been marked "3845". I'm not saying that that's what must be happening to explain what I see, I'm saying that's what _is_ happening. Now I have to be careful and logical at this point because I'm using ffmpeg to look at what ffmpeg is doing. There's a danger there. If ffmpeg is in error, as it certainly appears to be, then either the packet table is built wrongly or the packet table is correct but it's being accessed wrongly. I have no idea which alternative, build or access, is wrong. I could dump the packets and look at the binary values and parse the headers to see the actual 'page numbers', but I know how to do that solely for DVD VOB files. Or, I could somehow dump ffmpeg's packet table and see whether it's correct. I assume that '-framecrc' is doing that. Based on '-framecrc', it appears the packet table is being built wrongly. I could reliably use ffmpeg to examine ffmpeg if I could get ffmpeg to stop making changes and to instead make just the changes I want. For example, when I do a trim-cut, ffmpeg automatically changes all the 'page numbers'. If you took a physical book and ripped out pages 1..50, the top page would say "51". That doesn't happen in ffmpeg. The top page is now different, but it's different in inconsistent ways. The top page might say "0", or it might say "73688" or it might say "-4967". There doesn't seem to be any consistency about what the top page's 'page number' is. If I rip out pages 1..50, I want '-framecrc' to show "51" as the top 'page'. It appears there's no way to do that. It appears there's no way to prevent ffmpeg making wholesale changes to the packets. Now, there is the packet CRCs. Looking at them is the reason '-framecrc' exists. Tracking those packet CRCs before the cut and after the cut tells me that, yes indeed, ffmpeg is changing the page numbers to wrong numbers. For example, when joining two trims, each over an hour long, I get 6 seconds of the join in which the MPV player stops-starts-stops-starts-stops-starts-stops-starts-stop-starts -- 5 stutters. During that time, the 1st non-black frame of the second section flashes 3 times. When I look at those packets, '-framecrc' shows me why that's happening. The 'page numbers' don't match up. Now I cut on I-frames, so joining two clips should simply abut #2's beginning I-frame to #1's ending I-frame. That's not what's happening. What's happening is that parts of #1 are spewed into #2 and parts of #2 are spewed into #1. The videos are 'mixed' in some strange way. It's hard to figure out because the 'page numbers' are unreliable, and they come out of order. Imagine you rip out pages 1..50. You find that page 51 now says "398". In addition, what was page 49 has magically become "399" and is in the wrong section. Trimming errors are wrecking concatenations ... [snip] trimming has to take PTS into account so that the cut happens in the right spot with no leftover packets that shouldn't be there, but that apparently isn't happening and I have the proof. That certainly sounds consistent with behaviour I saw in the past when I tried to re-join trimmed clips. To be frank, Rob, if you want to help yourself, you may want to help me. I published my procedure. Duplicate it and apply it to some of the videos you've had problems with. Learn how to use '-framecrc' and '-showinfo'. It will take you awhile, but it will be time well spent. It will demystify a lot for you. I'll be here to help if you like. Thank you. The videos I've worked with in the past were simple h264-in-mkv/mp4, but at the time having to do a full re-encode was irksome. If I get a chance to replicate your procedure I'll post the results. When I saw what was happening I stopped and tried to partition the problem into cut-problems and join-problems. In that p
Re: [FFmpeg-user] sntsc
On 1/8/24 01:46, Andrew Randrianasulu wrote: пн, 8 янв. 2024 г., 09:13 Mark Filipak : On 1/8/24 00:26, Andrew Randrianasulu wrote: пн, 8 янв. 2024 г., 05:14 Mark Filipak : What is it that you want to know? I think I like to try and see bigger picture behind acronyms. What acronyms? SAR, DAR, PAR . DAR is a physical aspect (i.e., a W/H). It is the dots-by-lines aspect of the view. Note that I don't use the word "display" because that makes many people think of a whole screen. I use the word "view", instead, as in "lines per view", not "lines per display". PAR is a physical aspect (i.e., a W/H). It is the pixels-by-rows aspect of the 'picture' matrix. Note that I use the word 'picture', an alias, because data matrices are not really pictures. But MPEG and the rest of the world call them "pictures" so I call them 'pictures'. SAR is not a physical aspect, it's an aspect transform. It transforms pixels-by-rows to dots-by-lines. SAR = DAR/PAR means view(W/H)/'picture'(W/H). For example, (1024/576)/(720/576). Details. "DAR" means "display aspect ratio" and you probably know all about that. It's dpl/lpv, i.e., (dots per line)/(lines per view). DAR dpl/lpv 1024/576 = 16/9 for 16:9 'PAL', 768/576 = 4/3 for 4:3 'PAL', 853/480 = 16/9 for 16:9 'NTSC', 720/540 = 4/3 for 4:3 'NTSC'. "PAR' means "picture aspect ratio". It's ppr/rpp, i.e., (pixels per row)/(rows per 'picture'). PAR ppr/rpp 720/576 = 5/4 for 16:9 'PAL', 720/576 = 5/4 for 4:3 'PAL', 720/480 = 3/2 for 16:9 'NTSC', 720/480 = 3/2 for 4:3 'NTSC'. "SAR" means "sample aspect ratio". That term is from the days of flying spot film scanners. Modern SAR is actually not an aspect at all. It's a transform. SAR transforms pixels-by-rows into dots-by-lines [note1]. It's dpp/lpr, i.e., (dots per pixel)/(lines per row). 'SAR' dpp/lpr (dpl/ppr)/(lpv/rpp) [note2] (1024/720)/(576/576) = 1024/720 = 64/45 for 16:9 'PAL' -- 64 dots per 45 pixels, (768/720)/(576/576) = 768/720 = 16/15 for 4:3 'PAL' -- 16 dots per 15 pixels, (853/720)/(480/480) = 853/720 = 32/27 for 16:9 'NTSC' -- 32 dots per 27 pixels, (720/720)/(540/480) = 1/(540/480) = 1/(9/8) for 4:3 'NTSC' -- 9 lines per 8 rows [note3]. [note1] Though modern SAR is actually a transform -- a 'picture'-to-view transform (PVT) -- the "SAR" acronym has become so entrenched in the art that it would be impossible to get people to change to "PVT". I try to get around the issue by calling SAR-as-transform, 'SAR' (meaning it's an alias, not a real aspect ratio). [note2] The following is not a 'stupid math trick', it is real. 'SAR' = dpp/lpr = (dpl/ppr)/(lpv/rpp) = (dpl/lpv)/(ppr/rpp) = DAR/PAR. For example, 'SAR' = dpp/lpr = (1024/720)/(576/576) = (1024/576)/(720/576) = (16/9)/(5/4) = DAR/PAR. [note3] Why is 4:3 'NTSC' so different? Well, there's two ways to look at it: 1, for 4:3 'NTSC', 'SAR' is less than one while for the others, 'SAR' is greater than one, and 2, turning 4:3 'NTSC' into 640x480 would lose resolution whereas 720x540 preserves resolution. The difference is moot because TVs don't use 'SAR' anyway. What they do is look at the size of their screen (e.g., 1920x1080), look at DAR in the PES header (e.g. 4/3), compute the size of the view based on that DAR (e.g. 1440x1080), and scale directly (e.g., turn 4-by-4 pixel blocks into 8-by-9 dot blocks). That makes 'SAR' a kind of fiction (which it is in a way). If you're unhappy with 'SAR', then just forget it. Know DAR and PAR though. Know them well. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Towards better trims & concatenations
On 1/8/24 08:08, Rob Hallam wrote: On Mon, 8 Jan 2024 at 12:37, Mark Filipak wrote: On 1/8/24 07:16, Rob Hallam wrote: On Mon, 8 Jan 2024 at 12:07, Mark Filipak wrote: For example, if 'v' (video) and 'a' (audio) packets go from v-a-a-a-a-v-a-a-a-a-v... to a-a-a-a-a-a-a-a-v-v-v..., then somethings wrong, eh? That's the kind of difference I'm seeing between the two versions of 01.mp4. Forgive me for jumping in in the middle here, but is that strictly true? Is what true? Is it true that the audio packets are bunched up, out of time sequence, and pushed to the front? Yes, it's true. That's why the MPV player has difficulty and doesn't start at 00:00:00.000. Part of that problem is that, for some unknown reason, ffmpeg creates one time_base for frame packets and a different time_base for audio packets. It seems to me that that's just looking for trouble. Honest question, perhaps the spec says that they should be identical. There is no spec that defines how to trim and concatenate. Sorry, I don't understand you. Are you asking if I'm lying? I doubt it, but I don't know the antecedent of "that". Also, when you wrote "the spec", what spec did you have in mind? For clarity, I wasn't accusing you of lying... For clarity, I didn't think you were, and said so. ... and it certainly wasn't my intention to imply that; my apologies if it sounded that way! The 'that' in the above-quoted case was your example of packets- clearly they are ordered differently, something has changed and perhaps it shouldn't have changed. There is no 'perhaps' about it. I wondered if there was a practical difference; to go back to the multiplication example, if you get 120 either way, does it matter if you do 3*4*10 versus 10*3*4 ? Sometimes it does matter -- like in cases of floating-point maths -- but I am wondering if ffmpeg here is producing something that appears different but looks and sounds the same. I address this further down. I didn't have a particular spec in mind, but candidates would be ffmpeg specs... FFmpeg has specs? I'd surely like to see them. ...and/or specs for the container and codec formats in use- ie does this behaviour contradict those. I parse VOBs. I don't know the structures of M2TSs or MP4s or MKVs or anything else. But they all work off packet headers (e.g., PESs (packetized elemental streams)) that contain the structure and the settings that made the packet's payload what it is. There's no usage spec. Packet headers contain DTS, PTS, DAR, width, height, etc. Packet headers don't 'specify' how applications should create and maintain a valid packet table, nor do they specify packet table access methods. The specs just show structure. The H.262 spec goes a little further when it attempts to describe a virtual decoder machine for MPEG TS streams. That machine is a simple outline of how DTS & PTS work to render time ordered presentations from time disordered packets that are received. Illustrating such a small aspect of such a large procedure is like illustrating how the sun works by lighting a match. It's an important part, and the decoder model is good as far as it goes, but the rest is left up to the application and the specification is silent about that. In much the same way a*b*c is equivalent to b*a*c, does the order of packets necessarily matter if the output is perceptually the same? Yes, time order matters. If two videos are perceptually the same, then they're the same; they have the same internals. You can't move frames or audio samples around and it not be perceived. Things can get so bad that players drop packets. Is that perceivable? Yes, at some level of probing, it is. The frames and samples and chapters and subtitles are Legos. If you take the peak of a Lego building off and stick it onto the side of the building, is that perceivable? This is not brain surgery. It's Legos. Oh, I think I see why your difficulty, Rob. "a*b*c" happens at one instant. It doesn't matter in what order the multiplication happens because it's all in a single instant. With video frames, order matters. Frames are separated in time -- out of order is visible. The packets are in PTS order. Does the order of the packets matter? No, it's the order of the PTSs that matters. If the output is not perceptually the same, or there are timing issues / desync / other problems as a result then I can see that being a potentially important bug. The MPV player misbehaves for all 6 of the sons. The starting running time is not "00:00:00.000". Does it matter that the starting running time is not "00:00:00.000" ? Yes. I presume it does, otherwise you might not be raising this issue; but in my ignorance I can see the possibility that the reported starting running time is a 'cosmetic' issue rather than a functional one. Trimming errors are wrecking concatenations. If DTSs & PTSs aren't smooth and contin
Re: [FFmpeg-user] Towards better trims & concatenations
On 1/8/24 08:23, Bouke / Videotoolshed wrote: For clarity, I wasn't accusing you of lying and it certainly wasn't my intention to imply that; my apologies if it sounded that way! Don’t feed the trolls Bouke, are you calling me a troll? -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Towards better trims & concatenations
On 1/8/24 07:16, Rob Hallam wrote: On Mon, 8 Jan 2024 at 12:07, Mark Filipak wrote: For example, if 'v' (video) and 'a' (audio) packets go from v-a-a-a-a-v-a-a-a-a-v... to a-a-a-a-a-a-a-a-v-v-v..., then somethings wrong, eh? That's the kind of difference I'm seeing between the two versions of 01.mp4. Forgive me for jumping in in the middle here, but is that strictly true? Honest question, perhaps the spec says that they should be identical. Sorry, I don't understand you. Are you asking if I'm lying? I doubt it, but I don't know the antecedent of "that". Also, when you wrote "the spec", what spec did you have in mind? In much the same way a*b*c is equivalent to b*a*c, does the order of packets necessarily matter if the output is perceptually the same? The packets are in PTS order. Does the order of the packets matter? No, it's the order of the PTSs that matters. If the output is not perceptually the same, or there are timing issues / desync / other problems as a result then I can see that being a potentially important bug. The MPV player misbehaves for all 6 of the sons. The starting running time is not "00:00:00.000". Cheers, Rob PS I've been following along as I am also interested in cutting and re-joining- my first query to this ML was about whether there's a way to chop off the starts and ends of some clips, add transitions and re-encode those short overlapping bits, and then join them back on to their parent clips to avoid having to re-encode the whole lot You should be able to do all that without recoding except for the transitions, as you wrote. I and others have had lots of problems with concats. There are 3 concat methods. They all have problems with cuts. I think the real problem is deep inside ffmpeg affecting how the packet table is built and/or accessed. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Towards better trims & concatenations
On 1/8/24 00:34, Andrew Randrianasulu wrote: пн, 8 янв. 2024 г., 07:02 Mark Filipak : I think some of Mark's problems might steam from fact he apparently cuts blu-ray transport stream, not something commonly cut with ffmpeg. Yes, but not quite true. I'm cutting, '-ss 20.062', but remuxing to mp4, not m2ts. So I'm not really cutting the MPEG-TS stream. Unfortunately, the mp4s that ffmpeg makes are too different from the m2ts. They have new DTSs & PTSs, and whatever the problem is that ignores '-bsf:a setts=time_base=1/9' is not ignored in the mp4s. 00395.m2ts --cut--> 01.mp4 00305.m2ts --> 00.mp4 --cut--> 01.mp4 The two versions of 01.mp4 are very different. FFmpeg is making too many changes. Its changes are unnecessary and, in this case, detrimental. In this case, I'm trying to test how badly ffmpeg is making the cut, and all the changes are making that practically impossible. For example, if 'v' (video) and 'a' (audio) packets go from v-a-a-a-a-v-a-a-a-a-v... to a-a-a-a-a-a-a-a-v-v-v..., then somethings wrong, eh? That's the kind of difference I'm seeing between the two versions of 01.mp4. I have to stick with m2ts but I have to cut it down to just 34.076 seconds. I need to do that without altering the internals of the packets there is tsMuxer, it seems to have is own logic for dealing with mpeg transport streams. https://github.com/justdan96/tsMuxer There is also another libav* based cutter VidCut https://github.com/kanehekili/VideoCut Thank you, Andrew. I'll take a look at them. May be stream is ... slightly broken in some way? Even costly pro software at some version can produce slightly ... confusing stream. The m2ts is definitely strange in some way -- ffmpeg complains about the audio streams for example -- and it's doubly strange because the video is a Criterion movie. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] sntsc
On 1/8/24 01:46, Andrew Randrianasulu wrote: Well, here lies the problem for us! Ffmpeg (command line utility) encodes those files straight away, so for example VLC displays them correctly. But our software (cinelerra-gg) so far was not setting st->sample_aspect_ratio so say webm encodes were by default with wrong Display aspect ratio in both VLC and GNOME filemanager previews. You can set DAR in ffmpeg to whatever you want. I hope now (after my patches under testing) we set sample aspect ratio in both places (codecpar and st) so hopefully libav* based players will display them correctly out of the box. Well, I don't know your tools, but MPEG-TSs actually has no SAR setting. It has no PAR setting, either, but you can set PAR by setting horizontal_size_value & vertical_size_value. I don't know how to set them without ffmpeg reacting by actually scaling the samples. That's not what you will want. You want to correct the aspect without scaling. I don't know how to do that. Perhaps someone else can advise you. I'd sure like to know how to change MPEG tags. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] sntsc
On 1/8/24 00:26, Andrew Randrianasulu wrote: пн, 8 янв. 2024 г., 05:14 Mark Filipak : What is it that you want to know? I think I like to try and see bigger picture behind acronyms. What acronyms? At least this page explains how some 640*480 files might be born (it should be 486, but some lines are cut). Nonsense. If you're referring to DVD, there's no such thing as 640x480. There's 720x480. It decodes to 720x540. https://lurkertech.com/lg/video-systems/#480i Total Lines Per Frame 525. Nobody has those TVs anymore. This is all interesting and not really theoretical to me because at least one our user still have a lot of HDV and DV material and he hopes to get correct encoding results in those cases too! Sorry, I can't help there. I don't know what HDV & DV are. Is your friend trying to make a standards compliant DVD or BD? No? Then the correct encoding results are whatever can do the capture or the remux or the transcoding. I assume HDV & DV are analog, otherwise, why are you fussing about 704 & 525? If HDV & DV are digital, then 704 & 252 don't apply. All that analog capture stuff is moot. Get everything you can and then use ffmpeg to crop to whatever the image is. As long as the capture hardware is running at 60/1.001 fields per second, the field-to-field images should be stable and you'll be fine. If the videos are hand held camcorder, then the images will not be stable, but there are stabilizers you can use. Just get the images, then worry about presentation. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Towards better trims & concatenations
On 1/7/24 22:12, Jim DeLaHunt wrote: For instance, this command: > ffmpeg -f lavfi -i "testsrc" -to 1:00 testpat.m2ts generates a 60-second video with a test pattern. Anyone with recent FFmpeg can generate a video like this, though perhaps not identical. If you use this as your "mother" video, and apply your test method to it, does ffmpeg demonstrate the same bugs? If yes, then you can include instructions to generate that video in your bug reports. I don't think a synthetic video that ffmpeg creates is going do the job. I'll pass. Anyone could do it, and the developers would have done it. You could do it. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Towards better trims & concatenations
On 1/7/24 20:24, Jim DeLaHunt wrote: On 2024-01-06 19:24, Mark Filipak wrote: On 1/6/24 17:20, Jim DeLaHunt wrote: But what I am missing here is a concise problem statement. I'll work hard to implement all your suggestions. They are good and I appreciate the help. I've not done this sort of thing before. Also, what does "h:\BDMV\STREAM\00305.m2ts" refer to? That's the mother video from which the clone and sons are made. Is that a standard video which I can get a copy of somewhere? Nope. That presents an obstacle... The 'mother' is an M2TS. I'll try trimming it '-to 34.076' while leaving the beginning intact. The problem is that ffmpeg changes the DTSs and PTSs of the copy. For example, 00.mp4 is the 'mother's clone'. If I make 01.mp4..06.mp4 from 00.mp4 instead of from 00305.m2ts, the result is different -- things work out 'better', not just trimming, but other things, too, like audio time_base gets acted on. How can I trim 00305.m2ts '-to 34.076' without altering the TSs and other things? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] sntsc
On 1/7/24 17:34, Andrew Randrianasulu wrote: Well, we (cinelerra-gg users/hackers/maintainers) run into aspect ratio issues too , and I tried to demistify it for myself ... only to run into much more complex explanation at https://lurkertech.com/lg/pixelaspect/ I'm sorry, I couldn't get past the first sentence: "Pixels in the graphics world are square." They probably meant "dots" (aka "pels"). But I've read enough squirrely things in my time to know squirrely when I read it. My experience is that things that start squirrely get squirrelier. Some video folks who are stuck in analog TV write about 704x480 and 704x576 and 10:11 SAR and 59:54 SAR, and they talk about overscan. It's all nonsense. DVDs are not TV and never was. So, folks with analog TVs didn't see 720x480 because some of it got into the horizontal blanking. So what? There were no such SARs as 10:11 & 59:54. "59:54" isn't right even if 704 existed. Some of those people who write those squirrely things, and more, write them into standards. It's all still nonsense. What is it that you want to know? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Towards better trims & concatenations
On 1/6/24 17:20, Jim DeLaHunt wrote: Mark: Hi Jim, On 2024-01-06 11:52, Mark Filipak wrote: Below is what I plan to submit to trac. I welcome comments and corrections. … Good for you, digging into the details and specifics of how FFMpeg performs trims and concatenations. But what I am missing here is a concise problem statement. There are many errors. You say you plan to "submit to trac". Is this a bug report? Yes. It's hard to figure out how many bugs and whether all of my experiences really _are_ bugs or are just misunderstanding of what the ffmpeg directives are supposed to do. I'm quite experienced in these tasks, so the former is more probable. Certainly getting PTSs wrong from mother's clone to mother's son is a bug. Certainly getting trim time wrong from mother's clone to mother's son is a bug. Are those bugs specific to this use-case. Based on my experience and the reported experiences of others I'd say the bugs are endemic. I think there are other functions in ffmpeg that have 'learned' how to work around the bugs, and there are others that have not 'learned', so those use-cases fail. I'm guessing of course. If it is a bug report, what is the bug title? It should be a concise (1-10 words) statement of what is incorrect. That's good advice but there are multiple bugs. They may be interacting. I can't separate them into individual trac reports. What is the bug summary? It should a concise (1 paragraph) summary of the problem. The example commands you give seem to be a pretty specific set of instructions for "how to reproduce". It's a Windows command script that makes the clone and sons. The 'mother' can be any video. I reckon that different 'mothers' will expose differing symptoms. More than that, it's a systematic method to investigate the trimming procedure to determine whether it works properly. That method mostly uses '-framecrc'. Some use '-showinfo' and others show what happens in MPV during play. What is the "observed behaviour"? Is it something to do with the total number of packets in the "son" videos? Yes, for some sons. For other sons it's PTS errors that put packets and the images out of order. Or the frame number of the first non-black frame? Yes, for those sons that have a bogus total number of packets. If there is a single thing that produces all the bogus results, it's probably deep within ffmpeg, where the mapping happens. There must be a table built that relates the packets by packet index, by audio v video v chapter v subtitle, by DTS, by PTS, by frame number if video, etc. That table may be being built wrongly or the methods that access that table may be where the bugs are. From the outside, I can't tell. I just know what goes wrong. What is the "expected behaviour"? I see where you're going. The expected behavior is that all cuts are on N=481, that there are no extra audio packets in front of it, that the resulting PTSs have the same order as the original PTSs, and so on. I'll rewrite with that in mind. Also, what does "h:\BDMV\STREAM\00305.m2ts" refer to? That's the mother video from which the clone and sons are made. Is that a standard video which I can get a copy of somewhere? Nope. I don't see that you explain that. Without having the same source material as you, it is hard to reproduce the same results. The clone is a copy of the 'mother'. It is available. Do you want it? (Note that all the sons can be made from the clone instead of from the mother, though that's not the correct way to proceed.) It may be that this test methodology reveals multiple bugs, which might be better pursued if reported separately. How? How can they be separated? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Towards better trims & concatenations
On 1/6/24 17:20, Jim DeLaHunt wrote: Mark: I'm going to respond twice. Every son is wrong. Let me make that clear: Every son is wrong in some respect. Every son played by MPV shows that MPV is trying to deal with something unexpected. None of the MPV "FPS" report screens (i.e., [shift][I]) go 100% smoothly. None of the MPV "FPS" report screens start at '0:00:00.000' for example. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Towards better trims & concatenations
Below is what I plan to submit to trac. I welcome comments and corrections. What I wrote pretty much goes to the heart of FFmpeg, so I expect push-back. The more people who confirm what I have written, the better. The files are over 500 MB. If you want them, ask. But I recommend you modify the script below to process your own 'mother'. My 'mother' was h:\BDMV\STREAM\00305.m2ts. Towards better trims & concatenations. -- Mark. set MOTHER=h:\BDMV\STREAM\00305.m2ts set SS=-ss 20.062 set TO=-to 34.076 set FILT1=setts=time_base=1/9 set FILT2=setts=dts=DTS-STARTDTS:pts=PTS-STARTDTS set FILT3=setts=time_base=1/9:dts=DTS-STARTDTS:pts=PTS-STARTDTS set VCOPY=-c:v copy set VCODE=-vf separatefields,setdar=16/9 -c:v libx265 -x265-params crf=18 set ACOPY=-c:a copy -sn -dn : : The Windows settings above will make sense further down. : : When this command file is run, the mother: 00305.m2ts, is used to : create the mother's clone: 00.mp4, plus 12 sons: 01.mp4..12.mp4. : The clone and sons are created at c:\. : : THE FILES HOW MADETHE SIZES : 00305.m2ts (mother) 679600 packets 15091 MB :00.mp4 (clone) copy (reference) 4136 packets 136 MB :01.mp4 (son)'-ss -i' & FILT1 1711 packets56 MB :02.mp4 (son)'-ss -i' & FILT2 1711 packets56 MB :03.mp4 (son)'-ss -i' & FILT3 1711 packets56 MB :04.mp4 (son)'-i -ss' & FILT1 1629 packets52 MB :05.mp4 (son)'-i -ss' & FILT2 1629 packets52 MB :06.mp4 (son)'-i -ss' & FILT3 1629 packets52 MB : : The clone, 00.mp4, is made to enable packet tracing via packet CRCs. : : CORRELATING THE FIRST, NON-BLACK FRAMES: : MOTHER'S FRAME CLONE'S FRAME NOW KNOWN TO BE TRUE : 00305.m2ts, N=36 == 00.mp4, N=36 by looking & counting frames. : : CORRELATING THE FIRST, NON-BLACK FRAMES: : CLONE'S FRAMESON'S FRAMENOW KNOWN TO BE TRUE : 00.mp4, N=508 == 01.mp4, N=27 by looking & counting frames. : 00.mp4, N=508 == 02.mp4, N=27 by looking & counting frames. : 00.mp4, N=508 == 03.mp4, N=27 by looking & counting frames. : 00.mp4, N=508 == 04.mp4, N=2by looking & counting frames. : 00.mp4, N=508 == 05.mp4, N=2by looking & counting frames. : 00.mp4, N=508 == 06.mp4, N=2by looking & counting frames. : : COMPUTING START FRAMES: : CLONE'S FRAMESON'S FRAMERATIONALE : 00.mp4, N=481 == 01.mp4, N=0481 = 508 - 27. : 00.mp4, N=481 == 02.mp4, N=0481 = 508 - 27. : 00.mp4, N=481 == 03.mp4, N=0481 = 508 - 27. : 00.mp4, N=504 == 04.mp4, N=0504 = 508 - 2. : 00.mp4, N=504 == 05.mp4, N=0504 = 508 - 2. : 00.mp4, N=504 == 06.mp4, N=0504 = 508 - 2. : : The ffmpeg commands that made the clone and sons are in sections : that follow. : : OTHER FACTS: : There are9 ticks/sec FROM time_base. : There are 1.001/24 secs/frame == 0.041708[3..] secs/frame. : There are 90090/24 ticks/frame == 3753.75 ticks/frame. : : EVERYTHING ELSE IS DERIVED VIA FFMPEG TOOLS. : That's tricky because at this point, FFmpeg tools are untrusted. : : TRIMMING ACCURACY. : Timming accuracy is crucial for follow-on concatenations. : Using MPV, a 0:20.062 trim time is found. The starting PTS is : therefore approximately 1805580 ticks. But what is it, exactly? : That depends on how MPV handles numbers. : If MPV truncates, the actual trim time and PTS are in the range : 20.062[0..]..20.062[9..]1805580.[0..]..1805669.[9..]. : If MPV rounds, the actual trim time and PTS are in the range :20.0615[0..]..20.0624[9..] 1805535.[0..]..1805624.[9..]. : The only clone PTS in a range above is 1805553 -- so MPV rounds. : The trim point is therefore 1805553 ticks, exactly. : : SUGGESTIONS: : To the best of my knowledge, there's a small private data area in : every packet. Use it to record the source's packet number into the : target's packet. That would make packet tracing a lot surer. : Change '-showinfo' to report real PTSs, not ticks from a starting : PTS that often doesn't actually exist. Bogus 'PTS's are confusing. : Add frame numbers to '-framecrc'. : Change CRCs to cover only payloads, not whole packets. : Find a way to differentiate silent audio packets, one from another. : (Note that the first suggestion would accomplish it.) : Change the default audio packet time_base to be the video packet : time_base. Better yet, always use the same time_base. That's usual. : If the trim frame is preceded by audio, then automatically include : the preceding audio packet; the preceding one, only, not more. : BEGIN ffmpeg -to 35.118 -i %MOTHER% -map 0 -c copy -sn -dn 00.mp4 : Creating the mother's clone. The '-framecrc' below is the clone. : : PACKETS 0..2352 = : -3754, 0, 3753, 640654, 0x07c81f9c N=0 :
[FFmpeg-user] '-showinfo'-'-framecrc' mind meld
PS: Another way that will crack this nut is to simply add packet CRCs to '-showinfo'. Switching back and forth between '-framecrc' and an enhanced '-showinfo' would be a little more tedious to use -- it's what I'm doing now -- but at least it would make correlations possible, eh? -- Mark. Hi All, Ya know '-showinfo'? Ya know '-framecrc'? I need a mind meld of the two that works on a packet-by-packet basis. But that's impossible because of incompatible output methods. So, here's what I need and why. What: I need an ffmpeg command that • sees packets • reports packet DTS • reports packet PTS • reports whether frame (with 'N') or audio • reports packet CRCs Why: I have definitely found packets that wind up out of order following a trim, reshuffled, wrong DTSs & PTSs -- absolutely a bug, no doubt -- but I can't correlate that to the source because '-showinfo' uses ticks -- calls them "PTS" -- with an unknown starting point and does not show CRCs to correlate with '-framecrc' data. Why: I have definitely found trim-cuts that are 24 frames late -- absolutely a bug, no doubt -- but again, I can't correlate that with source frame numbers. Is there such a tool? Can such a tool be built? Aside: The table of DTSs, PTSs, packet POS, CRCs, etc., and the access methods must be gigantic. There appear to be access problems, and I'm trying to clarify the problems for bug submittal. We've all experienced trim-concat problems with certain video segments and I'm trying to illuminate them to help the developers. Cheers -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] '-showinfo'-'-framecrc' mind meld
Hi All, Ya know '-showinfo'? Ya know '-framecrc'? I need a mind meld of the two that works on a packet-by-packet basis. But that's impossible because of incompatible output methods. So, here's what I need and why. What: I need an ffmpeg command that • sees packets • reports packet DTS • reports packet PTS • reports whether frame (with 'N') or audio • reports packet CRCs Why: I have definitely found packets that wind up out of order following a trim, reshuffled, wrong DTSs & PTSs -- absolutely a bug, no doubt -- but I can't correlate that to the source because '-showinfo' uses ticks -- calls them "PTS" -- with an unknown starting point and does not show CRCs to correlate with '-framecrc' data. Why: I have definitely found trim-cuts that are 24 frames late -- absolutely a bug, no doubt -- but again, I can't correlate that with source frame numbers. Is there such a tool? Can such a tool be built? Aside: The table of DTSs, PTSs, packet POS, CRCs, etc., and the access methods must be gigantic. There appear to be access problems, and I'm trying to clarify the problems for bug submittal. We've all experienced trim-concat problems with certain video segments and I'm trying to illuminate them to help the developers. Cheers -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Unresolved concatenation and subtitle problems
One last note. The concatenation is I-frame..I-frame+I-frame..I-frame. So I should find a pair of back-to-back I-frames. Not found. Instead there appears to be a few hundred mixed up packets (I think ...can't be sure due to the unreliability-primitive nature of the tools). I remind the reader about the 5 stutters and 3 flashes at the join. I previously wrote that the stutter duration is 2 seconds. It is not. It is approximately 6 seconds. I made clean trims, but the concatenation is flawed. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Unresolved concatenation and subtitle problems
This is 00305+00306.mkv_framecrc.txt. It is headed by this analysis of the concatenation of 00305.mkv & 00306.mkv. 00305+00306.mkv contains either 241520 or 241552 or 241554 frames. The differences cannot be explained away as rounding differences. 00305+00306.mkv has a span of 1188892 packets: • 944567 audio packets PTS=0..10075411. 48000 samp-per-sec, 483618304 samples, 512 samp-per-pack. • 2782 subtitle packets PTS=54295..10073292. • 241543 video packets PTS=617..10075378. • That's 617.5±0.4[9..]..10075378.5±0.4[9..] = 10074761±0.9[9..] video ticks, exactly. = 241552.[711288..]±0.[023976..] frames, exactly. • '-showinfo' reports N=0..241519 = 241520 frames. • MPV shows 0.617..2:47:55.460 end to end = 0.6175±0.0004[9..]..2:47:55.4605±0.0004[9..] = 10074843.0±0.9[9..] ticks, exactly. = 241554.[677322..]±0.[023976..] frames, exactly. So, are there 241520 frames, as '-showinfo' claims, or 241552 frames, as '-framecrc' claims, or 241554 frames, as MPV shows? I favor 241552 as '-framecrc' claims for no particular reason. I will post 00305+00306.mkv_framecrc.txt on request. It is 70 MB. I will post 00305+00306.mkv_showinfo.txt on request. It is 124 MB. No, I cannot assume '-framecrc' is correct. In the face of inconsistent FFmpeg tools, I'm giving up. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Unresolved concatenation and subtitle problems
The saga continues... I'm trimming h:\BDMV\STREAM\00305.m2ts, making e:\00305.mkv FFmpeg appears to be adding soundless audio frames before the 1st video frame. Concatenating e:\00306.mkv, made the same way, produces stutter & flashing at the join. This report concentrates on the '-ss' trim of e:\00305.mkv. About 00305.m2ts: The 1st video packet is DTS=1044806, PTS=1048560. +-+ ... DTS precedes PTS by ¦ 1 frame ¦ <== remember this. +-+ + Now, I want to trim to ¦ 20.061708[3..]..1:33:10.83525 ¦ exactly. +---+ +---+ Therefore, I want¦ PTS=1805553.75..503175172.5 ¦ exactly. +---+ (At least, I think I do.) '-showinfo' says this: "n: 481 pts: 1805553 ... type:I". +---+ Therefore, I want frames ¦481..134046¦ exactly. +---+ But is frame 481 actually at PTS=1805553? No. Why do I say that? Because '-framecrc' says this: +---+ ¦ 1,1805040,1805040, 960, 1084 ¦ ¦ 1,1806000,1806000, 960, 1084 ¦ +---+ There is no packet with PTS=1805553 -- doesn't exist. So, what if I ignore that and just do this: set SOURCE=h:\BDMV\STREAM\00305.m2ts set TRIM=-ss 20.061708 -to 1:33:10.83525 set ARGS=-map 0 -c copy -dn set TARGET=e:\00305.mkv ffmpeg -report %TRIM% -i %SOURCE% %ARGS% %TARGET% MPV plays it but shows 0:00.616 as the start time. '-framecrc' shows 43 (presumably soundless) audio packets (DTS=0..448, PTS=0..448) preceding the 1st video packet (DTS=449, PTS=616). +--+ ... DTS precedes PTS by ¦ 4 frames ¦ +--+ The same thing probably happens at the '-to' trim point of 00305.m2ts, and it does happen at the '-ss' trim point of 00306.m2ts, so when I concat 00305.mkv & 00306.mkv, the join is messed up. For 2 seconds, MPV stutters 5 times and flashes the first image frame of 00306.mkv 3 times: stop-pause-go- -stop-pause-go- -stop-flash-pause-go- -stop-flash-pause-go- -stop-flash-pause-go. Then MPV continues as though nothing had happened. Each of the 5 stutters are like micro-movies in which running time stops but frames 'run'. Audio & subs flow though all that without a hitch. That tells me that audio packets are actually 'running the show'. What '-showinfo' is calling "PTS" is not PTS, it's ticks. Ticks relative to the 1st video packet, but not to _all_ packets. Since '-showinfo' lies about PTSs, I can't know 'N'. And 'framecrc' doesn't show 'N's, so I'm in the dark regarding the true identity of the frame and its true PTS. I also created e:\00305DTS-STARTDTS÷90.mkv set SOURCE=h:\BDMV\STREAM\00305.m2ts set TRIM=-ss 20.061708 -to 1:33:10.83525 set BSFV=-bsf:v setts=dts=DTS-STARTDTS/90:pts=PTS-STARTPTS/90 set BSFA=-bsf:a setts=dts=DTS-STARTDTS/90:pts=PTS-STARTPTS/90 set ARGS=-map 0 %BSFV% %BSFA% -c copy -dn set TARGET=e:\00305_DTS-STARTDTS÷90.mkv ffmpeg -report %TRIM% -i %SOURCE% %ARGS% %TARGET% and got similar results. I'm like you. I just want perfect video. I'll really appreciate help. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Unresolved concatenation and subtitle problems
The FFmpeg project is using PTSs to report relative measurements. DTS & PTS are in PES headers. They are metadata, NOT measurements. Please do not use DTSs/PTSs as metrics. Use "ticks", instead. For example, PTS=2854113..504223732 should be reported as "501369619 ticks", not as PTS=0..501369619. Thank you. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Unresolved concatenation and subtitle problems
On 12/28/23 07:47, Nicolas Gaullier wrote: When ffmpeg's '-vf showinfo' and ffprobe's '-show_streams' disagree, which should I trust? You should usually trust both, but their meanings are different. You should trust neither. I have more info that includes corrections to what I previously wrote -- gad, this is confusing and error prone work. COMPUTE (exact) MPV <--1:18:19.236208[3..]-> end to end 0..4699.1945 seconds, first..last 0..112668 frames, computed from seconds : SHOWINFO0..112668 frames 0..422927505 ticks <---+ FRAMECRC1044806..423972311 ticks vid ¦ :\\__ 422927505 <--+ 1048560..423979440 ticks aud :\\__ 422930880 STREAMS1048560..?vid start_pts <- not in showinfo, not vid PTS 1048560..?aud start_pts \ 3143152..? sub start_pts \_\__ 1st sub at 0:23.273 - confirmed. if -framecrc is right, then -showinfo "n: 0 pts: 0" <- wrong -- no equivocation, wrong -show_streams vid "start_pts=1048560" <- wrong -- no equivocation, wrong I previously wrote, "So '-framecrc' & '-showinfo' agree but they disagree with '-show_streams'." That was erroneous. They all disagree with each other. Apparently, ffmpeg/ffprobe should be fixed so that my chart would then be: MPV <--1:18:19.236208[3..]-> end to end 0..4699.1945 seconds, first..last 0..112668 frames, computed from seconds : SHOWINFO0..112668 frames 1044806..423972311 ticks <== when fixed FRAMECRC1044806..423972311 ticks vid :\\__ 422927505 1048560..423979440 ticks aud :\\__ 422930880 STREAMS1044806..?vid start_pts <== when fixed 1048560..?aud start_pts \ 3143152..? sub start_pts \_\__ 1st sub at 0:23.273 - confirmed. But is '-framecrc' actually correct? I will use the '-framecrc' numbers to do the DTS-PTS shifting and packet concatenations and will report back. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Unresolved concatenation and subtitle problems
On 12/28/23 07:47, Nicolas Gaullier wrote:
When ffmpeg's '-vf showinfo' and ffprobe's '-show_streams' disagree, which
should I trust?
You should usually trust both, but their meanings are different.
showinfo is a filter, so apply to a running filter graph, I don't think this
information could be very helpful for your use case.
show_streams will give you some start_time/duration using the same core
components (avformat_find_stream_info) as the concat demuxer, which actually
can help.
Another option is to use a kind of "plain raw dump" and guess
start_time/duration by yourself. This can be achieved with an ffmpeg -copyts -c copy -f
framecrc -
-continued below-
Thank you, Nicolas.
I ran this:
set SOURCE=h:\BDMV\STREAM\00306.m2ts
set TARGET=e:\00306.m2ts_framecrc.txt
ffmpeg -i %SOURCE% -copyts -c copy -f framecrc %TARGET%
Here's 00306.m2ts, packets 0..16, as reported by '-framecrc':
stream number ('0' is the video stream, '1' is the audio stream)
P ¦ DTS(P) PTS(P) T(P) B(P)/8 CRC(P)unknown
-- ¦ --- --- -- -- -
0: 0, 1044806, 1048560, 3753, 178583, 0x34cc62a3, S=1,1
1: 0, 1048560, 1056067, 3753, 92709, 0xfa7b5edb, F=0x0, S=1, 1
2: 1, 1048560, 1048560, 960, 1084, 0xe54d2b6f, S=1,1
3: 1, 1049520, 1049520, 960, 1084, 0xe54d2b6f, S=1,1
4: 1, 1050480, 1050480, 960, 1084, 0xe54d2b6f, S=1,1
5: 1, 1051440, 1051440, 960, 1084, 0xe54d2b6f, S=1,1
6: 0, 1052313, 1052313, 3753, 145206, 0x10576cdb, F=0x0, S=1, 1
7: 1, 1052400, 1052400, 960, 1084, 0xe54d2b6f, S=1,1
8: 1, 1053360, 1053360, 960, 1084, 0xe54d2b6f, S=1,1
9: 1, 1054320, 1054320, 960, 1084, 0xe54d2b6f, S=1,1
10: 1, 1055280, 1055280, 960, 1084, 0xe54d2b6f, S=1,1
11: 0, 1056067, 1063575, 3753, 141288, 0xb70f376e, F=0x0, S=1, 1
12: 1, 1063920, 1063920, 960, 1084, 0xe54d2b6f, S=1,1
13: 1, 1064880, 1064880, 960, 1084, 0xe54d2b6f, S=1,1
14: 1, 1065840, 1065840, 960, 1084, 0xe54d2b6f, S=1,1
15: 1, 1066800, 1066800, 960, 1084, 0xe54d2b6f, S=1,1
16: 0, 1067328, 1067328, 3753, 146136, 0xc75a68fb, F=0x0, S=1, 1
T(P) for stream 0 is reported erroneously:
reported T(P) actual T(P) N(P)
P0 3753 3754 1
P1 3753 3753 1
P6 3753 3754 1
P11 375311261 3
So '-framecrc' & '-showinfo' agree but they disagree with '-show_streams'.
They may agree because they 'drink the same beer'.
This is all indeterminate without the ability to parse actual m2ts headers.
That is where the truth lies.
Note that in some cases, it might happen that the real "first pts" comes before
the ff reported start_time. And in that case, you will see mpv (based on ff) play your
file at a point that is earlier than the start_time reported by ff.
I've seen that.
So, be careful, these start_time/duration things are often much trickier than
they look like.
It seems you want to join segments without reencoding.
First, you have to take care of the available features of your output muxer :
an mp4 is more powerful to handle stream discontinuities than an mpegts format.
Umm... (No, I'm not going to comment on why that might be at this time).
And there are two things to consider:
- "timestamp joining" : care about start/end points;
I cut and trim solely on I-frames, preserving (doubling) the I-frame on both
sides of a cut.
but also, if your input audio/video is not aligned/locked (any usual compressed
audio codec), you will have to reencode audio at least if you want to avoid a
hole (or overlap) in the timeline.
So video packs and audio packs are not correlated, eh? Too bad.
- keyframes : open-gop is not editable with a straight stream copy if you don't
allow some overlap; and you would certainly experience some difficulties to
handle this overlap in a muxer
So many things, very dependent on your exact files and workflow.
At the end, if you encounter an issue, try to reproduce it on short segments to
document a case in trac, with a very exhaustive report and corresponding media
samples.
Will do.
-
I have designed hundreds of hardware finite state machines (FSM).
Every one of them worked exactly as designed, zero bugs.
I was taught by Dr. John Battocletti at Ohio State University.
FSMs assure 100% coverage and 100% testability.
I have taught FSM methods to codesmiths in Silicon Valley.
The 'C' language has all the elements needed for FSM design.
I will help with FSM design in 'C' for free with anyone who asks.
OO FSM (object-oriented FSM) would be perfect for AV processing.
(The MPEG specifications utilize an informal form of FSM.)
I've been casually working on OOFFmepg for about a year.
OOFFmpeg could be implemented in 'C' using existing FFmpeg libraries.
Based on my experiences, I think OOFFmpeg could be made fairly quickly.
-
Cheers
Re: [FFmpeg-user] sntsc
This is important to me. I sent it yesterday, but from the wrong account, so it wasn't accepted by ffmpeg-user. If you somehow got 2 of them, please accept my apology. (Between TBird's quirks and Gmail's quirks, email is driving me nuts.) On 12/27/23 01:58, Kieran O Leary wrote: On Tue 26 Dec 2023 at 22:53, Mark Filipak wrote: Oh, no! Mister Billipedia! Hahahaha... (where people who are as ill informed as you are, get to pontificate) I think you must have misread the tone of Devin’s email, and I would hardly call him ill informed. His post was constructive and your language will only derail threads like this. Oh, I did not mean it like that. I meant the general 'you' as in 'you, the reader', as in 'people who are as ill informed as _they_ are'. I sincerely didn't mean Devon. But you are entirely justified in your objection. You read it differently, but your reading is reasonable and reasoned, I must admit. I sincerely apologize. I meant no harm. I certainly didn't mean to denigrate Devon. I only meant to denigrate Wikipedia. Peace and love. Please forgive my overly hasty post. I am appropriately chastened. In the future, I will try harder to express my true meanings. So sorry -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
