Avidemux Forum

Participate => Documentation & Tips => Topic started by: EFuggerth on April 10, 2018, 06:06:48 PM

Title: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on April 10, 2018, 06:06:48 PM
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?
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on April 10, 2018, 06:20:43 PM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on April 10, 2018, 06:52:32 PM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on April 11, 2018, 10:28:24 AM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on April 11, 2018, 11:27:55 AM
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.

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.

Quote
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.]

It has been disabled because it was both severely broken as well as unnecessary for MpegTS. It is mandatory only for DVD structures.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on April 11, 2018, 12:03:02 PM
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?]
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on April 11, 2018, 05:03:13 PM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on April 11, 2018, 09:12:26 PM
At the first glance, the problem of not decodable keyframes is related to this video being interlaced with the bottom field shown first.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on April 11, 2018, 10:01:46 PM
“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”…
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on April 17, 2018, 08:07:07 PM
Newbie to Hero Member:
Something’s up? (Dee-day’s looming…)
Over.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on April 17, 2018, 08:21:41 PM
No, not yet. I don't have time and peace of mind for any non-trivial Avidemux-related work ATM.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on April 17, 2018, 08:58:27 PM
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?]
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on May 11, 2018, 09:44:45 AM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on May 12, 2018, 10:01:57 AM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on May 22, 2018, 06:13:45 PM
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).
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on May 22, 2018, 07:02:14 PM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on May 22, 2018, 07:28:01 PM
While embracing the good news, I beg of Lord this bug not to escalate into buggery.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on May 24, 2018, 07:17:59 PM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on May 31, 2018, 04:35:17 PM
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?
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on May 31, 2018, 10:56:36 PM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on August 03, 2018, 04:20:06 PM
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.

Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on August 03, 2018, 04:36:47 PM
Quote
Though 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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on August 03, 2018, 06:21:20 PM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on August 03, 2018, 09:39:42 PM
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: EFuggerth on August 04, 2018, 02:37:56 PM
Will reflect – soon as material to deal with gathers…
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: 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.
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.
Title: Re: "Flashing sequence of pictures" instead of smooth video resulted...
Post by: eumagga0x2a on August 27, 2018, 06:06:05 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.