[FFmpeg-trac] #1224(undetermined:new): dvb-t to rtmp crash.

[FFmpeg]

#1224: dvb-t to rtmp crash.
-------------------------------------+-------------------------------------
             Reporter:  eregi        |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  unspecified  |  undetermined
             Keywords:               |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by Cigaes):

 Replying to [comment:32 eregi]:
 > So more or less it's the hardware fault and cannot be solved by applying
 somekind of a patch?

 Well, as I said, you could try a faster codec or a smaller resolution. Or
 a lower frame rate, I forgot this one. Or any combination of these
 solutions.

 But no, there is no magical solution: basically, if your computer needs 3
 minutes to encode 2 minutes of broadcast, the data that was received
 during the extra minute needs to be either stored somewhere or discarded.
 And if you store it somewhere, you will get ffmpeg's output lagging ever
 farther behind the broadcast stream '''and''' huge amounts of data
 accumulating.

 > Now this is offtopic, but how to create the dump? You mean just cat the
 stream and then convert it? It would mean that I would have to cat a
 stream for 10 min, then start converting it using ffmpeg and at the same
 time create new dump? Wouldn't work as an automated system..

 This is not for the automated system, this is for tweaking: you cat the
 device into a file for 10 minutes, then you try various combinations of
 ffmpeg options until you manage to find one that can convert the whole
 file in less than eight minutes and has acceptable quality. Once you have
 found it, you can insert it in your automated system.

 > Didn't got your idea from this - "can do the tweaking with a large
 enough dump, you just have to look at the fps field in the status line: it
 must stay way above 30."

 That is for the testing I was referring to in the last paragraph: you do
 not need to run the whole 10 minutes for each set of options you try: if
 after a few seconds ffmpeg prints {{{fps=12}}}, you know it is much too
 slow and you can stop it immediately.

 > Is there a way to make ffmpeg re-start and continue if it closes?

 You could just make a loop in shell: {{{while true; do ffmpeg ...;
 done}}}. Or even better, to avoid the probe time: {{{while true; do cat
 /dev/...; done | ffmpeg -i - ...}}}

 But that would look ugly: a few seconds of videos, then broken frames,
 then a few seconds of video, with a few lost seconds in between, repeated
 infinitely.

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