<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 6, 2017 at 7:05 PM, Jaka Bac <span dir="ltr"><<a href="mailto:jakabac@gmail.com" target="_blank">jakabac@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Michael,</div><div class="gmail_quote"><br></div><div class="gmail_quote">mpeg2video wants the packets to be segmented in a way that logical things go together and that there is no extra "garbage" at the end.</div><div class="gmail_quote">One problem that you have is that your code will feed mpeg2video with last frame in a GOP and the sequence header of the next gop after it. That is not desired by mpeg2video.</div></div></div></blockquote><div><br></div><div>You're right. I had done some experiments in the meantime and it indeed appears one cannot feed data to mpeg2video codec without segmenting into logical units.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">The other problem that you have is that you are triggering undefined behaviour with this line in your code:</div><div class="gmail_quote">p2 = memmem(p1 + 4, n, "\x00\x00\x01\x00", 4);<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">from address at p1 there is at least n bytes in the buffer if you are doing the calculations correctly (which I think that you do).</div><div class="gmail_quote">but you are searching from p1+4 up n bytes which goes past the end of your buffer. If there are 00 after the end of your buffer memmem might find a "false" start code.</div></div></div></blockquote><div><br></div><div>Yup, I also caught that problem and had already fixed it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">I think that the line in question should be:</div><div class="gmail_quote">p2 = (char*)memmem(p1 + 4, n-4, "\x00\x00\x01\x00", 4);<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Probably you can get away with the first problem (headers of the next gop after end of previous gop) since you feed the sequence headers at the start of the stream to the decoder (the other sequence headers are just repeated values)</div></div></div></blockquote><div><br></div><div>I changed the way I do segmentation, such that sequence and other non-picture-related headers are isolated and fed separately to the decoder. This fixed the pixellation problem. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">All in all, you would be better off with already tested parsers and demuxers from libavformat</div></div></div></blockquote><div><br></div><div>The sample code was just intended to illustrate the problem, it's not production code. The full context is that I'm trying to bridge ffmpeg and ExoPlayer for video decoding. The simple (and wrong) segmentation used in my sample code is based on the way ExoPlayer is segmenting a MPEG2 video stream (H262Reader).</div><div><br></div><div>The starting point was when I tried to use ExoPlayer with the Google software MPEG2 decoder available in Android (since Marshmallow). I observed bad pixellation. ExoPlayer devs put the blame on the MPEG2 decoder from Google. I then integrated ffmpeg with ExoPlayer for video decoding, but I was suprized to observe the same bad pixellation. That's how I ended up writing my sample code, to emulate what ExoPlayer and my ffmpeg integration were doing. Given that both Google's and ffmpeg's decoder show the same pixellation, I bet now that the root cause is ExoPlayer's segmentation.</div><div><br></div><div>Thanks again for your support, that really helped.</div><div><br></div><div>Michael.</div><div><br></div></div></div></div>