[FFmpeg-trac] #2215(undetermined:closed): Frodo 12 does not play live matroska stream

[FFmpeg]

#2215: Frodo 12 does not play live matroska stream
-------------------------------------+-------------------------------------
             Reporter:  wargand      |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
              Version:  unspecified  |  undetermined
             Keywords:               |               Resolution:  invalid
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by 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.

 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.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2215#comment:6>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker