"Flashing sequence of pictures" instead of smooth video resulted...

Started by EFuggerth, April 10, 2018, 06:06:48 PM

Previous topic - Next topic

eumagga0x2a

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.

EFuggerth

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.

eumagga0x2a

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.

EFuggerth

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).

eumagga0x2a

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.

eumagga0x2a

Got all sample files, thank you. For the starters, I'm trying to figure out why auto-append in the demuxer wrongly rejects them.

eumagga0x2a

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.

eumagga0x2a

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.

eumagga0x2a

Nightlies with auto-append for 1 GiB stream fragments fixed are available now.

EFuggerth

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.

eumagga0x2a

With the help of the log file you provided, I finally managed to reproduce the issue, thank you. Should be fixed 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.


EFuggerth

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.