On Mon, 8 Jan 2024 at 12:37, Mark Filipak <markfilipak.i...@gmail.com> wrote: > > On 1/8/24 07:16, Rob Hallam wrote: > > On Mon, 8 Jan 2024 at 12:07, Mark Filipak <markfilipak.i...@gmail.com> > > 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".