Recent Posts

Pages: 1 ... 8 9 [10]
91
a9c3ccb            [editor] Try to handle DTS going back in time more graciously in copy mode, accept up to 100 ms A/V desync
ubuntu HWE 16.04.3 LTS 64 bit x86 SMP, QT5, x265 version 1.9: avidemux 2.7.0 171012-64bit HWE Xenial with x265 version 1.9
92
Main version 2.6 / Re: Missing audio on video captured from VLC sometimes
« Last post by mean on October 12, 2017, 08:30:56 AM »
The PAT (= content of the file) is not present very often
I'll add a deeper probe, so that you get the audio

BTW, The file is incorrect from a DVB point of view, but valid as a TS file
Since avidemux is geared toward DVB content, it fails on such files

Anyway, tomorrow's nightly should be able to read the audio part
!dont forget to delete the .idx2 file!
93
Windows / Re: duration of cutting clip
« Last post by eumagga0x2a on October 12, 2017, 07:37:10 AM »
If B-frames are present, additional delay may be added to the video, increasing the total duration.

There is no space below the go-to-marker buttons currently, it is occupied by the "view filtered" checkbox. Moving the checkbox to a more suitable place would allow to display the duration of the selection there.
94
Windows / Re: "Too short" message on perfectly good files
« Last post by eumagga0x2a on October 12, 2017, 07:07:18 AM »
I don't know what  DVXA2 is, but I don't see why accelerating the display is relevant to an editing program such as Avidemux.

This massively saves CPU cycles for stuff like scaling. I'm not sure whether this works with the DirectX video acceleration version 2.0, but with decoding in hardware enabled, it should short-circuit decoding and display, avoiding downloading vast amount of data from the graphics card to the RAM and uploading it back.


95
Main version 2.6 / Re: Missing audio on video captured from VLC sometimes
« Last post by CelticSlayer on October 12, 2017, 07:04:36 AM »
Sorry, new here not sure what that means. I'd say about 6/10 times these recording clips from VLC work fine with a .ts extension and AVC/AAC video/audio. I think since I'm recording from a live internet stream sometimes the audio signature goes out of sync but the track is still there in the container so I'm unsure why Avidemux can't pick it up.
96
Windows / Re: "Too short" message on perfectly good files
« Last post by eumagga0x2a on October 12, 2017, 06:59:55 AM »
Your sample would still be warmly welcome. I don't have a full solution for now. In my sample, the DTS collision happens due to rounding by Avidemux (timestamps are still increasing in the sample, but the values are very close; when rounded, they become identical).

With the rounding logic commented out, saving the sample in copy mode still fails later due to a real DTS collision, which mostly points at a too high frame increment value got by the demuxer.
97
Main version 2.6 / Re: Missing audio on video captured from VLC sometimes
« Last post by mean on October 12, 2017, 06:22:31 AM »
confirmed
No PAT/PMT found
98
Main version 2.6 / Missing audio on video captured from VLC sometimes
« Last post by CelticSlayer on October 12, 2017, 06:05:05 AM »
Hey, sometimes when I load files recorded from VLC player Avidemux doesn't recognise audio. I can work on these files with audio in XMedia Recode, there seems to be a delay but the audio is still there in the editor. This only happens with a few of the recording clips. I've added a sample, thanks for your help.

https://1drv.ms/v/s!AnoJu6P6OB0thhp6tFC13Ey8bZjE
99
Windows / Re: "Too short" message on perfectly good files
« Last post by TCmullet on October 12, 2017, 01:02:57 AM »
I have samples few MiB in size exhibiting the same problem.
Could you please tell how you solve that problem?  That is, how do you reclaim the file, shuffling in whatever way necessary BUT WITHOUT reencoding?  Is there an FFMpeg command that (again, without reenoding) will shuffle things back into proper order so that FFMpeg inside of AVD will not barf at it??
100
Windows / Re: "Too short" message on perfectly good files
« Last post by TCmullet on October 12, 2017, 01:00:17 AM »
Code: [Select]
Percent:7
[adm_lavLogCallback] 19:08:25-205 [lavc] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 31882000 >= 31882000
[FF]Error writing video packet

As expected, duplicated decode timestamps, caught by the bundled FFmpeg which gets actually used when you select MP4 as muxer.
I don't begin to claim to know much about FFMpeg, only that it's been around a long time, is a great standalone tool for those hardy enough to get buried in the muck of specifying parameters in an age of GUIs, AND that it's the core driver (or maybe core functionality would be a better term) underlying many GUI-based programs.

I didn't know that AVIDemux was using it for things.  But I DO know that Replay Video Converter (from Applian), the program that created my file, DOES use FFMpeg to generate/encode to H.264 this file.  So on the surface, I want to ask, how is it that FFMpeg could generate encoded video that would cause an error when the same program (FFMpeg) is used to read the file??

I'd like your thoughts on that, please.  I did google much of the big phrase and found that this has been going on a long time, and that supposedly a bug-ticket has long since been filed with FFMpeg.  But I'll make one more observation...

In this thread,
https://superuser.com/questions/978888/application-provided-invalid-non-monotonically-increasing-dts-in-ffmpeg

the answer given is, "If the files play fine, you don't have to worry about it.  It means that in the input file, the timestamps associated with samples are not increasing monotonically. That shouldn't be the case, but I think that ffmpeg will usually correct these problems on its own.  If you are using an outdated ffmpeg version, updating to a newer one may help resolve these issues, in case it's a problem with the decoder rather than the actual input files."

What I want to observe is this:  This reminds me of what I read about Mpeg encoding years ago with regard to B-frames.  I thought I read it in connection with Mpeg4 (H.264, et al), but it may have been referring to Mpeg2 as well.  The B-frames (as I'm sure you know) are bi-directional predictors, not just prior-frame predictors like the P frames.  Therefore they can point FORWARD in time as well as backward.  This is what makes them so efficiency-producing.  But one of the points made years ago was that the encoder is not required to always write out the frames in chronological order.  As long as the PTSes (presentation timestamps) or DTSes (display timestamps, apparently they are synonyms) are properly attached to the frames to which they belong, it shouldn't matter what order they are written out in.  It's the job of the decoder to decode all the frames within a GOP and then SORT them into timestamp order for output to the player.  So, given this concept, why does any player or muxer care that the frames are not in order?  With regard to a muxer, I would think it's job is to simple shove the GOP out the door.  I'll appreciate any explanation you could give.   (And that's enough questions for one posting.)
Pages: 1 ... 8 9 [10]