Re: [FFmpeg-user] Towards better trims & concatenations
вт, 9 янв. 2024 г., 02:02 Mark Filipak : > 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. > > >
Re: [FFmpeg-user] Having a hard time getting good results with mpeg2video
Hi, I'm trying to make a DVD with a still image (1:1 aspect ratio) and audio, the only issue is that the video is a bit blocky even after setting the highest bitrate available. The command used: `ffmpeg -i image.jpg -i audiofile.wav -f dvd -muxrate 10080k -packetsize 2048 -pix_fmt yuv420p -r 24000/1001 -codec:v mpeg2video -g 18 -b:v 9800k -maxrate:v 9800k -minrate:v 9800k -bufsize:v 1835008 -vf "scale=720:576:flags=lanczos:force_original_aspect_ratio=decrease,pad=720:576:(ow-iw)/2:(oh-ih)/2" -codec:a pcm_dvd output.mpg` FFmpeg version (latest from Arch repos): `ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 13.2.1 (GCC) 20230801 configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-version3 --enable-vulkan libavutil 58. 29.100 / 58. 29.100 libavcodec 60. 31.102 / 60. 31.102 libavformat 60. 16.100 / 60. 16.100 libavdevice 60. 3.100 / 60. 3.100 libavfilter 9. 12.100 / 9. 12.100 libswscale 7. 5.100 / 7. 5.100 libswresample 4. 12.100 / 4. 12.100 libpostproc 57. 3.100 / 57. 3.100` I also played around with some hidden options but they didn't seem to make much difference: `-trellis 1 -dia_size 2 -pre_dia_size 2 -precmp rd -cmp rd -subcmp rd -mbd rd -last_pred 3 -vqmin 0 -vqmax 0 -qmin 1 -qmax 1 -dc 11 -vstrict 0 -mpv_flags '+mv0+cbp_rd+qp_rd' -lmin 1` You do not need a high bitrate for still images. Just use the defaults! Higher bitrates are only necessary for video with lots of movement. Use dedicated imaging software to scale the images to the size you need first. For example use Imagemagick or The Gimp for this, they have much better image scaling algorithms giving you a high quality scaled image. Then use those already scaled images as input for your video. This will most likely give a much better result. And a simpler commandline as you can completely omit the scale filter. So the only thing ffmpeg has to do is to convert your picture to the specified yuv colorspace. The ffmpeg scale filter is according to the documentation a "video scaling filter" meaning it is designed to scale moving pictures, not still pictures, For video some blocking or blurring often does not hurt or even benefits the perceived quality. ___ 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 continuous at the join, bad things happen. By that I don't mean
[FFmpeg-user] Having a hard time getting good results with mpeg2video
Hi, I'm trying to make a DVD with a still image (1:1 aspect ratio) and audio, the only issue is that the video is a bit blocky even after setting the highest bitrate available. The command used: `ffmpeg -i image.jpg -i audiofile.wav -f dvd -muxrate 10080k -packetsize 2048 -pix_fmt yuv420p -r 24000/1001 -codec:v mpeg2video -g 18 -b:v 9800k -maxrate:v 9800k -minrate:v 9800k -bufsize:v 1835008 -vf "scale=720:576:flags=lanczos:force_original_aspect_ratio=decrease,pad=720:576:(ow-iw)/2:(oh-ih)/2" -codec:a pcm_dvd output.mpg` FFmpeg version (latest from Arch repos): `ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 13.2.1 (GCC) 20230801 configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-version3 --enable-vulkan libavutil 58. 29.100 / 58. 29.100 libavcodec 60. 31.102 / 60. 31.102 libavformat 60. 16.100 / 60. 16.100 libavdevice 60. 3.100 / 60. 3.100 libavfilter 9. 12.100 / 9. 12.100 libswscale 7. 5.100 / 7. 5.100 libswresample 4. 12.100 / 4. 12.100 libpostproc 57. 3.100 / 57. 3.100` I also played around with some hidden options but they didn't seem to make much difference: `-trellis 1 -dia_size 2 -pre_dia_size 2 -precmp rd -cmp rd -subcmp rd -mbd rd -last_pred 3 -vqmin 0 -vqmax 0 -qmin 1 -qmax 1 -dc 11 -vstrict 0 -mpv_flags '+mv0+cbp_rd+qp_rd' -lmin 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] 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
> 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 ___ 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 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? 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? 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! 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. 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 didn't have a particular spec in mind, but candidates would be ffmpeg specs and/or specs for the container and codec formats in use- ie does this behaviour contradict those. > > 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". Does it matter that the starting running time is not "00:00:00.000" ? 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. I am happy to be corrected and educated, which is partly why I am still subscribed to this ML. I ask these questions because "ffmpeg produces output that plays incorrectly" is a different bug to "ffmpeg produces output that plays correctly but has a different file structure". Both are bugs, but it's worth being clear to which one the issues have identified belong so you and devs are on the same page. > > 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. I agree it should be possible conceptually, but in practice I couldn't refine a process to the point where it felt sufficiently robust to trust. I am quite open to the possibility that the fault may have been mine though! I may look into it again when I have sufficient quantities of time and need :) Cheers, Rob ___ 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 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. 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? 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. 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 ___ 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".
[FFmpeg-user] Issue encrypting udp stream using crypto protocol
Hi there, I'm trying to encrpyt a mutilicast UDP stream with crypto protocol (AES), here is the command line I use: ffmpeg -f decklink -channels 2 -format_code Hi50 -draw_bars false -video_input sdi -audio_input embedded -i "DeckLink Quad (4)" -filter_complex "[0:v]setfield=mode=tff,setpts=PTS-STARTPTS,drawtext=x=(main_w-text_w)/2:y=(main_h-text_h)/8:fontfile=C\\:/Windows/fonts/consola.ttf:text='TEST-05':box=1:boxcolor=00CC:boxborderw=20:fontcolor=yellow:fontsize=48[vout];[0:a]asetpts=PTS-STARTPTS[aout]" -c:v libx264 -flags:v +ildct+ilme -g 25 -profile:v high -level:v 41 -tune:v zerolatency -preset:v veryfast -x264-params "nal_hrd=cbr:interlaced=1:weightp=0" -pix_fmt yuv420p -b:v 1k -minrate:v 6000k -maxrate:v 1k -bufsize:v 1000k -c:a libfdk_aac -b:a 256k -ar 48000 -metadata service_provider="service provider" -metadata service_name="service name" -map "[vout]" -map "[aout]" -f mpegts -encryption_key 000102030405060708090A0B0C0D0E0F -encryption_iv 000102030405060708090A0B0C0D0E0F "crypto+udp://239.0.0.5:5000?ttl=1_size=1316_size=4096000=10.40.2.183" -loglevel verbo se The command line above works flawlessly without the crypto protocol. I've got an error saying "Crypto: seek not supported for write", I don't know why cause I'm even not trying to seek ... I did a lot of searches on Google, StackOverflow and ffmpeg trac to find a solution but without success till now. I also tried with different versions of ffmpeg, still same error. Is anybody already tried to do this ? Is this a bug ? Should I create a ticket on trac ? Here is the full console output (verbose): ffmpeg version n6.1.1-4-gfe3b2419a7-g0f824d792d+85 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 13.2.0 (Rev3, Built by MSYS2 project) configuration: --pkg-config=pkgconf --cc='ccache gcc' --cxx='ccache g++' --ld='ccache g++' --extra-cxxflags=-fpermissive --extra-cflags=-Wno-int-conversion --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --enable-ffnvcodec --enable-nvdec --enable-cuda-llvm --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libdav1d --enable-libaom --disable-debug --enable-libfdk-aac --enable-fontconfig --enable-libass --enable-libfreetype --enable-libharfbuzz --enable-libfontconfig --enable-libmfx --enable-libmysofa --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libopenmpt --enable-version3 --enable-librav1e --enable-libsrt --enable-libgsm --enabl e-libvmaf --enable-libsvtav1 --enable-chromaprint --enable-decklink --enable-frei0r --enable-libaribb24 --enable-libcaca --enable-libflite --enable-libfribidi --enable-libilbc --enable-libsvthevc --enable-libsvtvp9 --enable-libkvazaar --enable-librist --enable-librtmp --enable-librubberband --enable-libtesseract --enable-libzmq --enable-openal --enable-libcodec2 --enable-libglslang --enable-vulkan --enable-opengl --enable-libopenh264 --enable-openssl --extra-cflags=-DLIBTWOLAME_STATIC --extra-libs=-lstdc++ --extra-cflags=-DCACA_STATIC --extra-cflags=-DCHROMAPRINT_NODLL --extra-libs=-lstdc++ --extra-cflags=-DZMQ_STATIC --extra-libs=-lpsapi --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv --disable-w32threads --extra-cflags=-DKVZ_STATIC_LIB --enable-nonfree --extra-cflags=-DAL_LIBTYPE_STATIC --extra-cflags='-IC:/m-ab-s/local64/include' --extra-cflags='-IC:/m-ab-s/local64/include/AL' libavutil 58. 29.100 / 58. 29.100 libavcodec 60. 31.102 / 60. 31.102 libavformat60. 16.100 / 60. 16.100 libavdevice60. 3.100 / 60. 3.100 libavfilter 9. 12.100 / 9. 12.100 libswscale 7. 5.100 / 7. 5.100 libswresample 4. 12.100 / 4. 12.100 libpostproc57. 3.100 / 57. 3.100 [decklink @ 013cc9656740] Found Decklink mode 1920 x 1080 with rate 25.00(i) [decklink @ 013cc9656740] Using 2 input audio channels [decklink @ 013cc9656740] Frame received (#1) - No input signal detected - Frames dropped 1 [aist#0:0/pcm_s16le @ 013cc965c100] Guessed Channel Layout: stereo Input #0, decklink, from 'DeckLink Quad (4)': Duration: N/A, start: 0.00, bitrate: 830976 kb/s Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s Stream #0:1: Video: rawvideo, 1 reference frame (UYVY / 0x59565955), uyvy422(top first), 1920x1080, 829440 kb/s, 25 tbr, 1000k tbn [out#0/mpegts @ 013cc965adc0] Adding streams from explicit maps... [out#0/mpegts @ 013cc965adc0] Creating output stream from an explicitly mapped complex filtergraph 0, output [vout] [vost#0:0/libx264 @ 013cc9667340] Created video stream from complex filtergraph 0:[drawtext:default] [vost#0:0/libx264 @ 013cc9667340] [out#0/mpegts @
