2017-02-03 18:16 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>:

> 2017-02-03 16:54 GMT+01:00 Ivo Andonov <ivo.ando...@gmail.com>:
> > 2017-02-03 16:59 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>:
>
> >> The encoder sets no user data, so identification is not as simple as
> >> hoped: How do subsequent frames start? Do you know what the
> >> first bytes mean?
> >>
> > Yes, no user data is set and as such automatic identification is not
> > possible. The raw stream coming from the DVR is prefixed by a propriatory
> > frame header (that I filter) which is not MPEG stream compliant and is
> > meant for the viewer/recorder (timestamp, keyframe flag, frame data size
> > etc).
>
> How would another owner of this DVR get the streams?
>

Now that is a separate question. If it has to be integrated in the ffmpeg
suite, I can provide a PHP script that connects to the DVR and fetches the
stream. This can be used by someone to write a libav protocol I suppose. I
just do not feel like too much experienced to program it in C and integrate
it in ffmpeg. Let me know if I should open a new thread for this.


>
> > So far I'm attempting to implement the decoding by explicitly specifing
> to
> > ffmpeg the video codec to use (-vcodec xvid_alogics).
>
> An easier solution is to define a new "bug" in libavcodec/options_table.h.
>

Carl, thanks for opening my eyes on this! Of course that's a much easier
and neater solution. I just plunged into the source code and a lot of
things of the overall workings are unknown to me.
Works as expected!

Excuse my ignorance on this, but how are these options specified via the
libavcodec api when opening a decoder context?



> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to