Pass 1 time remaining / stops responding

Started by TimW, November 27, 2016, 12:02:16 PM

Previous topic - Next topic

TimW

Quote from: Jan Gruuthuse on December 08, 2016, 12:59:35 PM
Quote from: TimW on December 08, 2016, 12:18:33 PM

ssd is setup correctly? no temp writing on (Crucial_CT500MX)


I'm afraid you will have to excuse my ignorance on that point.  Are you referring to an Avidemux setting regarding where it stores temporary/work files?  Or to something more generic to do with windows?  If you can give me a pointer as to what it is I need to check I shall certainly do so.

eumagga0x2a

Quote from: TimW on December 08, 2016, 01:35:12 PM
Quote from: Jan Gruuthuse on December 08, 2016, 12:59:35 PM
ssd is setup correctly? no temp writing on (Crucial_CT500MX)

I'm afraid you will have to excuse my ignorance on that point.  Are you referring to an Avidemux setting regarding where it stores temporary/work files?  Or to something more generic to do with windows?  If you can give me a pointer as to what it is I need to check I shall certainly do so.

In an unrelated topic http://avidemux.org/smif/index.php/topic,17296.0.html 2-pass encoding using the HEVC encoder failed because some code specific to the x265 plugin converted paths to files containing the first pass stats from utf8 to ANSI on Windows in a bad way. This is not what we see here.

Could you please comment on the following?

[updateLoaded] 08:29:53-069  conf updated
[deleteSegments] 08:29:53-069 Clearing a new segment
[addSegment] 08:29:53-070 Adding a new segment
[updateStartTime] 08:29:53-070 Using pts2=00:00:00,320 to get dts, as this video does not start at zero
[addSegment] 08:29:53-070 Adding a new segment
[updateStartTime] 08:29:53-070 Using pts2=00:00:00,320 to get dts, as this video does not start at zero
[addSegment] 08:29:53-072 Adding a new segment
[updateStartTime] 08:29:53-072 Using pts2=00:00:00,320 to get dts, as this video does not start at zero
[addSegment] 08:29:53-076 Adding a new segment
[updateStartTime] 08:29:53-076 Using pts2=00:00:00,320 to get dts, as this video does not start at zero
Adding Filter changeFps -> 5...
[ADM_vf_addFilterFromTag] 08:29:53-085 Creating video filter using tag 5


How do you arrive at this segment layout? Did you append the same file to itself twice? What is the changeFps filter doing here?

Decoding errors might be significant because every second frame fails to decode.

Releases prior to 2.6.15 could not use hardware accelerated decoding and display on Windows, this is why you always see "Lavcodec" as decoder and "RGB" as display with 2.6.11.

There is no direct cue about the reason of the hang in the log IMHO. Maybe the hang is the result of running out of memory due to a memleak? This would explain why it doesn't happen with short videos.

Jan Gruuthuse

Quote from: TimW on December 08, 2016, 01:35:12 PM
I'm afraid you will have to excuse my ignorance on that point.  Are you referring to an Avidemux setting regarding where it stores temporary/work files?  Or to something more generic to do with windows?  If you can give me a pointer as to what it is I need to check I shall certainly do so.
SSD: https://www.cnet.com/how-to/how-ssds-solid-state-drives-work-increase-lifespan/

TimW

Hi eumagga0x2a.  I'm really sorry but I'm afraid I don't know what you mean by segment layout.  However what I can tell you is that there is no appending going on here, though there is some cutting, to remove adverts.  The change fps filter is required because Avidemux incorrectly sees interlaced PAL DVB-S HD broadcast input as being 50 frames per second.  In fact such input is 50 fields per second, equating to 25 interlaced frames.  If you don't put the change fps filter in there the output comes out as 50 frames ps and this confuses hardware players quite badly as it is not Blu-ray compliant.  As a result the encoded files won't play on blu-ray players (though they will usually play in software).  The fps filter overcomes this (thanks to Aquar for telling me this).  This might be related to why every second frame (or perhaps every second field?) fails to decode?  However if the recode does actually finish, the output is 25 frames per second and is fine and plays correctly in both hardware and software.  Hope this answers your question.  Thanks also for the info about versions - I intend to try v2.6.14 when I get chance, which will give me the most up-to-date version that does not use hardware decoding.  Much obliged.

eumagga0x2a

#19
A video is internally represented in Avidemux as a collection of video segments. These segments may originate from the same or from different (but compatible) video files.

The delete operation ("cut" is "copy to clipboard" + "delete", "delete" is just delete) got deleted from the log then :)

If the source is interlaced, you should not reduce fps but insert a deinterlacing filter instead (yadif should be the best). This is computationally very expensive but better than just dropping every second field.

I would strongly advise against any version prior to 2.6.15. You can always disable hw accel (both decoding and display, independently from each other) in 2.6.15, this is not an issue.

edit: Please watch the memory consumption of Avidemux during encoding.


mean

you should use resample fps instead of change fps

eumagga0x2a

Quote from: mean on December 08, 2016, 06:00:13 PM
you should use resample fps instead of change fps

After yadif or just alone? (I don't have 1080i samples to test, unfortunately)

TimW

There is usually no need to use a de-interlacer at all if the source is broadcast PAL DVB-S HD interlaced video.  If you remove the interlaced flag in Avidemux x264 settings it will produce progressive output anyway.  Since broadcast HD PAL video these days is usually artificially interlaced by creating each pair of fields from the same source frame, the resulting progressive frame will be fine.  However, if you want it to play back on a Blu-ray player, you then have to also set the "fake interlaced" flag to get the player to play the stream (though some will play it anyway).

As mean says, you do need to use the filter.  Apologies if I caused confusion with nomenclature.  The filter needed is called "Change FPS".  To use this you have to set a fps for both source and output, but in this case they both need to be set to 25.  This is because the source is really 25fps to start with, but the interlacing causes Avidemux to mistakenly believe it is 50fps.  Confusingly the sub-heading of this filter says "resample from X to Y fps".  The other fps filter is called "Resample fps" and it is therefore easy to confuse the two.  If you don't use the "Change FPS" filter the output will incorrectly be identified by mediainfo as 50fps.  It might play anyway depending on your player, but more importantly on a two-pass encode with a target filesize, the filesize will only be half what you wanted it to be, with correspondingly lower quality.

Returning to the crashing problem, I have gone back to 2.6.15 from the latest nightly build.  I will do some further experiments with settings to see if turning off hw decoding can be made to run as smoothly as on 2.6.11 and report back my findings in due course.

TimW

FPS update: Based on some tests I just did the "Resample fps" filter (set to 25) produces output indistinguishable (by mediainfo) from using "Change fps" with both source and destination set to 25.  Both filters also result in correct file size (if you don't use either of them, two pass with target file size, the output will only be half the expected size).  I should be grateful if someone could clarify whether there is any reason to prefer "resample to 25" over "change fps with both source and destination set to 25" in this particular circumstance (clearly they are radically different if the frame rate is actually being changed).  Very sorry if this has taken us off topic, but I am currently running the crash tests as well.

eumagga0x2a

Observing the memory consumption by Avidemux would save a lot of time and be much more useful as "crash tests". Why do you re-encode the video stream in the first place? Usually remuxing the transport stream into MKV suffices.

Could you please provide a 1080i sample (~5 minutes in duration should be enough) cut from such a .ts file for me to play with?

If Avidemux is not able to tell interlaced videos from progressive with twice as high fps, this is an issue, sure. I just don't know if and how this can be detected.

Does the indistinguishable by MediaInfo output remains indistinguishable when loaded in Avidemux?

Jan Gruuthuse

1080i 25FPS, there is also 30FPS (USA). Don't have access to these.
ID                                       : 2050 (0x802)
Complete name                            : /home/jan/Upload/avidemux/20161209 1015 - BBC One HD - bbc one HD 5 minutes.ts
Format                                   : MPEG-TS
File size                                : 287 MiB
Duration                                 : 5 min 0 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 7 995 kb/s

Video
ID                                       : 5400 (0x1518)
Menu ID                                  : 6941 (0x1B1D)
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : 27
Duration                                 : 4 min 59 s
Bit rate                                 : 7 148 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 FPS


DVB-S2 recording:
Files (287 MB total): 20161209 1015 - BBC One HD - bbc one HD 5 minutes.ts
Will be deleted on: 16 December, 2016
Download link: https://we.tl/8Mztbj2iSh

TimW

Observing memory consumption: Is there a way to log it?  I'd rather not sit and watch it, and I wouldn't really know what I was looking for.

Why recode?: To place on blu ray disc.  Broadcast h264 streams are not blu-ray compliant, and won't play in most hardware players.  Mainly because there are too many B frames, see this thread: http://avidemux.org/smif/index.php/topic,16163.0.html

Sample: See Jan Gruuthuse's previous post. 

Interlaced v progressive: According to Aquar, the developers are already aware of the quirk where 2.6.x interprets interlaced fields as frames, doubling the frame count.  Since there is a very simple workaround with the filter it's probably not a priority, although I can't speak for them.

Different filters: yes, I can't see any difference between the two in either media info or avidemux.  There may however be some difference during encoding, but that's well beyond my expertise I'm afraid.


mean

Resample fps will output what you ask for whatever the input , it will not shorten or lengthen the speed / duration
Change fps is somewhat different, it may change speed or duration or not

For your use case, resample fps is more suited

TimW

Hi mean.  In cases where a true frame rate change is needed, or you want to speed up/slow down the video, then I can see that the two filters do completely different jobs.  In the current case though, where we are not truly changing the frame rate but merely overcoming the field/frame quirk such that in reality both the input and output are 25 frames per second, both seem to produce the same result.  This is so both visually (to my eye at any rate) and according to mediainfo and so on.  I am curious and so should be extremely grateful if you could expand, if only for completeness, on whether there is some technical reason (stability? speed? quality?) to prefer "resample fps" over "change fps" in these particular circumstances, when superficially they produce the same result.  Many thanks.

mean