Opened 8 years ago

Closed 8 years ago

#5250 closed defect (fixed)

ffserver streaming broken in 3.0/master but worked in 2.8.6

Reported by: oviano Owned by:
Priority: important Component: ffserver
Version: git-master Keywords: regression
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I've yet to be able to stream anything via ffserver with the recent code.

Steps to reproduce:

  1. build ffmpeg/ffserver/ffplay from git master
  2. configure ffserver with attached ffserver.conf
  3. launch ffserver as shown in attached "ffserver.out"
  4. launch ffmpeg as shown in attached "ffmpeg.out"
  5. launch ffplay as shown in attached "ffplay.out"
  6. observe that nothing is displayed by ffplay
  7. press control+c to exit ffmpeg
  8. observe the change in ffplay's output
  9. press control+c to exit ffplay
  10. press control+c to exit ffserver
  11. build ffmpeg/ffserver/ffplay from git release/2.8
  12. launch ffserver as shown in attached "ffserver_2.8.6.out"
  13. launch ffmpeg as shown in attached "ffmpeg_2.8.6.out"
  14. launch ffplay as shown in attached "ffplay_2.8.6.out"
  15. enjoy Shaun The Sheep :o)

Additional notes:

I also spent considerable time building different versions of ffserver/ffmpeg/ffplay to try and establish when this regression was introduced.

The last working version I have found is this one in November 2015:

git checkout c03ffe1712e65b2f18d090d34db95ef18340bd0e

Unfortunately the next commit after the above introduced a segfault in ffserver (which was presumably later fixed) and subsequent commits after that either segfault or won't build at all, which could be masking the commit that causes the issue I am reporting. At this point I thought it more productive to file a bug report so a developer can reproduce the problem.

I can provide the sample file if required, but I was able to reproduce the problem with another unrelated video file so hopefully this won't be necessary.

My system:

Intel NUC 54350WYK with 8MB RAM
Ubuntu 15.10 new install, all updates
Latest Intel Graphics Installer 1.4.0

Attachments (2)

ffserver.conf (288 bytes ) - added by oviano 8 years ago.
logs.tar.gz (896.0 KB ) - added by oviano 8 years ago.

Download all attachments as: .zip

Change History (13)

by oviano, 8 years ago

Attachment: ffserver.conf added

by oviano, 8 years ago

Attachment: logs.tar.gz added

in reply to:  description comment:1 by Carl Eugen Hoyos, 8 years ago

Keywords: regression added
Priority: normalimportant

Replying to oviano:

The last working version I have found is this one in November 2015:

git checkout c03ffe1712e65b2f18d090d34db95ef18340bd0e

Unfortunately the next commit after the above introduced a segfault in ffserver (which was presumably later fixed) and subsequent commits after that either segfault

Which commit fixed the segfault that you claim was introduced in 611c22140a54db0baa863b26368e12d3a1d8267e ?

comment:2 by oviano, 8 years ago

I don't know but here are the ones I checked and what I found:

git checkout 6248f23859eb610079b1964e5f081ff0e9c62281 CR
#git checkout b1a32429ef6ccd94673e4c36924ad0949f4d50a1 CR
#git checkout 58d32c00beef237ffff56bd61a5fdc99057161a6 CR
#git checkout 9b9c9ef3b42116e7ad2111fc8145f4eca12d657b CR
#git checkout 7b2211bfc4b0c4568180a8db2478023c42d9ff51 WB
#git checkout b5f963bfec1f452c37eee900c7b11f065d10dd60 WB
#git checkout 303f931938c618668f7f83c646a1850bef84641e WB
#git checkout e25cac50e05d29a15d7a52c01c394ba913c97aee WB
#git checkout 73b03249133d6631520089798087cbd963eed9ca WB
#git checkout 5f2c8315b3c1b28da0386fddb118ad6a0ed77a0c WB
#git checkout 29b17528612c8b0f66e6982ab48cc0816e41f36f WB
#git checkout e6459c655e110cd9acb5d0658d89c415eaca847b WB
#git checkout 1d62ee38894afb696674db78cee8f8d89204a8fe WB
#git checkout 2ec18db75cff03a5cfa0a0f28f22da6866f720d1 CR
#git checkout 351e625d60165be67c362af6e96ead6c9262623f CR
#git checkout 611c22140a54db0baa863b26368e12d3a1d8267e CR
#git checkout c03ffe1712e65b2f18d090d34db95ef18340bd0e OK
#git checkout 2905c512044807567fc93402f7b3d6dca3552ce6 OK

CR - ffserver crashed with segfault
WB - wouldn't build
OK - worked correctly

So I haven't yet got as far as narrowing it down precisely.

However I do know that this one...

#git checkout git rev-list -n 1 --before="2016-01-01 00:00" master

...builds and doesn't crash, but exhibits the problem I'm reporting.

comment:3 by Carl Eugen Hoyos, 8 years ago

Do you know about git bisect?
To find the change fixing the crash, use 6248f238 and 7ea2db6e as starting points.

The commits you list above do not help, they are all from the same day.

comment:4 by oviano, 8 years ago

Thanks, I will learn about git bisect.

Sorry the above doesn't help, just giving you what I have. It was late :)

I can work back from the 2016-01-01 commit above if that will help you?

in reply to:  4 comment:5 by Carl Eugen Hoyos, 8 years ago

Replying to oviano:

I can work back from the 2016-01-01 commit above if that will help you?

Please use git bisect instead.

comment:6 by Carl Eugen Hoyos, 8 years ago

$ git checkout master
$ git bisect start
$ git bisect bad
$ git checkout 6248f238
$ ./configure && make

confirm that it crashes and use good if it crashes!

$ make distclean && git bisect good
$ git checkout 7ea2db6e
$ ./configure && make

confirm that it does not crash and use bad for the non crashing version!

$ make distclean && git bisect bad

Now continue with building, testing and using make distclean && git bisect good or make distclean && git bisect bad until git tells you which commit introduced the "regression" (which is actually the fix for the crash), remember to use good if it crashes and bad if it does not crash. If a version does not build, use git bisect skip.

comment:7 by oviano, 8 years ago

Ok, will do.

Are you able to reproduce my bug?

comment:8 by oviano, 8 years ago

So the crash referred to in my bug report was fixed with the following commit:

5a31f2318b8fed1f4711cb86eab6d9b679946878

So presumably I would now repeat a similar git bisect process but each step manually applying the above fix/patch somehow, so that I can get past the crash and establish when the bug reported was introduced....? Can anyone spot the git newb?! (Hey gotta start somewhere....)

Last edited 8 years ago by oviano (previous) (diff)

comment:9 by oviano, 8 years ago

Ok, I found the culprits after a very tedious git bisect process (building on an Intel NUC doesn't help!). It's these two commits:

e33d3720239314d28a48c64c1071ba9c048280d1
3444c00aab6e187360a5aa66216abeb15d26ddc6

First problem:

Two of the strings passed into av_opt_set_int do not match:

av_opt_set_int(s, "server_attached", 1, AV_OPT_SEARCH_CHILDREN);
av_opt_set_int(s, "write_index", pos, AV_OPT_SEARCH_CHILDREN);
av_opt_set_int(s, "file_size", file_size, AV_OPT_SEARCH_CHILDREN);

...should be...

av_opt_set_int(s, "server_attached", 1, AV_OPT_SEARCH_CHILDREN);
av_opt_set_int(s, "ffm_write_index", pos, AV_OPT_SEARCH_CHILDREN);
av_opt_set_int(s, "ffm_file_size", file_size, AV_OPT_SEARCH_CHILDREN);

(Isn't this a bit of a fragile way to go about things, relying on string matching with no error checking for a mismatch?)

Second problem:

When these fields are defined they have an invalid range:

static const AVOption options[] = {

{"server_attached", NULL, offsetof(FFMContext, server_attached), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_EXPORT },
{"ffm_write_index", NULL, offsetof(FFMContext, write_index), AV_OPT_TYPE_INT64, {.i64 = 0}, 0, 1, AV_OPT_FLAG_EXPORT },
{"ffm_file_size", NULL, offsetof(FFMContext, file_size), AV_OPT_TYPE_INT64, {.i64 = 0}, 0, 1, AV_OPT_FLAG_EXPORT },
{ NULL },

};

...should be...

static const AVOption options[] = {

{"server_attached", NULL, offsetof(FFMContext, server_attached), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_EXPORT },
{"ffm_write_index", NULL, offsetof(FFMContext, write_index), AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX, AV_OPT_FLAG_EXPORT },
{"ffm_file_size", NULL, offsetof(FFMContext, file_size), AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX, AV_OPT_FLAG_EXPORT },
{ NULL },

};

(Actually, I don't know what the accepted range is?)

If I make these changes then I can stream again using latest code.

Well I've learned a little "git" over the past two days, if someone can advise me on a suitable range for the two fields above then I am happy to learn "patch" and post it to the developers mailing list.

Or someone else can do it, I don't mind...

in reply to:  9 comment:10 by Carl Eugen Hoyos, 8 years ago

Status: newopen

Replying to oviano:

If I make these changes then I can stream again using latest code.

Please send your patch made with git format-patch to the development mailing list. The answers there will tell you the range if nobody else comments here.

comment:11 by Carl Eugen Hoyos, 8 years ago

Resolution: fixed
Status: openclosed

Fixed by you in a2f8beef2dfaee573f7c4a607afaa9e83fc2c1e0
Thank you for the report and the fix!

Note: See TracTickets for help on using tickets.