Recent Posts

Pages: 1 [2] 3 4 ... 10
11
Main version 2.6 / Re: Timestamp issues
« Last post by CryGuy on October 11, 2018, 11:22:08 AM »
Quote from: eumagga0x2a on October 11, 2018, 07:50:07 AM
Video begins at 80 ms because the elst says so, Avidemux doesn't mess with it.
Oh, ok. Would you mind letting me know where the value is read from?

Quote
In general, a transition to FFmpeg-like storage of timing info as a fraction is deemed highly desireable. It would require a lot of work however. Patches as always welcome.
OT: In VB, I could support you... ;) (yes, obviously kidding). I could do C(++), but.... that's a different topic.


EDIT: I'm asking such questions because I need transparency. When there are issues, things need to be reproducable for me, but as I'm always confused about the values displayed, it's hard for me to pointpoint the cause of a behavior.
12
Main version 2.6 / Re: Timestamp issues
« Last post by eumagga0x2a on October 11, 2018, 07:50:07 AM »
Video begins at 80 ms because the elst says so, Avidemux doesn't mess with it.

In general, a transition to FFmpeg-like storage of timing info as a fraction is deemed highly desireable. It would require a lot of work however. Patches as always welcome.
13
Windows / Re: Poor Audio Cuts?
« Last post by eumagga0x2a on October 11, 2018, 07:42:11 AM »
Quote from: BatmanLoko9 on October 11, 2018, 12:11:44 AM
Quote from: eumagga0x2a on October 10, 2018, 09:21:44 AM
I actually wanted to encourage to "get hands dirty" and start contributing to shape things to one's liking, at least this is how it worked in my case.
It does seem interesting, but all of it seems way above my head!

This is always this way initially.

Quote
It'd be nice to try and manually restore the older B marker behaviour but I seriously would have no idea how to  ;D

Could you please explain what you exactly mean here? There were zero changes WRT markers affecting deletions after 2.6.20/21 you are using. Earlier changes affected only deletion of a portion of video with the marker B at or after the last frame. The old behaviour made it impossible to delete the last frame.
 
Quote
Quote
The audio blip is a small portion of the previously decoded audio. I tried to fix it, but it turned out to be quite a difficult task. As explained above, play a silent passage in Avidemux directly before starting a save operation which includes re-encoding of audio. This will result in the blip consisting of silence and thus not noticeable.

Do you have any idea why the audio blip is present in 2.7, but not present in 2.6?

No, I am not that familiar with audio code. I am also not sure it was not present in 2.6. This might depend on audio decoder in use and even the audio output (the latter won't affect the saved video, however).

Quote
Is it related to the changes made to follow the principle of least surprise?

Unlikely.

Quote
Sorry, just to be clear, what do you mean by playing silent passages in Avidemux?

The blip consists of the last audio (about ~50 ms in duration) decoded before stopping playback. If playback was stopped during a loud passage in the video, you might get an audible noise in the saved video. If playback was stopped during an almost silent scene, there shouldn't be any perceptible defect.

Quote
if I have to use a workaround each time I want to make a new clip, or if that audio blip is going to be present when I make a clip, the newer versions of Avidemux may unfortunately be unsuitable for me.
I do not want this to be the case, as I think the program is truly fantastic, but should the blips persist it wouldn't really allow me to do what I want to and I may have to stop using it  :'(

As mentioned before, I tried to fix it and failed so far. If the Author of Avidemux doesn't fix this small problem himself, I plan to return to this bug at a later time, once much more important issues are solved. If you need Avidemux to work exactly as you need without workarounds right now, contribute code which fixes this bug (find and pay a capable developer to do it for you) or use another video editor.
 
14
Windows / Re: Poor Audio Cuts?
« Last post by BatmanLoko9 on October 11, 2018, 12:11:44 AM »
Quote from: eumagga0x2a on October 10, 2018, 09:21:44 AM
Absolutely no problem with complaining, thank you for raising the question. I actually wanted to encourage to "get hands dirty" and start contributing to shape things to one's liking, at least this is how it worked in my case.
It does seem interesting, but all of it seems way above my head! It'd be nice to try and manually restore the older B marker behaviour but I seriously would have no idea how to  ;D
 
Quote
The audio blip is a small portion of the previously decoded audio. I tried to fix it, but it turned out to be quite a difficult task. As explained above, play a silent passage in Avidemux directly before starting a save operation which includes re-encoding of audio. This will result in the blip consisting of silence and thus not noticeable.

Do you have any idea why the audio blip is present in 2.7, but not present in 2.6? Is it related to the changes made to follow the principle of least surprise? It just seems strange to me, and unfortunately my use for Avidemux requires lots of precise cuts like this. Sorry, just to be clear, what do you mean by playing silent passages in Avidemux? Is that something that is easy to do and replicate?
As I said, I use Avidemux for stuff like this constantly, so if I have to use a workaround each time I want to make a new clip, or if that audio blip is going to be present when I make a clip, the newer versions of Avidemux may unfortunately be unsuitable for me.
I do not want this to be the case, as I think the program is truly fantastic, but should the blips persist it wouldn't really allow me to do what I want to and I may have to stop using it  :'(
 
I still look forward to the new nightly, and I'm incredibly appreciative you took the time and effort to not only look into this, but fix it as well, You're great, it's just that the blip doesn't seem like it'd be easy to workaround if I'm making multiple cuts at a time.
 
Quote
If the green flash bothers you, disable DXVA2 display and use the OpenGL (QtGl) output (or feel encouraged to fix the issue yourself!). I get a brief initial corruption when initializing playback using VDPAU as well, but this doesn't bother me. This stuff is not on my todo list.

I'll try this, thanks. It doesn't bother me too much either, it just seems more noticeable on 2.7 than it was on 2.6 so I thought maybe it was something on my end.
15
Main version 2.6 / Re: Timestamp issues
« Last post by CryGuy on October 10, 2018, 05:04:23 PM »
Thanks for looking into it.

Quote
The elst says to advance audio by 66 ms relative to video beginning at 80 ms = 80+66 = 146 ms video delay.
As the PTS of the first video frame is 0, the video beginning at 80 ms is due to shifting all values by +80 ms because of compensating the negative -80 ms DTS value, right?
I don't find the 66 ms for the audio stream. AVStream.start_time is 0. Probably I'm looking at the wrong place. However, I'm assuming it's correct what you say, so the 146 ms make sense now.
Thanks.
16
Main version 2.6 / Re: avidemux works fine but trying the same with ffmpeg don't
« Last post by manbau00 on October 10, 2018, 04:54:48 PM »
Fine, hopefully you find it.

At the moment I use ffmpeg to cut the ts files.
17
Main version 2.6 / Re: Timestamp issues
« Last post by eumagga0x2a on October 10, 2018, 03:34:15 PM »
With a build from the current git master, I get 160 ms as PTS of the first frame, with DTS = 80 ms as specified in the elst atom for the video track for "Another sample.mp4".

Quote
There is no reason to show 0.146 for the first video frame. It is 0.08.

The elst says to advance audio by 66 ms relative to video beginning at 80 ms = 80+66 = 146 ms video delay.
18
Main version 2.6 / Re: Timestamp issues
« Last post by CryGuy on October 10, 2018, 12:49:49 PM »
Another Sample:
https://mega.nz/#!T5YxRY7T!HhA15FX4mesntqiH4wN6uMd4dgoOufYqdA3X7Xxy4js

There are negative DTS values this time, but even if you shift all time stamps to fit into the uint64 range, I don't understand the value 2.081 s being displayed for the first frame. But as I said, if this might change in the next build, I'm gonna wait for it.
19
Main version 2.6 / Re: Timestamp issues
« Last post by CryGuy on October 10, 2018, 09:40:13 AM »
Samples already linked in my first post. See "Video and audio.mp4".

Dumped values see attachment.
There is no reason to show 0.146 for the first video frame. It is 0.08.



20
Main version 2.6 / Re: Timestamp issues
« Last post by eumagga0x2a on October 10, 2018, 09:26:01 AM »
Quote from: CryGuy on October 09, 2018, 09:57:30 PM
I understand that shifting is necessary to avoid negative values due to the unsinged data type, but in the sample files, there is no negative PTS (and no negative DTS), hence nothing needs to be shifted IMO.

It would be necessary to have access to this sample then (the biggest sample video has been 7 GiB in size so far). At the very least, you could post the portion of admlog.txt related to parsing the container.
Pages: 1 [2] 3 4 ... 10