I have used and enjoyed AVIDEMUX as a tool to archive films taken from TV-broadcast.
Until now.
Now problems start even at loading... most of the stepping-functions fail... but the worst is that the resulting video is rather a set of flashing pictures than a smooth film when replaying.
Due to a change is service: the broadcast-rate has increased drastically. Now it is at ~15,000 kb/s (previously ~4000 kb/s), at 720*576 resol. and 25 frame/s.
My system is Win7 64bit, and Avidemux_2.7.0r180405_win64.exe is (freshly) installed. Video/Audio output are both in "Copy" mode, Output-format is set as "Mpeg TS Muxer", other options left as installed.
I guess (and hope) that setting properly some of the "million switches" your software offers will eliminate my problems.
Since I am a complete stranger in the video-terms applied, I would need a set of instructions to follow.
Could you help me, please?
Please provide a sample video (e.g. using WeTransfer) in which Avidemux fails to seek. Does an older Avidemux version work for you for this particular sample?
By the way, completely wrong part of the forum.
Thanks for your care.
I will be preparing a short sample (both source and Avidemux-manipulated) as soon as I learn the way of sending/attaching them in a message to you.
Previously I loaded +worked with versions 2.6.14 (32 bit) and 2.6.21 (64 bit), and encountered no such problems with source-videos of ~4000kb/s rate, while none of them works with these new ~15000kb/s rate videos.
Since size of files are somewhat a limiting factor in sending samples over, the videos behind the links (offered by "WeTransfer", as you suggested) are excerpts of about 30 sec (~30Mb).
Two sets are being sent for your perusal. Under each link there is a source-sample (in 3 parts, as is generated by the devices at recording) and 2 "manipulated" results: one with 2.6.21 version and another with 2.7._the_latest. [Manipulation here was practically limited to loading & saving – with testing the stepping-keys, too.]
1.) from News M1-hu media: https://we.tl/Cne2XFzKzq
2.) from a film: https://we.tl/16PnRTLrPG
The "Av 2-6_manip" files clearly show the flashing-effect.
While as to the Avidemux 2.7. I have to correct my previous statement. All that was said stood for an earlier 2.7. version. [Which, however, has been overwritten on refreshing it with the latest (e.g.: 2.7.0r180405_win64.exe).] That is, this latest 2.7. version gives free-of-flashing results.
HOWEVER:
• On loading the source-video you can discern that while the "1 minute" and "the smallest" steps (back&forth) are functioning proper, neither the "medium-stepping" nor dragging-on-timeline works as they should: the screen is gray-blank – just as it is right after loading.
• Another big difference exists in loading: This latest version do not offer concatenation of sequential files while all previous versions did. [And since recording TV-broadcasts (at least in my arrangement) is done by breaking the film's content into 1GB portions (separated by those 64kb service-files), such an option back would be a welcome.]
These side-effects together make fine-manipulations quite tedious, especially when problem appears at saving (marked as "Video is too short/incomplete") due to unhappy gaps under recording, and the erroneous part to be dropped is to be searched for by fine-tuning.
Thanks for the samples, I'll look at them as soon as possible. I need only source videos and precise editing steps, no output videos. Test with legacy versions matter only if the latest nightly fails at something which works in 2.7.0 release or in 2.6.x and other unsupported EOL versions.
Quote from: EFuggerth on April 11, 2018, 10:28:24 AM
While as to the Avidemux 2.7. I have to correct my previous statement. All that was said stood for an earlier 2.7. version. [Which, however, has been overwritten on refreshing it with the latest (e.g.: 2.7.0r180405_win64.exe).] That is, this latest 2.7. version gives free-of-flashing results.
Fine.
Quote
On loading the source-video you can discern that while the "1 minute" and "the smallest" steps (back&forth) are functioning proper, neither the "medium-stepping" nor dragging-on-timeline works as they should: the screen is gray-blank – just as it is right after loading.
Maybe wrong frames are marked as IDR (as keyframes). I'll check this.
QuoteAnother big difference exists in loading: This latest version do not offer concatenation of sequential files while all previous versions did. [And since recording TV-broadcasts (at least in my arrangement) is done by breaking the film's content into 1GB portions (separated by those 64kb service-files), such an option back would be a welcome.]
It has been disabled because it was both severely broken as well as unnecessary for MpegTS. It is mandatory only for DVD structures.
I understand disabling concatenation of sequential files, and there exists a route to overcome this point by using your built-in "appending" option in the "File" menu, indeed.
The visibility and tracking ALL frames are however of paramount import to clear all possible blemishes. [Is there anything necessary detail I have missed to describe?]
While very similar from the user's perspective, appending videos at the application level and concatenation at the demuxer level are fundamentally different. The former operates with technically independent videos (i.e. each video can be loaded separately, with timestamps starting from zero), the latter assumes that the files are just portions of a single big file split in binary way. If this assumption does not match the reality, things go very wrong. With all this in mind, in order to implement a more fine-grained approach, it would be required to find out what your recording device is actually doing.
I'll try to check why decoding of some frames fails. Didn't have a chance to look at the samples yet.
At the first glance, the problem of not decodable keyframes is related to this video being interlaced with the bottom field shown first.
"To find out what the recording device is actually doing" – especially in the binary kingdom – is certainly beyond me. It was to serve the trial of whatever depth that I sent over the short source-videos as they were: that is, in 3 parts ["000"(64kb)+"000"(2.2MB)+"info3"(32kb) – for the "News M1-hu].
Anyway, bigger source-files are built up as:
"000"(64kb)+"000"(1GB)+"001"(64kb)+"001"(1GB)+"002"(64kb)+"002"(1GB)+...+"00n"(64kb)+"00n"(residue)+"info3"(32kb)
Meanwhile, tentatively I tried appending sequential parts of the same source with success – except that manipulations were done mostly "in the dark", due to described failures in visibility while stepping.
So, the core to cure is visibility all-round. For which I am patiently waiting.
...and waiting "for the 2nd glance"...
Newbie to Hero Member:
Something's up? (Dee-day's looming...)
Over.
No, not yet. I don't have time and peace of mind for any non-trivial Avidemux-related work ATM.
So I wait, with full of hope. (As submissive Nubians in the line should.)
[Yet, conundrum of non-triviality: Stepping by 1 frame or by 1 minute works fine (back&forth), while the stepping maneuver in between them fails (i.e. gives blank instead of the actual picture). It seems a central blemish, isn't it?]
How was this channel broadcast? Over a satellite? Which one? Terrestrial? DVB-T? We would like to be able to capture the channel ourselves, if possible.
The signal arrives to my abode through a cable, however the service-provider offers satellite-signal also for "un-cabled" territories. The contact page/address is https://www.tarr.hu/ , with seemingly no clue for global attainability neither to the signal nor for any details in English.
Their email address is info@tarr.hu . Good luck for the try.
On contacting the service-provider, they assured me of their readiness to provide Avidemux's programmers information regarding "technical parameters", as soon as you write them (Orbán Roland TARR Kft., info@tarr.hu, my letter's ID is 2170976).
Thanks, we are on it at the moment, don't think that we need new samples. Currently, the problem looks like a ffmpeg bug, there is a workaround as the last resort.
The stream is field-encoded, which is very uncommon nowadays. When the keyframe (the first field) is fed to lavcodec after decoder flush, it immediately pops out a bogus gray image instead of waiting for the second field.
While embracing the good news, I beg of Lord this bug not to escalate into buggery.
Mean has independently found the solution and then identified the upstream fix for FFmpeg (https://trac.ffmpeg.org/ticket/6677) which solves this issue and pushed the changes (https://github.com/mean00/avidemux2/commit/48e3b37c2a141f98b5f3f364998c7c06501ce7c1) necessary to integrate this patch into Avidemux. You might want to try the latest nightly (http://avidemux.org/nightly/win64/) (r180524 at the moment). Please be aware that you won't be able to save a similar field-encoded mpeg2 video in copy mode yet.
This Mean-news is happy-news, rather.
(Sorry for my being late with checking your newest "nightly".)
Full visibility on tracking the frames is restored, indeed. (So, manipulations can now be followed again.)
HOWEVER: The complete (cut) film [if it comes from appending and saving the Avidemux-manipulated segments of the fixed broadcast] (on the usual "VLC" replay) exhibits a marked, extremely disturbing asynchrony between pictures and voices. [N.B.: the saving-process of the appended parts onto a single-part film is unusually slow.] On the contrary: No such asynchrony emerges if the resulting film is made by appending the original segments first and then Avidemux-manipulating the whole [and saving it (in an output format "Mpeg2 TS muxer (ff)")]. (Wherefore, incorporating a direction running this way into your next nightly could be useful.)
This I experienced after several trials.
How further then?
Your last sentence in the latest message warns as "Please be aware that you won't be able to save a similar field-encoded mpeg2 video in copy mode yet." Does it mean I should be expecting some further refining?
As stated above, the copy mode for field-encoded video is broken. Fix upcoming.
Re-encoding (adding a good deinterlacer is highly recommended) should work.
Your latest version (2.7.1) solved my pending archive-manipulations with success. (Though small bugs must still be hiding, they cause manageable inconvenience for the resolved.)
Wherefore:
A prominent Newbie having rambled leeward on forbidden pastures for an embarrassing period (with a relentless series of 66 winters survived) wishes to express his gratitude for this session and for all your hero-members' work behind.
Rewarding or not, I hereby take the boldness and attach a picture of "Siberian Honey-berry" [taken on a domesticated species in my garden], if for not other reasons than to spare the inconveniences of travelling there to see it.
Whereby to earn respect for the Newbian colors.
QuoteThough small bugs must still be hiding, they cause manageable inconvenience for the resolved.
Have you tested with the latest available nightly build (https://avidemux.org/nightly/win64/) (r180702 so far)? If the bugs persist, it would be nice to get to know what these bugs are.
Not yet.
Nightly 2.7.0 (180524) had already solved the main issue, then – out of a sudden – came a 2.7.1 version when making the robot of archiving. This latter worked more stable.
The hiding bugs must be somewhat tricky, for the peccadilloes are not predictable: The symptoms can be described clear, but there is no telling when the problem surfaces and when it decides not to. And so long as it remains so random in nature, I do not want to rob you of innocent nights.
Should your curiosity persist, however, I'll offer details made with the latest nightly available at the time – soon as I am over some tedious other tasks, and a newer bunch of films are crying for my nursing. But I fear, that to trap efficiently these hiding little monsters would require real-samples again, of appreciable sizes.
That nightly contains fixes for regressions https://avidemux.org/smif/index.php/topic,18363.0.html (playback stuttering or stuck after going to the previous frame) and for https://avidemux.org/smif/index.php/topic,18382.0.html ("fade to black" filter broken). One pretty important fix of audio delay calculation in the Mp4 demuxer has been added after the nightly was built.
If the issues you see are different, please provide more details.
Will reflect – soon as material to deal with gathers...
The promised check for remaining blemishes:
On working up today the newly gathered material (approx. 30 items) but now with your very latest nightly (2.7.1._180807), there appeared only one little fault, which is about this:
In the filled-in appended file (of several GB in size) [MPEG2 as recorded, to be saved in your MPEG TS(ff) format], while on search for a definite point in play-mode, the stop-button makes the actual-position jump back to the very beginning of the file (though the last active frame remains momentarily seen). This rather hampers A/B markers to insert. The phenomena happens rather random: at least 5 items responded so, several of them more than once.
My practice to overcome this is as follows: the stopping-position should be changed, and navigation has to be brought to the desired point by using the forward/backward jump/fine-tune buttons instead of play/stop.
An error message of "error seeking to xxx ms" used to appear earlier randomly too (though without any discernible problem in the afterwards) now didn't make a show.
Since you are strongly bent to make improvements, let me repeat another small point that would be easy to incorporate and is sure to offer comfort for the user. The practice in my processing always starts with appending quite a number of files (that are "sequential files" of the same film, broken into 1GB parts by the inherent workings of the recording device), which is a prerequisite for a proper job, but rather tedious on a large scale. A conditional branching incorporated in your program to offer an option for circumventing this and done automatically would probably not disturb anything already in place.
Quote from: EFuggerth on August 26, 2018, 07:37:22 PM
The promised check for remaining blemishes:
On working up today the newly gathered material (approx. 30 items) but now with your very latest nightly (2.7.1._180807), there appeared only one little fault, which is about this:
In the filled-in appended file (of several GB in size) [MPEG2 as recorded, to be saved in your MPEG TS(ff) format], while on search for a definite point in play-mode, the stop-button makes the actual-position jump back to the very beginning of the file (though the last active frame remains momentarily seen). This rather hampers A/B markers to insert. The phenomena happens rather random: at least 5 items responded so, several of them more than once.
Please reproduce the issue and provide compressed admlog.txt from that Avidemux session. When stopping playback, Avidemux tries to seek to the timestamp of the last displayed frame (earlier, it displayed the last decoded frame which was equivalent to jumping 8 frames ahead). If this seek fails, it falls back to the old behaviour.
Quote
Since you are strongly bent to make improvements, let me repeat another small point that would be easy to incorporate and is sure to offer comfort for the user. The practice in my processing always starts with appending quite a number of files (that are "sequential files" of the same film, broken into 1GB parts by the inherent workings of the recording device), which is a prerequisite for a proper job, but rather tedious on a large scale. A conditional branching incorporated in your program to offer an option for circumventing this and done automatically would probably not disturb anything already in place.
Please provide the exact size in bytes of the chunks of the stream your recoding device is producing. You could also install Linux and build Avidemux from source (which is trivial at least on Ubuntu) with "#if 0" at avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsIndex.h:47 (https://github.com/mean00/avidemux2/blob/master/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsIndex.h#L47) changed to "#if 1" to get the desired old behaviour.
With a new batch of film to archive having gathered and available for processing I went to the task to locate and document failure-action, as you asked.
In this, I thought to save you space & trouble, so, on finding a non-normal action I started a fresh Avid-session with the problematic-item, but the previously observed failure did not occur on repeating. Hence, the here presented admlog.txt file is a bit longer: it is the second film in the session where the problem occurred – and must have left its trace on the txt-record. I keep both complete film source-files and the full adminlog.txt as well for a while, but you required only its .ZIP version, which I supply: https://we.tl/t-de4hekQjyY The failure itself as I observed was the same I previously have already described. Namely: On a search for the declared end of the film in a manually appended file in play mode a press on the stop button has brought the time-marker back to the very beginning – instead of remaining (practically) were it previously was.
On appending:
So far as I can fathom, an exact size down to the bit does not exist for the chunks. The recording device is said to break longer items into 1GB portions + the remaining, and stores them in a folder. Since this feature did not changed and (optional) automatic appending was a problem-free part of your older versions, I can hardly imagine anything to hamper you from reinstalling this optional feature anew. I would rather remain a happy end-user than messing in your prime job.
Quote from: EFuggerth on September 22, 2018, 05:09:40 PM
On a search for the declared end of the film in a manually appended file in play mode a press on the stop button has brought the time-marker back to the very beginning – instead of remaining (practically) were it previously was.
This happens when the stream is corrupted (numerous occurences of "PTS going back" in the log indicate a damaged stream) at the spot where the playback stops. The following seek back to this spot fails in somewhat unexpected way, I must look into it first to be able to judge whether it is easily fixable.
QuoteThe recording device is said to break longer items into 1GB portions + the remaining
I need the exact number of bytes, "1GB" is not precise enough.
Quote(optional) automatic appending was a problem-free part of your older versions
It wasn't.
QuoteI can hardly imagine anything to hamper you from reinstalling this optional feature anew.
If you build Avidemux yourself (which is trivial on Linux), it is just a question of chaning a "0" into "1" at the location in the source I already mentioned. To safely re-enable the prompt in official builds, I need a more or less reliable indicator for a heuristic detection like the (exact) chunk size.
Data to help find a "reliable indicator for a heuristic detection like the (exact) chunk size" is in the ttached Table/picture.
My present OS is Win7 (Ubuntu's flexibility as regards to Avidemux is thus off), and each of your freshly installed nightly would force me to repeat intrusion. Thus, I'd be better off with your solution.
Thanks, the smallest "1GB" chunk (1,073,880,064 bytes) is 240640 bytes smaller than the largest (1,074,120,704), and even the smallest is bigger than 1 GiB (what "GB" on Windows stands for) = 1,073,741,824 bytes. If chunks happen to be within 1 MiB tolerance from n GiB in size we might re-enable prompting for binary append in the demuxer without getting too many false positives.
I have checked several other film-folders, and have found 2 chunks smaller than has already been passed: they are 1 073 831 936 and 1 073 783 808 bytes. Moreover, chunk-size is not at random: the size of 1 073 880 064 bytes appeared on 3 more occasions. Also is worth checking: dividing sizes with the smallest difference [48,128 bytes] always gives integer. The new biggest I could extract is 1 074 216 960 bytes.
I remain thus expectant – and patient as well.
Both in chunk-size recognition and on treating false time-marker jumps.
Auto-append in the MpegTS demuxer, now restricted to video streams split approximately at GiB boundaries as produced by some devices like action cams, has been re-enabled and should be available for testing in future nightly builds.
I'm jump-ready for testing.
Meanwhile, here is another admlog.zip file, where the unpredictable time-marker behaviour happened twice: at first when dropping the beginning part of the raw source-file, then on trying to mark the end (as described earlier).
Do you always need an append operation to reproduce rewind on stopping playback? I don't think a log will suffice, please provide a sample + exact steps to reproduce.
What you saw was mostly a result of failed seeks due to corrupted video stream so far. The behavior at the boundary of two segments might deserve more attention, however.
Got all sample files, thank you. For the starters, I'm trying to figure out why auto-append in the demuxer wrongly rejects them.
Detection fixed, it was broken for 1 GiB sized fragments due to my really stupid mistake, would have worked starting with 2 GiB.
Now trying to reproduce the seek failure on stopping playback.
No luck with reproducing a seek failure. More or less exact steps to reproduce like at least the approximate time in video where it happend for you would really help.
Nightlies with auto-append for 1 GiB stream fragments fixed are available now.
The misbehavior in the sent sample was at searching for the trimming point, while locating the beginning of the film (which was opened & appended full), with last positioning done by pushing the stop-button. [As a phrased previously: "The unwelcome jump of the time-marker happened right at searching for the actual beginning of the film to be trimmed."]
Though, as I mentioned already, I have found no such thing as exacts reproducibility here. To overcome the inconvenience of unhappy repeating (at slightly different time-points) I applied dragging followed by stepping (rough+fine) instead of play/stop.
Glad to know there are nightlies capable of automatic appending for me again. (Will you keep this feature incorporated from now?) As to go to the test, however, I would need more peace.
Peace indeed. Because, so to speak, I am "north by north" against Court, in a wide-ranging environmental issue, which they sedate to a personal matter striking hard my household. And this affair, closing to a kind of culmination, calls for every TBytes of my nerves capacity.
Thanks again for solving the problem that hampered for a period my archiving.
With the help of the log file you provided, I finally managed to reproduce the issue, thank you. Should be fixed (https://github.com/mean00/avidemux2/commit/3495b2e5a119043e0ddf4c139bc266ea6bbc4897) now, please try a future nightly.
As already suspected, admPreview::samePicture() was unsuitable once the seek to the last displayed (vs last decoded) picture failed. admPreview::nextPicture() may fail too, of course, but it is much more robust.
The issue had nothing to do with append operations or any particular editing steps.
Downloaded your r181112win64 (Nov 12, 2018) nightly at last, and archived 21 films without any disruption.
Auto-append is great again.
I appreciate your commitment.