MediaInfo Unexpected Changes
noctis90210 opened this issue · 9 comments
When I compared the original file vs the merged file there are some unexpected mediainfo changes found:
Original Video: Frame Rate Mode: Constant
Merged Video: Frame Rate Mode: Variable
Original Audio: Bit Rate: 192kbps
Merged Audio: Bit Rate: 129kbps
How have you compared that information? I would need you to detail that information to be able to carry out my own tests, thanks!
How have you compared that information? I would need you to detail that information to be able to carry out my own tests, thanks!
I installed MediaInfo app on my PC then i compared both the original file and the merged file.
[2022-10-30 12:02:28.526] [debug] Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 1, only the last option '-c:a aac' will be used.
[2022-10-30 12:02:28.526] [debug] Cannot map stream #0:2 - unsupported type.
[2022-10-30 12:02:28.526] [debug] Stream mapping:
[2022-10-30 12:02:28.527] [debug] Stream #0:0 -> #0:0 (copy)
[2022-10-30 12:02:28.527] [debug] Stream #0:1 -> #0:1 (aac (native) -> aac (native))
[2022-10-30 12:02:28.527] [debug] Stream #0:3 -> #0:2 (copy)
About audio with less bitrate, probably this is the reason? it should say "copy" and not "aac (native)" right?
That's right, reviewing the code I have found the problem that causes it, the wrong option was being used when treating the audio, I will open a merge request solving this problem to correct this problem as soon as possible, thanks for the help!
About the frame rate mode I haven't been able to take a look at it yet.
Lately I don't have much time to dedicate to the project.
Could you attach the log file corresponding to the video you use in mediainfo?
GH010012_Nov 1, 2022 12-26 AM.log
here is the log from 1.3.0
i tried to use older version, specifically 1.2.2 and it retains the 192kbps audio.
On the subject of the frame rate mode, it is not so simple from what I have been investigating, it has more to do with the video clips than really with the way of treating them, depending on what characteristics the video clips have, it is not possible to join clips in constant mode. I have done tests with my own clips and there are some that use constant mode and others variable mode, in which variable mode is used I have observed in mediainfo that they usually have different frame rates (nothing exaggerated, but different) and different bit rates /(pixel*frame). In principle, there is no simple solution to this, however, to make sure of this, could you attach a mediainfo screenshot of the 2 of your clips in tree view? Thanks.
Regarding the audio issue, I have already corrected the problem and in the next update it will be corrected, the problem was created when support for .360 files was added
heres the comparison, the constant one is the original, and the variable is the one that's merged.
but it seems not a huge problem since ffmpeg do its job to just join the video (Stream #0:0 -> #0:0 (copy))
at the same time everything plays normally and the reelsteady app detects the video normally without problems.
i also tried to use standalone ffmpeg combining just the video, and it produces the same thing, thats why i think theres nothing wrong with reelsteady-joiner.
Maybe its just the nature of the ffmpeg calculating things when combining 2 videos.
The problem with the audio has been solved in version 1.3.1, about the frame rate, as you say, it is not a problem with the processing of Reelsteady Joiner, but with how ffmpeg treats the video files.