Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#2215 closed defect (invalid)

Frodo 12 does not play live matroska stream

Reported by: wargand Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Sorry, I am not sure how to report this bug. My problem: I developed an application, which creates a matroska live stream: http://www.matroska.org/technical/streaming/index.html
From the two different ways to implement a matroska live stream, this one is implemented:

"A live Matroska stream is different than a file, because it may have no known end (only when the client disconnects). For that the Segment must use the "unknow" size (all 1s in the size)."

My app workes perfectly with a couple of TVs and XBMC 11. With XBMC 12 it broke. http://pastebin.com/bpncKfY0 contains the hopefully relevant parts of the xbmc log.

Of course XBMC is not FFmpeg, but I think the av libs are the most likely location for the problem.

Sorry for this very skimpy error description, but this is all I have for now.

Change History (11)

comment:1 by Carl Eugen Hoyos, 11 years ago

Resolution: invalid
Status: newclosed

I expect there is a XBMC bug tracker.

comment:2 by wargand, 11 years ago

Oh, I did not do the report for you, but for my partner. He did not want to believe me that it is useless to contact both the ffmpeg or the xbmc people. If in any project a 3rd party component is used and fails, one does not need to bother to report to either side. The usual result is a responsibility ping-pong. Project: Not our problem, report upstream. Upstream: Not our problem, report on project page.

comment:3 by Carl Eugen Hoyos, 11 years ago

Did you test the Matroska live stream that you create with (current) FFmpeg?

If yes and it did not work: Why did you not report that FFmpeg stopped playing your live stream?
If yes and it did work: Why did you not report the problem to xbmc (which is using a massively patched version of FFmpeg that is approximately a year old)?

If no: Why are you accusing us (me) of not helping you if you are not doing the absolute minimal testing required from everybody reporting bugs here (not only you)?

comment:4 by wargand, 11 years ago

Testing the live stream with the current FFmpeg is a bit difficult. My program connects via UPnP an then starts streaming. To feed it into FFmpeg directly would require some serious work. Problem is, I am currently on a somewhat tight schedule and I don't really see the need. As I said, the old XBMC 11 plays it. All Samsung TVs play the stream. On Android I can stream with BubbleUPnP and the VPlayer. The WD TV Live box also plays the stream. It is no proof, but I think this is a strong hint, that the stream is ok.

And of course, I did report to XBMC first. About a week ago. They ignored it totally. Friendlier: Apparently did not have the time to even look into the report.

I wrote the bug report here because my non-tech partner requested it and he would not have stopped bickering until I did. Sorry about that. If I could have faked the bug report for him I would have done it. I told him what the response would be and he got big eyes, when exactly happened what I predicted.

I am not accusing you, the only thing, which really surprised me and annoyed me a little bit, was how fast the rejection came. Not a single question. Just: Not our problem. Maybe it is not your problem. I am sorry, if I sounded a bit harsh.

Maybe the XBMC guys patched the bug in themselves. And definitely I did not provide an even remotely usable bug report. Also sorry here, but FFMpeg or XBMC are not the most simple and smallest projects. Building up enough knowledge to actually help is tough. See my report as some kind of head start. If it really are the patches, which the XBMC guys applied, you are in the clear. If it is something in your libs, enough commercial products use directly or indirectly FFMpeg, you probably will get proper reports soon enough.

in reply to:  4 ; comment:5 by Carl Eugen Hoyos, 11 years ago

Replying to wargand:

Problem is, I am currently on a somewhat tight schedule

Allow me to say that I consider this sentence (contrary to your earlier message) - that I of course have read often before - quite offensive.

[...]

I am not accusing you, the only thing, which really surprised me and annoyed me a little bit, was how fast the rejection came.

So it would have been friendlier if I waited longer? That does not sound very convincing to me...

Not a single question. Just: Not our problem.

What I should have written is "not enough information" but the very little information you provided indicates a (possible) bug in xbmc.
Please understand that I am *not* claiming there is no bug in FFmpeg, I am just claiming there is no (no in the sense of: not even the tiniest) possibility that this can be fixed - even if by some miracle the bug would be fixed in FFmpeg (I have no idea how given that there is no way to test and no hint what triggers the problem) how would this fix get into xbmc?

Maybe it is not your problem. I am sorry, if I sounded a bit harsh.

Don't worry - see above!

Maybe the XBMC guys patched the bug in themselves.

Allow me to repeat that I do not claim this.
(But did you check if xbmc is using the lavf matroska demuxer at all? I don't know.)

And definitely I did not provide an even remotely usable bug report.

Thank you for clarifying!

Also sorry here, but FFMpeg or XBMC are not the most simple and smallest projects. Building up enough knowledge to actually help is tough. See my report as some kind of head start.

Imo, this start should happen on the mailing list.

If it is something in your libs, enough commercial products use directly or indirectly FFMpeg, you probably will get proper reports soon enough.

I do not easily remember a (both useful or useless) bug report from a commercial product...

Last edited 11 years ago by Carl Eugen Hoyos (previous) (diff)

in reply to:  5 ; comment:6 by wargand, 11 years ago

Problem is, I am currently on a somewhat tight schedule

Allow me to say that I consider this sentence (contrary to your earlier message) -
that I of course have read often before - quite offensive.

Good heavens, why? I am a single developer in a project, which is actually far too big for one person alone. It is very close for a first alpha release, I am still fixing bugs. Suddenly I get a report: I upgraded to XBMC 12, it does not work anymore. Handle it. I just cannot dig into it right now. So I did the next best thing to do: Dumped it before the feet of the XBMC and FFMpeg guys. One of the groupe is from sure the correct recipient and might be interested to learn that somewhere a regression happened. Probably not the nicest thing to do, but offensive?

So it would have been friendlier if I waited longer? That does not sound very
convincing to me...

Perhaps something like: We regularly run unit tests. Matroska live streams are part of those tests and definitely work. It must be private changed the XBMC team did. With this response I could have gone to the XBMC team and could have given them at least something.

Giving bug reports is one thing, but if a project uses parts of another project, I usually don't bother. If you cannot exactly prove where the bug is located or prove beyond doubt, which group introduced the bug, it usually leads to nothing.

What I should have written is "not enough information" but the very little information
you provided indicates a (possible) bug in xbmc.

Maybe. But the XBMC uses your libs. I have no idea how old or how patched. For an outsider to both projects it is not easy to see this.

Please understand that I am *not* claiming there is no bug in FFmpeg, I am just
claiming there is no (no in the sense of: not even the tiniest) possibility that
this can be fixed - even if by some miracle the bug would be fixed in FFmpeg
(I have no idea how given that there is no way to test and no hint what
triggers the problem) how would this fix get into xbmc?

I cannot dig into the code myself. This is way beyond my current skill set. If your tests indicate that there is no problem with my kind of stream, I'd have an answer, when the XBMC team sends me here. If you find something, the bug would still be in XBMC, but then I could also contact the XBMC team and tell them: Look, FFMpeg fixed an important bug here, you have to upgrade your libs.

Maybe the XBMC guys patched the bug in themselves.

Allow me to repeat that I do not claim this.

I am developer myself, I am well aware of that. The problem could be on both ends. But I am foreign to XBMC AND FFMpeg. For me it is totally impossible to come to a meaningful conclusion.

(But did you check if xbmc is using the lavf matroska demuxer at all? I don't know.)

It does. This I can say for sure. I just don't know, which version and I don't know what are their patches.

And definitely I did not provide an even remotely usable bug report.

Thank you for clarifying!

Never claimed anything different.

Imo, this start should happen on the mailing list.

Maybe, but I was not sure, which was the correct mailing list. Nevertheless, I think everything is said.

If it is something in your libs, enough commercial products use directly or indirectly
FFMpeg, you probably will get proper reports soon enough.

I do not easily remember a (both useful or useless) bug report from a commercial product...

I don't know how fast new versions of FFMpeg are included in commercial products. If I were e.g. Samsung and I used FFMpeg in my TVs and it worked, I'd probably skip every upgrade, which does not fix a serious security flaw.

in reply to:  6 comment:7 by Carl Eugen Hoyos, 11 years ago

Replying to wargand:

We regularly run unit tests. Matroska live streams are part of those tests

Afaik, "live" tests are very difficult to implement. (And in this particular case, I have no idea what could be tested.)

[...]

If your tests indicate that there is no problem with my kind of stream

Which tests?
I may miss something, but I have not the slightest idea what I could test to either reproduce this ticket or make it clear it is a bug in XBMC.

[...]

I don't know how fast new versions of FFMpeg are included in commercial products. If I were e.g. Samsung and I used FFMpeg in my TVs and it worked, I'd probably skip every upgrade, which does not fix a serious security flaw.

Since I (incidentally) spent the last night with Samsung source code, I can assure you that you are very wrong about how "commercial" products handle FFmpeg (at least in the case of Samsung).

comment:8 by pross, 11 years ago

@wargand: I suggest you find a way to dump the live mkv stream to a file. (So the file can later be fed into FFmpeg to try and reproduce the bug.)

Without a way to reproduce the bug, we are all wasting our time here.

comment:9 by wargand, 11 years ago

@pross: I see what I can do. But it may take two or three weeks. Faster is really impossible. And maybe, I get a response from the XBMC team till then.

@cehoyos: This really is more for a mailing list. But nevertheless one last answer:

We regularly run unit tests. Matroska live streams are part of those tests

Afaik, "live" tests are very difficult to implement. (And in this particular case, I
have no idea what could be tested.)

Was only an example, what I would have expected. Yes, it is difficult to test. I don't know anything how the FFMpeg team is organized. Is there an expert on live streaming related stuff? Maybe a short question to him: Could it be? Answer: No, the related code did not change for <time interval>. This would have also been an answer I would have easily accepted. Just the very fast 'not our problem' made my think you just read 'xbmc' and immediately rejected it.

I also get bug reports for my programs. Often enough: It crashes. Then I also think: Thanks, great information. And now? But I also know that it is a report of a user of the program and I cannot always expect more. And even if it is a bad error report, a problem is probably there.

But of course, my stuff is tiny compared to FFMpeg. Probably your garbage bin just has to be bigger.

If your tests indicate that there is no problem with my kind of stream

Which tests?

I assumed there might be some. There are not so unbelievable many different methods to create streams. If I developed something like ffmpeg, I would create a helper program, which generates the most common types of streams. Also faulty streams. And a couple of video files. Then I'd set up some kind of cruise control. FFMpeg is an old, big and important project. Is there really no automated testing when the code is changed?

I may miss something, but I have not the slightest idea what I could test to either
reproduce this ticket or make it clear it is a bug in XBMC.

If there are no good test processes, you really have a problem with my report. Maybe I assumed too much. I wrote the code to wrap x264 frames into a matroska container myself. I tested the resulting stream against this program:
http://www.matroska.org/downloads/mkvalidator.html
If now someone comes and tells me that my stream broke, I could retest with this program and confirm the report or have at least an argument that it is most likely not the stream. FFMpeg was playing my stream, your original version might still do. This code did not materialize out of thin air. So it must have been tested once. I thought those test might still exist and would be run regularly. Or could at least manually be triggered, when a report comes in, which hints that there could be a problem in a certain module. Sorry, I know nothing about the FFMpeg development process.

Since I (incidentally) spent the last night with Samsung source code, I can assure you that
you are very wrong about how "commercial" products handle FFmpeg (at least in the
case of Samsung).

Was only an example. I have no idea how this is usually handled. Probably depends on the company.

in reply to:  9 comment:10 by Carl Eugen Hoyos, 11 years ago

Replying to wargand:

Just the very fast 'not our problem' made my think you just read 'xbmc' and immediately rejected it.

This is exactly true.
(It is not true that the very fast answer indicated my reasoning but it is correct that I just read 'xbmc' and immediately rejected it).

But nothing you have written since has made me believe that I could have done anything better.

comment:11 by compn, 11 years ago

we need a sample live mkv stream to test, otherwise we cannot guess the problem.
sorry.

Note: See TracTickets for help on using tickets.