mkv to HLS streaming fails with some samples in 2.10 v2

Added attachment:

Logs3.zip

For me, it crashes just like #8508 (closed).

update - tested on the official mkv samples. These were all transcoding succesfully (approx 4 weeks ago). now, I get a failure on tests 2,5,7,8. logs attached.

Added attachment:

OfficialTests.zip

tested on windows, so not 100% comparable with my previous tests.

using the 32bit build from 5/may 00:45

When the audio codec is disabled, then all the samples convert perfectly.

With the audio codec enabled (aac, --sout-avcodec-strict=-2) then I get the same failures.

testing on the mac build from the original report, I get the same result, so I guess that points the finger firmly at the audio side of things.

commit 3b0c2208 Author: Ilkka Ollakka ileoo@videolan.org Date: Sun May 5 15:30:55 2013 +0300

avcodec: check if we need to padd last frame

Should Fix [#8539](https://code.videolan.org/videolan/vlc/-/issues/8539)

Original author: ileoo@videolan.org

added Status::fixed label

closed

tested with Mac build from 06-May-2013 01:20 and I'm still getting the same failures.

I may be missing the point regarding last frame, but the issue where these are failing is that there is no output at all, (not that it fails at the end of the encoding).

removed Status::fixed label

reopened

Replying to [comment:6 ConfusedVorlon]:

tested with Mac build from 06-May-2013 01:20 and I'm still getting the same failures.

I may be missing the point regarding last frame, but the issue where these are failing is that there is no output at all, (not that it fails at the end of the encoding).

Which ones are the failures?

Hi,

I just tested with the 2.1 Mac build from 16/6 (revision 1.3.0-git-6793-g0ad07a9d)

I now get almost all fails.

successful tests from the official suite are 1,3,4,6 successful tests from my suite are E,M

there is a partial pass for D and I where VLC does output data, but for some reason, the stream segments are formatted in such a way that the iOS player tries to leap forward to 11.5 hours after processing the start of the first segment. Clearly you can't debug iOS - but there may be an obviously mis-formatted output here.

let me know if you need console output on these.

to clarify: in all the failure cases (except D & I) there is no output at all from VLC.

the errors on the official suite are:

[0x1068008b0] faad generic warning: decoded zero sample
[0x104001ab0] avcodec generic debug: using direct rendering
[0x102408e10] stream_out_transcode stream out debug: drift is too high (1371579927627453), resetting master sync
[0x103e00d60] avcodec encoder error: filling error on encode

my test suite generates a slightly more diverse set of errors!

changed title from mkv to mp4 transcoding fails with some samples in 2.10 v2 to mkv to HLS transcoding fails with some samples in 2.10 v2

Could you try tomorrows nightly builds? I commited few changes in livehttp muxer that could help.

there is a slight change.

for the two strange cases where iOS devices refused to play (jumping to 11.5 hours), they now display position of 4:56:53 when they start, but do actually play. So seeking is broken, but the movie plays.

all the failed transcodes are still fails though.

(tested revision 1.3.0-git-6821-gfbb82370 )

I have created Ticket #8825 (closed) to handle the specific case where iOS is getting the timing position wrong.

changed title from mkv to HLS transcoding fails with some samples in 2.10 v2 to mkv to HLS streaming fails with some samples in 2.10 v2

changed milestone to %Bugs paradize

mkv to HLS streaming fails with some samples in 2.10 v2

Child items ...

Activity