Pass 1 time remaining / stops responding

[eumagga0x2a]

Jan, thank you very much for the sample. The first thing which attracts attention is Avidemux often navigating to P-frames instead of I-frames as next/previous keyframe (pressing UP or DOWN). Is this a result of misdetection (or lack of detection) for interlaced frames?

To workaround misdetection, I close the video after it has been indexed (this is only applicable to transport streams) and edit the .idx2 file correcting the value for "Fps" and "Interlaced" accordingly, then load the stream again. Now it can be processed without need to insert a filter. The whole is definitely worth fixing, there should not be any need for a workaround (ffprobe gets or guesses the fps right).

WRT to archiving on bluray, I'd avoid this due to being a legacy technology and a huge waste of resources on top of some quality loss.

WRT to observing memory consumption, http://stackoverflow.com/questions/69332/tracking-cpu-and-memory-usage-per-process seems to match the requirements.

[Jan Gruuthuse]

Jan, thank you very much for the sample. The first thing which attracts attention is Avidemux often navigating to P-frames instead of I-frames as next/previous keyframe (pressing UP or DOWN). Is this a result of misdetection (or lack of detection) for interlaced frames?

Mean can probably enlighten you more on P-frames instead of I-frames. (I remember something about pseudo frames when the switch was made from frame based to times based avidemux editor).

[mean]

First field is an intra, 2nd is not

[TimW]

Thanks all, especially mean and Jan for the help provided so far.  In my latest tests 2.6.15 with hw acceleration disabled did manage to complete a full recode of a 2hr file.  With hw enabled, it failed 12 times out of 12 attempts, usually on the second pass.  With hw disabled, I had to set video display to Qt to get it to work, but this may have just been coincidence as sample size is so small.  I now have a workable solution with 2.6.15, so that's great.  On the grounds that I am pretty much up and running I probably won't be posting to this thread again but I am so grateful for you all getting me to this point and for the clarification on the side-issue of the filters.  Many thanks.

[eumagga0x2a]

First field is an intra, 2nd is not

Sure, but how does Avidemux (more precisely ADM_Composer::searchNextKeyFrameInRef) end up with a P-frame while looking for an intra? It is not like it were just one field off: there is really no keyframe next to such a P-frame.

[mean]

Just a guess but if Field 1 is intra and field 2 is P, it needs to decode both to get an image
The last decoded stuff is a P (2nd field)

[eumagga0x2a]

Wouldn't all keyframes get marked as P-frames then, would they? This is not the case. Some are true I-frames and saving a video in copy mode starting with such a frame results in a perfectly playable cut. Navigating with the UP or DOWN key to a "keyframe" marked as P and starting there results (as expected) in garbage when saved in copy mode.

[mean]

Depends if the 2nd field is a P or a I
Just a guess

[eumagga0x2a]

Is it possible that the 2nd field is an intra?? This would complicate the things a lot. Did you have a chance to look at Jan's sample?

[mean]

nothing prevents it from it afaik
no time to look at it yet

[mean]

There was a slight buffer overflow
Today's nightly *MIGHT* be better

[eumagga0x2a]

Unfortunately, not yet. By the way, the number of frames reported in ADM_Composer::searchNextKeyFrameInRef at line 200 of avidemux/common/ADM_editor/src/ADM_edSearch.cpp is also rather off (amounts to ~40fps) for the sample.

[mean]

2 different issues here
* 2 pass that seems to be stalling (or is stalled)
* Seeking on mixed type fields

Only the 1st one has been maybe fixed

[feelingshred]

Sorry for reviving old topic but when the developers of the program don't do something, we have to share the valuable info. I was just having crash after crash using the more recent version of avidemux, then I switched back to v2.5.5 (because it was the most downloaded of the old versions on sourceforge), and now I finally can convert my h264 video again without crashes and without weird artifacts on screen. I don't know what they tried to do with version 2.6.x but it's clearly not working.
To everybody out there, I strongly recommend using avidemux version 2.5.5 .
--- Thanks for sharing the solution of going back to 2.5 ---

[Jan Gruuthuse]

Looks clearly like a user error to me. avidemux branch 2.6.x does what it should supposed to do.