[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):

 @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.

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