[FFmpeg-trac] #3060(avformat:open): Option to disable "index seek table" and "index table iirc" in NUT muxer

[FFmpeg]

#3060: Option to disable "index seek table" and "index table iirc" in NUT muxer
-------------------------------------+------------------------------------
             Reporter:  mbat         |                    Owner:
                 Type:  enhancement  |                   Status:  open
             Priority:  wish         |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  nut          |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+------------------------------------

Comment (by mbat):

 Replying to [comment:1 cehoyos]:
 >
 \\
 > why don't you use a transport stream
 \\
 If you mean:
 fmpeg -i anyvideo.mpg -vcodec rawvideo -acodec pcm_s16le -f '''mpegts''' -
 | bmdplay -f pipe:0
 This does not work. Even with latest builds.
 \\
 If you mean:
 ffmpeg -i anyvideo.mpg -vcodec rawvideo -acodec pcm_s16le -f mpegts
 udp://127.0.0.1:1400 and then read the stream with some tool.
 This does not work. Even with latest builds (and VLC). And I can see a
 considerable cpu usage (20x compared with pipe solution).
 \\
 If you mean:
 ffmpeg -i anyvideo.mpg -vcodec libx264 [opts] -acodec libvo_aacenc [opts]
 -f mpegts udp://127.0.0.1:1400 and then read the stream with some tool.
 This works. But:
 1. Decklink needs uncompressed frames. It is a non-sense
 decode->encode->decode again if I just need to decode once. Plus you have
 a quality degradation which is not always acceptable for this kind of
 hardware (A. who buys a decklink wants the maximum output quality, B.
 Sometimes you need to analyze SDI output with some instuments so you need
 the original decompressed frame).
 2. High cpu usage when you could use 2% cpu as a maximum.
 \\
 > Is performance really a problem (but bandwidth not)?
 \\
 I'm not obsessed with optimization, but if you can do that with 2% of cpu,
 why doing it with 40%? Plus, using pipes, bandwidth is not a problem.
 \\
 I hope I have been clear enough. Of course I may be wrong on some of my
 considerations, so let me know if something is not correct for you.
 \\
 To summarize, my final goal is sending ffmpeg output to decklink
 decompressing frames just once (and with minimal resource usage). If nut
 muxer could disable index seek tables and iirc, the goal would be reached.
 \\
 Thanks

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