News:

--

Main Menu

Avidemux2.7.9-dev version (old thread)

Started by butterw, February 17, 2021, 10:34:23 AM

Previous topic - Next topic

eumagga0x2a

Thank you for testing, I don't have a theory at the moment. At least it is proven that new atom types written by very recent libavformat are not related to the issue. For a strict comparison, a test with FFmpeg 4.4 would be necessary (latest git is ahead of 4.4, of course), in case something was different in 4.4 only.

Just curious: does PS3 accept mp4 files without audio? If yes, does the error persist when no audio track is present?

Anon40213

It does accept mp4 without audio.

Can't check right now.

Anon40213

Mkv source muxed in may 10 build to mp4 with the audio removed works so it is the audio.

eumagga0x2a

A next guess. There is a minor (39 ms) discrepancy between the duration of the audio track in the media header (mdhd) vs the edit list (elst) atom in the MP4-MAY sample, I've uploaded the MP4-MAY sample renamed to MP4-MAY-audio-mdhd-patched.mp4 with the duration in mdhd at offset 0x10FFD2C modified to match the MP4-APRIL sample: https://we.tl/t-NK3eS8lBu2.

Anon40213

Still has the error.

[muxerMp4] Fix audio tracks in German language tagged as English when saving to MOV

Even if it seemingly makes no sense to do, I think it's worth a try muxing a file without that commit.

eumagga0x2a

Quote from: Anon40213 on May 30, 2021, 09:32:28 AMStill has the error.

I'm out of ideas.

Quote from: Anon40213 on May 30, 2021, 09:32:28 AM[muxerMp4] Fix audio tracks in German language tagged as English when saving to MOV

Even if it seemingly makes no sense to do, I think it's worth a try muxing a file without that commit.

This commit affects the MOV muxer only, the preprocessor define

#ifdef MUXER_IS_MOV
...
#endif

means that the compiler doesn't get to see this code at all when building the MP4 muxer and thus MUXER_IS_MOV is not defined. This is not seemingly, it simply makes zero sense to suspect any link to the issue, period.

butterw

#126
Feedback on 210611
! [Filter Manager] If there is as single disabled filter, the preview still shows this filter applied. The workaround is too manually add a Misc/Dummy filter.

The new cut point display feature is a great new feature.
! It doesn't seem to take into accounts cuts done to the start of the video.

! However, the unused Search for previous black frame buttons should be removed.

The button I'm most likely to use is `go to First Frame`, adding buttons effectively shifts the position I know
>> this makes this version unusable for me because of this (toolbar buttons can still not be customized without recompiling).

Also worth considering: Too many similar buttons >> confusing interface.
The main strength of Avidemux IMO is its simple interface, make sure you keep it that way with any changes.

szlldm

Quote from: butterw on June 12, 2021, 09:49:09 PM! [Filter Manager] If there is as single disabled filter, the preview still shows this filter applied. The workaround is too manually add a Misc/Dummy filter.

Preview always show the selected filter's output. If you open preview on a disabled filter, the title of the preview's window explicitely shows "Preview / DISABLED filtername".

Quote from: butterw on June 12, 2021, 09:49:09 PM! It doesn't seem to take into accounts cuts done to the start of the video.
You can always jump to the begining anyway.

Quote from: butterw on June 12, 2021, 09:49:09 PM! However, the unused Search for previous black frame buttons should be removed.

The button I'm most likely to use is `go to First Frame`, adding buttons effectively shifts the position I know
>> this makes this version unusable for me because of this (toolbar buttons can still not be customized without recompiling).

Black frame search buttons could be placed after Go to first/last frames buttons.
IMHO using Home/End buttons is way faster.



butterw

Quote from: szlldm on June 12, 2021, 11:43:57 PM
Quote from: butterw on June 12, 2021, 09:49:09 PM! It doesn't seem to take into accounts cuts done to the start of the video.
You can always jump to the begining anyway.
The suggestion is to add a red mark at the beginning so that I know I made a cut there.

Quote from: szlldm on June 12, 2021, 11:43:57 PM
Quote from: butterw on June 12, 2021, 09:49:09 PMThe button I'm most likely to use is `go to First Frame`, adding buttons effectively shifts the position I know
>> this makes this version unusable for me because of this (toolbar buttons can still not be customized without recompiling).

Black frame search buttons could be placed after Go to first/last frames buttons.

That's 12 Arrow buttons in the toolbar with only the 2 marker buttons as separator.
These unused Black frame search buttons should be removed, at least until the toolbar is made customizable.

eumagga0x2a

Quote from: butterw on June 13, 2021, 12:35:02 AMThe suggestion is to add a red mark at the beginning so that I know I made a cut there.

I think it works as intended = no red marks at locations other than boundaries between two segments. Imagine, you run a project script and add a single segment. Did you make a cut if the start time in addSegment() is non-zero?

Quote from: butterw on June 13, 2021, 12:35:02 AMThese unused Black frame search buttons should be removed

They are not unused.

However, I think they are seldom used and the function is accessible via the Go menu, so I would support removing them from the navigation widget (as to me, I prefer not to click, so that the placement of buttons doesn't matter when keyboard shortcuts are provided).

Anon40213

QuoteStill has the error.

QuoteI'm out of ideas.

Thought I would share that I encountered it outside of any avidemux use.  I grabbed a dailymotion video via hls and left it as is.

butterw

Quote from: eumagga0x2a on June 13, 2021, 09:00:06 AM
Quote from: butterw on June 13, 2021, 12:35:02 AMThese unused Black frame search buttons should be removed

They are not unused.

However, I think they are seldom used and the function is accessible via the Go menu, so I would support removing them from the navigation widget (as to me, I prefer not to click, so that the placement of buttons doesn't matter when keyboard shortcuts are provided).

- Previous Black Frame: Error (titled Info) "BlackFrame" "this feature is unsupported at the moment"
- Next Black Frame: this can work in some case, but it doesn't have a configurable tolerance for what constitutes a black frame, and also is not fast enough(ex: 150fps @720p).
- Go to next Prev/Next Cut Point is a more useful feature
- Given that these search for Black Frame actions are also available in the Go Menu, they should be removed from the toolbar until the buttons are made user configurable.

 

butterw

Quote from: eumagga0x2a on June 13, 2021, 09:00:06 AM
Quote from: butterw on June 13, 2021, 12:35:02 AMThe suggestion is to add a red mark at the beginning so that I know I made a cut there.

I think it works as intended = no red marks at locations other than boundaries between two segments. Imagine, you run a project script and add a single segment. Did you make a cut if the start time in addSegment() is non-zero?


The tooltip is labelled: "Go to the previous Cut Point", so yes if I've made a cut at the start of the video, it should go to the start of the video.




szlldm

Quote from: butterw on June 13, 2021, 08:44:40 PMThe tooltip is labelled: "Go to the previous Cut Point", so yes if I've made a cut at the start of the video, it should go to the start of the video.

Actually removing portion of the video at the start or at the end, is not cutting, but trimming. So the button works exactly as the tooltip suggest  ;D

butterw

There's a stronger argument for that than for shifting well established toolbar button positions.

I would personally prefer having a marker at the start or at the end if a trim was made.
Visualizing where edits have been done is the main new added feature for me.